Summary of "09172021 Lawn Tractor Meeting"

High-level summary

Meeting about steering calibration, sensors, logging and debugging for an Ackermann lawn tractor using ROS (referred to in the transcript as “ross”), the TEB/temp planner, and custom low-level controllers. The discussion covered the steering-angle workflow, recommended calibration/measurement methods, mapping and controller practices, IMU/rotational-velocity usage, sensor/hardware changes, logging and post‑mortem tooling, and next steps.

Steering / planner → steering-angle workflow

Conversion code maps five inputs to a steering angle (radians): forward velocity, rotational velocity, wheelbase, minimum turning radius, and wheelbase/turning-radius parameters.
The planner (TEB/temp planner) can be configured to output a steering angle instead of a rotational-velocity command. That angle is passed in the second field of a modified cmd_vel message.
The low-level controller must:
- Interpret the second field of cmd_vel as a steering angle (radians).
- Map that angle to the vehicle’s steering position sensor (A/D counts / encoder counts).
Important planner parameter: minimum_turning_radius. This constrains the maximum angle the planner will request. Tune it so the planner does not command beyond mechanical hard stops.

Calibration / measurement methods (recommended)

Use one or more of the following to find the hard-stop steering angle or verify the angle-to-sensor mapping:

Physical measurement
- Measure steering/wheel geometry directly to determine hard-stop angle (for example, ~45°).
Drive‑in‑circle measurement
- Crank steering to the hard stop, drive a steady circle, measure the circle diameter from base_link.
- Using the measured radius and wheelbase, compute the steering angle that produced that circle (use the same equations posted in the meeting).
Use measured rotational velocity
- Measure rotational velocity while driving a circle (from differential wheel odometry, GPS, or IMU).
- Run that rotational velocity back through the conversion equations to compute the corresponding steering angle.

Mapping & controller recommendations

Use the measured hard-stop angle as the scaling reference: map 0..max_angle (radians) → 0..A/D counts (steering sensor).
Remove ad‑hoc scaling in the cmd_vel multiplexer (mux). Pass the planner-produced angle straight through to the low-level controller with no conversion there.
Perform angle → sensor-count mapping only in the low-level controller.
Joystick teleop currently outputs ±1 (arbitrary). Better approach:
- Add a small node that maps joystick ±1 → ±max_angle so the joystick spans the full physical steering range.
Do not rely on example numeric outputs from simulator tuning (e.g., ±0.3 rad); those are simulator‑specific and not necessarily meaningful for the real vehicle.

Note: Simulator example numbers are arbitrary and can be misleading if applied directly to the physical vehicle.

IMU / rotational velocity

IMU, GPS, or wheel odometry can supply rotational velocity used for verification and calibration.
Rotational velocity from sensors is primarily for verification; angle-based control can operate without it if the angle measurements are trusted.
Some IMUs (example: BNO055-like or “O80” referenced) provide relative rotational change but not absolute compass heading. Choose the sensor and message format appropriate to your needs (or use GPS/odometry where absolute heading is required).

Sensor & hardware work, logging, and debugging

Added sensors and hardware:
- Second IMU and RTK GPS.
- Right-wheel speed sensor (3D-printed bracket) to derive odometry from wheel sensors alongside GPS.
- Current sensors: Pololu boards and larger 50 A sensors; later added a sensor for the steering servo as well.
- CAN bus between remote receiver and main microcontroller; USB-to-CAN adapter to publish CAN messages into ROS and record them in bag files.
Remote control / reliability improvements:
- Replaced cheap plastic transmitter E‑stop switch with a higher-quality metal switch to improve reliability.
- Fixed “runaway” behavior (vehicle continued previous commands when receiver→MCU comms dropped) by adding CAN from remote receiver to the main MCU and adding logging.
- Main MCU logs received inputs to CSV so the full chain (receiver → CAN → main controller → actuators) is traceable.
- E‑stop circuit still cuts power via relay, but releasing e‑stop resumes previous commands. Suggested adding logic to set speed to zero when commands stop arriving.
Power/current issues and mitigations:
- Observed blown fuse and large peak motor currents when driving on grass (peaks ~30–40 A; A/D clipping observed).
- Replaced fuses after measuring currents (examples: main fuse increased to 40 A, motor fuse 30 A).
- Logged current data to ROS bags for post‑mortem analysis.
- USB logging crashes were caused by power/current spikes coupling into USB. Fixed by routing power wiring so USB cables are not run parallel to heavy power leads.
- Experimented with 24 V vs 12 V supply — lowering voltage reduced peak currents.
- Larger current sensors required correction factors because their recommended scaling assumed 5 V but the system uses 3.3 V; applied computed scaling (approximately ×1.515) to align plots.

Logging & post‑mortem tooling

Use ROS bag + CSV logging across CAN, IMUs, GPS, odometry, and current sensors for incident analysis (runaways, power events).
Recommended workflow:
1. Measure physical capabilities (angles, currents).
2. Load parameters into the planner (minimum_turning_radius, wheelbase, etc.).
3. Drive and record sensor outputs (IMU/GPS/wheel odom/current).
4. Tune planner parameters based on recorded data and repeat verification.

Software housekeeping & user interface notes

Remove unnecessary scaling in the cmd_vel mux; let the planner angle pass through unchanged and do mapping in the low-level controller.
Optionally add a scaling node between joystick teleop and cmd_vel to map joystick output to the physical angle range.
Avoid confusing assumptions based on simulator example values.

Video / content management

Indexing of older steering videos is ongoing.
Two remaining videos plus two audio‑only files need publishing; audio‑only files may require creating a dummy video track for YouTube.

Planned next steps / checklist

Produce a step‑by‑step measurement and calibration guide:
- What to measure, how to compute the steering angle, and how to load it into parameters.
Test the proposed mapping in the field: pass planner angle through, map at low level, and verify with circle tests plus IMU/GPS/wheel odometry.
Finish indexing and uploading remaining steering videos.

References / components mentioned

ROS (referred to as “ross”)
TEB/temp planner
IMUs: BNO055-like, “O80” (relative rotation devices)
RTK GPS
Adafruit LoRa/LaRa radios
Teensy microcontroller
CAN bus + USB-to-CAN adapter
Cytron motor driver
Pololu current sensors and larger 50 A current sensors
3D-printed wheel speed sensor bracket

Main speakers / sources

Jeff — primary presenter and narrator of experiments, hardware changes, and logic
Al — participant asking clarifying questions and confirming details
Other referenced people/sources: Matt (developer whose simulator tuning produced ±0.3 example values), ROS/TEB planner docs and community, Adafruit, Pololu