Hi all — two updates today, VESC telemetry and compass steering for RTM/FM.
On the VESC side: what looked like a quick patch turned into a much deeper dive than
planned. A few rounds of diagnosis later, we got there. Root cause ended up being a
hardware conflict — the USB-C serial cable shares GPIO pins with the VESC UART on the
ESP32-C3, cable plugged in during field use silences VESC completely. Underneath that,
two firmware bugs were layered: the GPS UART MUX was taking the channel and never
handing it back to VESC, and a stale error flag was poisoning entire receive windows
from a single bad byte. Both fixed. The good news is the investigation forced a cleaner
MUX architecture out of us — GPS always has priority, always yields when done, VESC
defers properly. Battery %, wattage, and motor temp all live and stable now.
On compass steering: Jan flagged this early and he was right. The motor’s phase and
power wires generate enough EMF to make the compass completely unreliable the moment
throttle engages. RTM and Follow-Me are dropping compass navigation. What I’m doing
instead — take a heading snapshot from the compass at idle, where the data is actually
clean (no throttle, no EMF), then hand off to GPS course-over-ground + PD control once
throttle kicks in. Full PID is overkill for a tow buggy, PD handles it fine. Thanks Jan.
Water test is imminent — aiming for this weekend, next weekend at the latest. RTM
firmware is in good shape and I’m confident it’s ready.
Alpha reminder: pushing updates regularly, always grab the latest before testing.
BLE live on the TX — VESC Tool working (branch feature, not yet released)
NUS + VESC binary protocol over BLE. Connect with VESC Tool (free, iOS/Android) and get live FET temp, motor amps, duty, voltage and RPM from whatever the LoRa link is carrying from the foil. Still on feature/bluetooth, not merged to master yet.
EDIT: Great news BLE testing passed with flying colors !!! Now we have option to turn on BLE on TX and share it to VESC APP and see VESC values, If you do not have a VESC some values will still show up in the VESC Tool Gauges. Will move this feature to MASTER BRANCH, document it in README and push firmware soon.
One technical concern from my side before people spend time testing RTM/FM on real hardware: I think the current control logic still has a basic convergence problem.
In my view, throttle percentage should not be used as a proxy for speed. If GPS speed is available, RTM should use measured speed and limit throttle based on heading error, distance, and whether the buggy is actually converging.
A high fixed throttle value while the buggy is still far off-heading can easily produce the wrong behavior: the buggy starts facing away, applies throttle, turns poorly because both motors are already driven, distance initially increases, and the convergence/timeout logic stops the mode instead of bringing it back. Even if it does not timeout, it may oscillate rather than settle.
So before broader water testing, I would strongly suggest validating RTM at very low throttle with explicit checks for heading error, GPS speed, and decreasing distance. Otherwise testers may be debugging a basic control issue rather than testing a usable RTM feature.
Jan, thanks — this is a genuinely useful technical point and worth a
precise answer.
You’re right that the current RTM has no heading-error-proportional
throttle limit. The mode controls steering only (via differential
PWM offset); the user’s throttle passes through unmodified until the
approach decel zone engages in the final meters. Your concern about
the badly-aimed-start scenario is valid: high throttle + large
heading error reduces differential turning authority at the same
moment maximum correction is needed.
A few things that are in the code but may not be visible from the
design description:
The steering controller is P+D, not P-only. The derivative term
damps the oscillation you describe — it brakes the rate of heading
error change, not just the magnitude.
Phase C convergence check has a ~10s window before it can actually
stop RTM (the first sample at t≈5s only records the baseline
distance; a stop requires the second sample at t≈10s to be
non-improving). Most turns complete within that window.
The approach decel zone ramps throttle from full → 0 as the buggy
enters the final approach, so the arrival is controlled.
What your feedback is correctly pointing at: there is no protection
against the arm-with-high-throttle-while-facing-away scenario during
the initial turn. A heading-error throttle cap — e.g. cap throttle
at 25% while heading error exceeds 60°, release once aligned — would
directly address this. That is a targeted improvement worth adding
before broader testing.
Agree with your recommendation to validate first at low throttle
with serial logging active. That is how this should be tested
regardless.
I think the core issue is that RTM uses the same throttle behavior for turning/alignment and for closing distance. Those should probably be separate phases.
When heading error is large, the buggy should first align, not drive forward at high user throttle. On my tow boogie, high throttle leaves almost no useful turning authority, so 70% while off-heading can just make it drive away. Likely even out of range in 10 seconds.
Also, throttle percentage is not speed. Since GPS speed is available, I would expect RTM to cap or regulate based on measured speed, not raw throttle. Otherwise tuning will vary massively between boogies.
So I’d cap/suppress throttle during large heading errors and only ramp it once heading, GPS speed, and distance convergence look sane.
Good points all round — I took this on board and pushed a fix before the water
test. Live now online.
RTM now runs two explicit phases. When heading error is above a configurable
threshold (default 45°), throttle is suppressed to around 5% — enough to power the
differential for steering but not enough to drive the buggy away. It pivots toward
you first. Once heading error drops below the threshold, the run phase engages.
In the run phase, throttle is governed by GPS speed rather than raw user input.
There is a configurable target speed (default 4 km/h for first tests) that acts as
a ceiling regardless of the buggy’s motor or prop setup. This should also solve the
cross-boogie consistency point — the same config should behave the same on
different hardware.
One side effect noticed: during the align phase, motor current is near zero,
which means compass EMI bias is also minimal. So on builds with a BN-880 compass,
the hybrid heading mode gets cleaner readings exactly when it needs them most —
during the initial turn. This is a nice property of the phase separation rather
than anything we designed explicitly.
Both thresholds are configurable via the WebUI under the RTM group. Will report
back after the first water session.