Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Q] Does Road Runner use the Odometry Wheel Velocity? #108

Closed
EddieDL opened this issue Oct 28, 2020 · 7 comments
Closed

[Q] Does Road Runner use the Odometry Wheel Velocity? #108

EddieDL opened this issue Oct 28, 2020 · 7 comments

Comments

@EddieDL
Copy link

EddieDL commented Oct 28, 2020

Our team is looking at using the Open Odometry design for our dead wheels. One concern with this design is that it uses the REV Through Bore encoder. This encoder has a super high resolution, which we think would be fine for localization. However, as we understand it the getVelocity() method uses 16 bit integers which means it won't correctly monitor the velocity at "high" speed. Below is an issue from last year where this was discussed.

This raises our question of if Road Runner actually uses the velocity from the dead axle wheels if we are using the motor velocity PID? If it isn't used we think we could safely use this design for odometry wheels. If it is used, we will need to determine if we will be impacted based our potential velocity.

Issue

@rbrott
Copy link
Member

rbrott commented Oct 28, 2020

The quickstart does use the velocity from the dead axle wheels, and the issue you described is mitigated by #90. You shouldn't have to worry if you use Encoder.

@EddieDL
Copy link
Author

EddieDL commented Oct 28, 2020

That fix seems cool, but it doesn't look to me like the change actually uses the getCorrectedVelocity(). I feel like to really fix this we need to change from using getRawVelocity(). Is that right?

@rbrott
Copy link
Member

rbrott commented Oct 28, 2020

Yes, that's correct. I should have made that more clear before. The feature is opt-in because it might misbehave.

@NoahBres
Copy link

image

@EddieDL
Copy link
Author

EddieDL commented Oct 29, 2020

@NoahBres I feel dumb, I was looking right at that code and apparently completely ignored the wonderful comment.

We currently don't use the Rev robotics encoders or the omni wheels from the Open Odometry design. So we would have to invest to convert to this design. Our current implementation doesn't exceed 32767 counts / second. However, our current implementation is MUCH bigger than the Open Odometry design.

The only pause I have in making the investment now is @rbrott's statement below. I reviewed the code and it seems pretty solid. Should we be concerned about it misbehaving or is it just a possibility?

because it might misbehave

@NoahBres
Copy link

I believe the misbehaving comment was precautionary? The correction is kind of a hack, albeit a really neat one.

@rbrott
Copy link
Member

rbrott commented Oct 29, 2020

Should we be concerned about it misbehaving or is it just a possibility?

You probably shouldn't be very concerned. Malfunction is a slim possibility. However, if you know the correction is never applicable for your operating speed and resolution, it's safer to use the velocity directly instead of relying on the correction to be a no-op.

@EddieDL EddieDL closed this as completed Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants