U-Blox Neo M8M GNSS receiver leads to toilet bowl effect on loiter mode

Hardware Other Hardware
, , , ,
1

Dear all,

I have connected the U-Blox Neo M8M GNSS receiver to my Pixhawk, and ONLY the COMPASS output of 3DR’s GPS+MAG module as an external compass to the I2C port. (edit: The 3DR module is connected to Vcc and GND via its GPS port, it has the status LED on, and is visible to Mission Planner on compass calibration).

After that, I fly an octacopter, and set it to go in Loiter mode, but although the GNSS signal quality is OK, after few seconds it ends up in toilet bowl effect.

Then, I replace the M8M by the 3DR GPS and do the same test, and Loiter mode works fine. Like this, I can discard compass calibration and interferences as the sources of error.

I have been sniffing the data written by 3DR GPS, and I see the following U-Blox messages:

  • NAV-SOL
  • NAV-STATUS
  • NAV-DOP
  • NAV-VELNED
  • NAV-POSLLH

While my M8M was only writting RXM-RAWX, and RMC, VTG and GGA NMEA messages.

My questions are:

  • Can it be that the lack of this NAV-* messages is causing the error in the Loiter mode?
  • Why is Pixhawk not configuring the M8M to write this messages?

Right now I don’t have a UAV to test the M8N with the new configuration, and would like to be sure I have figured out the problem before next flight.

2

I’m not sure that your 3dr compass is even working.

If you don’t have the GPS portion connected, Im pretty sure the compass isn’t being powered. If I recall the serial connection provides the +5v and gnd, and only the (2) I2C data wires are connecting to your I2c port or splitter.

That is unless you’ve connected 5v and gnd to the serial connector of the 3dr gps.

So if what I’m saying is correct, your compass isn’t on, and it’s defaulting to the internal compass, which seems to never be very reliable on PH, or may not have even been calibrated.

I can see this causing your problem.

Just a thought…you might check and see if it’s using the external (does it show 2 compasses in mission planner when you hook it up this way?)

3

As @Lance_B pointed out, your compass in the 3DR GPS will not be powered if you have pulled the GPS connector.

To use this compass run a separate power line to the GPS port (if the I2C has 3 wires) or a power and ground (if the I2C has only 2 wires).

Have been caught by this myself.
It’s easy to overlook when your are shuffling components around.

4

Hi @Lance_B and @mboland ! thanks a lot for your replies. Actually I did power the 3DR module by hooking the power lines on the GPS port to the Pixhawk. I am sure about that because I could see the status LED on the 3DR ON. Moreover, when calibrating the compass, I could see 2 compasses on Mission Planner. That’s why I discarded the option of missing/bad external compass, and focused in emulating the GPS messages that the 3DR is writing. Any clues about that?

5

Ok, if someone was to come across this post with a similar problem, that’s how I solved it:

our problem was that the U-Blox chipset was not configured to accept UBX input protocol on its UART1 interface (which is the one we are using to connect it to the Pixhawk). Pixhawk is continuously sending and receiving configuration messages (in UBX format) to the GNSS module, and since we had not enabled this protocol, the Pixhawk messages didn’t have any effect. That’s why, even when we configured our module to write the exact same messages as 3DR writes, loiter mode still failed.

In my opinion, it would be a good idea if the APM could write a warning in this situations, otherwise it looks to the user as if everything was ok (Mission Planner was telling us 3D fix).

Thanks anyway for your help!

6

How Strange. Pixhawk is supposed to configure the GPS automatically. Apparently did not work in your case for some reason.
So always good to verify the GPS config via u-Blox u-Center configuration software.