For our final project, we joined with Team 5 to create a team of 4, which we called Team 5.5. We've built everything separately except for the vehicle-to-vehicle communication final project. You can find much of the same final project info on their page as well.
Zoey Huang - Aerospace Engineering
Jason Almeda - Computer Engineering
Liam Fowler - Mechanical Engineering
Johannes Diehm - UCSD Extension
Donkey Car Laps
Our goal was to develop a system of nodes in ROS to enable vehicle to vehicle communication between 2 cars. We took inspiration for our project from the "Black Ice" phenomenon, whereby cars in icy conditions slide out and crash due to difficult-to-see ice on the road. By allowing cars to communicate with one another, a car involved in a crash could tell other cars that there is an issue on the road ahead, allowing the cars to slow down or stop to avoid the road hazard.
Our project consists of two cars: the lead car and the follower car. If the lead car should crash, it shall publish a message to the follower car, which causes it to stop, thus preventing that the follower car from crashing into the same obstacle. For sensing the crash, we use the accelerometer sensor on an Openlog Artemis IMU in the lead car, which we initialized by adding the device when creating the Docker Container with the robot image. If a specific deceleration threshold is met (i.e. 10 milli g), the car publishes a message to a connected following car. If the follower car receives this specific message, it should cause an immediate stop.
In order to prevent hackers from slowing down or stopping the follower car without a road hazard being present, we also include a unique security string published by the lead car and subscribed to by the follower car. If the security string being sent to the follower car before a stop command does not match the expected security string stored on the follower car, then the follower car will not accept a message to stop, and will continue to move around the track.
In our case, we set the lead car to be the "Master" roscore, to which we connected the follower car (so that both cars use the same roscore). Both cars run many of the same nodes, clients, and servers as described in Dominic Nightingale's Simple ROS framework. However, in order to ensure the topics being published and subscribed do not cross cars (i.e. camera on one car is used by the lane guidance on the other car), we gave the each topic with the potential to cross over a new unique identifier.
You can find the GitHub repository to our code here: https://github.com/LiamEFowler/ECE-MAE-148-Group5.5-Black-Ice
In summary, we added a talker node on the lead car, a listener node on the follower car and the according launch files. In the talker node, we implemented a module to read the output of the IMU, filter it for the axis of acceleration that would give us frontal deceleration to detect crashes, and ignore acceleration due to road vibrations or centripetal acceleration while going around corners. After comparing this acceleration value to an acceleration expected in a crash (i.e. how an airbag works), the talker node publishes the security code and a message to continue running or to stop if the threshold was met. In the listener node we implemented a subscriber that read the security code and the message to stop or continue. If the security code was correct and a stop command was sent from the talker node, the listener node would publish a stop command to the lane guidance node. If the stop command was received by the lane guidance node, that node would publish a zero throttle to the ESC, stopping the follower car.
Files Made: - talker_node.py
Files Modified: - lane_guidance_node.py (follower car only)
- ros_racer_launch.launch (both cars)
Final Presentation Slides:
Currently, the two cars are connected via ssh on the same Wifi network (UCSDRoboCar5GHz). Since this works only while on Wifi, a next step would be to implement an off-network communication system using ESP32s connected to each car's Jetson Nano SBC.
The system is also not particularly robust due to inconsistencies reading the serial data from the IMU and running the ROS packages. In the future, it would be helpful to make this system more reliable and easier to use.
Instructor - Prof. Jack Silberman
TA - Dominic Nightingale
TA - Haoru Xue