Navio2 integrated GPS problems

Greetings, I’m running a Navio2 with the integrated GPS on a Tarot 690 quadcopter. The Navio2 is running the current APM 3.4.6. I can’t seem to get a quality GPS fix. Indoors, I get zero GPS. Outdoors, I get 5-6 GPS. I’ve tried putting the GPS/GNSS MCX antenna on a tall mast, but that didn’t help. I’ve tried putting a shield under the antenna, but that didn’t help. I tried stretching the GPS antenna as far away as possible from the from the frame(just to test), but that doesn’t help.

What am I missing. I’ve experimented with some of the GPS parameters suggested on this forum, but no luck.

For testing, I also mounted my cheap generic Ebay Pixhawk with an external M8N. Indoors I get about 8 sats. Outdoors I get about 15-18 sats. This is without even mounting on a mast.

I really need a companion based flight controller for some testing on a PitLab OSD on a quad. Any suggestions would be greatly appreciated.

thx

Dave, your not the only one. I have been troubleshooting my GPS for weeks now. I do get a fix, but its all over the place.

With 3D+DGNSS you would think you would be very stable – not so. I have a cheap USB/GPS sitting on the floor in my den which gets a 3D fix and is VERY stable (3Meters over 15min – not much different for a hour). The Navio2 has +6Meters over 40 seconds, even with the 3D/DGNSS – should be rock solid and within 1Meter over an hour.

I have done the indoors/outdoors/farm field etc. and get same poor performance on the Navio2 (I can get a 3D fix indoors no problem with any GPS units that I have)

I’m looking for a solution as well…

1 Like

Thank you for sharing. I tried a few more tests today and my findings were interesting.

  1. I disabled the integrated GPS/Antenna and connected an external GPS via the telemetry port. Oddly, I get about 10-12 sats indoors and about 15-18 outdoors. This is from my cheap ebay M8N off the Pixhawk. This is not a viable option, since I need the valuable single telemetry port for other devices.

  2. I shut down all the electronics on my Tarot except for the Flight Controller. With only the USB providing power, the GPS improved slightly. Indoors increased to 6-8 sats. Outdoors increased 8-10 sats. My Tarot has lots of electronics, but I would expect the Navio2 to filter as good as a cheap $19 ebay M8N.

Hopefully the solution isn’t a Navio3. For now this Navio2 might be a better fit on my large MTD fixed wing, where it’s easy to separate electronics and GPS accuracy isn’t as important. Uggh!

Hi Dave, thanks for sharing.

I have the Navio2 mounted on a Pi 2 Model B V1.1. I have removed it totally from the drone and get same results as when I had it mounted. I tried 4 different power sources - so I know my power is not the problem.

When looking at other sensors on the Navio2 (using their C++ example programs) I get values jumping as well. I think there is some interference between the Navio2 and the Pi. An example is the battery voltage and board voltage are not as stable as they should be (±0.5 volts with just the PI/Navio2 powered). This I think is what is messing up the GPS. I would think that the GPS with a 3D/DGNSS with a HDOP 0.7 should give stable values!

Do you have heat sinks mounted on your Pi’s? I have one on the CPU chip and another one on the LAN chip.

Peter, I ran some more tests with the C++/Python examples and my findings were similar to your findings. The GPS just isn’t that reliable. This clearly rules out ArduCopter as an issue.

My setup is a Raspberry PI 3 without any heat sinks. I do have a CP2102 USB serial attached, but I wouldn’t think that would cause any issues.

Anyone from Emlid care to chime in before I pull this Navio2 and replace it? At this point, the solution isn’t reliable enough for a quadcopter. I think it would work ok on a fixed wing.

thx

Hello guys!

Sorry it’s taken me so long to reply.

First off, you can attach it using a extremely cheap USB-Serial converter like CP2102 saving your hardware UART port. Just plug into USB and you’re almost good to go (you need to pass /dev/ttyUSB0 as -E switch to ArduPilot in /etc/default/arducopter).

Secondly, is it possible that this case might be also of use?

The only thing that could cause issues like that might be a faulty antenna connector or a faulty antenna.

Could you please try to make a little pressure on the antenna connector (or even rotate a little) whilst testing outdoors?

I seem to get values jumping all over the place for the LSM9DS1/MPU9250/M8N. These devices ALL share the same SPI interface. I think the problem is somewhere with that.

I dug up all the specs on those chips and was going to do tests using the example code as a starting point to try to figure out is it the Navio2 card are a possible Linux driver problem.

I first looked at the connector pins for the SPI. Navio2 documentation states:

SCLK pin 19 GI10, MISO pin 21 GP9, MOSI pin 23 GP11

However, raspberry documentation (from several places) states:

MOSI pin 19 GP10, MISO pin 21 GP9, SCLK pin 23 GP11

I hope the Navio2 documentation is wrong. I am trying to trace out the lines to verify.

I have the Raspberry sitting on my bench with nothing but power, keyboard, monitor, network connected (have had ALL removed one time or other and different power sources – same test results)

My reason for purchasing the Navio2 was for a arducopter (drone-quad) and EVERYTHING on the board. Using external/additional devices instead of the onboard devices is not the way I want to go.

Yeah, sure I understand. This is a very strange issue indeed I’ll try to do my best to solve your problem.

First of all, could you please post the output of dmesg after ArduPilot has been launched?

Where do you observe this behavior? Is it happening when using the examples or ArduPilot. ArduPilot would spit out a lot of warnings in a GCS in case it detected strange behavior on IMUs (these are critical for operation of a copter, so it’s essential that they work reliably)

dmesg.pdf (61.8 KB)

I get these when arducopter is running and when I am looking at MissionPlanner.

I also get them when using the C++ examples – which I use a lot for testing. I use u-center v8.5 via the ubox-spi-to-tcp program for a lot of GPS testing. I took my Garmin GLO and set it on top of the Navio2 – Navio2 with 6 satellites unstable, GLO rock solid!

When I had it connected to MissionPlanner with the unit just sitting on the bench, MP would show it moving and altitude ± 5 meters (even when I did the test outdoors with a 3D/dgnss GPS lock). I have seen a few times after it has just been sitting on the bench for several minutes a MP message about “velocity variance error” or something like that.

My one and only test flight of my quad is when I added throttle it lifted off the ground about 2 inches and flipped over on its back, and yes I re-checked motors/props etc. and all was fine. After that I want solid stable data values from the Navio2 before I will try this again :frowning:

We have a few reports that some radios interfere with the GPS (other GPS receivers may work differently due to different schematics/components). Do you have a radio connected and if yes can you try removing it?

Thanks for reply.

I have removed everything. just the pi and Navio2 card – with pi power and / or battery via the Navio2 board (both by power and servo bus). tried with network (rsh via cable and Wi-Fi - no monitor/keyboard/etc.) and without network (just the HDMI monitor). I use the C++ examples for testing.

I am so frustrated with this I have just left it sitting on my work bench wondering what to do next. I’m down to electrical noise in the design of the Navio2 board, or Linux kernel drivers causing the problems.

Could you please make a couple of screenshots with satellite levels from u-center like explained here?
Outdoors please, indoors may vary drastically due to the changing satellite geometry.

Here are some video’s I did a little while ago. It rained here for the last 2 days and is in forecast for the next 3 days – oh joy.

I cleared the database and started fresh for each of the Navio2 and the GT730F videos - both were powered up about the same time. The GT730F is a cheap USB GPS which is on my windows 10 computer. I also did test with my Garmin GLO which thanks to the latest Microsoft windows 10 upgrade messed up my Bluetooth connections. When it worked, the GLO was way more stable then the GT730F – only because it was designed as a real aircraft GPS device (within 1 meter over 1 hour operation). The units we stationary positioned for all the testing.

http://www.softrac.ca/Navio2.mp4

http://www.softrac.ca/GT730F.mp4

The GT730F_later video was 15 minutes later.

http://www.softrac.ca/GT730F_later.mp4

I have gave up on the GPS for now and focused on the Barometer and ADC units of the Navio2. They too are all over the place - i.e. voltages should not be jumping all over the place - remember I have ONLY the Pi and Navio2 on the bench for the testing.

Satellite levels could be better, but are fine. Overall that does look like a normal behaviour for u-blox.
I don’t know why your other unit is showing better positioning - maybe that’s because it is set to different type of profile for acceleration or for some other reason, but I see nothing wrong with Navio2 GPS here.

As for ADC and Barometer - could you please post here the values?

I’ve set up a bench test.

Raspberry Pi / Navio2 only

Powered from clean power source with additional 35000 MFD (that’s 35.000 Farads) and checked with oscilloscope connected to the server rail. Similar readings from pi power and/or power port.

Only A0 and A1 values should be valid – all others are unconnected!

Voltage reading on Mission Planner are also not stable when tested. And yes I did not have the two running at the same time!

I use the XL-MaxSonar (MB1240) using ADC A4 when assembled on my quad.

Test 1 - using putty over a network connection (Wi-Fi).

pi@navio:~ $ ./Navio2/C++/Examples/ADC/ADC
A0: 4.8300V A1: 4.9480V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0300V
A0: 4.8600V A1: 4.9680V A2: 0.0400V A3: 0.0220V A4: 0.0080V A5: 0.0300V
A0: 4.8580V A1: 4.9680V A2: 0.0380V A3: 0.0200V A4: 0.0080V A5: 0.0300V
A0: 4.8480V A1: 4.9600V A2: 0.0380V A3: 0.0200V A4: 0.0080V A5: 0.0300V
A0: 4.8480V A1: 4.9560V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8460V A1: 4.9620V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8420V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0140V
A0: 4.8420V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8460V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0080V A5: 0.0320V
A0: 4.8480V A1: 4.9560V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0140V
A0: 4.8480V A1: 4.9560V A2: 0.0380V A3: 0.0080V A4: 0.0300V A5: 0.0100V
A0: 4.8460V A1: 4.9560V A2: 0.0400V A3: 0.0200V A4: 0.0080V A5: 0.0320V
A0: 4.8500V A1: 4.9560V A2: 0.0400V A3: 0.0200V A4: 0.0080V A5: 0.0320V
A0: 4.8480V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8420V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0300V A5: 0.0100V
A0: 4.8460V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0140V
A0: 4.8480V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8480V A1: 4.9520V A2: 0.0400V A3: 0.0200V A4: 0.0080V A5: 0.0320V
A0: 4.8460V A1: 4.9620V A2: 0.0400V A3: 0.0080V A4: 0.0080V A5: 0.0320V
A0: 4.8460V A1: 4.9580V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0140V
A0: 4.8460V A1: 4.9600V A2: 0.0420V A3: 0.0080V A4: 0.0080V A5: 0.0320V
A0: 4.8480V A1: 4.9560V A2: 0.0400V A3: 0.0200V A4: 0.0080V A5: 0.0320V

Test 2 - removed the Wi-Fi USB dongle - local console and keyboard

A0: 4.8600V A1: 4.9620V A2: 0.0380V A3: 0.0200V A4: 0.0080V A5: 0.0300V
A0: 4.8720V A1: 4.9680V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0140V
A0: 4.8720V A1: 4.9640V A2: 0.0380V A3: 0.0220V A4: 0.0080V A5: 0.0320V
A0: 4.8740V A1: 4.9700V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8740V A1: 4.9780V A2: 0.0400V A3: 0.0200V A4: 0.0080V A5: 0.0320V
A0: 4.8740V A1: 4.9680V A2: 0.0400V A3: 0.0100V A4: 0.0320V A5: 0.0120V
A0: 4.8740V A1: 4.9680V A2: 0.0380V A3: 0.0200V A4: 0.0080V A5: 0.0300V
A0: 4.8720V A1: 4.9640V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8720V A1: 4.9740V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0100V
A0: 4.8760V A1: 4.9700V A2: 0.0400V A3: 0.0080V A4: 0.0080V A5: 0.0300V
A0: 4.8740V A1: 4.9680V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0120V
A0: 4.8640V A1: 4.9680V A2: 0.0400V A3: 0.0080V A4: 0.0080V A5: 0.0320V
A0: 4.8740V A1: 4.9700V A2: 0.0380V A3: 0.0200V A4: 0.0080V A5: 0.0300V
A0: 4.8720V A1: 4.9700V A2: 0.0400V A3: 0.0080V A4: 0.0320V A5: 0.0320V
A0: 4.8700V A1: 4.9680V A2: 0.0420V A3: 0.0080V A4: 0.0300V A5: 0.0120V

I also see nothing wrong here. What do you expect from these values?
A0-A1 show values with small jitter (which is normal for ADC), A2-A5 show “slightly random” values because they are unconnected.

I thought they would be more constant :frowning:

I looked through the ArduPilot code and they have some software de-jitter on the baro, but there is nothing on the ADC channels. Maybe there should be so the values don’t jump around when looking at values through MissionPlanner. I guess these can be corrected through software.

Too bad we can’t fix the GPS through software.

That’s just how these things work, they are not ideal - they have jitter, deviation etc.
Modern software (such as ArduPilot) handles sensor data very well.