HAMRCASTER MOBILITY RESEARCH

03 / Control & instrumentation

Control the vehicle.
Measure the caster.

Wheel speed and turret heading close the motion loop. Independent encoders reveal how each supporting caster moves along the route.

01 / Motion architecture

Two loops, one trajectory.

The Raspberry Pi corrects position and heading. The drive ESP tracks wheel speeds and returns encoder and IMU measurements.

High-level pose control and low-level motor controlWaypoints enter a trajectory generator, then pose PID and inverse kinematics on the Raspberry Pi. Wheel and turret rate commands travel over UART to the drive ESP. Wheel PID and the turret drive command the robot. Encoders and the IMU return feedback to the two loops. RASPBERRY PI / ROS 2DRIVE ESP32 / 10 MS LOOP TrajectoryPose + feed-forward Pose PIDx · y · heading error KinematicsWheel / turret rates UART Wheel PID + turret driveMeasured rate → motor PWM RobotPhysical motion PWM Encoders + IMU → odometry / localization → measured pose Wheel encoder rate Outer loop follows the route and preserves turret heading.Inner loop compensates wheel load.
01 — The same trajectory concept is used in simulation and hardware, with geometry and actuator limits configured for each platform.

  1. Generate the reference

    Blend waypoint corners and schedule a feasible velocity through each segment.

  2. Correct the motion

    Combine reference velocity with position and heading feedback, then apply inverse kinematics.

  3. Track actuator rates

    Send wheel and turret commands to the ESP; return motion measurements to the Pi.

02 / Powered wheels

A speed loop
for each wheel.

Quadrature encoders measure how fast the left and right wheels turn. The ESP compares these rates with their targets and adjusts motor PWM.

u = uff + Kpe + Ki∫e dt + Kdde/dt

Feed-forward supplies the nominal effort; PID corrects the difference. Integral limits and output saturation keep the command bounded.

Wheel encoder quadrature and feedback diagramA wheel encoder produces offset A and B square waves. Their edge order indicates rotation direction, and counts over elapsed time indicate wheel rate. Both return to the ESP wheel speed controller. ENCODER → DIRECTION + RATE Wheel rotation A B Edge order → directionCounts / time → angular velocity Drive ESP32100 Hz nominal wheel loop /left_wheel/encoder_ticks · /right_wheel/encoder_ticks
02 — Incremental counts provide a relative rotation measurement. Direction and counts per revolution are calibrated for the installed drivetrain.
Car ESP wiring & telemetry

GPIO assignments below are defined in the current drive firmware. They document the software configuration; the installed harness still needs to be checked against the board and encoder hardware.

ConnectionConfigured GPIO / interfaceSignal handling
Left wheel encoderA → GPIO14 · B → GPIO13Input pull-ups; both edges of A trigger counting, B determines direction
Right wheel encoderA → GPIO1 · B → GPIO2Same acquisition; firmware reverses the right-wheel count sign
Turret encoderA → GPIO5 · B → GPIO4Input pull-ups; relative rotation from A-edge quadrature counting
BNO055 IMUSDA → GPIO33 · SCL → GPIO34IMU55 sens(33,34); I²C at 100 kHz, default address 0x28
Motor driver outputsLeft PWM11 / DIR12
Right PWM41 / DIR42
Turret PWM7 / DIR6		5 kHz, 12-bit PWM configured by the drive ESP
Pi data linkSerial0 · 460800 baudBinary bidirectional UART; RX/TX GPIOs use board defaults and are not explicitly assigned in this source
Programming / logsUSB CDC · 115200 baudSeparate from the binary data UART

The Pi bridge publishes the three cumulative tick streams and /imu/data; wheel and turret rate targets travel back on the same UART. The firmware targets esp32-s2-saola-1. GPIO numbers refer to ESP pins, not connector positions.

Source files: HAMR_Controller/src/main.cpp, src/imu_55.cpp, src/imu_55.h, platformio.ini; host settings: hamr_control/hamr_bringup/config/hamr_uros_bridge.yaml. The explicit IMU constructor uses GPIO33/34; its adjacent GPIO4/5 comment is stale.

Independent turret heading and base orientationA rotated base supports an independently oriented turret. The turret encoder measures relative angle, while the fused base heading defines the world heading. The desired turret heading is held as the base turns. TOP VIEW / OFFSET TURRET θrelative Desired world headingBase yaw changesTurret encoder measuresrotation relative to the base. ψturret = ψbase + θrelative
03 — A relative encoder angle and the base heading together describe turret orientation in the world frame.

03 / Turret yaw

Keep the heading
while the base turns.

The Pi uses the turret's relative encoder angle and base orientation to estimate world heading. Its yaw correction coordinates turret rotation with the drive wheels.

The command travels through /turret/cmd_vel to the ESP. Encoder feedback returns through /turret/encoder_ticks and /HAMR_turret/odom.

Controller implementation

In the ROS/UART firmware branch, turret rate is mapped to PWM with a deadband, static-friction compensation, and a slew limit. World-heading feedback closes on the Pi. A separate local angle-PID mode is also present in the firmware; its activation depends on the selected command mode.

04 / Ball caster measurement

Three angles describe the motion.

H1 and H2 measure hemisphere rotation. CENTER measures the common rod. Each rotating module has its own ESP32-C6, battery, and wireless link.

H1, H2 and CENTER ball caster measurement architectureThe ball caster consists of independently rotating hemispheres and a shared carrier axis. H1 and H2 read incremental encoders over buffered A B Z signals; CENTER reads an absolute SPI encoder. Three XIAO ESP32-C6 boards send UDP telemetry to the ROS receiver on the Raspberry Pi or recording computer. These are measurement boards, not actuators. KINEMATIC SCHEMATIC H1H2CENTER / common rod H1 / AMT132S-VA/B/Z → buffer → XIAO ESP32-C6 H2 / AMT132S-VA/B/Z → buffer → XIAO ESP32-C6 CENTER / AMT252B-V14-bit SPI → XIAO ESP32-C6 Wi-FiUDP 5005 Raspberry Pi / recording hostcaster_encoder_bridgeRaw telemetry + valid angle topics Independent power · no wires between rotating nodes · passive measurement
04 — Simplified measurement coordinates. Physical side, direction, and zero offsets are calibrated against the installed assembly.
Hemisphere 1

H1 / φ₁

Quadrature counts capture the first shell's accumulated rotation and rate. An index pulse provides a separate reference event.

/caster_encoder/H1/joint_states
Hemisphere 2

H2 / φ₂

The same acquisition chain measures the second shell independently, revealing differences between the two contact motions.

/caster_encoder/H2/joint_states
Common rod

CENTER / α

A parity-checked absolute encoder measures single-turn rod angle. Continuous turns are reconstructed only when valid.

/caster_encoder/CENTER/joint_states

These three boards measure the passive caster. They do not drive its hemispheres or command the robot.

Acquisition and wiring reference
ChannelAcquisitionInterface
H1 / H2AMT132S-V, hardware x4 quadrature countingSN74LVC244ADW at 3.3 V; A → D0/GPIO0, B → D1/GPIO1, Z → D2/GPIO2
CENTERAMT252B-V, 14-bit absolute single-turn positionCS → D3/GPIO21, SCLK → D8/GPIO19, MISO → D9/GPIO20, MOSI → D10/GPIO18
Every module200 Hz default sampling; two samples per 100 Hz datagram2.4 GHz Wi-Fi / UDP to the configured receiver; independent 2S battery and 5 V UBEC
Reference calibrationSign, zero, count scale, time alignment2048 PPR / 8192 x4 counts is the tentative H1/H2 configuration, pending physical verification

Each ESP has its own boot clock. Raw packets preserve source timestamps, sequence numbers, and validity flags; ROS display headers use host receipt time. Resolution is distinct from measured angular accuracy.

05 / Wheelchair caster comparison

Swivel angle.
Wheel rotation.

For the conventional caster, the swivel angle describes its orientation and axle rotation describes rolling. The paired experiment compares this motion with the ball caster's reconstructed coordinates.

Target instrumentation The diagram reserves an encoder at the swivel axis and an optional wheel-axle encoder. Simulation uses joint states; the physical sensor and wiring details can be filled in after the rig is finalized.

See encoder and vision reconstruction →
Proposed wheelchair caster encoder placementA sensor on the vertical swivel axis measures caster orientation. A second optional sensor on the horizontal wheel axle measures wheel rotation. This is target hardware instrumentation, while simulation joint positions supply the same coordinates. Swivel encoderOrientation β Axle encoderRolling angle φOptional channel Simulation: joint positions → angle histories → replay
05 — Proposed measurement locations for the wheelchair caster. Sensor hardware and physical wiring are placeholders.

From angles to evidence

Replay the motion, then compare.

Preserve raw measurements, align their clocks, and apply the calibrated model. Trajectory error, caster orientation, and disturbance response can then be evaluated together.

Explore the experiment template →