When using command based and a motor controller like the TalonSRX or SparkMax, should the output of each motor controller be set in the subsystem’s periodic loop based on a variable or just once in a function?
set() is persistent - until over-written, it will continue to use the same value. No reason to call it every loop.
Create methods (‘functions’) in the subsystem, that are called by commands, that set() your motors. Therefore each time a command runs, a set() will be commanded. Once the set() is commanded, the motor controller will continue working at that set()ing until it gets a new set() from a different command.
no. In your class body write a setter for your motor controller like :
public void setLeftTalon(double voltage){
leftTalon.setVoltage(voltage);
}
Change leftTalon for your motor controller and don’t put this in any loop.
*This assumes you are using WPI_Talon. If not, use set().
I’ll go the other way on this. If motor safety is off, this will work. My definite preference is to have motor safety on and to explicitly set the motor’s speed every pass through the periodic/execute method. Admittedly, part of this preference is because I also program robots outside of FRC, where the hardware doesn’t automatically do a safety shutdown for you.
1 Like
I agree to spam call the set method, even if you’re telling it to stop.
A due to motor safety methods
B so you know it’s doing what you want
1 Like
Why does not having motor Safety outside of FRC make setting the motors every update better? And how does motor safety work for motor controllers that are not part of WPILIB?
Most control systems utilize a “maintain last state” paradigm. So if you stop updating state, it continues that last state, just like the set() method here. FRC’s WPILIB, DriverStation, and FMS have multiple provisions in place to help keep things fail-safe. From the configurable Motor Safety system, to the not meant to be avoidable EMERGENCY STOP. Other systems do not necessarily have analogs to this, thus it is very important to be mindful of your failure states, and ensure you are being as proactive as possible to avoid those states being fail-deadly.
1 Like
^^ Yes, that.
Am I understanding this correctly? Setting motor output repeated allows for the motors to be stopped quickly in case something goes wrong, when motor safety is not given to you. Also how does frc know when something is wrong?
You can set an output once, and assume its doing what you expect, but if you’re setting your desired state constantly you reduce risk of erroniously being in an undesired state, such as having code that is supposed to change the motor to stopped, but it does this after the checks for changed state this cycle, and because of some other logic the change isn’t picked up next cycle, and suddenly the motor strangely never gets stopped. If you store your desired state, and constantly say “be in this state”, you can be more confident that your state is being applied.
Depends on the system. There are numerous checkpoints. If you haven’t updated the motors, while in a non-zero setting, in a period of time, Motor Safety may trip because the code may be flawed. If communication with the DS or FMS is lost, all outputs will be stopped because the inputs will be stale and out-of-date. Of course the E-Stop is a manual thing, if the robot goes visibly berserk, requiring a reboot to recover.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.