-
Notifications
You must be signed in to change notification settings - Fork 0
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
simple lights red when we are in endgame #9
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great. I think what Justin wanted, tho, was to show different (solid) lights for different phases of the match.
eg, teleop is 2m15s
first 35s, one color
next 35s, next color
next 35s, next color
last 30s, final color
not sure if we want to use red if we wanted to use red for "something bad is happening"?
since we're adding more to Lights, I'd recommend tweaking Lights so it knew about different modes, vs have the color be controlled by the caller.
eg, lights.indicateMatchPhase(int phase /* one of the above */);
lights.indicateXYZ()
and then make the color an internal implementation detail for Lights. that will make it less likely that different part of OI/procedures use the same colors for different things, and it also makes it easier to update the color choices -- that would all be in Lights.java.
happy to work with you on this tomorrow if that would be helpful!
Thinking about this more, we should chat with Justin about this a bit. Justin would also like to have lights indicating the position (and maybe even piece type?) we've queued up for the robot. We should think about how all of these lights will work together. In the meantime, I'd suggest tweaking the Lights to switch from [set] color() methods to indicateXYZ() methods, as we'll be expanding on this a bunch very soon. Thank you! |
as discussed, at 30s left:
it'll be super helpful to make the Lights class have semantically meaningful methods (vs color ones, esp given above): o indicateGamePieceType( /* either an enum or a bool /) and then store some state (current color, blink state?) and use that internally in Lights to make the LEDs do what you want. thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is looking good overall. will you ultimately make 30s left blink?
@@ -66,6 +67,7 @@ public void run(Context context) { | |||
context.takeOwnership(Robot.drive); | |||
// context.takeOwnership(Robot.intake); | |||
context.takeOwnership(Robot.gyro); | |||
context.takeOwnership(Robot.lights); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should only grab ownership of lights for the small chunk where needed (below) as other mechanisms will also use Lights.
@@ -87,6 +89,9 @@ public void run(Context context) { | |||
// SmartDashboard.putString("Alliance", "NULLLLLLLLL"); | |||
// } | |||
|
|||
if(DriverStation.isTeleop() && DriverStation.getMatchTime() < 30){ | |||
Robot.lights.signalMalfunction(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why malfunction?
for luis
not been tested yet