Closed UserC2 closed 7 months ago
Does heading velocity control still work?
It should be unaffected, as it doesn't take the robot's current angle into account.
We should perhaps not use resetOdometry(). For localizing with apriltags, we use RobotContainer.drive.drive.swerveDrivePoseEstimator.addVisionMeasurement().
We should perhaps not use resetOdometry(). For localizing with apriltags, we use RobotContainer.drive.drive.swerveDrivePoseEstimator.addVisionMeasurement().
Reset odometry is used for PathPlanner to reset the pose of the robot when autonomous starts, not for vision measurements.
ah, i see
Ok, I've figured out why this happens:
resetOdometry()
resets the odometry and gyro angle assuming the robot is at the provided position.We can fix this in two ways:
resetOdometry()
and use the Limelight to find the robot position.
resetOdometry()
call in and ensure the robot is set up in the correct position at the start of auto.
The second method is ideal, since it still works when the Limelight fails and still works in simulation.
In summary: The current code works as expected. Remember to setup the robot in the correct place during autonomous (especially in simulation or when the Limelight doesn't work).
In simulation, make sure to zero the gyro before running an autonomous path, or the heading will be offset incorrectly (these instructions have been added to README.md).
Nevermind!
We are using SwerveDrive::getYaw()
to get the heading in most commands (except PathPlanner and AlignToAmp), which never applies the gyro offset.
I will be changing that soon.
See c98ddf5
Bug Description Resetting odometry to any angle other than 0 causes heading to believe that angle is 0.
Steps to Reproduce
RobotContainer.drive.drive.resetOdometry()
with a Pose2D with a non-zero rotation (e.g. 90 degrees)Expected Behavior