GPS Not Working on Navio 2

ArduPlane
, , , ,
1

Hi all,

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:

image.png1157×1362 206 KB

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:

image.png888×414 70.3 KB

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.

It should also be said that I’ve seen this problem persist when using “udp:127.0.0.1:14550”, “udpin:127.0.0.1:14550”, and “udpin:0.0.0.0:14550” as the connection string used by Dronekit and ArduPlane.

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.

2

Hi Marc,

I don’t have great ideas to help you. My first question is where did that info in the picture come from; you wrote it is your diagnostic files, are you referring to dataflash logs or is this information you get via MAVLink and log yourself?

Second question would be what version of ArduPlane are you running?

Not having a barometer working correctly is a problem, but I think it should be unrelated to the GPS problem.

3

Hi Francisco,

Thanks for the response.

  1. The first snapshot is a snapshot of a .txt file created by our Python software in which we print things like GPS time, location, etc. The second snapshot is of the output from running the command “emlidtool” which runs a few tests on the Navio 2.

  2. We are running ArduPlane 3.7.1.

I agree that the barometer warning/error is not related and is probably a benign issue since we can read altitude on APM planner.

4

Ok, then the first thing I would do is to look at the dataflash log produced by ArduPilot and see if the same happens with the GPS messages logged there. If it does, it is either the GPS or something in ArduPilot. If it doesn’t, then it is either in MAVLink side of ArduPilot or it is something with your Python software.

5

Thanks, Having looked at the .BIN files from ArduPlane, it shows no symptoms of the GPS cutting out. Thus, we believe it to be an issue with Dronekit.

6

A more or less easy way to confirm is connecting a standard GCS and then look at the telemetry log. If it also doesn’t have the problem than it is certainly being duplicated elsewhere (in this case, Dronekit).

7

I having very similar issues trying to run a script based sensor collection while flying. My guess is that the GPS stack does not support two services together accessing it information.

8

it looks to me that your GPS is being sampled at 20Hz, but you are only updating position data at much slower rate.