Hey Everyone!
During worlds, the software team and other VEX developers do a lot of the software support for teams. So if they have any issues we dig in to it to find if it is a mistake with the code or a potantial hardware issue. One of the other VEX developers did a write up in the VEX Forum about some of the common issues that students were running in to at Worlds.
Hopefully this can help your students avoid these issues as well!
First topic is incorrect use of event handlers, something we have covered before but it seems everyone forgets.
The symptom is that, for example, an event handler on a controller button sometimes works and sometimes doesn’t. At worlds the most common use was for firing pneumatics, a button push to set one state and a second button push to revert back to original state.
Simple code for a callback could look as follows.
void button_callback() {
static int calls = 0;
Brain.Screen.setFont( mono40 );
Brain.Screen.printAt( 100, 160, "Button %4d", ++calls );
}
This is just for demonstration purposes and prints the number of callbacks on the brain screen.
We often saw event registration at the beginning of driver control like this.
void usercontrol( void ) {
Controller.ButtonA.pressed( button_callback );
// more code
}
So what’s the problem with that ?
usercontrol can be called more than once.
The reason is that if the controller is connected (radio linked) to the robot and the field control is not connected (either new or legacy) then usercontrol will run. This is expected and what we usually want to happen when practicing. Once the field control is connected then the robot will usually be disabled unless the match has already started. When the driver control period starts then usercontrol will run again and the button_callback registered a second time, when controller button A is pressed button_callback will be called twice (and potentially more if field control was connected and disconnected more than once) and obviously if it is toggling a pneumatic solenoid nothing will actually happen (the solenoid will be enable and disabled very quickly or not at all).
Event registration should only happen once at the beginning of main. This would be the correct place for the code.
int main() {
Controller.ButtonA.pressed( button_callback );
Competition.autonomous( autonomous );
Competition.drivercontrol( usercontrol );
pre_auton();
while(1) {
this_thread::sleep_for(10);
}
}
The order that teams connected to the field and started their code varied and they had inconsistent results because of registering events in usercontrol.
Second topic, incorrect use of local variables.
Consider this code, a very simplified version of something we saw at worlds.
code
vex::pneumatics pn(Brain.ThreeWirePort.A );
void usercontrol( void ) {
int my_state = 0;
while (true) {
if( Controller.ButtonA.pressing() ) {
if( my_state == 0 ) {
my_state = 1;
}
else
if( my_state == 1 ) {
my_state = 0;
}
if( my_state == 1 ) {
pn.open();
Brain.Screen.printAt( 100, 100, "Open " );
}
if( my_state == 0 ) {
pn.close();
Brain.Screen.printAt( 100, 100, "Closed " );
}
while( Controller.ButtonA.pressing() ) {
this_thread::sleep_for(10);
}
}
this_thread::sleep_for(10);
}
}
The idea is to toggle pneumatics open and closed (much more was involved in the student code)
The team may allow usercontrol to run before connecting field control and press button A to open the pneumatics, then connect field control. The first time usercontrol is run in the match the pneumatics do not close when the button is pressed. The mistake is assuming that a local variable will maintain state between calls to usercontrol, the solution for this is to make the variable my_state static or (worse) global. my_state then retains its value between calls.
static int my_state = 0;
And finally, 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);
}
}
