Investigate robots not stopping at the end of matches

[PeterJCLaw]

During the competition matches there were a number of robots which carried on moving after the end of the matches. I'm not sure if this has been captured already somewhere, but I'm adding this in case it hasn't.

There was one occasion, though I can't recall which robot, where a robot was definitely still driving around substantially after the end of the match. This indicates that the motors weren't stopped, which implies that the power board's outputs weren't killed. There are a number of possible causes of this (competition mode USB not working, something awry in the software stack), though it definitely needs looking into if possible.

Separately, the mostly-black robot with the arms and the knight-rider like LED strip on a servo was regularly still running its LED strip and moving its servo after the ends of matches. That robot did seem to otherwise stop as expected, so this might actually be something else. In any case, this also definitely indicates that the power board was not shutting down at the end of matches.

[trickeydan]

There are two separate instance here, both caused by separate issues.

• The Black robot with LEDs was using threads, and as we had not considered teams using these, the threads were not correctly killed off it seems. (Non-main threads are not killed on timeout #69).

  • I believe that the pyserial instance was left in memory, and as the Arduino connection is not killed in make_safe (unlike the motor board, which loses power), this was able to persist in the other thread.

• The other robot mentioned was notably team 5 in the final. We have got the logs and SD card, it appears to be that the kernel did not detect the competition mode USB. This issue would be mitigated by Beep the zone #44, although that issue is still under debate.

[kierdavis]

This issue would be mitigated by #44, although that issue is still under debate.

Unfortunately, I don't think this will work. Since c12e5e3, the earliest that our code has access to the zone information and could emit a corresponding tone is immediately after the start button is pressed. Even if the person pushing the start button noticed that the robot was not in competition mode, there's no time to reboot the robot and try again without jeopardising the match. We would have to rework our metadata (zone info) loading strategy for this to work.

[trickeydan]

the earliest that our code has access to the zone information and could emit a corresponding tone is immediately after the start button is pressed

This was put in for @prophile during the week when we realised how short of a time we have.

I'd rather not do this in the future.

Tangent: 7 segment display on Pi Power Hat Rev2?