Software repository for a distributed ROS 2 rover system built around Unitree LiDAR L1, gas sensing, and autonomous navigation. This repository focuses on the rover software stack only:
- Arduino Mega motor and gas sensor code
- Raspberry Pi 5 bridge and sensor-side scripts
- ROS 2 Jazzy workstation navigation, mapping, and visualization stack
Here is the main repository link
LiDAR Scout Rover is a multi-computer robotics system designed to:
- drive a tank-style rover with ROS 2 velocity commands
- estimate motion with LiDAR-inertial odometry
- build a live map of the environment
- avoid obstacles while navigating to goals
- publish gas sensor readings from the embedded layer
The software is split across three compute layers:
Arduino Megalow-level motor control and gas sensor samplingRaspberry Pi 5LiDAR publishing, IMU publishing, serial bridge to the Arduino, Cammera publishingWorkstation / Intel NUC / laptopPoint-LIO, Nav2, obstacle processing, RViz, and the main autonomy stack
The current working version in this repository is
Version 3 uses:
- native Point-LIO local odometry behavior
slam_toolboxmap correction during live operation- a 360-degree point-cloud obstacle pipeline for Nav2
- tank-drive tuned Nav2 control parameters
This is the version that tested best as a complete software path in the rover project.
- Arduino receives motor commands over serial
- Arduino controls two DC motors through the motor driver shield
- Arduino reads gas sensor raw values and sends them back to the Pi
- Pi 5 runs the Unitree LiDAR driver
- Pi publishes:
/unilidar/cloud/unilidar/imu
- Pi bridges
/cmd_velto the Arduino motor serial protocol - Pi runs the Camera node
- Pi publishes:
/image_raw
- Point-LIO provides the local motion estimate
- custom bridges normalize odometry and TF for Nav2
- point-cloud processing nodes generate:
- filtered obstacle views
- a 360 obstacle cloud for Nav2
- safety / proximity responses
- Nav2 performs path planning and local control
- RViz is used for live visualization and operator interaction
ROS 2 JazzyPoint-LIONav2slam_toolboxpointcloud_to_laserscanPCLRViz2
MEGA/Arduino Mega motor and gas sensor codePI 5/Raspberry Pi bridge and robot-side scriptsDOCS/diagrams, defense notes, tuning guides, papers, and architecture writeupsDOCS/metrics_logs/cpu_comparison_report.md
The Version 3 stack is centered around these files:
/ws_lsr_nav2_v3/src/lsr_nav2/launch/rover_nav2_v3.launch.py/ws_lsr_nav2_v3/src/lsr_nav2/config/nav2_v3_params.yaml/ws_lsr_nav2_v3/src/lsr_nav2/config/slam_toolbox_v3_online_async.yaml/ws_lsr_nav2_v3/src/lsr_nav2/rviz/rover_nav2_v3_view.rviz
Important supporting files:
/ws_lsr_nav2_v3/src/lsr_nav2/src/nav2_obstacle_cloud.cpp/ws_lsr_nav2_v3/src/lsr_nav2/src/advanced_proximity_guard.cpp/ws_lsr_nav2_v3/src/lsr_nav2/src/cmd_vel_mux.cpp/ws_lsr_nav2_v3/src/lsr_nav2/src/odom_retimestamp_bridge.cpp/ws_lsr_nav2_v3/src/lsr_nav2/src/lidar_retimestamp_bridge.cpp
source /opt/ros/jazzy/setup.bash
ros2 launch unitree_lidar_ros2 launch.pycd ws_pointlio
source ~/ws_pointlio/install/setup.bash
ros2 launch point_lio mapping_unilidar_l1.launch.py rviz:=falsesource /opt/ros/jazzy/setup.bash
source /home/ros2/ws_pointlio/install/setup.bash
source /home/ros2/ws_lsr_nav2_v3/install/setup.bash
ros2 launch point_cloud_processing rover_nav2_v3.launch.pysource /opt/ros/jazzy/setup.bash
source /home/ros2/ws_lsr_nav2_v3/install/setup.bash
ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -r /cmd_vel:=/cmd_vel_teleopros2 run v4l2_camera v4l2_camera_node --ros-args \
-p video_device:="/dev/video0" \
-p image_size:="[640,480]" \
-p output_encoding:="rgb8"
Compared with earlier rover software branches, V3 improves:
- obstacle awareness around the full rover body
- long-run map consistency
- local control tuning for a tank-drive platform
- separation between raw LiDAR data, filtered obstacle data, and navigation control
Odometry drift is the gradual accumulation of error in a robot’s estimated position and orientation over time. In mobile robotics, this causes the reported pose to slowly diverge from the rover’s true position, even when the system appears to be functioning normally.
The GIF above shows version 2 with odometry drifting when Stationary.
The GIF above shows version 2 with odometry drifting when Moving.
The figure above shows IMU orientation data from the /unilidar/imu topic visualized in PlotJuggler.(Moving)
Even while the rover was stationary, the signals showed high-frequency oscillations and slow drift over time.(Stationary)
This behavior is consistent with vibration coupling from the spinning LiDAR assembly into the built-in IMU. Because the LiDAR physically rotates during operation, mechanical vibration from the internal motor can be transferred directly into the IMU measurements. This produces high-frequency oscillations that appear as pitch and roll jitter even when the rover is not moving. Since the IMU is integrated inside the LiDAR unit, small imbalances in the rotating mechanism may also introduce a persistent bias. Over time, that bias can be interpreted by the odometry or state-estimation pipeline as slow motion or rotation, which contributes to yaw drift and instability in the estimated pose.
As a result, the rover may appear to “shiver” in RViz through /odom or /tf despite remaining physically stationary. To reduce the long-term impact of this effect, map-based correction was integrated in Version 3 so that localization could be periodically realigned against the environment rather than relying only on odometry.
Potential Fixes
Mechanical damping: Use rubber vibration isolators between the LiDAR mount and the rover chassis to reduce the transmission of motor-induced vibration into the frame and IMU.
Zero-velocity updates: Configure the state-estimation system to detect when the rover is stationary so that IMU drift can be suppressed or weighted less heavily while the wheels are not moving.
Additional filtering or tuning: Tune the odometry or sensor-fusion pipeline to better reject the dominant vibration frequency and reduce the effect of IMU noise on /odom.
This repository reflects the rover software as developed and tested during the project.
The main working autonomy path is the live V3 navigation and mapping configuration. Some experimental follow-on work, such as saved-map localization refinements, is still under development and should be treated as secondary to the main V3 flow above.
Randy Rodriguez
LiDAR Scout Rover software architecture, ROS 2 integration, navigation, mapping, sensing, and system bringup
