V5 GPS sensor slow heading update / converging rate

The team I am mentoring is trying to use the GPS sensor but ran into an issue where the reported heading from the sensor was taking several seconds (3 to 5 seconds) to stabilize at an accurate reported heading, after the robot stopped motion. They are using the GPS sensor as part of a drivetrain in the configuration and using Python coding. They print out the reported data using the drive train heading command, to the console every 1 second, and you can see it takes 3-5 seconds for the angle to converge to a stable value. It slews/drifts about 5-10 degrees over that 5 seconds. They are not yet doing any additional filtering in the Python code which would only exacerbate this type of lag.

They think they observe the value as displayed on the Brain using the built in sensor display screen, seems to stabilize much faster to an accurate reading (hard to tell for sure).

Is this expected behavior of the sensor that it has some built in filtering that takes several seconds to converge? Is there a way to turn it off or speed that up? If they cannot trust the sensor angle for several seconds, they are not sure how useful the sensor can be. Adding 5 second delays in an auton or skills algorithm are prohibitive.


No, it should respond quickly.
You need to verify that the GPS is seeing the GPS field code strip (use the devices screen) and that the field strip is installed correctly.


The GPS “signal” is always reported as “100”, and when they look at the debug camera image on the devices screen on the Brain, it always looks like it sees the code strip really well and highlighted in red always. That debug image only refreshes at a super slow rate of like 1/second, but they assume that is just because it is a debug mode, and real GPS sensor is updated much faster…but that is just an assumption.

That’s normal, the image data is large so takes a while to transfer to the brain.

When looking at the alternate GPS dashboard, the top down view, you should see position and heading updating quickly.


Yes, the alternate dashboard does update quickly and looks accurate fairly quickly after the robot stops motion. It is just the data that is pulled using the Python code, takes several seconds to stabilize to an accurate value…it slews from say 45deg to 55 deg over 3-5 seconds, then says at 55deg +/- 0.1 deg forever until a new move is made. The robot is not vibrating, moving as far as they can tell. It “acts like” there is some moving average algorithm that is filtering the reported output data to the code.

Could it be related to using the GPS as “part of the drivetrain”, instead of using the GPS as a standalone sensor?

1 Like

ok, I’ll take a look and see if we can reproduce that. There is no filtering as far as I remember.


I tested with this code, I see no issues.

# ---------------------------------------------------------------------------- #
#                                                                              #
# 	Module:       main.py                                                      #
# 	Author:       james                                                        #
# 	Created:      2/6/2023, 4:31:35 PM                                         #
# 	Description:  V5 project                                                   #
#                                                                              #
# ---------------------------------------------------------------------------- #

# Library imports
from vex import *

# Brain should be defined by default

# gps on port 20

def show_gps():
      brain.screen.print_at("gps heading %8.2f" %(gps.heading()), x=10, y=60 )
      brain.screen.print_at("gps x       %8.2f" %(gps.x_position()), x=10, y=80 )
      brain.screen.print_at("gps y       %8.2f" %(gps.y_position()), x=10, y=100 )

Thread( show_gps )