You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CTRE's SwerveDrivetrain class updates the pose estimation inside of its 250 Hz odometry thread based on wheel positions. Since this occurs outside of the AdvantageKit IO architecture, when logs are replayed, the pose estimate will not be exactly the same. While this isn't ideal, I'm not sure of the practical impact.
The AdvantageKit swerve example, takes one approach to addressing this issue. This approach stills gathers wheel positions at 250 Hz but queues these values and updates the pose estimator in a manner consistent with the AdvantageKit IO architecture. This enables true replays. However, this is different than the CTRE solution in that the swerve commands are not applied as part of the 250 Hz thread. Again, I'm not sure of the practice impact.
We could do something icky like subclass the SwerveDrivePoseEstimator class and change the value of the m_odometry instance variable in our subclass of SwerveDrivetrain. We could implement a similar queueing solution. I'm not sure if this is worth the effort.
For now, I'm just capturing this issue.
The text was updated successfully, but these errors were encountered:
CTRE's SwerveDrivetrain class updates the pose estimation inside of its 250 Hz odometry thread based on wheel positions. Since this occurs outside of the AdvantageKit IO architecture, when logs are replayed, the pose estimate will not be exactly the same. While this isn't ideal, I'm not sure of the practical impact.
The AdvantageKit swerve example, takes one approach to addressing this issue. This approach stills gathers wheel positions at 250 Hz but queues these values and updates the pose estimator in a manner consistent with the AdvantageKit IO architecture. This enables true replays. However, this is different than the CTRE solution in that the swerve commands are not applied as part of the 250 Hz thread. Again, I'm not sure of the practice impact.
We could do something icky like subclass the SwerveDrivePoseEstimator class and change the value of the m_odometry instance variable in our subclass of SwerveDrivetrain. We could implement a similar queueing solution. I'm not sure if this is worth the effort.
For now, I'm just capturing this issue.
The text was updated successfully, but these errors were encountered: