Header Search Widget
Robot Open Autonomous Racing (ROAR™)

First Place Solution in 2021 Summer ROAR S2 Series

Written by Peter Peng describing his experience and solution for their first place solution in Summer 2021 ROAR S2 Series Competition. 

Team Name: High School Rookies
Team Members: Peter Peng, Rooney Xu, Charlie Sun, Amanda Chiang, William Situ

Table of Contents

Overview

For the 2021 Summer Competition, our team had the opportunity to compete in the ROAR Competition. Our team consisted of an old group that had competed in the inaugural season of this competition, and newly added members. Inside the ROAR S1 Series Competition hosted by University of California – Berkeley, the goal was to create a python-based autonomous AI code that could complete the course in the fastest time possible in a simulation environment.

The map used for the Summer 2021 Competition was larger and harder overall to code compared to the Inaugural season

Introduction

We believe that our method is the simplest way to make an effective code since we did not have too much coding experience. The original code works on a vehicle that uses a PID Controller/Agent to track the vehicle and a waypoint data set that is used to create a pathway for the vehicle. From the base code, we recommend to follow our two different ways of improving the overall code:

  1. Creating a new waypoint text file that optimally minimizes the amount of distance the car has to travel. 
  2. Changing the PID k values to smooth the car’s throttle and steering. 

By reading the blogs made by the previous contestants and winners of the S1 series, we were able to implement important improvements to our code.

We will just split the blog into two different sections: tweaking, and testing. 

Tweaking

We will start off with the first statement, “Creating a new waypoint text file that optimally minimizes the amount of distance the car has to travel.” This problem can be attributed to the data waypoint set that was given to everyone with the base code. The waypoints provided left room for optimization with sharper turns, straighter lines, and much more. To fix this, it is recommended to utilize a waypoint generating agent already provided called ROAR/agent_module/special_agent/waypoint_generating_agent.py. To utilize this, simply import the custom waypoint generating agent into runner_sim.py, and change the agent value from PIDAgent to WaypointGeneatig Agent, while also replacing the manual_control from “False” to “True”

Once you run runner_sim.py, this will allow you to personally control the car and create a set of waypoints that is based on how you drive. Take multiple tries to get the perfect waypoint and it will all be saved to the data/output folder.  

Next, for the second question, that is a problem with the PID values. We had tweaked these 3 Files:

  1. Pid_config.json under ROAR_sim -> configurations
  2. Simple_waypoint_local_planner_config.json under ROAR_sim -> configurations
  3. PID_controller.py under ROAR -> Control_module

These three files are key to finetuning your car. The PID_config.json file contains all the K-values for your PID controller. The P.I.D acronym stands for Proportional, Integral and Derivative. To summarize what each means, The Proportional, or Kp, refers to the current value of the equation, the Integral, or Ki, refers to past values of the equation and Derivative, or Kd, refers to potential future values. We began with a clean set of values, with every value as 0.0 and began to tune the Kp value and increase it by small increments until it was smooth enough to turn, but not drastic enough to oscillate. Next, we began to tune the Kd values to smoothen out any oscillation that may be occurring. At the end of it, it should look similar to this: 

The simple_waypoint_local_planner_config.json file refers to the amount of data waypoints the car sees at a time depending on the car’s speed. This is important as if the car sees too little or too much, it can lead to the car crashing into the wall. 

Finally, the PID_controller.py file will be the most important file overall as it can directly change the throttle and steering values. Inside the code you will find an area to modify the steering_boundary, or how wide a car is able to steer. The smaller the magnitude of the steering boundary is, the less it will be able to turn. Depending on how sharp the turns are, change the values to your liking. For the summer 2021 map specifically, there was one specific sharp turn for the final one and thus, we set the boundary to (-0.1,0.1). 

Upon changing the steering boundary, we had set a way for the car to decelerate once a turn was coming. To accomplish this, we set up an if statement that grabs the absolute value of the steering boundary and the vehicle speed, and if it passes those requirements, the throttle will be set to -1 and thus, lose speed.

Another piece of advice that was helpful for us, was the code, “next_waypoint.location.” What this does is to get the next waypoint from the data waypoint set that the PIDAgent utilizes. This allows people to hardcode the car’s throttle and steering depending on the map. For this map specifically, I had utilized it to maintain the throttle at a stable point of 0.95. Though this is not the max value of 1, it was used in order to keep the car stable due to the sharp turns overall. 

Testing

Upon finishing the initial coding, the process of testing began which took around two weeks to fine tune and tweak the code to guarantee the car crashes minimally. One thing to recommend is to turn on the Synchronized mode setting which matches the client’s FPS to the server’s FPS. This helps reduce the variability of a better computer affecting the overall performance significantly and helps you guarantee it will work on other computers. 

Upon multiple testings, we had discovered occasional errors that could only be found from hours of testing and leaving the simulation on running. One tip is to continuously run your code and make sure it has at least a 95% chance of working. 

Make sure to utilize the testing period that ROAR offers one week before the actual deadline. They will run your code on the official computer and message you with feedback / if the code actually works. Possibly everything can go wrong, but it runs fine on your computer.

We had spent around 4+ hours a week on testing the code at least to make sure the code was functional enough to work. 

Conclusion

We believe that several things can be improved on although our final product received the fastest time among high school contestants.. I believe if we had worked for more time overall, then it could be faster by changing the throttle to 1 and guaranteeing it worked. Other possible improvements include hardcoding the code to accelerate at greater intervals and decelerate only when necessary, or creating an even more efficient data waypoint.

Advantages:

  • Easy to begin even with relatively no experience in coding.
  • The car had a high possibility of reaching the finish line

Disadvantages:

  • Not as efficient as it could have been
  • Some variables were not taken into account such as the strength of the computer. 

If anyone would like to watch a quick preview of our code, it can be found here: