I’m integrating a Jetson Nano as an external companion computer with a BlueBoat (BlueOS + Navigator) to run autonomy + collision avoidance using MPC+CBF. Jetson will compute commands and stream them back to the boat at ~10–50 Hz, with manual override/failsafe.
I need guidance on:
Best way in BlueOS to route/stream MAVLink telemetry to Jetson (UDP/TCP endpoint setup, typical ports).
Best control input for continuous MPC output on BlueBoat (velocity/yaw-rate setpoints vs RC override vs guided/waypoints) — what’s recommended/supported?
Should MAVROS (ROS 2) run on the Jetson or inside BlueOS ROS2 extension, for lowest latency + reliability?
Best practice for failsafe/watchdog so loss of Jetson commands returns to manual/hold.
Any working reference configs (BlueOS endpoint + MAVROS/pymavlink connection string) would be super helpful.
Hi @rishabh307 -
I would recommend installing your Jetson Nano onboard the BlueBoat with an ethernet switch, and assigning it a static IP like 192.168.2.102.
There are lots of ways to send commands to the system from there - you could simulate pilot input with pymavlink, or send the appropriate Mavlink commands directly, emulating a GCS. I believe the ROS 2 extension for BlueOS presents the vehicle as a ROS node, and so I would assume latency is comparable to the other methods, depending on your code structure of course. From a reliability standpoint, it therefore seems best to work with ROS if that’s what you’re comfortable with, or planned to develop your “MPC+CBF” algorithms to interface with. The Ardupilot forums may have more experience too!
The BlueBoat already has failsafes you can configure in BlueOS, but generally I’d recommend putting the vehicle in loiter mode if something goes wrong (assuming the system can navigate normally, and isn’t suffering from a motor failure.) This will soon be possible with default ArduRover firmware, but currently the “hold” mode failsafe action would just turn off the motors, allowing the unit to drift away.
We’ve not done very little work testing with ROS, or external control sources like this - maybe @patrickelectric has some references, or the developer of the ROS2 extension @ItsKalvik !
@rishabh307 I agree with Tony: connect the jetson to a switch and set a static IP. Then install the ROS 2 extension on the Pi, which will expose the FCU (robot controls) over the network via ROS 2. From there, you can run ROS 2 on the Jetson and send control commands to the FCU.
ROS 2 is a solid choice if you want to leverage existing ROS 2 packages—for example, using onboard sensors for SLAM. If you already have a reliable, non-ROS 2 way to get obstacle locations and you’re aiming for peak trajectory tracking performance (e.g., >30 Hz), I’d stick with a non-ROS 2 approach.