I tried to replicate it and successfully created the failures
At first, I tried mavproxy to verify if the network is connecting
mavproxy.py --master=udpout:192.168.1.103:14552
It works, so udp connection should be perfect.
Then I tried pymavlink
import time
from pymavlink import mavutil
master = mavutil.mavlink_connection("udpout:192.168.1.103:14552")
master.mav.ping_send(
int(time.time() * 1e6), # Unix time in microseconds
0, # Ping number
0, # Request ping of all systems
0 # Request ping of all components
)
master.wait_heartbeat()
while True:
try:
print(master.recv_match().to_dict())
except:
pass
time.sleep(0.1)
It works too. The ping is necessary to get the heartbeat, otherwise it stuck forever.
After that I tried dronekit
connection_string = 'udpout:192.168.1.103:14552'
from dronekit import connect, VehicleMode
print("Connecting to vehicle on: %s" % (connection_string))
vehicle = connect(connection_string, wait_ready=True, source_system=1)
vehicle.wait_ready('autopilot_version')
print (" Last Heartbeat: %s" % vehicle.last_heartbeat)
print (" System status: %s" % vehicle.system_status.state)
print (" Mode: %s" % vehicle.mode.name) # settable
vehicle.close()
print("Completed")
It doesn’t work.
Then I found this discussion suggesting that old version of Ardupilot used to work. So I loaded Arducopter 3.6.9 into the Cube and tried again.
Now it is definitely receiving messages from my Cube, but the errors spammed the communication.
These few lines are not appearing in Ardupilot 4.0.0. So maybe firmware version is also a factor. Maybe most of the message became unrecognizable for the dronekit. The discussion above also says that building dronekit from source will solve the problem.
By the way, I am using CubeBlack and the old standard carrier board. They are old enough and still having the same issue, so I don’t think the Orange or ADS-B carrier board cause the problem.