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.
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.
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?