Summary of "09242021 Lawn Tractor Meeting"
Overview
The meeting focused on integrating ROS with a small lawn-tractor robot. Main topics included path planners, STM32-based controllers, flashing/debugging tools, odometry and steering calibration, and ROS tooling (plotting, topics, and documentation). Community items mentioned included a commercial agricultural route/path planner from an Argentinian developer/company (not free) and recent/planned releases from ROS/ROS-Industrial and local developer communities (Ecumen).
Hardware and flashing / debugging tools
Boards discussed
- STM32F4 Discovery — includes on-board ST‑LINK debugger.
- “Blue Pill” STM32 dev board — typically requires an external ST‑LINK or an alternate Arduino-compatible bootloader.
Tools
- STM32CubeProgrammer (STMicroelectronics)
- Used to flash .hex files and to upgrade ST‑LINK firmware.
- Has a Java dependency; behavior varies by OS (Linux/Windows).
- STM32CubeIDE
- STM IDE; sometimes fails to communicate with ST‑LINK. CubeProgrammer can be used as a workaround.
- ST‑LINK debugger/cable
- Required for instruction-level debugging (breakpoints, single-step, variable/assembly viewing).
- Alternative: Arduino-compatible bootloader on Blue Pill
- Flashing the Blue Pill with an Arduino bootloader allows USB programming via the Arduino IDE when ST‑LINK is unavailable.
Practical notes and troubleshooting
- Discovery board is recognized automatically as ST‑LINK when plugged in; Blue Pill usually needs wiring or an external ST‑LINK.
- ST‑LINK firmware may need upgrading via the programmer UI.
- Troubleshooting tips: check device detection, ST‑LINK firmware versions, and OS-specific port permissions (Linux quirks).
Path planners, ROS planners and conversion utilities
Planners referenced
- TEB (Timed Elastic Band) local planner — teb_local_planner
- Can be configured to produce steering-angle style outputs (angle instead of ω).
- Default local planners — trajectory_rollout, DWA
- Typically output linear and angular velocities (v, ω).
- Noted: ROS-Industrial and community planner posts exist (some older than initially thought).
Conversion utility
- A ROS node/utility exists (in teb_local_planner or related repos) to convert standard cmd_vel (v, ω) into Ackermann-style messages (steering angle + forward speed) or other robot-specific command formats.
- Important implementation note: guard against divide-by-zero when ω or v = 0 — return zero steering angle in that case.
Steering geometry, odometry and calibration
Key kinematic relations
- Turning radius:
- R = v / ω (when ω ≠ 0)
- Ackermann-style steering angle (front wheel):
- δ = atan(L / R), where L is the wheelbase (distance from front axle to rear axle)
Note: the relation above comes from viewing the turnaround radius and wheelbase; some descriptions use atan(wheelbase / radius).
Odometry from differential wheel encoders
- Forward distance ≈ (Δleft + Δright) / 2
- Instantaneous rotation (radians) ≈ (Δleft − Δright) / track_width
- track_width = distance between rear wheel contact points
- Heading update: integrate rotation samples over time (heading += Δθ each sample)
Recommended calibration procedure
- Physically measure maximum wheel angles at hard stops:
- Mark tire positions for left hard stop, center, and right hard stop (chalk/wood block).
- Measure angles with a protractor to get max steering angles.
- Record encoder/A-D counts corresponding to left hard stop, center, right hard stop.
- Map planner output angles to encoder counts (e.g., input angle range ±maxDegrees → encoder range).
- Verify mapping:
- Command the vehicle to drive at a given angle, read odometry-derived rotation, and compare to expected rotation.
- Iterate mapping parameters until odometry and steering outputs match.
- Ensure accurate physical measurements for wheelbase L and track width (example used in meeting: ~0.51–0.52 m).
Debugging, telemetry and development workflow
Debug data strategy
- Microcontroller publishes a single comma-separated array (stm_array) containing many floating values (odom results, encoder counts, PWM outputs, steering PWM, instantaneous radius, heading delta, etc.).
- Advantage: simplifies logging and plotting rather than creating many small topics.
- A ROS node parses the array and:
- Builds/publishes standard odometry topics and TF transforms.
- Optionally extracts and republishes individual values as dedicated topics.
- Publish rate is controlled by the microcontroller loop (example: 10 Hz); ROS receives and republishes at that rate.
Debugging approaches
- Arduino-style debugging: typically uses serial print statements.
- ST‑LINK (GDB-style) debugging: allows stepping through C code, setting breakpoints, watches, and inspecting assembly — more powerful for low-level issues.
Performance note
- Some Python ROS nodes were observed consuming 100% CPU — likely due to missing proper ROS spin/sleep (use rospy.Rate or similar). Fix spin loops to reduce CPU load.
Plotting and analysis
- PlotJuggler used for visualizing topics and comparing values; it aligns data by timestamp even if topics publish at different rates.
- Recent PlotJuggler versions reportedly auto-convert quaternion topics to Euler angles for plotting.
- Use PlotJuggler to compare odometry, IMU, GPS and microcontroller values by timestamp for validation and tuning.
Guides, tutorials and references
Mentioned or implied resources: - STM32CubeProgrammer docs/website (flashing and ST‑LINK firmware updates). - YouTube video on flashing Blue Pill with an Arduino bootloader (enables Arduino IDE uploads). - teb_local_planner GitHub (conversion node for v/ω → Ackermann/steering). - PlotJuggler (visualization and bag file analysis). - ROS wiki pages (package docs across kinetic/melodic/noetic — noted as sometimes hard to navigate).
ROS documentation and wiki translation issues
- ROS1 wiki (MoinMoin) is complex and inconsistent; translating package pages across distributions (kinetic/melodic/noetic) is difficult.
- ROS2 docs (ReadTheDocs/GitHub) are easier to clone and edit — suggested model for mirroring ROS1 docs.
- Proposed approach: scrape the ROS wiki to collect pages and analyze/repair broken links offline (direct server access not available). Community translation work is ongoing; several Spanish contributors involved.
Recommendations / Action items
- For STM32 development:
- Obtain a working ST‑LINK adapter and use STM32CubeProgrammer to flash and update ST‑LINK firmware.
- Configure STM32CubeIDE to talk to ST‑LINK for full debugging.
- If ST‑LINK is not available:
- Consider flashing a Blue Pill with an Arduino bootloader for rapid iteration via USB.
- Software and planner integration:
- Use or modify the teb_local_planner conversion node to accept cmd_vel and output ackermann-style commands; ensure divide-by-zero checks.
- Calibration:
- Calibrate steering by measuring physical max angles and mapping encoder counts accordingly; validate against odometry-derived rotation.
- Performance:
- Fix Python ROS nodes to use proper rospy spin and Rate controls to avoid 100% CPU usage.
- Analysis:
- Use PlotJuggler to compare and validate odometry, IMU, GPS, and microcontroller values by timestamp.
Main speakers / sources mentioned
- Meeting participants (unnamed): primary developer presenting STM32, odometry, steering calibration, and ROS integration; another participant assisting with ST‑LINK/CubeProgrammer troubleshooting and tips.
- External organizations / projects:
- Ecumen (Argentina) — local developers releasing path planner(s) and Arduino/UNO port.
- Argentinian developer/company — commercial agricultural path planner (cloud farming/route planner; not free).
- STMicroelectronics — ST‑LINK, STM32CubeProgrammer, STM32CubeIDE.
- TEB planner / teb_local_planner GitHub and ROS planner ecosystem (move_base, trajectory_rollout, DWA).
- PlotJuggler (visualization tool).
- ROS wiki / ROS community contributors (including Matias and other translators).
Category
Technology
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...