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

Better lights for robot #98

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

Better lights for robot #98

wants to merge 7 commits into from

Conversation

The-Arx
Copy link
Contributor

@The-Arx The-Arx commented Mar 21, 2024

Description

Allows both halves of lights to be turned on independently. Currently second half has none but we can add stuff to signal to the player.

How Has This Been Tested?

Untested because robot was unavailable

@The-Arx The-Arx self-assigned this Mar 21, 2024
@@ -108,6 +108,8 @@ public void handleOI(Context context) {
drive.setCross();

context.releaseOwnership(drive);

Copy link
Contributor

Choose a reason for hiding this comment

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

comment - what does turning off the front signify?

also, don't forget to take and release ownership of lights

private static final int BACK_OFFSET = 48;
private static final int BACK_SLOT = 2;

public void signalPlayersGreen() {
Copy link
Contributor

Choose a reason for hiding this comment

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

each of these signal* or turnOffFront methods should check context ownership

calling Procedures should take and release ownership as appropriate.

I can help you with this when we talk.

Copy link
Member

Choose a reason for hiding this comment

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

Agree, +1. @dejabot can you please help make sure this gets into the codebase so it is ready before tomorrow morning?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The check happens inside of the setAreaColor and animate methods.

@@ -19,6 +19,6 @@ public void run(Context context) {

context.waitForSeconds(2);

Robot.lights.turnLightsOff();
Robot.lights.turnOffFront();
Copy link
Contributor

Choose a reason for hiding this comment

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

do you want to signal that there's now a note in the intake?
btw what does turn off front signify?

Copy link
Member

Choose a reason for hiding this comment

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

That would be a good idea. I think the sample code I pushed to main didn't include this on accident. My bad.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It did have that but was just collapsed by GitHub when reviewing I think

@@ -169,6 +171,10 @@ public void handleOI(Context context) {
context.takeOwnership(drive);
drive.stopDrive();
}

if (isRotatingToSpeaker && drive.isAtRotationTarget() && Robot.shoulder.isFinished()) {
Robot.lights.signalCanShoot();
Copy link
Contributor

Choose a reason for hiding this comment

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

take and release ownership of lights

Copy link
Member

Choose a reason for hiding this comment

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

Agree with debajit, + 1
Also, this code seems like it would make the lights flash on/off a lot while Luis is moving the robot, and then will be static once Luis stops the robot. Would it be better to make it so there is one lights sequence if the robot is in lock mode and another in the procedure if the robot has started the actual shooting procedure?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is what Raj asked me to implement. It turns on the light when it is ready but waits until Louis releases the button to turn it off.

@dejabot
Copy link
Contributor

dejabot commented Mar 21, 2024

nice job with this! I think it's close. to avoid having multiple procedures accidentally trying to use the lights simultaneously, you should check context ownership in Lights for any methods that modify the state of the lights, and you should take and release ownership for any procedures (or OI fragments) that call those methods.

it might also be helpful to comment about what the front and back are representing.

ultimately, it'd be great to write up markdown docs (in docs/) for what the lights mean.

thank you!

Copy link
Member

@maxspier maxspier left a comment

Choose a reason for hiding this comment

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

This is almost perfect! I think there's just a few things to talk over and discuss with @dejabot, and then implement, and then we can get this merged to main before tomorrow! Great work, especially with the split LED strip design! All of this code should be really useful on the robot!

@@ -169,6 +171,10 @@ public void handleOI(Context context) {
context.takeOwnership(drive);
drive.stopDrive();
}

if (isRotatingToSpeaker && drive.isAtRotationTarget() && Robot.shoulder.isFinished()) {
Robot.lights.signalCanShoot();
Copy link
Member

Choose a reason for hiding this comment

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

Agree with debajit, + 1
Also, this code seems like it would make the lights flash on/off a lot while Luis is moving the robot, and then will be static once Luis stops the robot. Would it be better to make it so there is one lights sequence if the robot is in lock mode and another in the procedure if the robot has started the actual shooting procedure?

private static final int BACK_OFFSET = 48;
private static final int BACK_SLOT = 2;

public void signalPlayersGreen() {
Copy link
Member

Choose a reason for hiding this comment

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

Agree, +1. @dejabot can you please help make sure this gets into the codebase so it is ready before tomorrow morning?

@@ -19,6 +19,6 @@ public void run(Context context) {

context.waitForSeconds(2);

Robot.lights.turnLightsOff();
Robot.lights.turnOffFront();
Copy link
Member

Choose a reason for hiding this comment

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

That would be a good idea. I think the sample code I pushed to main didn't include this on accident. My bad.

Copy link
Member

Choose a reason for hiding this comment

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

There's something to be said about the use of context taking ownership using the Lights class. Theoretically, we would not need to take or release ownership of the lights. However, it does allow for a better handoff between mechanisms/oi/procedure. This could be a thing to discuss with @dejabot ; he should be able to help you with this decision, and then if you decide to implement context he (or I) can help you implement it. Some of the comments I made are assuming we are using this context based lights code, so if we are then you should probably keep them, or otherwise just disregard them.

@dejabot
Copy link
Contributor

dejabot commented Mar 22, 2024

re: context ownership - having the Lights mechanism check for context ownership, and having calling procedures/OIFragments takeOwnership and releaseOwnership of the context is the right thing to do. The Lights mechanism has mutable state, and you want to ensure that two different procedures etc aren't clobbering each other; that's what the context ownership checks protect.

that said, since we're at comp now and want to minimize "wiggling the jello", I think it's fine not to put in the context ownership checks and do the take/release ownership calls in the procedures/oi. we can add that after comp. unlike a moving mechanism, there's less danger of actual physical clobbering with accidental concurrent manipulation, so we should be okay.

go ahead and proceed with the code without context ownership logic. we can add it after the comp.

excited to see this in action!!

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