Position drift problem on rover

This position drift problem has existed for a long time. I used two different ArduPilot hardware, three firmware, two testing sites, and two different rover for a control group experiment.
Number of satellites:>20
Hdop: less than 0.5
EFK: Normal (white characters)
no red alrm on mission planner

The phenomenon is as follows: after the rover completes driving along the planned path (a rectangle with 4 waypoints) and returns to the starting point (keep arming, keep power on). After waiting for 10 minutes I drove again along the same planned path and I saw that the four actual waypoints of the vehicle had shifted in one direction by 5-10 meters(Rectangle drift as a whole, with no change in the angles of the four corners of the rectangle)by my eyes. But Mission Planner shows the path points of the vehicle’s movement are still the same, without any drift or shifted. Sometimes after 5 or 10 minutes when driving the same path again.The actual driving trajectory of the rover will return to the original correct path(back to the first time path)

This phenomenon feel like caused by GPS drift, but the number of satellites is greater than 20. hdop is less than 0.5. The number of satellites and GPS signal quality should be sufficient for normal operation. So I don’t know where the problem is.

If it is the same flight control/firmware/vehicle, I may suspect that I did not check for interference issues myself or that there is a bug in firmware. But there is a control group experiment. It is obvious that interference or other hardware issues can be ruled out.
So does anyone know what the approximate cause of this problem is?

Thanks all helpers

Hi @Fayeli,

Thanks for the report. This is surely GPS drift. I really cannot imagine a software bug that would cause a drifting position as described.

I suspect the solution is to get a high quality GPS like a UBlox F9P and also make sure that it is far away from sources of interference. Around 1.5Ghz is the frequency apparently so radios and companion computer with unshielded USB cables are a common cause.

If you have a log we can have a look but really, it’s the GPS.

I’ve had this exact behavior once when my base station was allowing the gps correction signal to float around. The root cause of my problem was fixed by correcting the configuration of the base station.

thanks for your reply

did u use GPS or RTK?My position drift problem is on GPS.
So if u use GPS,please let me know how to fix this problem.

Thanks for ur reply

I use neo3 GPS on one rover and MG-902 gps(M9) on another rover.Those are the best GPS I can get.

I can sure these not any 1.5GHZ sources of interference around.The radio is 2.4ghz.and no any video transmitter or computer on rover.

Do you have any solutions or suggestions to solve this problem?

I’ll sent a log to you after next test.

In my case I use a base station to generate an RTK correction signal based on a single accurately known GPS point. That correction signal is sent to the rover to be used by the on-board GPS units. I was using the survey-in feature on the base station to find the GPS reference point. If you start trying to use the reference before it is done surveying in, you see the entire reference system shift around. I learned that after the reference point is established, it is best to enter the GPS coordinates into the base station manually and to take it out of the survey-in mode.

1 Like

Hi
what do you mean by base station?I mean what device?
It’s a good way to deal with this difrt problame base on you idea.But it looks like you need do this process everytime when you start to use rover.It deviates from my desired outcome

I want to find a way to reduc position drift.Like more higher sensitivity GPS antenna/modification/installation of shielding equipment or devices for a certain parameter in firmware.

Once base stations are setup and operational most people just leave them running mounted up on a permanent structure with an open view of the sky (typically a roof top). They provide that reference to a known fixed GPS point to eliminate drift. Without RTK GNSS receivers (even good ones) are only accurate to 2-3 meters. That is why applications that require precision centimeter level placement use RTK to feed that reference to the onboard GNSS receiver.

RTK correction signal can also be obtained in other ways. Sometimes the correction service is purchased and sometimes it is provided by your local government agencies. Sometimes NTRIP (Networked Transport of RTCM via Internet Protocol) service is even provided online free. In my case here in the US it was cheaper long term to just build my own base station.

Thank you for your patient help. This is a great suggestion
I understand what you mean now.

  1. Set up your own RTK base station, and the time required for precise positioning after each startup is usually 1-2 hours. And I hope the rover can quickly locate and operate in different venues.
    2.In my country, there are also similar internet-based RTK positioning services that are paid monthly.

But I don’t need high-precision positioning like RTK. Because GNSS has sufficient accuracy. But the problem of overall path translation caused by position drift is very troublesome. And I hope to use low-cost solutions to reduce position drift.

All of this discussion about RTK is fairly moot and is overcomplicating the solution.

The Neo3 series is quite old and not very performant. There are plenty of fairly low cost solutions that use more modern modules like this M10Q module from Matek.

1 Like

Thank you Yuri

I will try this M10Q.Do you know any other GNSS modules like M10Q?I’d like to have a try.

you need to give a list of the components on your machine, there are lots of devices that can really mess with GPS signals, anything usb, some lidars. pi cameras, gopro wifi.

Google knows if you search for “gps m10”…