Rosettadrone 2 <-UDP-> MAVROS works only unidirectional

MariusBeul commented 2 years ago

Issue details

My connection looks like this: Rosettadrone 2 <-UDP-> MAVROS I can receive data from the drone but cannot publish anything with MAVROS. No heartbeat arrives at the drone. If I use Qgroundcontrol instead of MAVROS (Rosettadrone 2 <-UDP-> QGroundcontrol), the bidirectional UDP connection works and also the heartbeat comes through. The telemetry port in Rosettadrone 2 is set to 14550. I tried many different fcu_urls and receiving data works for example with

fcu_url:=udp://:14550@:14555/?ids=255,1" fcu_url:=udp://:14550@ fcu_url:=udp://:14550@:33749

The gcs_url is empty. Many messages arrive on the "/mavlink/from" topic, but on "/mavlink/to" nothing is published. Shouldn't I see the heartbeat from MAVROS here?

Am I doing something wrong connectionwise? Thank you for your support!

MAVROS version and platform

Mavros: The version that comes with ros-melodic-mavros and the current master branch. ROS: Melodic Ubuntu: 18.04

Autopilot type and version

[X] ArduPilot [ ] PX4

Version: ?3.7.1?

Node logs

[ INFO] [1641480350.446197624]: MAVROS started. MY ID 255.1, TARGET ID 1.1
[ INFO] [1641480356.529426617]: udp0: Remote address: 192.168.0.10:33749
[ WARN] [1641480356.634363808]: RADIO_STATUS not from 3DR modem?
[ INFO] [1641480356.636827616]: RC_CHANNELS message detected!
[ INFO] [1641480356.984039894]: CON: Got HEARTBEAT, connected. FCU: ArduPilot
[ INFO] [1641480357.087527805]: RC_CHANNELS message detected!
[ WARN] [1641480359.000536118]: VER: broadcast request timeout, retries left 4
[ WARN] [1641480360.004007925]: VER: broadcast request timeout, retries left 3
[ WARN] [1641480366.000325425]: CMD: Command 520 -- wait ack timeout
[ WARN] [1641480366.003431409]: VER: unicast request timeout, retries left 2
[ WARN] [1641480371.016490415]: CMD: Command 520 -- wait ack timeout
[ WARN] [1641480371.018437711]: VER: unicast request timeout, retries left 1
[ WARN] [1641480376.037921165]: CMD: Command 520 -- wait ack timeout
[ WARN] [1641480376.040334669]: VER: unicast request timeout, retries left 0
[ WARN] [1641480381.056068011]: CMD: Command 520 -- wait ack timeout
[ WARN] [1641480381.058163883]: VER: your FCU don't support AUTOPILOT_VERSION, switched to default capabilities

Diagnostics

header:
  seq: 82
  stamp:
    secs: 1641480460
    nsecs: 448215822
  frame_id: ''
status:
  -
    level: 0
    name: "mavros: FCU connection"
    message: "connected"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "Received packets:"
        value: "12303"
      -
        key: "Dropped packets:"
        value: "0"
      -
        key: "Buffer overruns:"
        value: "0"
      -
        key: "Parse errors:"
        value: "0"
      -
        key: "Rx sequence number:"
        value: "1"
      -
        key: "Tx sequence number:"
        value: "0"
      -
        key: "Rx total bytes:"
        value: "450826"
      -
        key: "Tx total bytes:"
        value: "22121"
      -
        key: "Rx speed:"
        value: "4353.000000"
      -
        key: "Tx speed:"
        value: "210.000000"
  -
    level: 1
    name: "mavros: GPS"
    message: "No fix"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "Satellites visible"
        value: "5"
      -
        key: "Fix type"
        value: "1"
      -
        key: "EPH (m)"
        value: "0.00"
      -
        key: "EPV (m)"
        value: "0.00"
  -
    level: 0
    name: "mavros: Heartbeat"
    message: "Normal"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "Heartbeats since startup"
        value: "207"
      -
        key: "Frequency (Hz)"
        value: "2.000019"
      -
        key: "Vehicle type"
        value: "Quadrotor"
      -
        key: "Autopilot type"
        value: "ArduPilot"
      -
        key: "Mode"
        value: "STABILIZE"
      -
        key: "System status"
        value: "Active"
  -
    level: 0
    name: "mavros: System"
    message: "Normal"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "Sensor present"
        value: "0x00000000"
      -
        key: "Sensor enabled"
        value: "0x00000000"
      -
        key: "Sensor health"
        value: "0x00000000"
      -
        key: "CPU Load (%)"
        value: "0.0"
      -
        key: "Drop rate (%)"
        value: "0.0"
      -
        key: "Errors comm"
        value: "0"
      -
        key: "Errors count #1"
        value: "0"
      -
        key: "Errors count #2"
        value: "0"
      -
        key: "Errors count #3"
        value: "0"
      -
        key: "Errors count #4"
        value: "0"
  -
    level: 1
    name: "mavros: Battery"
    message: "Low voltage"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "Voltage"
        value: "0.00"
      -
        key: "Current"
        value: "0.0"
      -
        key: "Remaining"
        value: "94.0"
  -
    level: 1
    name: "mavros: 3DR Radio"
    message: "Low RSSI"
    hardware_id: "udp://:14550@:14555/?ids=255,1"
    values:
      -
        key: "RSSI"
        value: "0"
      -
        key: "RSSI (dBm)"
        value: "-127.0"
      -
        key: "Remote RSSI"
        value: "0"
      -
        key: "Remote RSSI (dBm)"
        value: "-127.0"
      -
        key: "Tx buffer (%)"
        value: "0"
      -
        key: "Noice level"
        value: "0"
      -
        key: "Remote noice level"
        value: "0"
      -
        key: "Rx errors"
        value: "0"
      -
        key: "Fixed"
        value: "0"
---

Check ID

OK. I got messages from 1:1.

---
Received 1776 messages, from 1 addresses
sys:comp   list of messages
  1:1     0, 33, 1, 65, 74, 141, 109, 241, 242, 147, 24, 125, 30

vooon commented 2 years ago

Second part, after @, is a remote address, so it should be like that: udp://:14555@<ap>:14550. /mavlink/to will be silent if you don't use gcs_proxy node. Plugins directly talks to fcu link on ROS 1.

MariusBeul commented 2 years ago

Hello vooon, thank you for the comment. I tried

udp://:14555@<ap>:14550, but no connection could be established. However, when I tried udp://:14550@<ap>:14555 (ports changed) at least data from the drone to MAVROSwas transmitted. No heartbeat arrived at the drone from MAVROS though.

Is there a proven technique how I can check if (and which) UDP packets are sent from the PC running MAVROS?

MariusBeul commented 2 years ago

I have an update on this topic: Indeed a connection is established and data is send from MAVROS to Rosettadrone 2 , but it does not contain valid fields. When I bytewise decode the message that arrives at Rosettadrone 2 from QGroundcontrol, they look as follows: 254,9,182,255,190,0,0,0,0,0,6,8,192,4,3,75,225 with the structure (startbyte, length, sequence, sysid, compid, msgid, 9 byte payload, 2 byte checksum) which corresponds to a heartbeat message with #0. If I do the same with MAVROS, messages look like 253,9,0,0,10,240,0,0,0,0,0,0,0,0,18,8,192,4,3,226,167 with an unknown structure. My insights (with zero-based counting): Byte 4 is continually increasing so I suspect it to be a sequence. Bytes 19 and 20 are supposedly a checksum again since they change with every message. The remaining bytes stay constant. The last 5 bytes before the checksum are the same in both messages and part of the payload. Bytes 5 and 6 are sysid and compid. I wonder why the Startbyte is different. Also why is the message 4 bytes longer although byte 1 says 9?

vooon commented 2 years ago

First byte 0xFD is a framing marker of MAVLink version 1, 0xFE - MAVLink version 2. Version 2 has bigger header: https://mavlink.io/en/guide/serialization.html

MAVLink 2 was in all major APs for a while, so mavros just defaults to it. But as i see, you use some older implementation, which only speaks v1, so i suggest to set fcu_protocol: "v1" in your params file.

MariusBeul commented 2 years ago

Thank you for the answer! Apparently, setting fcu_protocol: "v1.0" doesn't change anything. Still MAVLINK 2 packets arrive at the AP. After some research, I think this issue refers to the same problem.

Somehow the fcu_protocol parameter doesn't work.

vooon commented 2 years ago

https://github.com/mavlink/mavros/blob/master/mavros/src/lib/mavros.cpp#L58 code still there. Could you please check again that you set /mavros/fcu_protocol := "v1.0" before node startup?

MariusBeul commented 2 years ago

I correctly set the parameter. Also I could confirm that the flag is correctly set here (flag == 0 || 2, depending on the version). MAVLINK 2 messages are sent to the AP independently of the flag. Rolling back to versions mavros: release 0.32.0 mavlink: release 2020.2.2-1 as suggested in the other thread resolved the issue. However, switching to MAVLINK 1 in the current master implementation doesn't work for me.

mavlink / mavros