Px4 Jetson Nano Connection


I am trying to connect my Jetson Nano to a Px4 controller for off board control. I want to use Pymavlink and Qgroundcontrol to do so. When trying to compile code, I did this:

import serial
from pymavlink import mavutil

Define the serial port and baud rate

serial_port = ‘/dev/ttyS1’
baud_rate = 57600

Initialize the serial connection

connection = mavutil.mavlink_connection(serial_port, baud=baud_rate)

Main loop for communication

while True:
# Receive and process MAVLink messages
msg = connection.recv_msg()
if msg:

# connection.mav.heartbeat_send(6, 8, 192, 0, 0)

Close the serial connection when done


If I am connecting via the TELEM2 port on Px4 and I am using the GND,RX,TX pins on the Jetson (pins 9,10, and 8), how do I ensure that this connection works in my code?Also, which baud rate should I be using, because I have seen people using a baud rate of 115200.

Hi user 1171171,

Are you using the devkit or custom board for Jetson Nano?
What’s your Jetpack version in use?

I’m not clear about what’s your use case and the usage of PX4.
Could you share the block diagram of your connections?
and also the full dmesg for further check.

Are you sure that the particular serial port is not also used as a serial console? For the serial port you are actually using, it should be group dialout, not tty. Compare your port (on the Jetson side) via:
ls -l /dev/ttyS* /dev/ttyTHS*

Try to check in QGroundControl what BaudRate setup for Telem2 on your pixhawk.

Check documentation for carier board for your Jetson Nano to be sure what UART ports can be used and with witch file port it is associated (might be /dev/ttyTHS1, /dev/ttyTHS2 or somthing totally different).

I am using Jetson Nano with original DevKit board and for testing MavLink connection via MavProxy I am using this command “sudo mavproxy.py --master=/dev/ttyTHS1 --baudrate 57600 --aircraft MyCopter”

Hi @vdoom.heretic, thank you for the response.

Can I ask how you connected your Jetson (Devout) and pixhawk with the UART and Telem2? I ran a program similar to yours, where I used the serial connection (/dev/ttyTHS1) and I got this error: serial.serialutil.SerialException:[Errno 13] Could not openport /dev/ttyTHS1 [Errno 13] Permission denied: ‘/dev/ttyTHS1’

Thank you, this is part of the solution. I am also unsure how to connect my pixhawk and Jetson using the UART. Would appreciate any guidance on this issue

Unfortunately I am not expert in the topic. I just start investigating it 2 weeks ago for my own hobby project. I used this video as tutorial for wiring https://www.youtube.com/watch?v=nIuoCYauW3s

I don’t know the details of the pixhawk. No doubt there is a specified setup for the serial port. If that setup is speed 115200, 8-bit, no parity, and one stop bit, then the defaults won’t need to be changed. If the physical wires used are to the pins normally used for serial console, then you will have to disable serial console (after which you have an ordinary port running by default at 115200 8N1).

On the Jetson side, assuming you use one of the integrated serial ports, any use of the UART after being fully booted would normally be one of the “/dev/ttyTHS*” files (which is really a driver interface). Optionally, sometimes a legacy port would be used, which is one of “/dev/ttyS*” (same hardware, different drivers).

I don’t know which driver interface (which “/dev/ttyTHS” or “/dev/ttyS” file) goes with which pins on the Jetson. However, if you know which file your software talks to at the Jetson end, just run “ls -l” against that file and see if it is group dialout (in which case you are in luck), or if it is group tty (in which case you must disable serial console).

If you need to disable serial console (and this is a very useful thing for debugging and other purposes, I would not disable it unless you truly need to do so), then do this:

sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service

Please note that this disables serial console within Linux, but boot stages might still have output during boot stages (boot is its own operating system).

That video is showing use of the Seeed Studio carrier board, which is not a dev kit. I don’t know the details of that carrier board, and some carrier boards use the same electrical layout as the dev kit, which would mean they use the same device tree, but many third party carrier boards use a different device tree. There are times when one changes a serial port via device tree (in addition to the nvgetty.service), so this might be part of the final answer. If you are using a true developer’s kit, versus a third party carrier board (such as Seeed) it is important to state that.

FYI, some serial ports use hardware flow control, which is what the video’s CTS and RTS wires are. By default Jetsons do not use this, which is why he is able to cut the CTS and RTS wires (one would typically change the device tree if you want to enable CTS/RTS flow control). He is able to cut the +5V wire because the UART is self-powered at the Jetson end. This leaves only the ground, TX, and RX wires. All of the exposed UART ports have a ground, TX, and RX, and the software setup is all that differs. I don’t know which device special file (“/dev/ttyTHS*”) to use, but it depends on which pins are connected to. The typical pin 9 and 10 plus ground is normally serial console on a dev kit, so I am betting you need to disable nvgetty.service to cause the permissions of the device special file to revert from group tty to group dialout.

And remember, if you talk to device special file as a regular user (versus sudo root), then this is when you need to add your user to the group dialout. To illustrate, if your user name is “nvidia”, then one would add group dialout to user nvidia as a supplemental group via:
sudo usermod -aG dialout nvidia

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.