Pixhawk 6C Telem2 Communication Issue with MAVROS

ROS / MAVROS / MicroDDS
1

Greetings to the community! I recently purchased a Pixhawk 6C and I’m trying to connect it to my Jetson TX2 via Telem2. However, I’m encountering the following message when attempting the connection:

[ INFO] [1626484707.877844634]: Known MAVLink dialects: common ardupilotmega ASLUAV all autoquad icarous matrixpilot paparazzi standard uAvionix ualberta
[ INFO] [1626484707.878015418]: MAVROS started. MY ID 1.240, TARGET ID 1.1

It’s worth noting that I also have a Pixhawk 4 with the same firmware version 1.14, and it connects without any issues. I have configured the following parameters in QGroundControl:

MAV_1_CONFIG = TELEM 2
MAV_1_MODE = Onboard
MAV_1_RATE = 921600 baud
MAV_1_FORWARD = True
SER_TEL2_BAUD = 921600

These same values are set on both the Pixhawk 4 and Pixhawk 6. However, the Pixhawk 6 fails to establish a connection with MAVROS. I even reinstalled MAVROS on the Jetson TX2.

To launch the MAVROS node, I use the following command:

roslaunch mavros px4.launch fcu_url:="/dev/ttyTHS2:921600" gcs_url:="udp://:14401@127.0.0.1:14550"

My question is: Is there any additional configuration that needs to be done on the Pixhawk 6 to establish the connection with MAVROS? I appreciate any help or suggestions you can provide to solve this issue and successfully connect to the Pixhawk 6.
Greetings and thank you to everyone in the community for your support!

2

Can you try with latest main?

You might need this fix: fmu-v6c: fix Telem1, Telem2 without flow control by julianoes · Pull Request #21540 · PX4/PX4-Autopilot · GitHub

Or alternatively, try with setting flow control off: MAV_1_FLOW_CTRL.

1 Like
3

I have already tried setting flow control off (MAV_1_FLOW_CTRL), but it doesn’t seem to work.
I also tried to flash the latest firmware 1.13.3 using qgroundcontrol (Developer Build (master)) but still did not work.
I upload the firmware v1.13.0 and I got this output

[ INFO] [1662441610.422696160]: IMU: Attitude quaternion IMU detected!
[ INFO] [1662441689.394849664]: CON: Got HEARTBEAT, connected. FCU: 128
[ WARN] [1662441691.446243968]: VER: broadcast request timeout, retries left 4
[ WARN] [1662441692.438616448]: VER: broadcast request timeout, retries left 3
[ WARN] [1662441693.445863488]: VER: unicast request timeout, retries left 2
[ WARN] [1662441694.449616864]: VER: unicast request timeout, retries left 1
[ WARN] [1662441695.440712096]: VER: unicast request timeout, retries left 0
[ WARN] [1662441696.443369376]: VER: your FCU don't support AUTOPILOT_VERSION, switched to default capabilities
[ INFO] [1662441699.409386208]: HP: requesting home position
[ WARN] [1662441699.431973536]: CON: Lost connection, HEARTBEAT timed out.
[ WARN] [1662441700.411977856]: PR: request list timeout, retries left 2
[ WARN] [1662441701.413690528]: PR: request list timeout, retries left 1
[ WARN] [1662441702.415769024]: PR: request list timeout, retries left 0

using the v1.13.3 when I unplug the uart connection, qgroundcontrol shows “Connection to mission computer lost”

Update
with v1.13.3 using telem3 with MAV_2_FLOW_CTRL Auto-detected

[ INFO] [1684395941.119493056]: MAVROS started. MY ID 1.240, TARGET ID 1.1
[ INFO] [1684396007.769953696]: IMU: Attitude quaternion IMU detected!
[ INFO] [1684396681.408920992]: CON: Got HEARTBEAT, connected. FCU: 128
[ WARN] [1684396683.452967584]: VER: broadcast request timeout, retries left 4
[ WARN] [1684396684.448149280]: VER: broadcast request timeout, retries left 3
[ WARN] [1684396685.452099808]: VER: unicast request timeout, retries left 2
[ WARN] [1684396686.454770176]: VER: unicast request timeout, retries left 1
[ WARN] [1684396687.448808320]: VER: unicast request timeout, retries left 0
[ WARN] [1684396688.451392608]: VER: your FCU don't support AUTOPILOT_VERSION, switched to default capabilities
[ INFO] [1684396691.422229248]: HP: requesting home position
[ WARN] [1684396691.438878080]: CON: Lost connection, HEARTBEAT timed out.
[ WARN] [1684396692.424484608]: PR: request list timeout, retries left 2
[ WARN] [1684396693.427929088]: PR: request list timeout, retries left 1
[ WARN] [1684396694.429310944]: PR: request list timeout, retries left 0

Is that output correct? because when using pixhawk 4 I get a different output.
Do I need to modify this parameter in pixhawk 6c SYS_COMPANION since I did not find it?

4

I disabled the flow control, it works perfectly. Maybe u need check the ttl cable u used.

1 Like
5

The connection between Jetson’s RX, TX, and Pixhawk’s RX, TX was set up as follows:

  • Jetson TX2 RX → Pixhawk Telem2 TX
  • Jetson TX2 TX → Pixhawk Telem2 RX
  • GND → GND

I have found that the Pixhawk Telem2 operates flawlessly at baud rates up to 500,000. However, when I attempted to increase the baud rate to 921,600, I encountered an issue where this message would appear after approximately 5 minutes. It’s worth noting that I also configured the SER_TEL2_BAUD parameter to match the 921,600 baud rate setting

[INFO] [1662441610.422696160]: IMU: Attitude quaternion IMU detected! 
[INFO] [1662441689.394849664]: CON: Got HEARTBEAT, connected. FCU: 128 
[WARN] [1662441691.446243968]: VER: Broadcast request timeout, 4 retries left 
[WARN] [1662441692.438616448]: VER: Broadcast request timeout, 3 retries left [WARN] [1662441693.445863488]: VER: Unicast request timeout, 2 retries left 
[WARN] [1662441694.449616864]: VER: Unicast request timeout, 1 retry left 
[WARN] [1662441695.440712096]: VER: Unicast request timeout, 0 retries left 
[WARN] [1662441696.443369376]: VER: Your FCU does not support AUTOPILOT_VERSION, switched to default capabilities

If anyone has insights or suggestions regarding this issue, I would greatly appreciate your input. Thank you!

6

I am using an usb to ttl adapter, because the GPIO pin may not have enough power, did u use the GPIO pin on jetson ? try use usb - ttl connection to see if it is the power issue.

7

Have you tried 1.5 Mbit or 3 Mbit baudrates?

1 Like
8

It works with 3 Mbit. From now on I will use 3Mbit
Do you know what could be the reason for this?

9

Not sure but it could be that only certain baudrates are nice multiples of the clock frequency and therefore work better.

1 Like