Tank-Track Mobile Platform
Tank-Track Mobile Platform
Author: Joel Johnston Date: 2026-04-06 Domain: Robotics / Autonomy Stroke Timeline: Pre-stroke
Abstract
Tracked robot with onboard compute. Dual DC gear motors driving rubber tracks with skid-steer differential drive, Raspberry Pi 4B as main compute, ESP32 as motor controller, ultrasonic sensors for obstacle avoidance, and MPU-6050 IMU (inertial measurement unit) for orientation tracking. Carbon fiber chassis with 3D-printed brackets from the parametric OpenSCAD library. $245 total build. roboNet mesh integration makes this a mobile network node. Future: SLAM (simultaneous localization and mapping) with RPLiDAR.
Hardware
Drive System
- Motors: 2x DC gear motors, 12V, 200RPM, with quadrature encoders
- Drive type: Skid-steer differential — no steering mechanism, turning is achieved by varying track speeds
- Motor driver: L298N dual H-bridge, 2A per channel, PWM speed control
- Tracks: Rubber tank tracks, 35mm wide
- Power: 11.1V 3S LiPo 2200mAh (main), 5V 3A BEC (buck-boost for compute)
Compute Stack
- Main SBC: Raspberry Pi 4B (4GB) — navigation, sensor fusion, mesh client, user interface
- Motor controller MCU: ESP32 — receives velocity commands from Pi over USB serial, drives L298N, reads encoder feedback, runs velocity PID loop
This split keeps real-time motor control on the ESP32 (deterministic, loop time <1ms) while the Pi handles non-deterministic tasks (navigation, network, CV).
Sensors
- Ultrasonic distance sensors: HC-SR04 (3x) — front, left-front 45°, right-front 45°
- IMU: MPU-6050 (6-axis) — 3-axis accelerometer + 3-axis gyroscope, I2C
- Encoder feedback: Quadrature encoders on both motors (via ESP32)
Chassis
- Plates: Carbon fiber 3mm (custom cut, 2x — top and bottom)
- Brackets: 3D-printed PETG from parametric OpenSCAD library
- Standoffs: M3 aluminum, configurable height for different payload heights
- Payload capacity: approximately 500g on top plate
Software Architecture
ESP32 Motor Controller
Firmware responsibilities:
- Receive
{left_vel, right_vel}commands over USB serial (JSON or simple binary protocol) - Run velocity PID loops independently for each track (encoder feedback)
- Report actual velocities and encoder counts back to Pi at 50Hz
- Handle watchdog — if no command received in 500ms, stop motors (failsafe)
The ESP32 firmware is deterministic. Command-to-motor-response latency: <5ms. The Pi does not need to worry about real-time constraints.
Raspberry Pi Navigation Stack
ultrasonic sensors → obstacle map (2D grid, robot-centered)
↓
path planner (reactive avoidance)
↓
velocity commands → ESP32 → motors
↑
IMU → heading hold (Kalman filter)
encoder odometry → position estimate
Obstacle avoidance: VFH (Vector Field Histogram) — simple reactive planner. Scans ultrasonic readings, computes histogram of obstacle density by angle, finds clearest direction, steers toward it.
Heading hold: When no steering correction is needed, the Pi uses IMU gyroscope integration to maintain the commanded heading. Encoder odometry provides secondary reference. Simple complementary filter (not full Kalman — sufficient for indoor use).
roboNet Mesh Client
Pi runs the standard roboNet mesh client. The robot registers as a node with capabilities:
{
"node_type": "mobile",
"capabilities": ["drive", "ultrasonic_scan", "imu", "odometry"],
"location": "dynamic"
}
The mesh can dispatch tasks to the robot:
- Drive to coordinates (relative to home)
- Scan an area (systematic coverage pattern)
- Report sensor data on demand
Full BOM
| Component | Cost |
|---|---|
| Raspberry Pi 4B (4GB) | $55 |
| ESP32 development board | $8 |
| DC gear motors with encoders (2x) | $30 |
| L298N motor driver | $8 |
| Rubber tank tracks (pair) | $25 |
| 3S LiPo 2200mAh | $22 |
| 5V BEC (buck converter) | $8 |
| HC-SR04 ultrasonic sensors (3x) | $9 |
| MPU-6050 IMU | $5 |
| Carbon fiber plates (2x) | $40 |
| 3D-printed brackets (PETG) | $5 |
| Hardware, wiring, connectors | $15 |
| Total | ~$245 |
Autonomy Stack — Current and Future
Current: Reactive Navigation
The current implementation uses reactive navigation — no map building, no global planning. The robot responds to immediate sensor readings. Effective for obstacle avoidance in dynamic environments. Insufficient for destination navigation.
Future: SLAM with RPLiDAR
Adding RPLiDAR A1 (2D LiDAR, 360-degree, 12m range) enables:
- Mapping: build an occupancy grid of the environment while driving
- Localization: use the map to determine position (particle filter or scan matching)
- Path planning: A* or Dijkstra on the occupancy grid for destination navigation
Software stack: slam_toolbox (ROS2) or a custom lightweight SLAM implementation. The Pi 4B has sufficient compute for 2D SLAM at normal robot speeds.
Future: Multi-Robot Coordination
Through the roboNet mesh, multiple tank-track platforms can share maps and coordinate:
- One robot maps, others receive the map
- Distributed area coverage (no overlap)
- Rendezvous for payload transfer
The coordination is handled by the mesh task dispatch system — no robot-specific coordination code. Same protocol as any other distributed task.