Precision and drift of GPS position

A

Angelo

Well-known member
Hello,
With a GPS, I want to measure duration and distance of the braking phase of railway machines, from 100km/h to 0km/h.
I don't need absolute position precision. I juste need to measure distance of braking phase.
GPS reception is good, test site is in a rural area.
A first prototype is working, I receive NMEA and uBlox messages from a 10Hz module on Teensy 4.
So no electronics problems, as it is designed by electronics and software engineers.

But what about precision and drift of position coordinates????

I know there is drift in position values, but what is the "frequency" of this drift ?
I am assuming there is a negligible drift during the measurement phase of 10-30 seconds. Is this correct ????

A second solution is to measure distance by integrating the speed, which is very precise.

There is also a solution to use both speed and position, and fit them in a kahlman filter.

Any hints, links, ideas are welcome.
 
@Angelo: I don't have a direct answer to your specific question, but maybe you could employ the methodology that is employed by the <DGPS system> (a friend of mine wanted to create a robotic mowing system, & needed a way to remove the variability of the reported GPS system, so this is the approach that he successfully applied to his problem):

Using GPS unit #1, run it in a fixed position for some long period of time (24-48 hours or more) & have it to determine its "average" position (the longer it is run, the better will be its position determination). This becomes your "reference GPS". It will remain in its fixed location, recording the difference between its "average" position & the calculated positions during the measurement period of your device under test (DUT).

GPS unit #2 will be on your DUT, recording reported positions, which will include the slight variability that you are looking to remove. By applying the correction as recorded by GPS #1 to the position values recorded by GPS #2, your resulting GPS data captured for subsequent processing should be much more accurate.

Hope that helps . . .

Mark J Culross
KD5RXT
 
Last edited:
kd5rxt-mark said:
@Angelo: I don't have a direct answer to your specific question, but maybe you could employ the methodology that is employed by the <DGPS system> (a friend of mine wanted to create a robotic mowing system, & needed a way to remove the variability of the reported GPS system, so this is the approach that he successfully applied to his problem):

Using GPS unit #1, run it in a fixed position for some long period of time (24-48 hours or more) & have it to determine its "average" position (the longer it is run, the better will be its position determination). This becomes your "reference GPS". It will remain in its fixed location, recording the difference between its "average" position & the calculated positions during the measurement period of your device under test (DUT).

GPS unit #2 will be on your DUT, recording reported positions, which will include the slight variability that you are looking to remove. Be applying the correction as recorded by GPS #1 to the position values recorded by GPS #2, your resulting GPS data captured for subsequent processing should be much more accurate.

Hope that helps . . .

Mark J Culross
KD5RXT
Click to expand...
Sparkfun has such a system, including a better antenna. Gives cm precision.

Mmm can also be used with one unit. It will give a far better accuracy than a "normal" unit.
 
Last edited:
Considering that you're "trains" are running on tracks, it becomes a one dimensional system (I hope ;-) ). Also I expect rather big distances and repeat tests.

So you can determine a lot of the errors when testing the system (don't have to brake hard the first time...). I do expect good accuracy if you use an antenna with a clear view to the sky.
 
Mark,

For various reason, RTK or dual receiver setup is not applicable. Too complex for the end users.

I asked the final user about what he currently has. He told me that the current system, based on an encoder with pulse counters, displays meters with one decimal. Meaning 10cm resolution :eek:

I will implement various algorithm and display values. I could test them on the road with my car :)
 
Angelo said:
A second solution is to measure distance by integrating the speed, which is very precise.
Click to expand...
In this solution, what is your source for speed? Measuring rotations of the wheels or GPS?

If you can add another sensor besides the GPS, such as wheel speed or even acceleration, a Kalman filter can give good results. A simpler alternative that may work is a complimentary filter. Either of these two methods would require fine tuning for your specific application.
 
Angelo said:
Mark,

For various reason, RTK or dual receiver setup is not applicable. Too complex for the end users.

I asked the final user about what he currently has. He told me that the current system, based on an encoder with pulse counters, displays meters with one decimal. Meaning 10cm resolution :eek:

I will implement various algorithm and display values. I could test them on the road with my car :)
Click to expand...
I suspect that the sparkfunLG290P type of receiver (+antenna) will give a far better accuracy. If I read the docs correctly 0.7meter absolute without RTK. This far better than "normal" GNSS receivers. It will give almost certain far better relative accuracy.

For about 400 euro's including antenna that seems a no brainer, if it's a business decision.
 
msadie said:
In this solution, what is your source for speed? Measuring rotations of the wheels or GPS?

If you can add another sensor besides the GPS, such as wheel speed or even acceleration, a Kalman filter can give good results. A simpler alternative that may work is a complimentary filter. Either of these two methods would require fine tuning for your specific application.
Click to expand...
The main goal of this project is to avoid the encoder, which is not part of the machine. They have to each time install it, with cables hanging around.
A solution where they open the window, install the magnetic antenna, connect the receiver to the power connector is a dream.

I know GPS speed is very precise, so integrating it should be easy.

On the current system, the zero speed detection is very imprecise. As it triggers the timer counter, the braking duration is very imprecise. The distance is precise, due to the use of an encoder on an axle.

Thanks for the ideas, I will try with a NEO-6P receiver I have.
 
For shorter distances integrating velocity works a lot better than change in position. For cars this is certainly the case, you can get far more accurate measurements using the velocity method. But it does depend on how quickly you stop, the faster you come to a stop the better it works since there is less time for the errors to add up.

However depending on the deceleration and jerk rates (rate at which acceleration changes) you may want to play with the GPS dynamics mode (CFG-NAVX5 message from memory). The standard mode applies smoothing filters that can result in speed errors when things are changing rapidly. Changing to a higher dynamics mode gives a nosier but more responsive output. What works best will depend on the data.

For zero velocity detection you need to put in a slight estimate since you'll never get exactly zero. Look for a value below a certain threshold and then interpolate from that. Or look for below a certain speed and large changes in direction.

One issue to look for, the ublox systems sometimes skip output cycles if you dial the output rate up too high. Reducing the maximum number of satellites used can help with this if you need to. But make sure to check the position/velocity time stamps and if one is missing interpolate to fill in the gap.
 
Last edited:
I'm a bit surprised: The GPS is a positioning device and speed is calculated from those positions.

Why would speed then more precise than location?

BTW. Am I correct that the NEO-6P receiver is limited to 5Hz updates? Or more than 5meter at 100 km/h.
 
AlainD said:
I'm a bit surprised: The GPS is a positioning device and speed is calculated from those positions.

Why would speed then more precise than location?
Click to expand...
Because GPS speed isn't based on position change. GPS calculates speed based on the doppler shift of the signals. If you know where the satellites are and the component of your velocity towards or away from them then you can calculate your systems velocity.

You do first have to account for satellite motion, earth rotation (which is position dependent), relativistic effects and receiver clock errors. But once you've done that the rest is easy.

AlainD said:
BTW. Am I correct that the NEO-6P receiver is limited to 5Hz updates? Or more than 5meter at 100 km/h.
Click to expand...
Yes, by the book it's only able to run at 5 Hz. I have seen that generation of parts run fairly reliably at 10 Hz if you play with the settings to limit the number of satellites used in the solution calculation but that does involve a bit of messing around. I'm not sure why anyone would be using that for a new design, the Neo / Max 9 or 10 series would be a far more sensible choice for a new design.
 
FWIW trying to establish the distance moved by a train based its wheel rotation you quickly loose accuracy, which quickly accumlates over time and distance. When I worked on an ETCS project a few years back we had to resync actual train location with calculated train location using trackside equipment placed at regular intervals. The issue is that metal wheels on metal rails invariably slip when applying acceleration / deceleration forces and taking environmental factors such as adhesion levels, weather, gradients etc into consideration. Using GPS RTK seems a good solution.

www.racelogic.co.uk based in the UK, provide COTS solutions for high precision positioning including braking performance.
 
Last edited:
Turby said:
FWIW trying to establish the distance moved by a train based its wheel rotation you quickly loose accuracy, which quickly accumlates over time and distance. When I worked on an ETCS project a few years back we had to resync actual train location with calculated train location using trackside equipment placed at regular intervals. The issue is that metal wheels on metal rails invariably slip when applying acceleration / deceleration forces and taking environmental factors such as adhesion levels, weather, gradients etc into consideration. Using GPS RTK seems a good solution.

www.racelogic.co.uk based in the UK, provide COTS solutions for high precision positioning including braking performance.
Click to expand...
The Racelogic systems generally use the velocity based methods for calculating stopping distance. The professional grade products use a 100 Hz GNSS system and have the option of also integrating inertial measurements. In that situation RTK doesn't normally add much, RTK improves the position but doesn't do much for velocity.
Only if the distances are large enough that change in position gives a better results than integrating velocity would RTK be of significant benefit for stopping distance.

Since they are looking at using an old GPS that they had sitting around I'm guessing the racelogic products are probably a little outside the budget for this project.
 
I will use of the NEO-6P just for the prototype phase, and just because it is in my drawer with an unused Teensy board.
For the final product, I will use a more recent GPS module. Like the Neo / Max 9 or 10 series mentioned by AndyA.

Another reason to move to a GPS solution is also to avoid the errors mentioned by Turby.

The end users are not in the electronics/software side. They are the guys who make the final setup and check of the machine after assembly. They have a mix of hydraulic, pneumatic, electric knoweledge. One of the test is to check the brakes.
 
Last edited:
Will you have an indication available telling you when the brakes are applied? Some sort of signal you can hook into (probably with lots of protection to prevent it blowing up the processor) that can be used to tell you when to start measuring?

As AlainD indicated at 100km/h you will have a fair distance between GPS points, even with a 25 Hz system it'll be over a meter. And if you have to calculate the start of breaking point based purely on when the velocity starts to decrease this could lead to some significant errors.
If on the other hand you have a digital signal indicating when to start measuring from you can use that combined with the PPS from the GPS to give you a very accurate break start point indication.

Some more expensive GPS systems have a trigger input that they can timestamp for you and give you the signal time to within a few ns. In the ublox price range you need to do this manually in the processor, either by timestamping an interrupt or using a timer capture input. Not quite as good but probably good enough.
 
In the current system, the driver start the measurement by pressing a button. He has one hand on the speed/brake lever, and the other on the button. At the same time he presses the start button and apply brake. When the vehicle stops, he writes the numbers, time and distance, on a test report.

Writing this reminds me that the Teensy 4.1 has a SD slot and USB. It could even generate automaticaly the test report with date, time, position of test and results. At the end, the operator removes the SD or USB stick, or connect the PC and retrieve the reports.
 
I would use an accelerometer to detect start and stop of braking. Likely to be jolt at the end giving negative deceleration as the vehicle comes to a stop and the springs (suspension) settle.
You could potentially double integrate the acceleration (deceleration) to get distance travelled.
 
Back in 2023, a friend and I developed a logger for race cars. The logger was based on the Sparkfun SparkFun GPS-RTK Dead Reckoning Kit (SMA).
This module uses a UBlox ZED-F9R, which integrates a high-end GPS chip with accelerometers and wheel-tick sensors (which we did not use). My friend built the logger box and used connections with the Pacific Northwests Porsche Club to put the logger on some cars running test laps at the Ridge Motor Sports track near Shelton, WA. I wrote the T4.1 sketch to collect the data at 25Hz and a MatLab app to display the lap data as a simulated overhead view of multiple laps. In short, the video shows multiple laps by the same (or different) cars on the track as if they were racing each other. In reality, each 'car' is the data from a lap during which the driver had the track to himself.

5 fast laps by a very good driver in Porsche GT3

The 25Hz data files show good precision of the GPS data, which generally included data from multiple GNSS systems (GPS with SBAS, Galileo, and GLONASS.) The background track image is from Google Earth and has been 'adjusted' compensate for a few meters of error in the image as a hilly track is projected on a flat screen. The overall accuracy of the plotted images is about 1 to 1.5 meters---which is why the car sometimes seems to drive over the track borders. In reality the driver, one of the best in the club, keeps his wheels on the track while driving the best route.

The 'car' plots include a visual clue as to acceleration: 'taillights' which are green when accelerating, yellow when coasting, and red when braking. The data panel shows speed in MPH and acceleration in meters/second. X acceleration is speed change, Y acceleration is cornering centripetal acceleration.

The code for the logger is optimized for the ZED-F9R and T4.1. I can share the source sketch if anyone else is using that chip set. It's an expensive module (~$350), but the integrated accelerometers and gyros are worth the cost if your budget allows that expense. Getting the chip to send data at 25Hz required many hours of testing configurations and setup commands to the ZED.

While we were doing some initial tests, we found that the short-term precision of the ZED-F9R was about 0.4 meters drift over a 2-minute lap time.
 
AndyA said:
Because GPS speed isn't based on position change. GPS calculates speed based on the doppler shift of the signals. If you know where the satellites are and the component of your velocity towards or away from them then you can calculate your systems velocity.

You do first have to account for satellite motion, earth rotation (which is position dependent), relativistic effects and receiver clock errors. But once you've done that the rest is easy.
Click to expand...
Thanks, I didn't know that.
 
Angelo said:
In the current system, the driver start the measurement by pressing a button. He has one hand on the speed/brake lever, and the other on the button. At the same time he presses the start button and apply brake. When the vehicle stops, he writes the numbers, time and distance, on a test report.

Writing this reminds me that the Teensy 4.1 has a SD slot and USB. It could even generate automaticaly the test report with date, time, position of test and results. At the end, the operator removes the SD or USB stick, or connect the PC and retrieve the reports.
Click to expand...
You can also "write" the report to the regular usb as keypresses when they have a notepad open.
 
mborgerson said:
Back in 2023, a friend and I developed a logger for race cars. The logger was based on the Sparkfun SparkFun GPS-RTK Dead Reckoning Kit (SMA).
This module uses a UBlox ZED-F9R, which integrates a high-end GPS chip with accelerometers and wheel-tick sensors (which we did not use). My friend built the logger box and used connections with the Pacific Northwests Porsche Club to put the logger on some cars running test laps at the Ridge Motor Sports track near Shelton, WA. I wrote the T4.1 sketch to collect the data at 25Hz and a MatLab app to display the lap data as a simulated overhead view of multiple laps. In short, the video shows multiple laps by the same (or different) cars on the track as if they were racing each other. In reality, each 'car' is the data from a lap during which the driver had the track to himself.

5 fast laps by a very good driver in Porsche GT3

The 25Hz data files show good precision of the GPS data, which generally included data from multiple GNSS systems (GPS with SBAS, Galileo, and GLONASS.) The background track image is from Google Earth and has been 'adjusted' compensate for a few meters of error in the image as a hilly track is projected on a flat screen. The overall accuracy of the plotted images is about 1 to 1.5 meters---which is why the car sometimes seems to drive over the track borders. In reality the driver, one of the best in the club, keeps his wheels on the track while driving the best route.

The 'car' plots include a visual clue as to acceleration: 'taillights' which are green when accelerating, yellow when coasting, and red when braking. The data panel shows speed in MPH and acceleration in meters/second. X acceleration is speed change, Y acceleration is cornering centripetal acceleration.

The code for the logger is optimized for the ZED-F9R and T4.1. I can share the source sketch if anyone else is using that chip set. It's an expensive module (~$350), but the integrated accelerometers and gyros are worth the cost if your budget allows that expense. Getting the chip to send data at 25Hz required many hours of testing configurations and setup commands to the ZED.

While we were doing some initial tests, we found that the short-term precision of the ZED-F9R was about 0.4 meters drift over a 2-minute lap time.
Click to expand...
Where and how did you place the antenna, seems a bit complexer given the forces on a race car...
 
The antenna was usually taped in place on the front dashboard or inside the rear window. We tried to keep it near the center of the car. One thing we learned is that YOU CANNOT place the antenna on the flat deck under the rear window and just above the engine. At certain engine speeds when the car is accelerating, the large currents going to the fuel injectors just below the antenna generate RF harmonics that will saturate the front end amplifier in the antenna circuit and you lose GPS signal for several seconds. The max accelerations were normally less than about 1.1Gs. The GPS module was usually mounted on a foam pad that helped isolate the accelerometers from high-frequency vibrations. Calibration coefficients were also applied in the MatLab program to correct scale and offset errors so that when sitting still the X and Y accelerations were zero and the vertical was 1.0G. We weren't too concerned about absolute accuracy for the accelerations and +/- 0.1 G was adequate.
 
Going back to the OP, I guess the solution depends on what level of accuracy and precsision is required.
 
BriComp said:
I would use an accelerometer to detect start and stop of braking. Likely to be jolt at the end giving negative deceleration as the vehicle comes to a stop and the springs (suspension) settle.
You could potentially double integrate the acceleration (deceleration) to get distance travelled.
Click to expand...
End of braking is far less critical. Being slightly off on the time to stop adding distance doesn't make much difference when you are going slowly. It's that start of braking that matters.
And do you want when they first press the peddle/handle or when it first starts to have an effect, at 100km/h that can make quite a difference.
One option is to put a pressure sensor on top of the brake activation switch/peddle. It's extra equipment to install but gives you the time the user generated the input rather than when that input starts to make a difference. In some situations that's an important distinction.
 
You must log in or register to reply here.
Back
Top