Navx

[Silicasandwhich]

• fixed navx java sources
• made networktable for reading pitch

[argylearson]

Just saw this: https://pdocs.kauailabs.com/navx-mxp/software/roborio-libraries/

"[Update: 1/7/2022 – Version 4.0.442 is now available – which is compatible with the FRC WPILib 2022 Release Candidate 1. For more details on installation, see the page corresponding to your chosen development language.]"

[Silicasandwhich]

So the things is that the last update to the SimDevice.java file was June 3rd, 2022, and it removed the deprecated create[datatype]() functions used by the distributed version, so the 1/7/22 update to the navx libraries wouldn't be made for compatibility with that version of the file. Furthermore, the final WPILib 2022 release was in February of 2022, so the update to SimDevice.java wouldn't have broken compatibility with navx that year. So, in total, if the most up-to-date version was made in 1/7/22, we do indeed need to use our manually-patched version

[argylearson]

Gotcha. Hmm, if it's just a runtime error and not a compile error, does wrapping the calls to the NavX in if (Robot.IsReal()) fix the issue?

[Silicasandwhich]

I think the only reason it's not a compilation issue is because of how third party libraries are distributed (via maven, meaning they're precompiled). Additionally, the simulation issues weren't the only problem, there was also the call to RuntimeDetector.isRaspbian() in the constructor, which means that simply having an AHRS in your code will cause runtime errors no matter what.

[Silicasandwhich]

progress as of now:

• gyroscope rotation measurements are very accurate and don't seem to be drifting
• we have learned that the displacement axes follow the "minecraft" coordinate system (y is vertical, x and y are horizontal, which suggests it's just a standard right hand coordinate system).
• gyroscope displacement measurements are very much not accurate, the documented error is around 10 cm (which is already pretty high), but our testing was much less flattering. The Z axis displacement seems to just balloon off into infinity while the robot is at rest, and the Y axis measures a drop of a couple feet as a change by six meters. this makes sense since double integration of acceleration will make minor sensor noise have a much larger effect than it would on rotation, but it shouldn't be happening to this extent
• What exact directions the displacement axes represent is unclear and will require testing to determine (basically, are they relative to the robot at all times, are they relative to the robot's orientation when it was last reset, etc.)
• Displacement accuracy may be improved using vision targets, but I see no reason to use vision targeting to correct rotational readings.

[Silicasandwhich]

going to merge this for now so that the main branch doesn't runtime error, but ill open it again