I’m trying to establish a serial connection between the navigator flight computer and a Jetson to send control messages to the autopilot. I’ve gotten one-way communication working both with a local python script that forwards messages using pyserial, as well as by configuring a MAVLink-Server endpoint. However in both cases, while the Jetson can read the mavlink messages, its commands back are not acknowledged.
I’ve recently tried to configure a MAVLinkRouter serial endpoint but it fails to create with the error AUTOPILOT_ENDPOINT_CREATE_FAIL.
Is there any documentation or are there previous posts I’ve missed about these errors? Would appreciate any help!
I’s important to note, the Navigator is not a “flight computer” but merely a host PCB for the sensors required by an autopilot. Can I assume you’re trying to create a communications link between a Raspberry Pi + Navigator and a Jetson?
You may have better luck making this connection via ethernet / TCP/IP, adding a UDP Client endpoint pointed at the Jetson IP address?
Can you share what device /ttyS0 is? That doesn’t look like a serial port of the Navigator or a USB adapter…
Yes, I’m using the stock BlueBoat configuration of Raspberry Pi + Navigator and want to connect this to a Jetson over serial for control. I’m using the navigator’s serial 1 port (/dev/ttyS0 per the technical details) with a JST-GH adapted to the UART pins of the Jetson. I know this will introduce some latency regardless but am trying to minimize this with a serial connection.
An ethernet connection is not preferred as the Pi’s port is in use for the onboard router. I’ve tested running the communication to the Jetson over the onboard network with an endpoint to its address but am having issues with the reliability of the connection.
Serial would be perfect if I can figure out why I can’t send commands back. It’s weird to me that I can establish the connection and read the data on the Jetson with a MAVLink-Server endpoint but that my messages don’t get back to the autopilot.
On the Jetson’s end, the connection looks like this:
/dev/ttyTHS1 is the uart address on the Jetson. All my control works perfectly when connected over network, but commands don’t make their way back when connected with uart.
Let me know if this makes sense and if I can provide any more information. Thanks for your help!
Do you have an ethernet switch in the BlueBoat? This would put the Pi on the same network as the Jetson, and allow for much faster communications speeds…what has been unreliable about this approach?
It may be. worth trying Serial 3 or Serial 4 on the Navigator, Serial 1 is shared with other resources.
I’m not sure we’ve done much testing with serial links like this… I’ll enquire internally and let you know!
No our BlueBoat doesn’t have the ethernet switch. I misspoke earlier, I previously had the Jetson connected wirelessly (not with ethernet) to the boat’s network, and I believe the connection was bottlenecked by the amount of mavlink messages. I’m sshing into the Jetson through the BlueBoat network and this froze when the boat was >~5m away. The connection between the Jetson and the boat itself may have been ok (can’t confirm) but I need to maintain that ssh connection.
The ethernet switch seems like a good solution but I’d really like to try everything I can with serial first.
I’ve just retested serial 1, 3, and 4 and have the same issues - reading data on the Jetson but can’t send anything back.
The BlueBoat does not make a WiFi network, unless you’re talking about the hotspot that BlueOS on the Pi makes? This is not going to reach very far as you’ve found - you should be reaching BlueOS via the BaseStation and Mikrotik WiFi connection.
Getting an Ethernet switch is definitely the preferred solution if you want to SSH into the Jetson over the long range radio link! It would also let you handle far more bandwidth between units than the serial connection provides.
That said, you’re actually not setting up the Serial connection in the correct way… the MAvlink Endpoints are for connecting BlueOS to external control clients or autopilot hardware via serial. For a serial connection to the autopilot itself, delete any serial route you may have added and simply adjust the following Autopilot Parameters:
Serial#_Protocol= Mavlink
Serial#_Baud = 115200 (higher is better for short distances and more bandwidth!)
Most of the serial ports were already to set to MAVLink2 - is this correct? I configured serial 3 like this but didn’t have any success. Don’t get a heartbeat or any messages.
I forgot that I had removed some serial ports from the autopilot when I was testing some manual communication. After adding the ports back to the autopilot I’m now receiving messages again but still cannot send anything back.
Can you share the code that sends messages? You’re likely not addressing the correct device ID or generally have something that makes the autopilot ignore your message…
Definitely, here’s an example of writing the mode.
#state machine callback
def state_callback(self, msg: String):
mode = msg.data; self.current_mode = mode
self.get_logger().info(f'Mode: {mode}')
mode_id = self.master.mode_mapping().get(mode)
if mode_id is not None:
self.master.mav.set_mode_send(
self.master.target_system,
mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED,
mode_id
)
self.get_logger().info(f'Sent mode ID {mode_id}: {mode}')
else:
self.get_logger().warn(f'Unknown mode: {mode}')
This action works perfectly when I connect to mavlink over the network (self.master = mavutil.mavlink_connection(‘udp:0.0.0.0:14551’)) but doesn’t work when I connect over serial (self.master = mavutil.mavlink_connection(‘/dev/ttyTHS1’, baud=115200)).
Are you thinking that the target_system is wrong?
I’ve tested the Jetson’s ability to write independently both with a loopback test by shorting RX/TX and by monitoring the output with an Arduino.
stop the autopilot process, and then use screen /dev/tty<S0|AMA1|AMA2..> <baudrate> or any other serial monitor to talk to the board on the other side, just to validate the serial communication itself, with no mavlink
stty -F /dev/tty<PORT> will tell you if the port in use is using the correct baudrate
fuser /dev/tty<PORT> will show you if any other process took the port over
Thanks for your message. After disabling the autopilot I tried testing communication through terminal. I first tested sending messages from the BlueBoat to the Jetson. On the BlueBoat I would send a message with “echo “test” > /dev/ttyAMA1” and read it on the Jetson with “screen /dev/ttyTHS1”. I made sure they had the same baud rate first. This worked great but as soon as I swapped roles I didn’t see anything in the BlueBoat’s terminal. I checked serial 3 and 4. I also checked that no other processes were using the port.
I also retested the Jetson’s tx pin by reading messages directly with an Arduino which worked.
