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

PX4 Autopilot
1

Hi,

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)

image
image785×357 67.6 KB

to the NVIDIA Jetson AGX Orin pins 6, 8 and 10 of the 40 pin I/O connector (see figure below).
OrinPinout
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:
    *CONFIG_MODUELS_MICRODDS_CLIENT =n *
    CONFIG_MODULES_MICRORTPS_BRIDGE = y
  3. $make cubepilot_cubeorange_rtps
  4. $make cubepilot_cubeorange_rtps upload

Now we start the rtps client via the nsh shell using:
$mavlink_shell.py *
$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 sensor_combined_listener.launch.py

Status:
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.

Questions:

  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.:
    RTPS_CONFIG
    GPS_2_CONFIG
    SER_GPS2_BAUD
    MAV_X_CONFIG
  7. How to set up the pixhawk CubeOrange to automatically start micrortps_client after reboot avoiding the need to start it manually via nsh console

Thank you very much for you support!

2

Hi @sebastian-uav2021,
I think your problem is the serial port configuration.
you should not modify CONFIG_BOARD_SERIAL_GPS2 as it is specific for your board. You should instead use the original value (/dev/ttyS5) to configure the client, namely

micrortps_client start -d /dev/ttyS5 -b 115200

Regarding the agent on the Jetson side, I have no experience with that board but you should search online which is the right device to use, /dev/tty*, and if you need to modify the board setting to enable it. This is something that you always have to do when working with rasberry Pi boards, so maybe it is the same also for the Jetson.

No, the ports of client and agents depends on the two boards and are not related
If you say that the Orin uses ttyTHS0 then the two commands are

micrortps_client start -d /dev/ttyS5 -b 115200

and

micrortps_agent start -b 115200 -d /dev/ttyTHS0

This is right, there is no port mapping.

As you don’t use a second GPS you just need to make sure that a second gps is NOT configured so that you can freely use its serial port

use RTPS_CONFIG and specify GPS2: Parameter Reference | PX4 User Guide (main)
then reboot and set the baudrate with SER_GPS2_BAUD Parameter Reference | PX4 User Guide (main)
Here GPS2 is just a name to identify the serial port. This is also why you must not modify CONFIG_BOARD_SERIAL_GPS2.

3

Hi Benja,
thank you very much for your fast repsonse. :blush:

After making your proposed changes (CONFIG_BOARD_SERIAL_GPS2 and ttyS5) , we can confirm that the micrortps_agent now receives data.
However, we are know continuously receiving the following warning in the terminal running the micrortps_agent:
"[ micrortps_agent ] Unexpected topic ID ‘27’ to publish Please make sure the agent is capable of parsing the message associated to the topic ID ‘27’
This behavior is similar to the one we had while using the USB connection at place of UART via port ttyACM0. When we check our ROS2 topics, it seems that nothing is published. Do you also know how to fix this issue? We expect this to be probably a configuration issue of the rtps-ROS2 bridge.

See figure below:

Screenshot from 2022-09-29 14-02-58
Screenshot from 2022-09-29 14-02-581920×1080 412 KB

(1) in the terminal on the upper left, the agent is running
(2) the terminal on the upper right shows the nsh shell, where we’ve started the client
(3) in the terminal on the lower left, our ros2 listener node is running (nothing is printed to the console)
(4) in the terminal on the lower right, we tried to subscribe to some topics, however without any success.

Regarding the auto-start after reboot. Making the settings for RTPS_CONFIG and CONFIG_BOARD_SERIAL_GPS2 does not seem to fix the issue. We still have to start the micrortps_client manually via nsh shell. However it might be that it worked once, but we are not a 100% sure. Nevertheless, automatic start of the client after reboot seems at least not to be persistent (we tried multiple times including reconnection and reboots of both hardwares. Do you have any further ideas what we could try?

Many Thanks!

4

This last issue is due to the agent and client being not aligned. Are you working on the main branches of all repos? PX4-Autopilot, px4_ros_com, px4_msgs

You can easily fix it running, from your PX4-Autopilot folder

ROS2_WS_DIR="your ros2 workspace path" make update_ros2_bridge

This will update the agent, its messages definition and the messages templates.

This process should normally be automatically performed by CI on the PX4-Autopilot repo but for some reason it is not working lately.

Setting RTPS_CONFIG and CONFIG_BOARD_SERIAL_GPS2 should be enough to automatically start the client, make sure that no other drivers or module are using the GPS2 serial port and that you correctly set up the baudrate.

5

We basically used the sources from here (those are claimed to be the master branches):

$ git clone https://github.com/PX4/px4_ros_com.git ~/px4_ros_com_ros2/src/px4_ros_com
$ git clone https://github.com/PX4/px4_msgs.git ~/px4_ros_com_ros2/src/px4_msgs

Nevertheless, we followed your suggestion:

$ ROS2_WS_DIR="home/uam/px4_ros_com_ros2" make update_ros2_bridge

And receive the following output (latest run to create the screenshot; might not indicate all previously made changes / updates):

grafik
grafik1920×1080 259 KB

Please note, that our PX4-Autopilot folder is not located in the sam workspace but is located at path:

home/uam/PX4-Autopilot

Is this fine?

When we now run the agent and client, this results again in the ID27 warnings.
Therefore, we built the px4_ros_com_ros2 package once again by running the following skript in px4_ros_com_ros2/src/px4_ros_com_scripts

$ source build_ros2_workspace.bash

Unfortunately, if we now run the agent and client, this results again in the ID27 warnings.

As explained above, we are running the agent and client at the exact same baud rate, by using the following commands:

$ micrortps_client start -b 115200 -d /dev/ttyS5
$ micrortps_agent start -b 115200 -d /dev/ttyTHS0

Our next step would be to delete our complete workspace and set it up once again from scratch. Do you have any additional ideas? Thanks a lot so far :slight_smile: !

6

And what about the PX4-Autopilot source?

Yes, it is.

I suggest you clean your ros2 workspace and recompile:

source clean_all.bash
source build_ros2_workspace.bash

You said it worked well in simulation? Was there any warning?

7

The PX4-Autopilot source was from here:

$ git clone https://github.com/PX4/PX4-Autopilot.git --recursive
$ bash ./PX4-Autopilot/Tools/setup/ubuntu.sh

However, we applied the following change prior running ubuntu.sh (a “fix we found in some forum to allow installation on our arm64 Nvidia Orin Ubuntu machine”)

  1. delete g+±multilib and gcc-multilib lines in ~/PX4-Autopilot/Tools/setup/ubuntu.sh
  2. open terminal and run “bash ./PX4-Autopilot/Tools/setup/ubuntu.sh”
  3. reboot your computer
  4. make …

Excuse me please, I was not a 100% right before. We have verified the simulation on a separate Ubuntu workstation, not on our Nvidia Orin System. On the ebedded hardware we had another problem. Please refer to:

We did not find a solution for that yet either. So it might be the case that our PX4-Autopilot setup is not right.

I’ve tried the scripts proposed by you located in px4_ros_com_ros2/src/px4_ros_com/scripts, however the results unfortunately did not change.

source clean_all.bash
source build_ros2_workspace.bash

Here is the corresponding output:

grafik
grafik1920×1080 280 KB

The only warning we had was regarding the “ros1_bridge”. As due to my understanding the rtps_bridge does not make use of ros1_bridge, I guess this is however not an issue ?
About the ROS_DISTRO indications, I am not quite sure, but I guess they are also not critical, as all our other ROS2 packages on that machine run without any issues.

8

I’d like to add that we use the separate Ubuntu Desktop PC workstation to create and upload the firmware to pixhakw CubeOrange, as we noticed that it does not work (at least not stable) to build for and flash the cubepilot from the Nvidia Orin (not sure if it worked a few times). However, we thought that this will work, as we can run the “agent” on the orin and the “client” is flashed from the workstation that could be proven to work by simulation.

9

I do the same, but you need to be sure that you are always using the same versions.
Once again, on the Ubuntu workstation does the simulation run without warnings?
Knowing that we can narrow down the issue.

I would keep only the ROS2 workspacce on the Orin board and remove the autopilot folder as it is not necessary if the firmware is uploaded from the workstation

10

Ok, I did not setup the Workstation. It was done by some former colleague who is not available anymore. Do you know how to check the version?

11

We run the simulation on the workstation using the following command:

Terminal 1:

$ make px4_sitl gazebo

Terminal 2:

$ source ~/px4_ros_com_ros2/install/setup.bash
$ micrortps_agent -t UDP

Terminal 3:

$ source ~/px4_ros_com_ros2/install/setup.bash
$ ros2 launch px4_ros_com sensor_combined_listener.launch.py

We are getting almost the same output here, so the simulation seems also not to work. Sorry for the confusion:

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

and

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

12

You can

  1. Check the date of the last commit
  2. Check the last git tag (version)
  3. Open QGC during sitl and check the version of the autopilot from there

OK, then it is definitively agent and client not matching. Start by using

ROS2_WS_DIR="your ros2 workspace path" make update_ros2_bridge

nn the workstation to see if this solve the issue there in sitl. Then manually copy the ros2 workspace source files (of px4_ros_com and px4_msgs) to the Orin, recompile everything and check if it works.

I’m assuming that the PX4 versions in the workstation and in the drone are the same: you used the workstation to upload the firmware and you did not change anything between experiments (make update_ros2_bridge only affects the ros2 workspace)