Correct Limelight pose when running auton

[caseyjbrotherton]

There are two issues that we have found with using limelight for pose estimation:

1. When starting in front of the speaker, and moving directly away from the speaker, there is a static 4 inch error. This could be because something specific in the field. We should add an adjustment, and check on a regulation field when able to do so.
2. When running a multiple note path is run, the limelight position caused the robot to hit the Amp. ( details below )

Notes on 2 based on testing done on January 28th:

Notes about tests on Jan 28th:

• 19:10
  • Test path visited 3 notes on the ground
  • Hit the amp, as well as X was incorrect
  • Limelight and odometry were turned on
  • Log file included as well as screenshot of poses
• 19:24
  • Limelight and odometry were on
  • Path visited 2 notes on the ground
  • ( Grabbed wrong log file)
• 19:37
  • Limelight disabled by covering one april tag
  • Path visited 2 notes on the ground
  • Completed successfully
• 19:57
  • Path visited 3 notes on the ground and ran the intake
  • Limelight disabled by covering one april tag
  • Last note it missed

While running tests, there was network flakiness. Log messages were repeated on the rio log multiple times.

There was an excessive number of Pose logs. ( 2524 over 8 seconds; 1890 over 6 seconds ) Not sure if this has any impact, but noting it.

videos and logs:

https://drive.google.com/drive/folders/1Q-TxwRmtFgTbT9DsKBl7l5xFkL1TmkzR?usp=drive_link

[caseyjbrotherton]

@riversry Can you put the list of tests that we had discussed on Sunday here?

Only one I can remember is:

• Change the limelight framerate and retest picking up two notes

I would also like to test with isCompetition = true. This will reduce some of the shuffleboard network traffic. I would also like to test just placing the robot in front of the speaker, and check the poses again.

Last time we checked it was 4 inches off in X. I would like to see if that is still the same, and if there is any difference in Y

[caseyjbrotherton]

Here is another thought.

We update the robot pose using LimelightSubsystem every periodic when we find two tags. And we use the latency information as well to allow wpilib to make adjustments based specifically on the latency.

Limelight information is not updating every 20ms, so it appears from code that we are sending multiple of the same pose with an incorrect latency to update our position. ( If we wanted to verify that, we could log the pose every time we update it in the LimelightSubsystem periodic )

Can we figure out how to trigger the position update only when the NT:/limelight/hb tag increases? or the data changes?

Maybe use subscribe? https://docs.wpilib.org/en/stable/docs/software/networktables/publish-and-subscribe.html#subscribing-to-a-topic

[riversry]

Full list of ideas to try:

• Try limelight at a higher framerate because (Casey's comment above)
• Try running a NamedCommand at the end of the path because it appears that the path concluded before the robot was able to move forward far enough to intake the third note.
• Add a functionality to disable the limelight for auton paths and use odometry solely.
• Edit the wheel radius in an attempt to get the odometry error to 0

[riversry]

Tests:

• We used the limelight heartbeat to resolve the latency issue
• We added a better physical "sunshade" to block the fluorescent light's glare into the limelight
• We tried running the limelight at 960p for 40fps, changing the exposure, downscale, and quality threshold

Possible Issues:

• The limelight may be experiencing motion blur which leads to left-to-right error with little to no back-forward error

[riversry]

Tests:

• We attempted to do the ChArUco camera calibration sequence multiple times, resulting in a high reprojection error that was consistently above 60 (the limelight documentation page says it should be ideally less than 1)
• The calibration sequence was first attempted with the limelight inside of the mount, which after seeing a reprojection error of above 75 was moved to the floor, which resulted in a slightly smaller reprojection error of roughly 65. This issue was mentioned numerous times in ChiefDelphi posts, but there has not been a satisfactory answer as of yet.
• We calculated the distance from the limelight to the center of each tag in case the error we were seeing was resulting from inaccurate field dimensions. However, we still received error, which means that the field dimensions are not the sole problem, it is either a combination of poor calibration and poor field dimensions or just entirely poor calibration.

[caseyjbrotherton]

There have been a bunch of changes. We switched to photonvision. Photionvision is useable for positioning, especially closer to the speaker. It also updates 100ms instead of Limelight's 300ms.

Closing this issue. Follow on work for positioning will be under a new card