Video summary

09172021 Lawn Tractor Meeting

Main summary

Key takeaways

Technology

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:

  1. Physical measurement

    • Measure steering/wheel geometry directly to determine hard-stop angle (for example, ~45°).

  2. 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).

  3. 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

Original video