Software Description
(Please do not quote these posts as they contain embedded images, thanks)
The control signals to the robot (or rather the joystick) are very simple. One signal either enables or disables the robot, the other selects driver control or autonomous operation. The match controller has separate signal buffers for the two alliances but it’s important to note that both blue robots receive exactly the same control signal as there is no additional buffering in the driver interface. The same is true for the red alliance, both teams receive exactly the same control signal. The tournament manager software controls when these signals are switched, to verify operation independently from the tournament manager software I created a small application to communicate with the match controller and allow them to be switched individually. In addition to this, it provides test modes for driver control and autonomous in a similar way that tournament manager does. Here is a screen grab of the Mac version (PC version is similar).
As can be seen from this screen shot, GPIO0, GPIO1 and GPIO2 are used for driver interface 1, GPIO3, DTR and RTS are used for driver control interface 2.
When the tournament manager software is controlling these signals it ensures that the driver/autonomous selection is always made before the robot is enabled rather then trying to switch them exactly at the same time. This ensures that a robot is not briefly put into the wrong mode when a match starts or restarts.
One unusual aspect I found is that tournament manager constantly toggles the driver/auton control signal when the robots are disabled before and after a match. I have no idea why it does this, it may just be a bug or the joystick possibly detects this and takes some type of unknown action, who knows (well only VEX and DWAB I guess).
Here is a composite scope capture showing how the control signals for one driver interface are switched for a single match, it illustrates the timing of the enable/disable and driver/auton signals.
In addition to controlling these two signals, tournament manager also controls the LED power signal to flash the leds on the driver interface. This function is completely independent from robot control, however, if the driver interface leds are working correctly then it’s a very good indication that field control is working. Part 3 of this post will cover what to look for if you think field control did not work for you.
Here is a scope grab showing how tournament manager controls the LED power signal when robots are disabled, the “flash” rate is 1 Hz. These were captured before the inverting buffers and are therefore show inverted as compared to the actual signals.
There are a few important things to understand about the field controller software.
-
Control is one way using two simple signals, there is no feedback from the joystick or robot to field control.
-
The field control is holding you robot in disable until released, that is, if for some reason field control was not working, a disconnected cable or something like that, then your robot will be enabled.
-
Field control does not use any form of “special” commands to your robot, it can not erase your program, it does not directly tell your robot what to do, it only “releases” your robot when the match starts.
-
If your alliance partner was released by field control and you did not move, then it’s not a field control problem. The signals that you are receiving are exactly the same as your alliance partner, in fact, you are directly connected to your alliance partner joystick through the driver interface.
-
If both you and your alliance partner have problems when the match starts, it may be a field control problem, see the next section and check the leds on your joystick and the driver interface, they are there to help you.