Introducing the F1/10 Simulator
We’ll help you get there faster
Over the last month, we have developed a lightweight 2D simulator for F1/10th racecars. It was designed to be an easy way of rapidly prototyping autonomous racing algorithms with minimal differences to racing with the actual car. It is written in C++ and built with ROS, on a Linux platform. The visualization uses RViz to show the track walls, the car, and simulated LiDar scan points.
Getting started (edited 08/02/19)
The simulator runs on Ubuntu 18.04 with ROS Melodic. To run it on a Linux, clone from our GitHub here and follow the README. We also have it set up in a Docker image here.
We are still working on full documentation for the simulator, but for now you read this post as an overview of its features and check out the README on GitHub for more details.
Features of the simulator
- publishes simulated laser scan and odometry messages
- supports both joystick and keyboard control
- uses time-to-collision for collision detection
- easy to import new maps
- obstacles can be added dynamically during simulation
ROS setup
We set up the simulator with two main objectives in mind- similitude to the real car and fast prototyping of racing algorithms.
We achieve the first by writing the simulator node such that it can be swapped out with the car itself, and if all topic names remain the same, the same exact code can be run to drive the car.
The rest of the ROS nodes are organized so that new planning algorithms can be added quickly and toggled between during driving. Each of the planning nodes (shown below* as Safety Copilot, RRT, and Pure Pursuit) listens to the sensor data (laser scan and odometry) published by the Simulator node, and publishes Ackermann Drive messages to their own specific topic. The Mux node listens to all of these topics, then takes the message from whichever planner is turned “on” and publishes it to the Simulator on the /drive topic. The Mux also listens to joystick and keyboard messages too, for manual driving.
The Behavior Controller node tells the Mux node which planner is “on” through the /mux topic. The default setting is such that each planner is mapped to a joystick button and keyboard key, and they are simply toggled on and off manually. But, since the Behavior Controller node listens to sensor messages, you could write the controller such that the car switches autonomously between planners during a race depending on these dynamic inputs.
*Note that the default public simulator only has an example “random driver” planner as an example, in addition to the joystick and keyboard. The three shown below are examples that we have implemented.
Dynamics
We use a Single Track (Bicycle) model from CommonRoad’s Vehicle Models to simulate a rear wheel drive car with Ackermann steering. The bicycle model gives a realistic simulation of steering, acceleration, and also tire slipping with only seven state space variables. It requires a few physical parameters from the car, including center of gravity location, cornering stiffness of the tires, and moment of inertia.
What’s coming next
We currently have a few main objectives for the simulator moving forward:
- IMU sensor data: The simulator will publish IMU data so that algorithms that depend on this sensor data can be tested on the simulator
- System Identification: To make the simulation as accurate as possible, we are testing various methods to fine tune the physical parameters (acceleration/deceleration profile, cornering stiffness, etc.) of users racecars
- RL support: We are adding a second mode that’s made for running Reinforcement Learning episodes — it will not use ROS so that it can be much faster than real time, and will allow users to test various RL algorithms quickly and without risk of crashing their car
- Multi-car simulation: We are developing multi-car functionality within the simulator for tasks like simulating head to head racing, or training an RL agent in a crowded racetrack
Stay tuned to the F1/10 blog for updates!
