Challenge- Create a MoveRobot Command

All you'll need to do is make a class that:

• Create a Command with the type MoveRobot. Your command will need all the methods and fields mentioned above.

• The command has fields: double leftSpeed, double rightSpeed, and RomiDrivetrain subsystem.

• Make the MoveRobot constructor have three parameters: RomiDrivetrain m_subsystem, double newLeftSpeed, and double newRightSpeed.

• In the command's initialize() function, we'll call the subsystem's MoveMotors() method, and put the speed variables in it.

• You can repurpose the ExampleCommand that comes with your project.

Sample Code

package frc.robot.commands;

import frc.robot.subsystems.RomiDrivetrain;
import edu.wpi.first.wpilibj2.command.Command;

/** An example command that uses an example subsystem. */
public class MoveRobotCommand extends Command {
  @SuppressWarnings({"PMD.UnusedPrivateField", "PMD.SingularField"})
  private final RomiDrivetrain m_subsystem;
  private double leftSpeed;
  private double rightSpeed;

  /**
   * Creates a new ExampleCommand.
   *
   * @param subsystem The subsystem used by this command.
   */
  public MoveRobotCommand(RomiDrivetrain subsystem, double lSpeed, double rSpeed) {
    m_subsystem = subsystem;
    leftSpeed = lSpeed;
    rightSpeed = rSpeed;
    // Use addRequirements() here to declare subsystem dependencies.
    addRequirements(subsystem);
  }

  // Called when the command is initially scheduled.
  @Override
  public void initialize() {
    m_subsystem.moveMotors(leftSpeed, rightSpeed);
  }

  // Called every time the scheduler runs while the command is scheduled.
  @Override
  public void execute() {
    

  }

  // Called once the command ends or is interrupted.
  @Override
  public void end(boolean interrupted) {
    m_subsystem.moveMotors(0, 0);
  }

  // Returns true when the command should end.
  @Override
  public boolean isFinished() {
    return false;
  }
}

Sample Code (alternate)

package frc.robot.commands;

import frc.robot.subsystems.RomiDrivetrain;
import edu.wpi.first.wpilibj2.command.Command;

/** An example command that uses an example subsystem. */
public class MoveRobotCommand extends Command {
  @SuppressWarnings({"PMD.UnusedPrivateField", "PMD.SingularField"})
  private final RomiDrivetrain m_subsystem;
  private double leftSpeed;
  private double rightSpeed;

  /**
   * Creates a new ExampleCommand.
   *
   * @param subsystem The subsystem used by this command.
   */
  public MoveRobotCommand(RomiDrivetrain subsystem, double lSpeed, double rSpeed) {
    m_subsystem = subsystem;
    leftSpeed = lSpeed;
    rightSpeed = rSpeed;
    // Use addRequirements() here to declare subsystem dependencies.
    addRequirements(subsystem);
  }

  // Called when the command is initially scheduled.
  @Override
  public void initialize() {}

  // Called every time the scheduler runs while the command is scheduled.
  @Override
  public void execute() {
    m_subsystem.moveMotors(leftSpeed, rightSpeed);

  }

  // Called once the command ends or is interrupted.
  @Override
  public void end(boolean interrupted) {}

  // Returns true when the command should end.
  @Override
  public boolean isFinished() {
    return false;
  }
}

Answer Breakdown

DO NOT OPEN UNTIL YOU FINISHED WRITING CODE!

Let's break down these two sets of code.

The header looks pretty normal, but you might find this line.

 @SuppressWarnings({"PMD.UnusedPrivateField", "PMD.SingularField"})

VSC gives warnings in your console for a variety of reasons. PMD.UnusedPrivateField refers to having private fields that are declared, but are never actually used. PMD.SingularField is creating a variable you'll only use in one spot of code, and never again.

Generally, doing these is considered messier, and VSC gives these warnings to help unsuspecting programmers optimize and clean up their code. However, due to the nature of FRC Programming, these warnings tend to be a nuisance rather than helpful. For example, what if you created a Spark variable, but didn't know how often you'd use it in your code? You'll create a new Spark variable at the top, instead of having to create a brand new one every time you want to use it. It's just more convenient.

This line of code stops VSC from panicking whenever these errors happen.

The constructor is pretty standard, nothing interesting to say about it, aside from the addRequirements() method. The addRequirements() method simply takes subsystem(s) in its parameters, and as the name suggests, forces the command to require the subsystem. Without it, your code will not work properly.

There are two approaches for using commands that I like to use.

---