How do I tell if the alliance is amplified in Java code

I’ve already checked the docs in the driverstation class, and I can’t seem to find any way for the robot code to tell when the alliance is amplified.

1 Like

I don’t believe that info is made available to the driverstation or robot

5 Likes

As per Q&A question 62:

Will the FMS send information about whether AMPLIFICATION mode is active/inactive via NetworkTables? If not, is there another method for the ROBOT to be able to determine the current AMPLIFICATION state via code?

Answer:

No.

7 Likes

The robot doesn’t get that information, but the drive teams do. The new team signs have displays on the back with a lot of info on them, including the Amp countdown when it’s activated. If it’s not activated it displays a “00” for the time. When it is, it’s a number counting down from “10”. It’s on the left side of the display. Here’s the Field Tour video talking about it:

Potential workaround:
Could the limelight / vision system detect the lighting on the subwoofer that positively confirms amplification is in progress?

Could the drive team, once they acknowledge amplification is activated, hit a button on their control panel to tell the robot amplification is active?

3 Likes

Could the limelight / vision system detect the lighting on the subwoofer that positively confirms amplification is in progress?

Maybe, but that’s a lot of work for what would likely be inconsistent detection. It would only “work” while maintaining line of sight.

Could the drive team, once they acknowledge amplification is activated, hit a button on their control panel to tell the robot amplification is active?

Sure, but that’s cognitive load on team devoted to otherwise very important tasks. And it raises the question; if the drive team already knows, what’s the point of telling the robot?

5 Likes

Telling the robot could kick off an automated sequence of scoring, searching for and acquiring a new note, and scoring again with minimal driver input. What else do you suspect OP’s code was intending to do with the information?

1 Like

The biggest use would be not letting the robot score the speaker after the amplification ended without some override. So that you could more efficiently utilize the game piece towards re-amplification.

Detecting the lights would be challenging. Or detecting the drive station countdown.

So funny story, I’m just trying to synchronize our LED strips on our robot to in game events including auto, endgame, and amplification. Not that it makes a difference. It’s still unfortunate that it’s not possible :sob::sob:

7 Likes

As someone who has synchronised the robot LEDs to the RSL… I feel ya. It’s awesome, if just a little unnecessary.

3 Likes

week 5 waiting for electrical to finish wiring vibes

1 Like

Though you got the method to be exposed in the code to make it easier to do, to be fair

1 Like

I am electrical too (small town teams :on::top:)
currently waiting for MECHANICAL to start assembling any of the major mechanisms week 5 vibes

4 Likes

aint no way its week 5

well ya got one day left in week 4

Then it’s week 5

“The real goal is not to win, but change the game rules code library.”

3 Likes

Annoy the WPIlib devs with your jank so they make it work better

1 Like

Attach a camera to the DS that points up towards the amp timer

If we had access to match info, we’d add it. However none of that is sent from the FMS to the robots, so there’s nothing from our end we could do. And based on how the FMS is architected, the actual robot control portions are separate from the rest of the FMS for safety and control reasons, so piping that data down from the scoring parts of the FMS is actually a LOT harder than people think.

2 Likes

Week 5 waiting for mechanical to make a single CAD type stuff