Skip to main content

Overview

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.

How it works

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.

Missing alt text value

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.

Missing alt text value

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.

Missing alt text value

User Registration

DREM has two racer registration flows: Racers sign up independently or event staff members facilitate racer sign-up. 

Missing alt text value

How it works (continued)

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.

Missing alt text value

Leaderboard

Leaderboards allow racers to see how they rank against other competitors and are accessible to anyone with the link for the event.

Missing alt text value

Event Manager

Events (races) are stored in Amazon DynamoDB and are managed by DREM users with operator or admin group membership.

Missing alt text value

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.

Missing alt text value

How it works (continued)

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.

Missing alt text value

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.

Missing alt text value

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.

Missing alt text value

Well-Architected Pillars

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.

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.

Read the Operational Excellence 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, whichdefends 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.

Read the Security 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' architectureusingan AWS Cloud Development Kit (AWS CDK), which can help you to build microservices through domains (essentially building constructs).

Read the Reliability 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.

Read the Performance Efficiency 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.

Read the Cost Optimization whitepaper

Lambda, Amazon S3, and AWS CDK help tominimize 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.

Read the Sustainability whitepaper

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.
Open sample code on GitHub

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.