My car had sensors such as the SICK TIM 571 Series LiDAR, Razor 9DOF IMU, Intel Realsense D455 Camera, VESC 6.6, and a NVIDIA Jetson Xavier.

Our solution to navigate around the racetrack autonomously relied on mapping the track, localizing to know our current location on the track, and path-planning and control with the help of the ROS Navigation Stack. I installed and configured ROS drivers to interface with each sensor and piece of hardware on my car, including the LiDAR, IMU, Intel Realsense Camera, and VESC 6.6. I also configured a F710 Logitech Joystick, which used some code to convert joystick inputs to motor commands, enabling us to drive the car. For the actual solution, I used laser_scan_matcher, a ROS package that outputs the 2D pose of the car using the change between consecutive laser scans, and gmapping, a ROS package that produces a map of the environment using SLAM. We also used a waypoint logger script and drove around the track to generate waypoints that we could pass in as an input to move_base, a node in the ROS Navigation Stack that uses a global and local planner to output command velocities to a base controller. However, along the process, we faced issues relating to the accuracy of our odometry and setting up move_base. While we were not able to make the car run autonomously, we learned a lot and thought we’d document the challenges we faced to be successful in future races! 

Challenges:

1. Height of the LiDAR w.r.t. the black rubber walls. 

The inner part of the track is lined with black rubber walls, which we originally planned to use for mapping and localization of the car. However, when I drove the car around the track and visualized the map in RViz, the black rubber walls were not visible. We concluded the LiDAR was mounted too high on the car, resulting in the laser beams passing over the walls. This reduced our ability to accurately localize the car around the track, leaving us to rely on odometry. 

2. Noise in odometry readings. 

With the laser beams not hitting the walls, odometry became critical in our ability to accurately localize our car. However, when driving the car (slowly) from the starting line to collect odometry data, we observed a significant deviation in the 2D pose of the car after completing one lap. We tried three different sources of odometry: wheel odometry using the encoders in our brushless motor, pose estimation from laser_scan_matcher, and our IMU. All sources showed a significant difference between the starting and ending position of the car. 

What we would do differently next time:  

1. Test early, test often. 

The LiDAR problem could be avoided by measuring the height of the LiDAR mounted and the black rubber walls, which is a quick way to check if the solution is viable. 

2. Use an extended kalman filter to fuse different sensor readings for odometry. 

This would reduce the noise and increase the accuracy of our car’s ability to localize. 

Overall, I’m grateful to have gotten the opportunity to travel to Oakland to participate in the two-day hackathon, the race, and meet people in the community! I feel more confident in my programming abilities, improved my understanding of ROS and the navigation stack, and feel inspired after seeing the different methods our competitors used to navigate autonomously. It’s been a pleasure and both Harrison and I are excited for returning to the track in November!