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.
Hi,
I am building a tow boat with a Pixhawk 6C, two VESCs and differential thrust.
My current setup is:
• BREmote transmitter with GPS carried by the rider
• BREmote receiver on the boat
• Holybro M10N GPS connected to the Pixhawk for the boat position
I am not planning to use the BREmote Follow-Me logic itself.
Instead, I would like to use ArduPilot on the Pixhawk for my own navigation and safety functions (Follow-Me, geofence, safety stop, etc.).
Is there any way to access or forward the rider GPS position received by the BREmote system to an external flight controller such as a Pixhawk?
For example:
• UART
• MAVLink
• Serial GPS output
• SBUS
• Any other interface
Or is the rider GPS position only available internally within the BREmote Follow-Me implementation?
The follow-me software is still in developement. However to my knowledge it is not planned to make the rider position available to any outside interface. You may request that from @macfly1202 or @monter_man as soon as they have finished their follow-me implementations. Or just add it yourself, since the code will be open-source.
FYI, on my fork, I implemented telemetry forwarding from the GPS to a VESC app. It’s not as good as serial, but it works on the Tx. It could also be implemented via Bluetooth to forward that information received on the RX.
The tow buggy is back — Follow-Me + Return-to-Me both working!
Long time no see! The ESC burned out and it took a month to get a new chip, but she’s
alive again — and Follow-Me and Return-to-Me modes are both running well. A few more
water sessions to be sure, then I’ll email beta testers the repo + flashing
instructions (fair warning: the setup’s involved — read the whole README). Really proud
of where this landed. More soon — see you on the water!
Heads up — bug found and fixed. Please reflash both boards.
Found this while testing yesterday. The receiver shares one serial line between the GPS and the VESC, and the priority was backwards — it sat on the VESC and only checked the GPS for 10 milliseconds twice a second. The GPS talks in bursts, so that window almost always missed them. The receiver was catching about 2% of the GPS feed, roughly one heading update every 25 seconds.
Fixed: priority swapped, the line now rests on the GPS. GPS went from 0.1 to 84.8 sentences per second on the bench, and it holds a proper fix now. VESC telemetry went from 72% to 100% as a bonus.
Also added guards so Follow-Me won’t steer on a heading that has stopped changing, plus a safety net that stops it if it isn’t actually following. Latest is on master. Your saved settings are not wiped.
Still alpha, and this fix is not proven on the water yet — bench tests only. Test at your own risk and keep manual control in reach.
I have no experience on the Bremote, but I am currently investigating… planning to build a tow similar to Etienne’s HIGHFIELD show room boat.
I have questions about the Bremote V2 receiver.
Are people using the Wet Sens capability?
I was thinking about using AP_WET_MEAS to provide « extended sensing ».
Perhaps an additional Arduino sensing wetness, humidity, IMU could be connected to this pin.
Firmware behavior: AP_EN_WET_MEAS is pulsed HIGH briefly, then AP_WET_MEAS is sampled. AP_WET_MEAS is active‑low (0 = wet).
Perhaps it’s a better idea to simply proxy the receivers pwm signals…
The goal would be to turn off the pwm signal when sensing something bad, before deciding on cutting power from battery.
Not sure if I completely understand your goal…
The wet sens is working currently, so when wetness is detected, the remote will show that and vibrate. It will let you continue to drive however so you can make it back to land safely
Just cutting PWM when wetness is detected is a bad idea, since the water will continue to corrode everything that’s plugged into battery, and you won’t have a way to get back to land to clean/unplug/dry the components.
I don’t know if humidity will be of any value regarding safety?
Also an IMU is of questionable use in my option… Sure if the eFoil or boogie is upside down you could stop the motors… But detecting an actual fall and shutting off the motors immediately will be hard to implement and likely lead to many false-positive motor shutoffs in bumpy water…
If you want to do that, I would not use the wet sens pins, rather just a 2nd microcontroller and have that cut power to the Rx or just pull the PWM pins low / cut them with a relay
Nope, just connect 2 wires that will get wet and therefore conducive in-between
You can use a PCB with open traces, or just tape the wires or some conducive tape next to each other. No “active” circuitry required
GPS is sorted — TX and RX both configure properly now.
The firmware used to send GPS settings and never check whether the
module accepted them. It now verifies every write and reads the
setting back out of the module.
BN-880 and similar now run dynModel Sea instead of factory Portable.
Portable allows 694 mph and 12,000 m, so the receiver will publish
physically impossible fixes as high-confidence — a logger on the same
buggy emitted 254 km/h at 4,800 m with HDOP under 3. Sea caps it at
56 mph / 500 m. It doesn’t make a good fix more accurate, it kills
the outliers. Matters most on the RX, since that GPS feeds
Return-to-Me and Follow-Me. (Riding above 500 m altitude? Use
Automotive instead — Sea will start rejecting good fixes.)
M10 owners — your GPS was probably never configured at all. u-blox
removed the legacy UBX-CFG messages on M10. The five the firmware was
sending don’t exist there, so nothing landed, including dynModel. It
now detects the dialect from the ACK/NAK and re-sends through the
modern interface. You don’t declare your chip — BN-220, BN-880, M8N,
M9N, M10 all self-configure from the same image.
Baud is now found by listening for NMEA across five rates before
transmitting anything. Wrong-baud bytes make u-blox count framing
errors and eventually switch off its own receiver — and that counter
only clears when the GPS loses power, not on a reboot. That one bit
me on the bench.
New bench commands: ?gpscfg, ?gpsbaud, ?gpssetup. Run ?gpssetup once
per unit.
Hardware-verified on both boards. Settings are not wiped.
Also started — a multi-TX branch. Up to four remotes sharing one
buggy and taking turns in the water: lock your remote to offer
control, the next rider takes it with a squeeze. Going in alongside
it is proper link authentication — right now the receiver obeys
anything addressed to it and has no way to tell who sent it, so a
packet can be copied or replayed. Design stage, nothing flashed. I’ll
post when it’s actually been in the water. … And this Multi-TX mode gets a new
display dot on the TX showing status.
For GPS with compass I had to add support for a newer M100 module.
I also switched to Automotive since I am above 500m.
It is crazy how good AI supportes/generates code, see:
The tow buggy is back — Follow-Me + Return-to-Me both working!
