GPS-Denied Navigation Rover

WHAT: assembled the metal 4WD chassis, mounted the four gear motors with their Hall encoders, and wired each side's two motors in parallel to one BTS7960 full-bridge module (two modules total, one per side), giving classic skid-steer (left channel, right channel). WHY: skid-steer needs no steering servo and turns in place, which is exactly what a survey-and-verify rover wants, at the cost of wheel scrub, which is precisely the odometry problem this build exists to measure.

Each module is a full bridge built from two BTS7960 half-bridges: each side gets an RPWM/LPWM pair (forward/reverse PWM) plus R_EN/L_EN enables. I verified motor polarity and encoder direction per channel with a small pigpio test script before anything touched ROS, a mislabelled encoder pair silently corrupts odometry and is miserable to debug later.

motor_test.py, spin each side slowly, print encoder counts

import pigpio, time
pi = pigpio.pi()
# BTS7960: (RPWM, LPWM) per side on hardware-PWM-capable GPIOs
LEFT, RIGHT = (12, 13), (18, 19)
for rpwm, lpwm in (LEFT, RIGHT):
    pi.set_PWM_frequency(rpwm, 20000)   # 20 kHz: above audible
    pi.set_PWM_frequency(lpwm, 20000)
    pi.set_PWM_dutycycle(rpwm, 60)      # ~24% duty, forward creep
    time.sleep(2)
    pi.set_PWM_dutycycle(rpwm, 0)

What can go wrong: with the common ground between the BTS7960 and the Pi missing or loose, the PWM reference floats and the motors twitch randomly. I verified with a multimeter continuity check from driver B- to Pi GND before first power-up, and confirmed each side spins forward for a positive command.

WHAT: the Li-ion pack feeds two fused branches, one through the latching e-stop to the BTS7960 motor input, one through a DC-DC buck producing a clean 5 V/5 A rail for the Pi 5, LiDAR, IMU, and camera. WHY: a stalled 4WD drivetrain pulls many amps and drags an unprotected shared rail down with it; the instant the Pi browns out, your estimator dies and the log with it. Separating the rails is the single most important reliability decision on the build.

The e-stop is a physical, latching mushroom switch wired in series with the motor branch only. Press it and the wheels are dead while the Pi keeps logging and can still be SSH'd into, which is what you want for post-incident forensics. Every test run starts with an e-stop check and a clear test area.

RAIL CHECK, under-voltage flags before and during runs

vcgencmd get_throttled        # bit 0 set = under-voltage detected now
dmesg | grep -i voltage       # kernel log of brownout events
vcgencmd pmic_read_adc         # Pi 5: reads the actual 5 V input rail (measure_volts core reads the SoC core rail, not the supply)

How I verified: brief 2-3 second stalls of all four motors against a blocked wheel on a current-limited bench supply while watching vcgencmd get_throttled in a loop, the throttled flags stayed at 0x0, meaning the logic rail never dipped. Before the rail split, the same test tripped under-voltage within seconds. Stall testing is done brief and current-limited only: stalled motors get hot fast and a stalled drivetrain across a battery is a fire risk, never run this against the Li-ion pack directly.

WHAT: Ubuntu 24.04 Server (64-bit) flashed to a high-endurance microSD, then ROS 2 Jazzy from the official apt repository. WHY: Jazzy is the current LTS ROS 2 release and pairs natively with Ubuntu 24.04 (noble); staying on the supported pairing means every package I need, robot_localization, slam_toolbox, Nav2, installs from binary debs instead of source builds on an ARM board.

I install ros-jazzy-ros-base (headless, no desktop GUI) because the rover runs without a monitor; RViz runs on the laptop over the network with a shared ROS_DOMAIN_ID.

INSTALL, ROS 2 Jazzy on Ubuntu 24.04 (noble)

sudo apt update && sudo apt install -y curl gnupg lsb-release
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \
  -o /usr/share/keyrings/ros-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] \
  http://packages.ros.org/ros2/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/ros2.list
sudo apt update
sudo apt install -y ros-jazzy-ros-base python3-colcon-common-extensions python3-rosdep
sudo rosdep init && rosdep update
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc

How I verified: ros2 run demo_nodes_cpp talker on the rover and the matching listener on the laptop over Wi-Fi, if messages flow, the install, the network, and the domain configuration are all good before any robot code exists.

WHAT: wrote the robot_description URDF for the chassis, base_link at the geometric center, four wheel links at measured offsets, imu_link at the BNO085's physical location, laser_link at the LiDAR puck's rotation center. WHY: the EKF, the scan matcher, and SLAM all fuse data through TF transforms; if laser_link is 5 cm off its real position, every fused estimate inherits that bias and it shows up as a mystery drift that no amount of covariance tuning fixes.

Every offset in this file was measured on the physical robot with calipers, not copied from the chassis listing. The listing lies; the calipers don't.

urdf/rover.urdf (core frames, offsets measured on the bench)

<robot name="gps_denied_rover">
  <link name="base_link"/>
  <link name="laser_link"/>
  <joint name="laser_joint" type="fixed">
    <parent link="base_link"/>
    <child link="laser_link"/>
    <origin xyz="0.10 0.0 0.18" rpy="0 0 0"/>
  </joint>
  <link name="imu_link"/>
  <joint name="imu_joint" type="fixed">
    <parent link="base_link"/>
    <child link="imu_link"/>
    <origin xyz="0.02 0.0 0.09" rpy="0 0 0"/>
  </joint>
  <!-- left_wheel_joint / right_wheel_joint: continuous, at measured
       wheel_separation/2 = +/-0.16 m, radius 0.065 m -->
</robot>

How I verified: ros2 run tf2_tools view_frames generates a PDF of the live TF tree, I checked every frame appears under base_link with the measured offsets, and in RViz the laser scan overlays cleanly on walls when the rover rotates in place (a wrong laser offset makes the scan smear in an arc).

WHAT: brought up the ros2_control framework with diff_drive_controller commanding the motors through a custom hardware interface that exports PWM duty to the BTS7960 through the Pi 5's hardware PWM channels (GPIO 12/13 and 18/19 via /dev/pwmchip; pigpio does not support the Pi 5's RP1), and reads the four encoder channels back as wheel joint states via gpiod. WHY: diff_drive_controller gives me a calibrated /odom topic and a /cmd_vel interface for free, the same interface Nav2 expects, as long as wheel_separation and wheel_radius are honest.

Two of the four wheels per side share one joint in the controller config (left pair as one virtual wheel, right pair as one); both encoders on a side are averaged in the hardware interface, which dampens single-encoder glitches.

config/controllers.yaml, diff_drive_controller parameters

controller_manager:
  ros__parameters:
    update_rate: 50
    joint_state_broadcaster:
      type: joint_state_broadcaster/JointStateBroadcaster
    diff_drive_controller:
      type: diff_drive_controller/DiffDriveController

diff_drive_controller:
  ros__parameters:
    left_wheel_names: ["left_wheel_joint"]
    right_wheel_names: ["right_wheel_joint"]
    wheel_separation: 0.32      # measured, then calibrated (see Run 2)
    wheel_radius: 0.065         # measured with calipers
    publish_rate: 50.0
    # NOTE: encoder ticks (1200/rev after x4 quadrature decoding) are a parameter of
    # the custom hardware interface that converts ticks to radians, NOT of
    # diff_drive_controller, which only takes wheel_radius and wheel_separation.
    odom_frame_id: odom
    base_frame_id: base_link
    enable_odom_tf: false       # the EKF owns odom->base_link

How I verified: ros2 control list_controllers shows both controllers active, then ros2 topic pub /cmd_vel geometry_msgs/Twist ... at 0.2 m/s with the wheels off the ground while watching ros2 topic echo /odom, reported velocity matched the command and stopped cleanly at zero. enable_odom_tf: false matters: two publishers fighting over odom->base_link (controller and EKF) causes TF frame fighting and a robot that teleports in RViz.

WHAT: wired the BNO085 breakout over UART (Pi 5 /dev/serial0, GPIO 14/15) with I2C as fallback, and publish sensor_msgs/Imu from a small node I wrote wrapping the Adafruit CircuitPython BNO08x library over the SHTP protocol. WHY: the BNO085 does sensor fusion on-chip, it outputs rotation-vector orientation already filtered against gyro drift, which at this price point is far better than anything I would integrate from raw gyro rates on the Pi.

The BNO085's mode is selected by strapping pins: PS1 high with PS0 low selects UART-SHTP (3 Mbit/s); PS1 high alone does not select anything by itself, and PS1 low with PS0 high gives the simplified UART-RVC mode, a 100 Hz heading-only stream, not full SHTP. A udev rule gives the port a stable name so the node never breaks when USB devices enumerate in a different order.

/etc/udev/rules.d/99-rover.rules + node bring-up

# stable device names regardless of enumeration order
KERNEL=="ttyAMA10", SYMLINK+="imu"
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", SYMLINK+="lidar"

pip3 install --user adafruit-circuitpython-bno08x
ros2 run rover_bringup bno085_uart_node --ros-args \
  -p port:=/dev/imu -p frame_id:=imu_link
ros2 topic hz /imu/data     # expect a steady 100 Hz

What can go wrong: the first bring-up published garbage because the breakout shipped with PS1 floating and was actually in I2C mode, the UART port stayed silent and my node timed out. Fixed by soldering the PS1 jumper, then verified by rotating the rover 90 degrees by hand against a square and confirming the published yaw moved by 1.57 rad, not by "about" 90 degrees.

WHAT: the LD19 2D LiDAR (360-degree triangulation scanner, 12 m class range on high-reflectivity targets, less on dark ones) connects through its UART-to-USB adapter board and publishes sensor_msgs/LaserScan on /scan via the vendor's ROS 2 driver. WHY: LiDAR is the only sensor on the rover that observes the world rather than the wheels, wheel odometry and IMU are both proprioceptive and both drift, while scan matching against static walls gives an external reference that arrests that drift.

One rover gets the LiDAR first; the second rover runs encoder+IMU-only until the aiding comparison runs are done, which conveniently isolates the LiDAR's contribution as an experimental variable.

DRIVER, ldlidar_stl_ros2 build and launch

cd ~/ros2_ws/src
git clone https://github.com/ldrobotSensorTeam/ldlidar_stl_ros2.git
cd ~/ros2_ws
rosdep install --from-paths src -y --ignore-src
colcon build --packages-select ldlidar_stl_ros2
source install/setup.bash
ros2 launch ldlidar_stl_ros2 ld19.launch.py   # port_name:=/dev/lidar
ros2 topic hz /scan                           # expect ~10 Hz

How I verified: placed the rover in a corner of the room, echoed /scan ranges at the four cardinal angles, and compared against a tape measure, readings agreed within the sensor's stated tolerance. A scan that looks plausible but is rotated 180 degrees is the classic silent failure here, which is why step 04's frame verification matters.

WHAT: the robot_localization package runs an Extended Kalman Filter (ekf_node) fusing wheel odometry (x and yaw velocities) with the BNO085's fused orientation and angular velocity, publishing the odom->base_link transform on /odometry/filtered. WHY: the encoders are good at short-range translation but blind to slip; the IMU is excellent at heading but can't measure translation at all. The EKF is where each sensor covers the other's blind spot, with honest covariances so the filter knows how much to trust each input.

The tuning principle I follow: trust the IMU for heading (its yaw is drift-corrected on-chip), trust the encoders for short-range translation, and let the covariance grow when inputs disagree instead of forcing consistency. Over-tight covariances are how you get a filter that is confidently wrong.

config/ekf.yaml, robot_localization EKF (2D mode)

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    publish_tf: true
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    odom0: /odom
    odom0_config: [false, false, false,
                   false, false, false,
                   true,  false, false,
                   false, false, true,
                   false, false, false]
    odom0_differential: false
    odom1: /odom_rf2o
    odom1_config: [false, false, false,
                   false, false, false,
                   true,  false, false,
                   false, false, true,
                   false, false, false]
    odom1_differential: false
    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, true,   # fused yaw orientation
                  false, false, false,
                  false, false, true,   # yaw rate
                  false, false, false]
    # false: imu0_config fuses no linear acceleration, so there is nothing to de-gravitize
    imu0_remove_gravitational_acceleration: false
    # process_noise_covariance is a 15x15 matrix (x,y,z,roll,pitch,yaw,v...,a...); diagonal below, starting point, tuned per Run 3
    process_noise_covariance: [0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05, 0.0, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05, 0.0, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.08, 0.0, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0,
                               0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01]

How I verified: drove the rover in a tight square by teleop and watched /odometry/filtered versus raw /odom in RViz, the fused estimate should track the raw odometry closely on good floor and diverge gracefully (not snap) when I deliberately drag one wheel. I also checked ros2 topic echo /diagnostics for the EKF's own warnings about missing or stale inputs.

WHAT: two additions on top of the EKF. First, rf2o_laser_odometry (RF2O, dense range-flow scan-to-scan matching) publishes a LiDAR-based odometry estimate that becomes a third EKF input. Second, slam_toolbox runs in online async mode to maintain a map and the map->odom correction. WHY: on a skid-steer chassis, wheel slip is not an edge case, it is every turn. RF2O measures actual motion over the ground from the scans themselves, so when the wheels lie, the filter has a witness that doesn't.

SLAM Toolbox's job is the map frame: odom is smooth but drifts, map is globally consistent but jumps at loop closures. Keeping both is standard practice and exactly how the published research stacks it.

AIDING, install and launch scan matching + SLAM

sudo apt install -y ros-jazzy-slam-toolbox
# RF2O is not packaged for Jazzy on apt, so clone the ros2 branch into the
# colcon workspace and build it from source:
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws/src
git clone -b ros2 https://github.com/MAPIRlab/rf2o_laser_odometry.git
cd ~/ros2_ws
source /opt/ros/jazzy/setup.bash
colcon build --symlink-install
source install/setup.bash
ros2 launch rf2o_laser_odometry rf2o_laser_odometry.launch.py \
  publish_tf:=false 'init_pose_from_topic:=""'
# rf2o publishes /odom_rf2o -> added as odom1 in ekf.yaml (x, yaw velocities).
# publish_tf:=false is load-bearing: RF2O defaults to publishing odom->base_link,
# which would fight the EKF's own transform. One publisher per TF edge, always.
# init_pose_from_topic defaults to a sim-only topic that never arrives on a real
# robot; empty starts the node at the origin instead of waiting forever.
ros2 launch slam_toolbox online_async_launch.py \
  slam_params_file:=~/ros2_ws/src/rover_bringup/config/slam.yaml

What can go wrong: RF2O diverges in featureless environments (a long blank wall or open field gives scan matching nothing to lock onto), silently feeding the EKF confident garbage. Mitigation: its input gets a larger covariance than the wheel odometry, so the filter degrades toward encoder+IMU behaviour instead of chasing the scan matcher. Verified by watching /odom_rf2o freeze while driving parallel to a blank wall, exactly the failure I expected, caught before it cost me a dataset.

WHAT: the u-blox M9N logs a GNSS track over a known loop (measured on the ground with markers) as a reference track, published on /fix by the nmea_navsat_driver but never subscribed by the estimator. Once fix quality is stable, I switch GNSS off on my own receiver, stopping the receiver's navigation output with a UBX command, and the rover keeps driving on odometry + IMU + LiDAR. WHY: this is the whole point of the build. Because the estimator never sees GNSS in either phase, the cut simulates the denied condition; after the cut there is no truth receiver anymore, so drift is scored by loop closure, the distance between the EKF's estimated end pose and the surveyed start marker, with the M9N reference validating the pre-cut segment. There is zero ambiguity about where each number came from.

Every run is recorded with ros2 bag record, and a Python analysis script (rosbag2_py + matplotlib) produces the drift plots: error versus distance, with and without LiDAR aiding. Dataset, URDF, EKF config, and plots get published together so the numbers are reproducible, not just claimed.

LOG, record a drift run, then analyze offline

ros2 bag record -o drift_run_03 \
  /odom /odometry/filtered /odom_rf2o /imu/data /scan /fix /tf /tf_static
# analysis: aligns EKF pose and GNSS truth by timestamp, plots error vs distance
python3 analysis/drift_plot.py --bag drift_run_03 \
  --truth /fix --estimate /odometry/filtered --out drift_run_03.png

What can go wrong: a drift plot is only as honest as its ground truth, an M9N in single-point mode wanders by metres on its own, which would poison the comparison. Mitigation: I only start a run once the receiver reports a stable 3D fix with low estimated error, and I cross-check the GNSS track against the surveyed ground markers at the cut point. If the two disagree before the cut, the run is discarded, not explained away.