I am having trouble getting some code to run on my new system using the Navio 2. I am in the middle of switching from using a Raspberry Pi 3 and Pixhawk to using a Raspberry Pi 3 and Navio 2. In terms of software, this project uses the ArduPlane flight stack controlled by Dronekit and Python code. The plane itself is a Fly Zone Calypso. I communicate with the plane using two Alfa AWUS036NEH dongles (one on the plane and one used by a laptop over UDP sockets via some Python code). Besides any message listener threads employed by Dronekit, the code is single-threaded.
The problem with the software is that the GPS does not seem to be updating when it prints a timestamp to a diagnostic file. In fact, the GPS time, location, and other GPS info do not update. A screenshot of my diagnostic files can be seen below:
Note: The GPS seems to update at the beginning when the plane is on the ground. However, after takeoff is when the repeated updates occur. The single software loop should at a rate of 500 ms (i.e., 2 Hz). The Navio 2’s GPS and the MAVlink connection itself should be able to handle this as it did before on the Pixhawk. Therefore, these diagnostic files should have different times printed with each line rather than the same GPS update printed for 10 - 20 lines. An identical line printed ten times implies that the GPS did not update for two seconds. This cannot be right. Before, when the software used a Pixhawk, repeated lines never occurred more than twice in the diagnostic
Thus, I run the emlidtool on the command to see if there are any issues and I get this error which seems like it should be unrelated:
I do have some altitude problems and the barometer does not seem to be covered but could this be related? If not, does anyone know what might cause the Navio 2’s GPS to stall? The first guess is that since the problem occurs after takeoff that the GPS might be experience electromagnetic interference (EMI) from the servos and motors.
Another thing I checked was that the ArduPlane parameter for GPS type was set to “Auto Detect”. It was but is there another ArduPlane parameter for GPS that needs to be set? Is it somehow possible the Navio has a mismatching baud rate with the GPS? Is this an issue with Dronekit or the MAVlink/MAVproxy connections employed by Dronekit?
Thanks for reading the entire post. Any help is greatly appreciated.
did you check the gps status in missionplanner? if it is gpsstatus 1 (or higher) all the time then:
most likely related to EMI from (3DR or RFD modem) or gps antenna connector has a bad connection; someone on the forum, i believe, did succesfully use some kind of electric conductivity spray on that center pin!
Hi Benedikt, thanks for answering. Yes, I should mention that the GPS looked active on APM Planner and the GPS HDOP error was less than 1 m for most of the time.
I’m working on the same exact project with marc, and I just want to add that when we stop receiving GPS updates using the SYSTEM_TIME mavlink message added as a dronekit message listener, we also see link timeouts with dronekit to APM and stop receiving the messages, and then get a link restored and receive one GPS update then nothing for another 10 seconds. This persists throughout the flight, with a short reconnection to get a single update from APM, which is old GPS data.
i’m not so familiar with planes - but i don’t see an issue with your gps on the hardware/ardupilot side;
did you set mavproxy up with --daemon (through a service file)? otherwise its being stopped and started continously;
baudrate in missionplanner for serial 1 (-C switch) is set to 115200? (if you use -C to send mavlink to dronekit/localhost)
-A switch should be 115200 by default;
We start the ArduPlane instance on boot after calling sudo systemctl enable arduplane. Our commands are:
TELEM1=“-A udp:127.0.0.1:14550”
TELEM2=“-C /dev/ttyAMA0”.
We then launch our dronekit script using python plane.py --connect 127.0.0.1:14550. We also tried udpin:127.0.0.1:14550 and udpin:0.0.0.0:14550 as TELEM1 and the zero showed improvements for two flights then the problem persisted.
The ones currently on the pi are dronekit 2.9.0 and pymavlink 2.1.0. We are running dronekit on the pi, trying to connect via local loopback on 127.0.0.1:14550 as you can see above as our TELEM1.
i am not aware of a way of doing that…sry - because i never experienced a problem with the buffer;
you might want to re-look into the stability of your dronekit script;
Thank you anyways. We are convinced Dronekit is the culprit but we are looking for a workaround before changing any Dronekit code. We also think this might be a compatibility issue between different versions of Dronekit and PyMAVlink.
@panky Not quite, since we are unable to reproduce the link timeout…link restored error that only occurs directly after takeoff. I’ve tried seting the min takeoff speed&acceleration to 0, disabling stall prevention, but I don’t get the periodic link losses between dronekit and arduplane. The code runs perfect with the planes outside sitting on the ground, and we tested EMI by holding the plane and running full throttle. We are going to fly this week, and our potential solutions are to use SUDO dronekit_script.py, update the dronekit/pymavlink versions, monitor UDP buffer and MAVLINK messaging, make sure BAUD/data rates are equal, and throw in print statements in all the while loops inside dronekit. Any other suggestions on how to get the plane to think it is flying, or possible fixes or tests while out in the field? Anything with QGroundControl or Mission/APM Planner?
