use reprojection error for multitag pose estimation #88
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Phoenix 6 library updates the custom odometry object itself; no other code should update it with swerve module positions.
For this first stage of tuning, we want to keep the odometry objects clean of any vision estimate. This will change later in the tuning process.
Statically allocate the swerve module position array and objects to avoid allocations during periodic. Move the update to the pose estimator before logging the pose to keep the pose synchronized with the other inputs.
Update max angular acceleration based on a more reasonable MOI. Three main auto, each with varying speeds: distance (straight line), rotation (straight line with 180° rotation), oval (oval path with rotation and pause).
The intake has been removed.
Having a clear change in LED color will make it easier to synchronize the video to the log file.
When running multiple pose estimators, we need to ensure the pose is reset for all of them; not just the hardware-specific drivetrain subsystem object.
… pose estimate. When running multiple pose estimators, we need to ensure the pose is reset for all of them; not just the hardware-specific drivetrain subsystem object.
Logging the corner will make it easier to check accuracy on the 1mx1m grid.
These poses can be displayed on a 3D Field tab in AdvantageScope to visually verify the location of each tag.
Log the distance traveled during a tuning auto path. This is useful to compare against the physically measured distance on the carpet. Log the difference between the final pose based on odometry and the final target pose. This is useful to analyze how close the robot thinks it is getting to the final pose in an auto.
The center of the robot will be at the (1.0, 1.0) position after running this auto.
…ose. This is useful when verifying vision pose estimates when the robot is not moving. The statistics tab in AdvantageScope provides the necessary analysis.
Maintain an buffer of poses such that we can interpolate the pose corresponding to the timestamp of the vision pose estimate. Log the difference between the vision pose estimate and this interpolated pose estimate. This is useful for validating the positions of AprilTags on the field when the roobt is not moving and for tuning the vision pipeline latency when the robot is moving.
Add a Tunable that is added to the vision pose estimate timestamp to enable further tuning of the latency of the vision pipeline. Add a local constant to the Vision class to enable/disable incorporating vision pose estimates into the odometry. This is useful to disable when tuning the vision pipeline.
… custom odometry object This should be disabled while tuning odometry and enabled when all tuning is complete.
This helps visually verify the robot to camera transforms.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.