😵Competition Skeleton FAQs
Last updated
Last updated
Starting from Fall 2023, ROAR Competition will be running on Monza Map with the ROAR_PY suite as the underlying control system.
If you experience any issues while developing solutions for the ROAR Competition, feel free to reach out to us by submitting an issue in the competition skeleton repo.
In this page we will provide you with useful resources that gets you familiar with the competition infrastructure code and how your solution code is scheduled on the CPU during evaluation.
The ROAR_PY control suite is an innovative control suite that supports Python async features, gymnasium - the common Reinforcement Learning API interface standard, and streaming control commands over communication protocols like websockets.
The core APIs of ROAR_PY are receive_observation(), get_last_observation(), and apply_action(). Students should find control codes written in ROAR_PY extremely easy to understand and implement if we trim away the PID / pure-pursuit mathematics.
Before we start, it might be good to read through some coordinate definitions for ROAR_PY control suite. Please browse through the tabs provided in the "Coordinate System" page to fully understand the local/global coordinate of different objects.
It might also be benefial to read about way point structures provided to you
Now, it is very important to note that the x axis of the vehicle/waypoint's local coordinate always points forward, the y axis of the vehicle/waypoint's local coordinate always points to the left of the vehicle, and any z axis in ROAR_PY points upwards.
Great, now you have a good basic understanding of how coordinate systems in ROAR_PY work, you should skim through the example submission.py file to gain a better understanding on how the example pure-pursuit PID controller work. If you have problem understanding some API calls, always refer back to the ROAR_PY documentation below.
If you have thoroughly read through ROAR_PY documentation and still have trouble understanding certain concepts needed to write your solution, submit an issue in the competition skeleton repository and we will be able to help you (and potentially you can help us polish our documentations).
Codes contained in submission.py are merely a fraction of the code that we run during evaluation.
There are also competition daemon codes running to ensure that a competition rule violation will be detected. Part of the competition daemon codes will also take responsibility of spawning the vehicle and looping through the lifecycle of the competition rules and ticking the submission codes.
Therefore in submission.py, you may not use receive_observation() calls because the sensor datas are already refreshed each timestep by the competition daemon. You can use get_last_observation() or get_last_gym_observation() to fetch your data from your sensors.
You may feel free to use any sensors that are passed into the __init__ function, which is saved for you as self.SENSOR_NAME.