Simulation and Tools for Global Formula Racing

Artificial Intelligence
Robotics
Hardware

With the development of an autonomous race car comes the need for an accurate simulation environment, continuous integration, and accurate tests written for the software. Our goal is to provide those for Global Formula Racing to advance all of the softwares and to develop the car so we can win competitions. There are three components that were worked on throughout the year. Simulator core, Devops, and testing. Simulator core was tasked with selecting and developing a new simulator to replace the old simulation environment. The new simulator was originally supposed to be a simulator named CARLA that was built off of unreal engine and pygame. But because of compatibility issues, we decided to go with CarMaker as our new simulator. We chose this because of its utility when creating maps to test our current models on. It also easily integrates with our data transfer pipeline, and allows us to monitor how our sensors are working with the code that we write for them. We simulate detection of the surrounding area, mostly cones which are indicators for the path that the car needs to go. We also simulate the software that we write for controlling the actual car. The reason for this is we need to get an idea of how the car will act with the current software on it, before the car is even built. That way once it is built, we upload the software and can immediately begin making sure the car behaves the same way it does in simulations. Devops was responsible for creating a system to automatically run and test the simulator. When new code is add to GitHub it first needs to be tested to ensure it is fully functional. GFR had been using CI tools for Atlassian, but decided to switch to open source tools. Since the simulator requires a lengthy configuration process the entire build environment was virtualized in a docker container for fast replication. To test new code, the branch is pulled into a docker container by the Jenkins server. Once the build is complete the results are returned to the developer. Additionally, Jenkins can be used to run tests on the simulator in order to validate changes to the car itself. This is particularly helpful since physical testing can not be done on the car most of the year. Being able to test the car year round will provide more provide more data and greater opportunity for optimization of the autonomous system. Testing is geared towards data flow management and storage management. We wanted to make sure that the output from the simulator could be translated into accurate data that would be useful for the team. In addition, creating an effective framework testing method is to have data classification of each output from the system. The classification of data must be implemented in the back-end of the system and built into the GFR server (ROS server). We also implement new data interfaces to generalize all data types from other teams to avoid confusion and will be documented neatly for future team members. Furthermore, noise nodes are added into each message type to provide accurate realistic data that could be compared with the ground truth of the actual readings.

0 Lifts 

Artifacts

Name Description
Expo Poster Poster that we created for the spring 2020 COE expo   Download
Functionality presentation During winter 2020 we created a current functionality presentation for the position that we were in and where we wanted to go.   Link
Project Archive A paper of every single piece of documentation, research, diagrams, and just about anything else that was done over the year.   Download
GFR website Global Formula Racing's website   Link
Design Presentation Design presentation done in winter term   Download