Connection of pixhawk CubeOrange to Nvidia Jetson AGX Orin via PX4-ROS 2 Bridge using UART


first of all we want to say that we are completely new to the topics px4 and ros2 and started in September 2022 from scratch.

Currently, we are trying to connect pixhawk CubeOrange to Nvidia Jetson AGX Orin via PX4-ROS 2 Bridge using UART.

We’ve made the setup according to
ROS 2 User Guide (PX4-ROS 2 Bridge) | PX4 User Guide
and used
GitHub - PX4/px4_ros_com: ROS2/ROS interface with PX4 through a Fast-RTPS bridge
as well as
GitHub - PX4/PX4-Autopilot: PX4 Autopilot Software

The sanity check was successful and correct installation of PX4-ROS 2 Bridge could be verified via simulation (make px4_sitl_rtps gazebo).

Now we want to test with real hardware. Therefore we’ve connected the pins 2, 3 and 6 of GPS2 connector of the pixhawk CubeOrange (see figure below)

to the NVIDIA Jetson AGX Orin pins 6, 8 and 10 of the 40 pin I/O connector (see figure below).
Of course, we’ve connected the “Tx” to the “Rx” pins and “GND” to “GND”!

Apart from the UART connection, the CubeOrange is powered via USB cable by the Orin. We also use USB connection for mavlink / nsh console.

Then we are setting up our CubeOrange firmware for rtps with the following steps:

  1. In /boards/cubepilot/cubeorange/default.px4board we set the CONFIG_BOARD_SERIAL_GPS2 parameter to our desired port “/dev/tty[***]”
  2. In /boards/cubepilot/cubeorange/rtps.px4board we’ve set:
  3. $make cubepilot_cubeorange_rtps
  4. $make cubepilot_cubeorange_rtps upload

Now we start the rtps client via the nsh shell using:
$ *
$micrortps_client start -d /dev/tty"[
]" -b 115200

In a new terminal we start the rtps agent:
$micrortps_agent start -b 115200 -d /dev/tty"[**]"

*** we’ve already tried several port ttyS1,ttyS3,ttyS4, ttyTHS0, ttyTHS3 etc.

Finally, we start a listener in a new terminal:
$ros2 launch px4_ros_com

Both, the micrortps_client and micrortps_agent start, but there is no communication between them and nothing seems to be published in ros2. Notice that we’ve tried several ports and ensured that agent and client use the same baud rate. We’ve also checked the ports of our interest and all are dialout and have read/write rights (sudo chmod 666).

Further investigations:
As UART did not work, we wanted to test the connection at place of the UART by using the USB port. If we connect both the client and agent on port ttyACM0, then the nsh console is terminated and the following warning is frequently updated in the terminal that runs the agent:

"[ micrortps_agent ] Unexpected topic ID ‘10’ and ID ‘27’ to publish Please make sure the agent is capable of parsing the message associated to the topic ID ‘10’ and ID ‘27’

Unfortunately were not able to map our ros2 topics to the above IDs.


  1. How to find out if the connected pins on the Orin side belong to ttyTHS0 (serial@3100000) or ttyTHS3. We did not find out and therefore tried both of them.
  2. Did anyone of you face similar problems by using UART between Orin and Cubepilot?
  3. Can anyone share a simple example for testing serial link between Orin and Cubepilot using either UART or USB?
  4. Do we have to start the micrortps_client at the same port in nsh shell as the one we use for the micrortps_agent? If yes, by using $ls /dev/ in nsh console, we found out that the serial ports used by Orin for the UART “ttyTHS0” and “ttyTHS3” seems not to exist, even if we specify one of these ports by using CONFIG_BOARD_SERIAL_GPS2 prior firmware upload.
  5. After many hours of research, we could not identify the required “port-mapping” between the “client” and “agent”. Although we found a couple of discussions in forums that came close to the topic, we could not find a clear and for us understandable explanation. Could anyone please help here?
  6. We also use QGroundControl for monitoring and debugging. Are there any parameters that we need to set here, e.g.:
  7. How to set up the pixhawk CubeOrange to automatically start micrortps_client after reboot avoiding the need to start it manally via nsh console

Thank you very much for you support!

hello sebastian-uav2022,

please refer to below for Orin uart mappings.
for example,

pin# signal name ball name GPIO software customer usage
K53 UART1_TX UART1_TX GPIO3_PR.02 UART-A / serial@3100000 40-pin header Pin 8 GPIO/UART1_TXD
J58 UART5_TX UART2_TX GPIO3_PX.04 UART-B / serial@3110000 M.2
H62 UART3_TX_DEBUG UART3_TX GPIO3_PCC.05 UART-C / serial@c280000 Primary Unified Debug UART
L5 UART4_TX UART4_TX GPIO3_PH.03 UART-D / serial@3130000
C58 UART2_TX UART5_TX GPIO3_PY.05 reserved secondary debug UART

you may see-also sysfs, please visit pinconf-groups for checking uart functions.
for example,

# cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups | grep uart
2 (uart3_tx_pcc5):
120 (uart2_tx_px4):
155 (uart1_tx_pr2):

Hi JerryChang, thank you for the quick reply! Thanks to this information we now are confident that we are connected to the port ttyTHS0! :)

hello sebastian-uav2022,

do we have further issue waits for resolve, are we able to close this forum discussion thread?

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