Personal ROS 2 Rover

Overview

I am building a tracked rover as a long-term platform for autonomous navigation and mapping. The system combines a ROS 2 Jazzy computer, a Teensy 4.1 running micro-ROS, a four-channel encoder motor driver, and an LD19 2D LiDAR.

The project is intentionally labeled in progress. The drive-control path is operating, LiDAR data can be inspected in ROS 2 and RViz, and the mapping and autonomous-navigation stack is still being integrated and tested.

Problem and motivation

Competition robots taught me how to build for a fixed course and deadline. This rover gives me room to design a reusable system: one where sensing, embedded control, compute, and higher-level autonomy have stable interfaces and can evolve independently.

The broader goal is a rover-and-drone platform that can map rough areas and eventually combine ground and aerial sensor data. The current work is focused on making the rover base dependable before expanding that scope.

Current approach

ROS 2 publishes standard geometry_msgs/msg/Twist velocity commands on /cmd_vel. A micro-ROS node on the Teensy subscribes to those commands, converts linear and angular velocity into differential track speeds, and sends the resulting values to the motor controller over I²C.

The firmware also publishes a heartbeat and stops the motors when commands time out. That failsafe keeps the low-level controller responsible for a safe stop even if the higher-level ROS process disconnects.

Architecture

The current control path is deliberately layered:

1. A ROS 2 computer runs operator control, visualization, and the developing autonomy stack.
2. A serial micro-ROS agent connects the ROS graph to the Teensy.
3. Teensy firmware translates /cmd_vel into differential track commands.
4. The motor driver controls the tracked chassis over I²C.
5. The LD19 LiDAR publishes scan data for inspection and mapping work in RViz.

An NVIDIA Jetson Orin Nano is planned as the primary onboard computer as perception and autonomous navigation expand.

Challenges and tradeoffs

The project crosses several failure boundaries: Linux processes, a serial transport, microcontroller firmware, I²C, power, and mechanical hardware. I am keeping each interface observable and testing the drive base separately before depending on it for mapping.

Using standard ROS messages makes the system easier to connect to existing tools. It also requires careful scaling and safety limits when abstract velocity commands become real motor output.

Current result

The rover accepts keyboard-generated ROS 2 velocity commands through micro-ROS and drives the tracked base through the Teensy motor controller. The LiDAR workflow is documented and produces scan data for RViz. SLAM integration, odometry, transforms, autonomous navigation, and the drone connection remain active milestones.

What I am learning

This build is forcing software decisions to survive contact with hardware: device paths change, two programs can contend for one serial connection, motors need explicit timeouts, and a clean ROS graph does not guarantee correct physical motion. Documenting those details is becoming as important as implementing them.