Controlling Rev Blinkin from commands

We are implementing a REV Blinkin LED Driver, in a Java Command Based project, and ended up with a philosophy of controls problem that’s only marginally related to the original problem.
Necro’ing the thread in case the original problem got solved, and in parallel hoping we don’t run into it…

The problem posed is to light an LED pattern when the robot is in quickTurn (arcade) mode, and cancel go back to default when it is in normal drive.

The initial solution we are using is implementing an entire second command structure and overloading the button so that two commands should be triggered by the button press, completely parallel to each other. So the OI looks like this:

public OI() {
    driver = new Joystick(0);
    quickTurn = new JoystickButton(driver, 6);
    quickTurn.whenPressed(new QuickTurn());
    resetTurn = new JoystickButton(driver, 6);
    resetTurn.whenReleased(new ResetTurn());
    ledquickturn = new JoystickButton(driver, 6);
    ledquickturn.whenPressed(new ledQuick());
    ledresetturn = new JoystickButton(driver, 6);
    ledresetturn.whenReleased(new ledReset());
}

Instead, should I be adding a requirement of subsystem LED to the existing quickturn command and call a method to light LEDs from the existing quickturn command?

I moved this to its own thread because it is its own topic.

1 Like

I think this is the better design. If you were to change the button that quickturn is on, you’d be changing it in multiple spots. The quickturn action itself and the LEDs reflecting the quickturn action are inherently coupled - it wouldn’t make sense for them to ever perform one without the other (assuming both are working properly).

I would change the Quickturn command to change LEDs during execute and during end.

If you want to have changing LED state a command (e.g. SetLEDState, or something), you could couple them in a small ParallelCommandGroup (in 2020) that performs both the quickturn command and the set LED state command.

2 Likes

What you are doing is fine. We implemented button overloading with commands on our 2019 robot for intaking, where our intake button had two commands: The first was to move our elevator/wrist to the correct position and the second to run our intake wheels while it was held. Personally, I prefer this way of organizing the code as it splits the commands into ones that can be organized by subsystem instead of having one large command that has multiple dependencies that can be hard to split if needed, but its pretty much just preference.

1 Like

Thank you, that’s a strong design argument.

How much further could I take it? If the drivetrain Subsystem is aware of it’s state change (via a boolean that determines if it should quickturn or regular drive), should it directly report it’s statechange directly to the LED subsystem? Is it a reasonable design pattern for Subsystems to send things directly to each other?

I would say yes.

I think that as for “how far you could take it,” it depends on how much functionality the LEDs are actually presenting to your robot. If it’s literally just on/off for quickturn, then I think you don’t need to put too much effort into making sure the LED code is “perfect.” However, if you’re using it for driver feedback on multiple subsystems, then you may want to treat LEDs as a subsystem itself and have commands that change the LED states.

If going down that approach, I would probably assign each subsystem a “priority” (can be represented by just an integer), and allow each subsystem to (optionally) submit a desired LED state to the LED subsystem. The LED subsystem then manages these desired states and displays the highest priority message from another subsystem.

Here’s some Python code for a quick mockup:

class Quickturn(Command):
    def __init__(self, priority = 1):
        self.priority = priority

    def execute(self):
       LEDSubsystem.request_state(LEDSubsystem.ALL_BLUE, self.priority, self)
        # blah blah whatever else in here

    def end(self):
        LEDSubsystem.remove_state(self)

LEDSubsystem would then keep track of which commands/subsystems have submitted states to it, could just use some ArrayList and sort by priority or something. Maybe not the best design but my first thought.

Again, all depends on how much composability you want out of it. Just make sure not to go too crazy, at some point your drivers may not even remember which LED pattern means what :slight_smile:

Note that this priority based approach is only necessary if you are attempting to change LEDs from multiple subsystems at the same time. If you can guarantee that you won’t ever have commands trying to access the LEDs at the same time, you can just assign colors at will, I suppose.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.