This is important because, at worlds this year (for Skyrise), team 2442A was placed in the Science division on the middle field (forgetting the number, sorry) for a match. Something happened with the field control that caused our autonomous not to run. The only logical explanation I can come up with is that our LCD menu system’s safety tripped and ended all tasks pertaining to pre-autonomous and autonomous, launching our robot into tele-op ready mode. As such, autonomous was not run once field control was up and running again.
Again, is there a different way to check the game state than what I am currently using?
Please post your codes and competition template if you modded it.
Personally, I would not try to shut down motors by stopping tasks.
The way I would do it is to give all motor commands to some global variables, send these variables to motors in a loop in a separate task, and simply using boolean global variables to stop sending values to my motors in that task and send zero instead, should I want to shut down all motors in emergency.
Field control, receiver state and ROBOTC’s competition template are dangerous things to mess around with. If you don’t have a full field control kit to learn every single detail of it, I suggest leaving this area and trying something you know for sure that’s gonna work. Well, things like this, if you miss a thing, you only know it by losing a match.
Some of my personal insight after losing 2 matches within 10 pts at worlds because of a multitasking glitch in autonomous with field control and finishing ranking 27, seeing the team on my left getting picked by the last alliance as second pick. I still can’t stop blaming the programmer for not including one start task command at beginning of autonomous. I was the programmer.
The menu system waits for a user to press a confirm button. Before confirming, a user can do anything they have created menus for (I use a few menus to select autonomous). Before I implemented the safety, the menu system would wait infinitely for the user to confirm, even if the match entered autonomous or tele-op mode. So, the safety “presses the confirm button” for the user so the robot isn’t effectively dead on field the entire match.
The code isn’t completely finished yet, and I plan on doing a large reveal in the near future. I hope you understand my unwillingness to post the entire source. I have not modified the competition template.
The concerning piece as it appears in source:
//Safety feature - Stop LCD control because the game has entered driver control mode
if (!(nVexRCReceiveState & vrDisabled) && !(nVexRCReceiveState & vrAutonomousMode))
{
startTask(usercontrol);
break;
}
And in pre-auton:
startTask(UpdateLCDTask);
while (!endPreAuton) { wait1Msec(25); }
I am not shutting down motors by stopping tasks. All I am doing is making the menu system stop running and starting the task usercontrol directly before returning to pre-auton.
Indeed, these things can be dangerous to mess with. The problem is, I spent hours with a full field control kit trying different things and nothing came up. I didn’t think this bug was possible in the first place. As such, it would help if I knew exactly what happened with field control. Unfortunately, I don’t, but in the end the safety worked and we were able to operate the robot during tele-op.
Both of your replies point to the same thing: there isn’t another way of getting the game state. At any rate, thank you for your time and effort.