Ok, last one I can think of for today.
motor setVelocity is evil…
consider this code.
void autonomous( void ) {
m1.setVelocity( 100, percent );
this_thread::sleep_for(1000);
m1.spin( reverse );
}
/*----------------------------------------------------------------------------*/
void usercontrol( void ) {
m1.setVelocity( 0, percent );
m1.spin( forward );
while (true) {
m1.setVelocity( Controller.Axis1.position(), percent );
this_thread::sleep_for(10);
}
}
The intent is for the motor to spin at 100 percent in reverse during autonomous after something else has happened. In reality the motor will often spin forwards at 100% immediately and then spin in reverse.
The problem is again that usercontrol can often run when the controller/field connection order is inconsistent. If user control runs, the motor is told to spin at 0 velocity and then we run into problems.
setVelocity has different functionality depending on whether the motor is stopped, when it means set the velocity to be used by the next spin command (with no velocity parameter), however, if the motor has already been told to spin then it means change velocity to a new value.
When auton runs after usercontrol and setVelocity used, the motor will move.
as I said, setVelocity is evil.
but the pattern comes from blocks where it was required to reduce the number of parameters each block had and overloads were not available.
You could stop the motor at the beginning of auton, but my preferred solution is to never use setVelocity and add velocities as parameters to the spin command.
void autonomous( void ) {
this_thread::sleep_for(1000);
m1.spin( reverse, 100, percent );
}
/*----------------------------------------------------------------------------*/
void usercontrol( void ) {
while (true) {
m1.spin( forward, Controller.Axis1.position(), percent );
this_thread::sleep_for(10);
}
}