After an interesting test session yesterday I have new results to add to this discussion. When I wrote our heading tracker I assumed that getAngle() and getYaw() would move in sync. It seemed to me that the yaw would be derived from the total angle accumulated by the Navx. Testing of this code seemed to bear this out as our heading tracking was solid…but that testing did not include many (if any calls) to resetYaw.
Now our tests seem to show that these two items don’t move in sync, at least not always, and we see this at the resetYaw() call. In our testing we record the yaw and heading (getAngle derived) just prior to resetYaw() and just after. In most cases (though not all), we see the yaw is not zero after the reset, but some value typically a few degrees. However, the getAngle value (our heading) has not changed by the same amount, typically but not always unchanged from before resetYaw(). We then move on to the start of the next auto move where (as part of this investigation) we record the yaw and heading again. At this point the yaw has changed again (not unexpected) but the getAngle value now matches the original getAngle value plus this 3rd read of the yaw. This happens on a lot of resets but not all and the are some variations of the readings but there is the strong suggestion of some disconnect between getYaw and getAngle.
This could be our code but I have checked and checked it and don’t see anything to explain this.
A supporting observation is that our auto routine uses a mix of straight driving schemes, one based on not deviating from zero yaw (requires a resetYaw at start of drive) and one based on driving to a specified heading. We visually observed that as the routine progressed, the heading driving seemed to get off and a heading of zero (for instance) would end up not pointing in the correct physical direction, meaning the robots idea of heading zero no longer points directly down the field. This appeared to explain our routines tendency of getting off heading and failing to navigate the course. As part of the tests yesterday, all of the zero yaw driving moves were replaced with drive to heading moves (no calls to resetYaw) and the heading did not deviate from correct physical heading and the robot navigated the course correctly.
A separate test had the robot lined up with a physical mark on our floor and heading initialized to zero. Lots of teleop driving all around the room including greater than 360 spins and then lining back up with the physical mark. The final heading, zero. We then added a button to call resetYaw(). We executed the same driving test but pushed the button to call resetYaw() randomly during the driving. At the end when we lined back up with the mark, the heading was not reading zero, a few degrees off.
To summarize, it appears we are seeing cases of resetYaw() resetting getAngle() but not resetting resetYaw()…or they are both reset but then getYaw() changes without a corresponding change in getAngle().
Do you know what the relationship is between these two angle measures by the Navx?