rcairman
commented
9 years ago After additional tests I have found out, that this problem is not only related to MAVProxy but MAVLink in general. When I use tracker + 3DRadio + copter configuration (no MAVProxy) i have no problems, but when I change copter to plane I get similar problems that I am getting with MAVProxy. More info about my tests: http://diydrones.com/xn/detail/705844:Comment:2009218
Hi,
I am working intensively on a dedicated digital datalink for communication with my UAV - I use Ubuquiti Bullet M5 radios to stream 2 video streams (FullHD 30fps classic camera + 640x480 15fps IR thermal camera) plus all MAVLink telemetry and RC commands (separate dedicated C socket application). For now I am getting good results up to 1,5km and in the future I will be replacing Bullets with a specialized IP datalink that will give me more range but this is not relevant at this point.
In order for me to acheive greater range I need to use an Antenna Tracker with a directional antenna and I have been doing some work here as well (pending pull request in AntennaTracker code + discussion on diydrones: http://diydrones.com/xn/detail/705844:Comment:2008046).
My connection schematic is as follows: On the flying part of the system I have a Pixhawk, an Odroid microcomputer and the beforementioned Bullet M5 (plus additional stuff for my video streams but this is not relevant). Odroid is connected to Pixhawk's telem1 port using FTDI USB to UART converter just as 3DRadio would have been. On the Odroid I have a MAVProxy instance with /dev/ttyUSB0 as master and udp as out. On the tracker side I have a Bullet M5, APM 2.5 and a RaspberryPI. RaspberryPI is connected to APM's UART2 (MUX jumpers set to UART2) via another FTDI USB to UART converter just as a 3DRadio would have been. On the RaspberryPI I have another instance of MAVProxy with udp as master and /dev/ttyUSB0 as out. For now I am connecting my laptop with Mission Planner to APM's USB port (to exclude other possible sources of the problem). It is meant to be either handled by another MAVProxy out or an additional FTDI and another instance of MAVProxy.
Basically the flow of information looks like this: Pixhawk telem1 --- FTDI --- Odroid with MAVProxy --- UDP over Bullets --- RaspberryPI with MAVProxy --- FTDI --- APM 2.5 --- Mission Planner
I am yet unsure if this is a bug in MAVProxy or a misconfiguration/misuse of features, but I have a following problem: With the above schema I am either unable to connect (using MP) or I have a connection, that is unreliable. Most times I get a lot of "Allready got param" and updating param list takes forever. In a result, my Antenna Tracker most of the time is unable to recover MAV location from streams and (although it usually reports a valid location) it either points into a wrong direction or changes the angles rapidly. What makes it even more difficult to debug is the fact, that from time to time everything seems to work fine and once every 5 or 10 flights my tracker is behaving as expected. I tried to reproduce proper behavior by figuring out proper poweron order but it doesn't seem to make a difference.
During my analysis I replaced my whole system with a pair of 3DRadios (excluding MAVProxy) and everything works as expected - when I connect with MP I can see both the tracker and the copter on the map and I can switch between them with Ctrl-x. Param read/write, waypoint management and actions (mode change, takeoff etc) works well. On the other hand, when I run Odroid's MAVProxy with additional --out=udpin I can connect my Mission Planner directly to Pixhawk with no problems whatsoever so the problem is most likely related to MAVLink id's and relaying data between inputs and outputs.
Randy suggested something similar on diydrones: "Maybe there's an issue with the fowarding of mavlink packets - perhaps both the tracker and MAVProxy are forwarding packets back and forth and this is leading to a network storm." there is no excessive traffic visible on the network so I don't think it is a bandwidth problem (I can connect directly to Pixhawk at the same time and it works well).
Since it works fine using 3DRadios I believe the problem is located somewhere between MAVProxy and MAVLink relay features in copter and tracker. Did anyone encounter a similar problem? Is there something I can do to help narrow the problem down? I am willing to resolve this problem, but I am looking at python for the first time and I am currently setting up a development environment so it may take me some time.