MAVProxy on raspberry pi to MAVLink ESP32 not working - sort of solved

Ground Control Software MAVLink
,
1

I’m trying to get mavproxy.py on a raspberry pi to connect to a flight controller via udp using a MAVlink ESP32 wifi module. It’s not working. Mavlink connects but just reports “link 1 down” over and over.
In my case the MAVLink wifi module is connected to the FC via UART 2 and it’s definitely working. If I connect to the wifi from my laptop, QGC or Mission Planner can connect to the FC - it works fine. I can also use mavproxy from my laptop (and it’s a Mac!!!) via the wifi and again - works fine no problem.
But if I connect my Raspberry Pi running the latest bullseye to the wifi - it connects and gets an IP address, I just get link down.
Oh - its ArduPlane 4.2.2 and the latest MAVProxy.py (using apt-get install).

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.2  netmask 255.255.255.0  broadcast 192.168.4.255
        inet6 fe80::26f:33e0:c664:5f9d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:06:f4:b9  txqueuelen 1000  (Ethernet)
        RX packets 350  bytes 129352 (126.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35  bytes 5142 (5.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This is what happens when I run mavproxy using the above IP address:

**pi@binarypi**:**~ $** mavproxy.py --master=udp:192.168.4.2:14550
Connect udp:192.168.4.2:14550 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from 192.168.4.2:14550
MAV> link 1 down

Here is a diagram that shows what I’m trying to do:

MavLinkArchitecture2022-09-20.001
MavLinkArchitecture2022-09-20.0011920×1080 131 KB

More information.
If I run 2 windows and start one listening at the broadcast address 192.168.4.255, then wait for it to start running, then start another one listening at 192.168.4.2, the second one will connect and keep working even thought the first one will go down as before. huh?

mavproxy --master=udp:192.168.4.255:14550
mavproxy --master=udp:192.168.4.2:14550

So if I put two masters on the command line, both links will come up, sometimes the first will fail, but the 2nd one will keep working. It seems like a bit of a hack, and probably a bit of unnecessary overhead, but it does work - so I’m going with it for now.

mavproxy.py --master=udp:192.168.4.255:14550 --master=udp:192.168.4.2:14550 --out=udp:100.126.58.78:14550

What am I doing wrong?

2

New (interesting) information. I ran tcpdump on the pi and found that the udp traffic is arriving at 192.168.4.255 (broadcast IP). So if I use mavproxy.py to listen at that address, I get an initial connection to the plane, for a couple of seconds, before I start getting no link and link 1 down messages. But after the rush of messages at 255, the messages stop arriving at .255 and start arriving at .2 but ONLY IF I listen on the 255 address first!

pi@binarypi:~ $ mavproxy.py --master udp:192.168.4.255:14550
Connect udp:192.168.4.255:14550 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from 192.168.4.255:14550
MAV> Detected vehicle 1:1 on link 0
online system 1
MANUAL> Mode MANUAL
Vcc 4.1
AP: u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
no link
link 1 down
no link

I put some debug in the code and basically the MAVLink module just stops sending messages (the mpstate.status.last_message stops updating) after it sends the first handful of messages.

Again - this doesn’t happen if I use mavproxy.py on my Mac, connected to the same MAVlink wifi. Only on the pi.

3

You’ll want mavproxy.py --master=udpin:192.168.4.2:14550 for using broadcast UDP with MAVProxy

4

I tried that - it had the same problem.
Also - I do want bidirectional telemetry. Does udpin only go one way?

5

Huh … maybe try udpout or udpbcast?

udpin, udpout, udpbast are all two way

6

I tried udpout but not udpcast - I’ll try that. But the real mystery is - why is this different on the pi? udp works fine on my Mac. (connecting the same FC/MAVlink wifi board).

7

link 1 down (with udpbcast)

8

You may need to use the IP of the MAVESP instead: mavproxy.py --master=udpout:192.168.4.1:14550

I suspect the Mac and Linux handle broadcast packet in slight different ways…

9

I’ve tried that also. It won’t connect at all on that IP.

10

Did you try TCP on port 5760?

11

[Errno: 111] Connection refused sleeping

Tried all addresses, 192.168.4.1 (ESP32 address), 192.168.4.2 (pi address), 192.168.4.255 (broadcast address).