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

Fix shooter speed tuning #178

Open
james-ward opened this issue Apr 6, 2022 · 5 comments
Open

Fix shooter speed tuning #178

james-ward opened this issue Apr 6, 2022 · 5 comments

Comments

@james-ward
Copy link
Contributor

In Hawaii Qualifier 38 (https://github.com/thedropbears/pyrapidreact/releases/tag/hawaii-q38) we changed the shooter speed from being a will_reset_to to just a regular float. This made the shooter flywheels go completely haywire. This was reverted in the next match (https://github.com/thedropbears/pyrapidreact/releases/tag/hawaii-q43) and everything worked again.

There is some sort of bug here, and we have been relying on this behaviour all season. Suggest we work out what it is, and retune the shooter so that it is working properly.

@auscompgeek
Copy link
Member

The weirdest part is that it seemed to behave in test mode… at least last time I had a look.

@james-ward
Copy link
Contributor Author

james-ward commented Apr 6, 2022

Yeah, that's a good point Davo. That's why it got on the field in that state - we ran it in test mode in the pits and it behaved. Obviously we didn't run it in teleop (or auto) or we would have seen it and not put in on the field in that state.

But we confirmed it on the practice field - fired it up in teleop and it oversped the flywheels to the point that a pulley exploded. Reverted the code, and it was fine.

To be complete in our investigations I should point out that there were three commits made between the failure match and the previous match, but the will_reset_to change is the only one that touched the shooter.

@auscompgeek
Copy link
Member

I wasn't able to replicate this behaviour in the simulator. I did find a divide by zero in the shooter motion compensation though.

@OliverW10
Copy link
Member

It looks like we also added some I term to the flywheel pid, this could have caused large oscillations when it starts up but maybe not in test mode where it is on the throttle so would ramp more.

@james-ward
Copy link
Contributor Author

Well spotted. That's definitely the bug. The I term should be on the turret, not the shooter.

So I guess we know why we lost that match then!

This was all motivated by investigating why the robot was refusing to fire, which we though could only be flywheel error calculation. The other criteria (turret alignment and robot speed seem unlikely to be the culprit). I think we should still remove the will_reset_to because it was messing with the graphs of flywheel error.

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