Is anyone having any problems getting a GPS fix using their BlueBoat or a Navigator in general? We have tried with 2 different BlueBoats and a stand alone Navigator with the same MRO GPS units in the BlueBoats and a Here 2 and we do not get a fix. We have tried using 4 different computers, different versions of QGC, different versions of Mission Planner, and even checked in cockpit in Blue OS and never get an accurate reliable lock. Sometimes we will get a lock but the boat is positioned over a mile away from its actual location, upon reboot it will either not get a GPS lock, or will be in a different location away from its actual physical location. We have lots of experience with Ardupilot UAVs and Rovers, and I have never had GPS issues with I tested all the GPS boards. When these GPS units are connected to a Pixhawk Cube Black, they all get a GPS lock in QGC and MP. I am at wits end trying to get a GPS fix as it is paramount to use these boats for our purpose, and the only thing that they have in problem is using a navigator. Anyone else have any problems with GPS and Navigators? Thanks for your help.
Hi @FairweatherIT -
The most interesting aspect of your issue is that your test hardware, when returned to BR HQ, got GPS lock without issue! I’m eager to hear if anyone else is having similar GPS issues…
I just wanted to publicly thank Tony and Willian at BlueRobotics for going out of their way to help us get a GPS lock for our boats, that is repeatable and consistent. I will leave the technical details for them to disseminate, but all is working now at FIT HQ. Thanks for your extraordinary help.
His GPS worked until plugged into the navigator. Upon inspection, we noticed that ArduRover was configuring it to output UBX (U-blox binary protocol). but upon doing that, for some reason the gps either had no lock or didn’t send the messages required for ArduRover to function.
We worked around it by manually configuring it to output NMEA. this can be done either by using u-center or PyGpsClient. We used PyGpsClient as it is able to talk through bridges. I can write a better guide on how to do this later, but the important thing is you need to get the baudrate right in bridges. that is usually 230400 after ArduRover sets it up, or 57600/38400 from factory, IIRC.
On ArduRover, GPS_TYPE should be set to NMEA, and GPS_AUTO_CONFIG should be set to disabled.
The baudrate on the serial port (SERIALX_BAUD_) must also be set accordingly to the baud you setup your gps to.
Again, this is the first time we see this issue. If anyone else runs into it, please report and let’s us know, as it will need more investigation.
We ran into this same issue with Navigator and a uBlox F9P a few months ago. Changed the output to NMEA and it just worked. Any baud rate from 57600 through 230400 worked, but I think we stayed at 230400.
Please can I have some more info on setting up the bridges and forcing the mode of the GPS. I have a customer who has a similar sounding issue after updating to BlueOS 1.3.1.
You should see readable data in the right of the Binary Console. If you see garbled data on the right like the image below, the baud rate is incorrect. Go back and try another.
Go back to BlueOS and delete the Serial Bridge you created.
Go back to Autopilot Firmware → Serial Port Configuration and set Serial 5 to /dev/ttyAMA3. Then Save and Restart. You should now have a working GPS.
Further Problems
After doing this I was able to get the GPS to obtain a fix and connect to satellites, but intermittently I get a problem in QGC and Cockpit where it complains about: GPS1: not healthy. I got this error all the time at a baud of 57600, but this still happens from time to time at 230400 rendering the BlueBoat unusable.
If I set GPS_AUTO_CONFIG to Enabled and reboot, it immediately returns the GPS to the No Fix state.
I have also tried setting the GPS back to default settings and then forcing NMEA. It did not help.
Any further suggestions?
Can someone please dump the config of a known good working GPS for me?
I’m trying to replicate the issue here. I did notice a “drop” in available satellites once switching to Ardupilot’s config, but it does seem to recover after a while (3 sats almost immediately, 6 sats after 10min, while indoors).
…
While setting up the bridges to get a dump, I think I clicked something I shouldn’t (cold start?) and now ardupilot sees no gps again!
Connecting it to u-blox and clicking “Revert to default configuration”
, then connecting it to Ardupilot made it work straight away.
In order to get a file, I had to go the “Generation 9 Advanced Configuration”
window, which allows loading the difference from defaults. And it did generate an human-readable file, which is nice. Here it is: good_settings.txt (138.9 KB)
Manually applying GPS settings and turning GPS_AUTO_CONFIG off is a temporary solution. What is the permanent fix? Have you been able to replicate this on your own hardware?
Hi Chris (@gwa-gwa). I had an epic battle with my GPS back in the summer. Have a look at my detailed thread here:
Long story short: it’s my belief that ArduRover’s gps_autoconfig function is trying to set a particular u-blox protocol parameter that the Gen 9 u-blox chips no longer support. I disabled autoconfig and manually set up my GPS using u-center, and it’s been working great ever since.
My next steps in debugging this are connecting the GPS to both a navigator and a Pixhawk, and checking if there are any differences in the resulting data.
I also still don’t understand why this is so rare.
Do you happen to have any extensions installed?
How often do you get the “GPS1: not healthy” message?
