Integrating Jetson Nano into BlueROV for real-time controls calculation

Hi everyone,

I am looking to add a Jetson Nano to a default blueROV build. My goal is to develop a stand alone c++ library to run on the Jetson Nano that will override the controls of the blueROV. I just need to figure out how to stream data from the blueROV onboard PC to the jetson nano so that I can perform calculations then send the controls commands back to the blueRov’s onboard PC. From my reading on these forums, it seems that MAVlink/MAVproxy could be the tools I need, but any more specifics would be appreciated.

Hi @cmarq, welcome to the forum :slight_smile:

The BlueROV communicates via MAVLink over UDP. If your Jetson Nano is on the same network as the onboard Raspberry Pi (e.g. via wifi or ethernet) you should be able to establish MAVLink communications and control the vehicle with the relevant commands.

There are a variety of MAVLink libraries available, and you should be able to use the C++ or C ones if you’re wanting to make a C++ program for control. We have some Python-focused (pymavlink) examples here and a more complete program example here that it may be helpful to refer to. Blue Robotics doesn’t have any C++ focused examples, but there should hopefully be some in the relevant library.

Be aware however that secondary communications with the flight controller will always have higher latency and lower frequency sensor data than the autopilot firmware has access to. If you’re wanting to write detailed control systems to control the individual motors then it’s likely worth modifying the ArduSub firmware rather than doing abstracted control from an external device. If high level control is fine (e.g. you’re doing some computer vision and just want to tell the vehicle roughly where to steer) then external control should be ok (since that’s how ROV operators do manual control anyway).

Note that if you’re making an autonomous vehicle and don’t need to send anything to the topside you could potentially connect a flight controller (e.g. Pixhawk, Pixhawk 4) directly to your Jetson Nano (using a serial-based MAVLink connection, instead of over UDP) and avoid having the Raspberry Pi in between, which would reduce some latency and may add extra space in your enclosure. The best approach will depend on your requirements and the tools and skills available to you :slight_smile:

Hi Eliot!

Thanks for the info, the latency was something I am concerned about as well. We are looking to keep the Jetson Nano as separate from the original blueROV as possible so we can concentrate on the controls instead of all that would go into replacing the raspberry pi with a Jetson nano.

I was thinking to connect the Jetson Nano directly to the Pixhawk over the telemetry port and use mavlink to grab position/velocity data and return back thruster commands while allowing the raspberry pi to keep handling everything else. Do you think that would be a reasonable approach or am I making some oversights?

I asked about this internally, and I’m told it should work but you’ll need to make sure the telemetry port you’ve selected is properly set up for MAVLink communication via the SERIAL parameters. That should be the default, but it wouldn’t hurt to check SERIAL1_BAUD matches what you want to use (if you’re connecting to Telem1), and SERIAL1_PROTOCOL is set to MAVLink2 (2).

Gotcha. Good to know. For connecting to telem1, its required to have DF13 connectors right? Is there any way to connect wires directly without having these connectors until they arrive?

On a Pixhawk, yes.

There’s no simple / intended way for connecting without the connector. As a couple of hacky options,

  1. If you have small wires, a fine-tipped soldering iron, and a lot of patience you could potentially solder wires on directly, but it could damage the connector and would need to be removed in order to make the connector usable again. I expect that’s not worth doing.
  2. It could also be possible to 3D print a split-out piece that holds each wire separated and in place, which would be difficult to make reliable but could work reasonably well for some prototyping (it could be taped to the Pixhawk to keep it in place).