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

Shooterlights #114

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Shooterlights #114

wants to merge 5 commits into from

Conversation

P-McG9
Copy link

@P-McG9 P-McG9 commented Mar 31, 2024

Description

Lights turn cyan when spinup starts and lime green when at speed.

How Has This Been Tested?

I built it and got no errors. Other than that it has not been tested

Copy link
Contributor

@qntmcube qntmcube left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks pretty good, but there are a couple changes that need to be made. Also, try applying spotless again— it seems to be complaining (it's always very pedantic)

visionContext = context.startAsync(new DriverShootNow());
if(isAtGoodSpeed.isNewlyTriggering()) {
Robot.lights.signalAtSpeed();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, for the startSpinup and atSpeed lights signals, it might be better to do that in BoxopOI where the shooter is actually triggered. Sorry the code is a little unclear right now, but this only rotates the robot and waits for the shooter to be ready before shooting instead of actually spinning up and down the shooter.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make a difference in how it works, or is it just to make more sense and be more organized? If it's not on getButtonPressed, wouldn't it just continually check no matter which class it's in? I can still move it to driverOI, but I think it would be the same?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait it does make a difference for signalStartSpinup, but probably not for signalAtSpeed

@dejabot
Copy link
Contributor

dejabot commented Apr 1, 2024

FYI, another way to do this (for future) would be:

  • create a Procedure called SignalShooterAtSpeed or similar, that has a waitFor that waits for the shooter to be close to the expected speed, and once there, has the light signal that the shooter is at speed
  • context.startAsync(SignalShooterAtSpeed) when we start spinning up the shooter, eg BoxOpOI.java:~line181.
  • stash the LaunchedContext returned by above, and in the BoxOpOI loop check if non-null each iteration of handleOI.
    • somewhere in the loop, if non-null, null it out when isDone
    • around line 185, if non-null call stop() and null it out when the boxop stops the shooter

that way, we tie the lights directly to the boxop starting up the shooter.

Made the isNotZero method use the speed tolerance instead of actually using zero
Moved the if-statement for activating the signalAtSpeed method out of the button pressed if-statement
@qntmcube
Copy link
Contributor

qntmcube commented Apr 1, 2024

Looks better, but I think you forgot to re-add the lightsStartupShooter in boxopOI. It would be better to have all of the logic in there but not critical for now (although specifically for the signalShotComplete I think where you have right now in driverOI is better). Also, remember to run spotlessApply again.

@P-McG9
Copy link
Author

P-McG9 commented Apr 2, 2024

I did put it into BoxOpOI, it's line 180.

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

Successfully merging this pull request may close these issues.

3 participants