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

Make Command-Based Trigger.whileTrue, onTrue, whileFalse, onFalse true to their names #7413

Open
tom131313 opened this issue Nov 20, 2024 · 2 comments · May be fixed by #7425
Open

Make Command-Based Trigger.whileTrue, onTrue, whileFalse, onFalse true to their names #7413

tom131313 opened this issue Nov 20, 2024 · 2 comments · May be fixed by #7425
Labels
type: feature Brand new functionality, features, pages, workflows, endpoints, etc.

Comments

@tom131313
Copy link

Trigger the command on condition of changing state (the current action) AND on the initial state (the new, improved action).

For example, whileTrue would trigger when the condition changes from false to true. In addition, the proposed new trigger activates if the initial state of the condition is true. These actions would happen if the command can be scheduled - that is the mode is Enabled or the command can run in Disabled.

This has the potential of being a breaking change for some users. I suggest methods with both behaviors could be supported.

The current motivation for this change is a bumper limit switch on a robot should trigger a command that prevents certain movement in that state. When that command is used to move away from an obstacle and not toward the obstacle the limited command ends and the normal default command resumes. Because the current trigger behavior doesn't honor the initial state, the work-around is tedious to use triggers to change commands for the change of state.

  /**
   * Starts the given command when the condition changes to `true` or is initially `true`
   * and cancels it when the condition changes to `false`.
   *
   * <p>
   * Doesn't re-start the command if it ends while the condition is still `true`.
   * If the command should restart, see {@link edu.wpi.first.wpilibj2.command.RepeatCommand}.
   *
   * @param command the command to start
   * @return this trigger, so calls can be chained
   */
  public Trigger whileTrue(Command command) {
    requireNonNullParam(command, "command", "whileTrue");
    m_loop.bind(
	
        new Runnable() {
          private boolean m_pressedLast; // initial value ignored - protected by firstTime
          private boolean firstTime = true; // indicates the command has never been scheduled
		  
          @Override
          public void run() {
            boolean pressed = m_condition.getAsBoolean();

            if ((command.runsWhenDisabled() || DriverStation.isEnabled()) // command can be scheduled
                && pressed  // desired condition
                && ((!firstTime && !m_pressedLast) // state has changed
                    || firstTime)) { // initially suppress comparison to previous state
                  firstTime = false;
                  command.schedule();
              }

            else if (!firstTime && m_pressedLast && !pressed) { // has state reverted
                command.cancel();
            }

            m_pressedLast = pressed;
          }
        });
		
    return this;
  }
@tom131313 tom131313 added the type: feature Brand new functionality, features, pages, workflows, endpoints, etc. label Nov 20, 2024
@rzblue
Copy link
Member

rzblue commented Nov 20, 2024

Duplicate of #5608

@tom131313
Copy link
Author

#5608 is a special case of this more general description and solution. I searched the issues but missed that one. I'm sorry I didn't see it. Thanks for your better memory to find the very similar issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Brand new functionality, features, pages, workflows, endpoints, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants