Commands from MAVProxy ignored when a second GCS is connected

Ground Control Software MAVProxy
1

Hello,

I have a companion computer (Beaglebone) connected to my Pixhawk 2.1/Cube on the Telem2 port and an RFD900x link over Telem1 to Mission Planner. While trying to use the Beagle to send a QHOVER-Arm-AUTO command sequence to the Cube, I noticed that when Mission Planner was actively connected to the Cube over Telem1, commands from the Beaglebone were frequently ignored.

A minimal reproduce of this problem was to:

  1. Running a basic MAVProxy instance on the Beaglebone (none of my own modules were active) i.e. mavproxy.py --master /dev/ttyO1
  2. Running Mission Planner on my ground station.
  3. Continually run commands to switch between GUIDED and MANUAL mode i.e. mode MANUAL and mode GUIDED so that I could hear the servos respond if the command was successfully received.

This is what I saw when Mission Planner was on (many commands were not acted on)

GCS%20-%20noACK
GCS - noACK.PNG801×579 1.53 KB

When I turned off Mission Planner, I got this (perfect reception of all commands)

NoGCS-ACKED
NoGCS-ACKED.PNG586×751 1.03 KB

I tried, individually:

  • Connecting Mission Planner to the aircraft over USB instead of the RFD.
  • Adding the --mav10 command line option as recommended in: "MAVPROXY" ignores command
  • Changing the source system ID of MAVProxy to 254 to avoid conflicting with Mission Planner’s ID of 255
  • Changing BRD_SER2_RTSCTS to 0 as in https://diydrones.com/forum/topics/mavproxy-ignores-input since my RTS and CTS cables are not connected to the Beaglebone, only RX/TX/Ground.
  • Connecting the RFD to Telem2 and the Beagle to Telem1 instead to see if there’s any preference for a port
  • Ran MAVProxy on the GCS laptop and send an output to local UDP port 14550, then connected Mission Planner to that port. If the mavfwd option is set to False then the issue goes away. If it’s on, the issue persists.
  • Set SYSID_ENFORCE to 1, SYSID_MYGCS to 254 and set the mavproxy instance on the Beaglebone to have a source ID of 254. My Mission Planner instance could no longer command the aircraft, but commands were still being ignored at the same rate on the mavproxy instance which now should have had exclusive control.
  • Tried changing the baud rate out from Telem2 to the Beaglebone to 38400 and 115200 (from the default of 57600)
  • Removed the Beaglebone from the system - connected MAVProxy over USB to the Cube and Mission Planner over the RFD900x link. The MAVProxy instance still could not successfully send commands sometimes. Changing the setup to use MAVProxy on both USB and over the RFD solves the issue - specifically connecting Mission Planner / APM Planner as one of the GCSs causes the issue.

The only consistent solution is just to disconnect Mission Planner altogether when the Beaglebone is sending commands, which isn’t an option. Does anyone have any idea why this is the case, or have anything I could try to resolve this?

Thank you in advance.

2

bump! I’m working around this temporarily by just disconnecting Mission Planner whenever the companion computer executes its critical command sequence, but I’m still trying to find the root cause.

3

Try APMPlanner2 or QgroundControl (QGC) … I “always” use mavproxy with one of those.

4

Unfortunately APMPlanner2 shows the same problem :frowning:
Have not tried QGC, will give that a shot, thanks!

5

Have you changed the mavlink system ids?

6

Yep, I’ve tried having all system IDs be unique, that didn’t seem to resolve the issue either.