[SEO Subhead]
This Guidance demonstrates how to deploy and configure DeepRacer Event Manager (DREM), a set of tools that simplify the hosting of AWS DeepRacer events. DREM automates multiple event operations including user registration, model loading, leaderboard updates, timing, and car management. It allows events to be produced faster and with less effort, less staff, and less technological resources to get race cars on the track, faster!
AWS DeepRacer is an autonomous race car, 1/18th the size of a vehicle, driven by machine learning and designed to test reinforcement learning (RL) models when racing the cars on a physical track. Using cameras to view the track and an RL model to control throttle and steering, the car shows how a model trained in a simulated environment can be transferred to the real-world.
Please note: [Disclaimer]
Architecture Diagram
Overview
This architecture diagram provides an overview of how to automate the multiple operations that are entailed for AWS DeepRacer events. These events include website hosting, access management, race management, model management, fleet management, and car management. For architecture diagrams highlighting these events, open the dropdown options below.
Step 1
Event staff, racers, and spectators access the web applications hosted in AWS with the AWS DeepRacer Event Manager (DREM) through a web browser.
Step 2
DREM consists of three different frontends built using React.
Step 3
The backend is shared by all frontends and built using the serverless components: AWS Lambda, AWS AppSync, Amazon DynamoDB, and Amazon EventBridge.
Step 4
The DREM backend is composed of a suite of modules, each focusing on a specific set of features. The modules own their own API definitions and AWS infrastructure.
Step 5
Website Hosting: Hosting for the set of web-based applications that comprise up DREM.
Step 6
Access Management: Allows registered users of DREM to be added and removed from groups, which allows them to access more privileged functions.
Step 7
Race Manager: Records and manages data for races and events.
Step 8
Leaderboard: Manages, displays, and publishes the race leaderboard used at DeepRacer events.
Step 9
Model Manager: Facilitates racers uploading models to DREM and event staff pushing those models to cars ready for racing on the track.
Step 10
Fleet Manager: Designates collections of AWS DeepRacer cars to simplify device management.
Step 11
Car Manager: Activates new cars, adding them to DREM, and then manages them.
Step 12
Each AWS DeepRacer car is connected to DREM through AWS Systems Manager.
Step 1
Event staff, racers, and spectators access the web applications hosted in AWS with the AWS DeepRacer Event Manager (DREM) through a web browser.
Step 2
DREM consists of three different frontends built using React.
Step 3
The backend is shared by all frontends and built using the serverless components: AWS Lambda, AWS AppSync, Amazon DynamoDB, and Amazon EventBridge.
Step 4
The DREM backend is composed of a suite of modules, each focusing on a specific set of features. The modules own their own API definitions and AWS infrastructure.
Step 5
Website Hosting: Hosting for the set of web-based applications that comprise up DREM.
Step 6
Access Management: Allows registered users of DREM to be added and removed from groups, which allows them to access more privileged functions.
Step 7
Race Manager: Records and manages data for races and events.
Step 8
Leaderboard: Manages, displays, and publishes the race leaderboard used at DeepRacer events.
Step 9
Model Manager: Facilitates racers uploading models to DREM and event staff pushing those models to cars ready for racing on the track.
Step 10
Fleet Manager: Designates collections of AWS DeepRacer cars to simplify device management.
Step 11
Car Manager: Activates new cars, adding them to DREM, and then manages them.
Step 12
Each AWS DeepRacer car is connected to DREM through AWS Systems Manager.
-
Website Hosting
DREM consists of a number of web-based applications, hosted using Amazon S3 and Amazon CloudFront, which are accessed by event staff, racers, and spectators.
Click to enlarge
Step 1
DREM consist of three different web apps hosted in AWS, including DREM itself, the leaderboard, and the event streaming overlays.Step 2
The frontends are protected by AWS WAF which filters malicious web traffic, helping protect the application against common exploits and bots.
Step 3
Each app has its own Amazon CloudFront distribution. CloudFront is a global content delivery network.Step 4
Each app is backed by its own private Amazon Simple Storage Service (Amazon S3) bucket. The connection between Amazon S3 and CloudFront is protected by an origin access identity (OAI).Step 5
Each Amazon S3 bucket is protected by a bucket policy so the website only can be reached through the CloudFront distribution network.Step 1
DREM consist of three different web apps hosted in AWS, including DREM itself, the leaderboard, and the event streaming overlays.Step 2
The frontends are protected by AWS WAF which filters malicious web traffic, helping protect the application against common exploits and bots.
Step 3
Each app has its own Amazon CloudFront distribution. CloudFront is a global content delivery network.Step 4
Each app is backed by its own private Amazon Simple Storage Service (Amazon S3) bucket. The connection between Amazon S3 and CloudFront is protected by an origin access identity (OAI).Step 5
Each Amazon S3 bucket is protected by a bucket policy so the website only can be reached through the CloudFront distribution network. -
Access Management
-
Access Management
-
User Registration
-
Privileged Access
-
Access Management
-
User accounts are created and stored in Amazon Cognito. Access to model management and event functionality requires an account. Leaderboards and streaming overlays are publicly accessible.
Click to enlarge
Step 1
Users access the DREM web app URL through a browser. If the user has no active login, the user is redirected to the login page.Step 2
The provided user credentials are verified with Amazon Cognito and JSON Web Tokens (JWTs) are returned. The token data includes which Cognito user group the logged-in user belongs to.Step 3
When the DREM web app accesses the AWS AppSync API, the Cognito JWT is added to each request.
Step 4
Cognito verifies the JWTs.
Step 5
Access to the various AWS AppSync API endpoints is restricted by Cognito groups.Step 6
The leaderboard and streaming overlays, both open to the public, have read-only access to leaderboard information. The AWS AppSync access for these websites is protected using API keys.
Step 1
Users access the DREM web app URL through a browser. If the user has no active login, the user is redirected to the login page.Step 2
The provided user credentials are verified with Amazon Cognito and JSON Web Tokens (JWTs) are returned. The token data includes which Cognito user group the logged-in user belongs to.Step 3
When the DREM web app accesses the AWS AppSync API, the Cognito JWT is added to each request.
Step 4
Cognito verifies the JWTs.
Step 5
Access to the various AWS AppSync API endpoints is restricted by Cognito groups.Step 6
The leaderboard and streaming overlays, both open to the public, have read-only access to leaderboard information. The AWS AppSync access for these websites is protected using API keys.
-
User Registration
-
DREM has two racer registration flows: Racers sign up independently or event staff members facilitate racer sign-up.
Click to enlarge
Step 1
At larger events, walk-up participants who don’t bring their own models, choose a default pre-trained model. An event staff member logs into the DREM app and browses to the user registration page to facilitate racer sign up.
Step 2
Information collected through the registration form for each racer is submitted to the AWS AppSync API.
Step 3
The AWS AppSync API verifies that the provided JSON Web Token (JWT) is valid and has access to invoke the AddUser API method.
Step 4
The user registration Lambda function creates the user in the Cognito user pool if the user does not already exist.
Step 5
Before the user is created, Cognito invokes a pre-signup Lambda trigger function which emits an EventBridge event notifying other modules that a new user has been created.
Step 6
Cognito sends an email to the newly created user with information on how to access the DREM web app.
Step 7
After following the instructions in the email, the newly created user can log into the DREM web app and upload or delete their own AWS DeepRacer models.
Note: A racer can also create their own user by browsing to the DREM web app and selecting signup. A user is then created in Cognito and the process follows Steps 5 and 6.
Step 1
At larger events, walk-up participants who don’t bring their own models, choose a default pre-trained model. An event staff member logs into the DREM app and browses to the user registration page to facilitate racer sign up.
Step 2
Information collected through the registration form for each racer is submitted to the AWS AppSync API.
Step 3
The AWS AppSync API verifies that the provided JSON Web Token (JWT) is valid and has access to invoke the AddUser API method.
Step 4
The user registration Lambda function creates the user in the Cognito user pool if the user does not already exist.
Step 5
Before the user is created, Cognito invokes a pre-signup Lambda trigger function which emits an EventBridge event notifying other modules that a new user has been created.
Step 6
Cognito sends an email to the newly created user with information on how to access the DREM web app.
Step 7
After following the instructions in the email, the newly created user can log into the DREM web app and upload or delete their own AWS DeepRacer models.
Note: A racer can also create their own user by browsing to the DREM web app and selecting signup. A user is then created in Cognito and the process follows Steps 5 and 6.
-
Privileged Access
-
For an event staff member to gain privileged access to DREM, their users need to belong to certain Amazon Cognito groups. DREM comes with a default admin user which is created during deployment. This admin user can then be used to grant privileged access to other members of the event staff.
Click to enlarge
Step 1
An event staff member with admin access can log into the DREM web app and browse to the groups page. There they can add or remove users from groups to change a user’s privileges. The update request is sent to the AWS AppSync API.
Step 2
The AWS AppSync API verifies that the provided JSON Web Token (JWT) is valid and has access to invoke the addUserToGroup/deleteUserFromGroup API methods.
Step 3
The Lambda resolver function calls Cognito and either adds the user to the group or removes them.
Step 1
An event staff member with admin access can log into the DREM web app and browse to the groups page. There they can add or remove users from groups to change a user’s privileges. The update request is sent to the AWS AppSync API.
Step 2
The AWS AppSync API verifies that the provided JSON Web Token (JWT) is valid and has access to invoke the addUserToGroup/deleteUserFromGroup API methods.
Step 3
The Lambda resolver function calls Cognito and either adds the user to the group or removes them.
-
-
Race Manager & Leaderboard
-
Leaderboard
-
Event Manager
-
Race Manager
-
Leaderboard
-
Leaderboards allow racers to see how they rank against other competitors and are accessible to anyone with the link for the event.
Click to enlarge
Step 1
When the leaderboard or streaming overlays are loaded, the AWS AppSync API is invoked to get all current leaderboard entries for the event.
Step 2
The Lambda function performs a query in DynamoDB for the relevant leaderboard items.
Step 3
After each race, an event staff member submits the race to the backend, invoking an Amazon EventBridge event from the race manager.Step 4
The leaderboard entry and stats are calculated for the user by a Lambda function. The new leaderboard entry is stored in DynamoDB and a GraphQL mutation to the AWS AppSync API is sent.
Step 5
The mutation invokes a subscription on the AWS AppSync API, pushing the newly added leaderboard entry to the connected leaderboards and streaming overlays.
Step 6
During a race, the time keeper page in the DREM web app regularly submits GraphQL mutations to inform other parts of the system of the current status of the race.
Step 7
The mutations invoke a subscription which the leaderboard and streaming overlay is subscribing to, thus pushing the race status info to the connected clients.Step 1
When the leaderboard or streaming overlays are loaded, the AWS AppSync API is invoked to get all current leaderboard entries for the event.
Step 2
The Lambda function performs a query in DynamoDB for the relevant leaderboard items.
Step 3
After each race, an event staff member submits the race to the backend, invoking an Amazon EventBridge event from the race manager.Step 4
The leaderboard entry and stats are calculated for the user by a Lambda function. The new leaderboard entry is stored in DynamoDB and a GraphQL mutation to the AWS AppSync API is sent.
Step 5
The mutation invokes a subscription on the AWS AppSync API, pushing the newly added leaderboard entry to the connected leaderboards and streaming overlays.
Step 6
During a race, the time keeper page in the DREM web app regularly submits GraphQL mutations to inform other parts of the system of the current status of the race.
Step 7
The mutations invoke a subscription which the leaderboard and streaming overlay is subscribing to, thus pushing the race status info to the connected clients. -
Event Manager
-
Events (races) are stored in Amazon DynamoDB and are managed by DREM users with operator or admin group membership.
Click to enlarge
Step 1
A member of the event staff logs into the DREM app and browses to the events page. On the events page, they can create a new event, update, or delete existing events.
Step 2
The request is sent to the AWS Appsync API and the item is created, updated, or deleted in DynamoDB.
Step 3
When the item is added, updated, or deleted in DynamoDB, the change is sent on the DynamoDB stream which invokes an Lambda function.
Step 4
The Lambda function generates an event and emits it to EventBridge to notify the leaderboard module of the change.
Step 1
A member of the event staff logs into the DREM app and browses to the events page. On the events page, they can create a new event, update, or delete existing events.
Step 2
The request is sent to the AWS Appsync API and the item is created, updated, or deleted in DynamoDB.
Step 3
When the item is added, updated, or deleted in DynamoDB, the change is sent on the DynamoDB stream which invokes an Lambda function.
Step 4
The Lambda function generates an event and emits it to EventBridge to notify the leaderboard module of the change.
-
Race Manager
-
Lap times are recorded for events using the race manager. Times can be recorded either manually or automatically by using a Raspberry Pi and timing strips for improved timing accuracy.
Click to enlarge
Step 1
Timekeeping: A member of the event staff logs into the DREM app and browses to the time keeper page to select the race for which they are recording the lap times. On the time keeper page, users record the lap times and submit them to AWS AppSync when the race is over.
Step 2
The request is sent to the AWS AppSync API and a race summary is calculated and stored in DynamoDB through a Lambda function.
Step 3
The Lambda function generates a new race summary event and emits it to EventBridge to notify the leaderboard module of the change.
Step 4
Race management: A member of the event staff logs into the DREM app and browses to the manage race page. On the manage race page, they can modify and delete existing races and individual lap times for a racer. Modified races are sent to AWS AppSync.
Step 5
The request is sent to the AWS Appsync API and the item(s) are updated or deleted in DynamoDB through a Lambda function.
Step 6
The Lambda function generates a new race summary event and emits it to EventBridge to notify the leaderboard module of the change.
Step 1
Timekeeping: A member of the event staff logs into the DREM app and browses to the time keeper page to select the race for which they are recording the lap times. On the time keeper page, users record the lap times and submit them to AWS AppSync when the race is over.
Step 2
The request is sent to the AWS AppSync API and a race summary is calculated and stored in DynamoDB through a Lambda function.
Step 3
The Lambda function generates a new race summary event and emits it to EventBridge to notify the leaderboard module of the change.
Step 4
Race management: A member of the event staff logs into the DREM app and browses to the manage race page. On the manage race page, they can modify and delete existing races and individual lap times for a racer. Modified races are sent to AWS AppSync.
Step 5
The request is sent to the AWS Appsync API and the item(s) are updated or deleted in DynamoDB through a Lambda function.
Step 6
The Lambda function generates a new race summary event and emits it to EventBridge to notify the leaderboard module of the change.
-
-
Model Manager
Getting models from the racers to the car is the main function of DREM. Users upload their models into an Amazon S3 bucket for storage. Event staff members can see all of the uploaded models and select specific models to send to particular cars in order to facilitate an efficient racing queue.
Click to enlarge
Step 1
Racers and staff authenticate with Cognito.
Step 2
Each racer uploads the pre-trained AWS DeepRacer models they want to test or race on the physical AWS DeepRacer car to Amazon S3 through the DREM App. Racers can also delete their models from Amazon S3.
Step 3
An event staff member selects specific uploaded AWS DeepRacer model(s) to send to a particular connected AWS DeepRacer car. Multiple cars are connected to enable cars to be prepared to race while others are racing, and ‘swap outs’ take place in the event of a crash.
Step 4
The upload request is sent to the AWS DeepRacer car through an AWS Appsync API which validates authorization with Cognito.
Step 5
The API invokes a Lambda function which generates a short lived pre-signed URL for the model, and then uses Systems Manager to send a Systems Manager Run Command to the car.Step 6
The run command processes a download script on the car, which uses the Amazon S3 pre-signed URLs to download the AWS DeepRacer model onto the car that is ready for use by the racer.
Step 1
Racers and staff authenticate with Cognito.
Step 2
Each racer uploads the pre-trained AWS DeepRacer models they want to test or race on the physical AWS DeepRacer car to Amazon S3 through the DREM App. Racers can also delete their models from Amazon S3.
Step 3
An event staff member selects specific uploaded AWS DeepRacer model(s) to send to a particular connected AWS DeepRacer car. Multiple cars are connected to enable cars to be prepared to race while others are racing, and ‘swap outs’ take place in the event of a crash.
Step 4
The upload request is sent to the AWS DeepRacer car through an AWS Appsync API which validates authorization with Cognito.
Step 5
The API invokes a Lambda function which generates a short lived pre-signed URL for the model, and then uses Systems Manager to send a Systems Manager Run Command to the car.Step 6
The run command processes a download script on the car, which uses the Amazon S3 pre-signed URLs to download the AWS DeepRacer model onto the car that is ready for use by the racer.
-
Fleet Manager
The fleet feature allows event organizers to designate a collection of cars in the DREM application. One use case is tracking cars associated with specific event hardware kits.
Click to enlarge
Step 1
The event staff can create, update, or delete a car fleet. The request is submitted to AWS AppSync.
Step 2
The request is sent through AWS AppSync using a Lambda resolver, and each fleet is stored as a DynamoDB item.
Step 3
The Lambda resolver also emits an EventBridge event to notify the car manager module of the change.
Step 1
The event staff can create, update, or delete a car fleet. The request is submitted to AWS AppSync.
Step 2
The request is sent through AWS AppSync using a Lambda resolver, and each fleet is stored as a DynamoDB item.
Step 3
The Lambda resolver also emits an EventBridge event to notify the car manager module of the change.
-
Car Manager
Event staff members use the car manager feature to add cars to DREM via car activation. It’s also used to remotely restart the AWS DeepRacer service on a car.
Click to enlarge
Step 1
Event staff complete and submit a new car activation request in the DREM Web app and submit the request to AWS AppSync.
Step 2
The activation request is sent to AWS AppSync which validates the requestor’s authorization with Cognito, and then invokes a Lambda function.
Step 3
The Lambda function creates a new AWS Systems Manager Hybrid Activation and returns a command line interface (CLI) prompt with the activation information passed back to event staff.Step 4
The Lambda function creates a new Systems Manager Hybrid Activation and returns a CLI command with the activation information passed back to event staff.
Step 5
An event staff member submits commands to remotely administer the AWS DeepRacer car, such as delete all models, restart Robot Operating System (ROS), or update tail light color. The command requests are submitted to AWS AppSync.Step 6
Commands are sent through AWS AppSync, Lambda, Systems Manager, and sent to AWS DeepRacer cars as Systems Manager Run Commands.
Step 7
Event staff members generate preformatted labels to print and affix to the cars, which aids in car identification. The request to create the labels is sent to AWS AppSync.
Step 8
The label command is sent through AWS AppSync and Lambda, which generates the label based on data retrieved from Systems Manager.Step 9
Car tagging updates, such as updating which fleet a car belongs to, arrive from the fleet manager module through EventBridge. Next, they are processed through Lambda, which updates the tags in Systems Manager.Step 1
Event staff complete and submit a new car activation request in the DREM Web app and submit the request to AWS AppSync.
Step 2
The activation request is sent to AWS AppSync which validates the requestor’s authorization with Cognito, and then invokes a Lambda function.
Step 3
The Lambda function creates a new AWS Systems Manager Hybrid Activation and returns a command line interface (CLI) prompt with the activation information passed back to event staff.Step 4
The Lambda function creates a new Systems Manager Hybrid Activation and returns a CLI command with the activation information passed back to event staff.
Step 5
An event staff member submits commands to remotely administer the AWS DeepRacer car, such as delete all models, restart Robot Operating System (ROS), or update tail light color. The command requests are submitted to AWS AppSync.Step 6
Commands are sent through AWS AppSync, Lambda, Systems Manager, and sent to AWS DeepRacer cars as Systems Manager Run Commands.
Step 7
Event staff members generate preformatted labels to print and affix to the cars, which aids in car identification. The request to create the labels is sent to AWS AppSync.
Step 8
The label command is sent through AWS AppSync and Lambda, which generates the label based on data retrieved from Systems Manager.Step 9
Car tagging updates, such as updating which fleet a car belongs to, arrive from the fleet manager module through EventBridge. Next, they are processed through Lambda, which updates the tags in Systems Manager.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
Amazon CloudWatch RUM and AWS X-Ray help you run and monitor your systems effectively, so you can gain key insights into events. For example, CloudWatch RUM helps you collect and view web application performance in near real-time. This includes page load times, errors, and user behavior. Also, it can help you to understand how the application is used, patterns of usage, and to determine when a response or change is required. Additionally, the debug information from X-Ray helps to determine when a response is required and to assist you in identifying the factors contributing to a platform issue.
-
SecurityRead the Security whitepaper
CloudFront, AWS Shield Standard, Cognito, and AWS Identity and Access Management (IAM) work in tandem to protect data, systems, and assets in a way that improves your security posture. CloudFront improves website security with traffic encryption and access controls and integrates with Shield Standard, which defends against distributed denial-of-service (DDoS) attacks at no additional charge. Also, by scoping IAM policies to the minimum permissions required, you limit unauthorized access to resources. Moreover, Cognito provides authentication and authorization for the web application, including securing the AWS AppSync APIs. Cognito also has a central location for identity verification, making it easier to manage access while reducing the requirements for multiple credentials.
-
ReliabilityRead the Reliability whitepaper
All services configured in this Guidance are monitored by Amazon CloudWatch, which collects metrics and helps you to visualize those metrics through dashboards so that you can understand the health and status of the application. CloudWatch also helps you to more easily analyze and debug distributed systems so you know how your applications and its underlying services are performing.
Additionally, you can provision highly scalable and reliable workloads through small components within a microservices' architecture using an AWS Cloud Development Kit (AWS CDK), which can help you to build microservices through domains (essentially building constructs).
-
Performance EfficiencyRead the Performance Efficiency whitepaper
Lambda, DynamoDB, and AWS AppSync collectively work to enhance the performance efficiency of your workloads. For example, Lambda provides a scalable, serverless solution to enhance the performance of the application, it can scale up and down when needed, and only consumes the necessary resources. While with DynamoDB, you get a mechanism for storing data at scale, with millisecond latency. Finally, AWS AppSync provides multiple options for data retrieval that are evaluated to ensure the most optimum way is returned for the user and the application.
-
Cost OptimizationRead the Cost Optimization whitepaper
Lambda, Amazon S3, AWS Budgets, and AWS CDK all help you to avoid unnecessary costs and maximize your return on investment. For example, Lambda functions are only billed when called, and therefore you are only paying for the minimum required compute to run the application. Also, there are multiple lifecycle policies applied to the storage within Amazon S3 that remove files based on the age of the files. Furthermore, AWS Budgets are set to ensure that costs do not go beyond what is expected, and also helps to govern usage. Finally, by utilizing infrastructure as code through AWS CDK, resources can be automatically provisioned and terminated.
-
SustainabilityRead the Sustainability whitepaper
Lambda, Amazon S3, and AWS CDK help to minimize the environmental impacts of running cloud workloads. Specifically, Lambda supports user sustainability by only scaling with user load. And by utilizing Amazon S3, the application can minimize the use of data processing and storage requirements, as the central repository of storage can be consumed by all services. Furthermore, AWS CDK allows for rapid application testing and deployment through infrastructure as code.
Implementation Resources
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.