Does the FMS turn the branch circuits off on the PDB? In other words do the controllers and co-processors still have power after the match has ended? I realize the main breaker will remove all power, but does a team have time to power down their co-processors so data is not corrupted? How do team handle the shutdown of co-processors?
A self shut down cycle that is times from the start of the match is one way I know.
Thanks.
FMS doesn’t talk directly to the robots. The DS disables the robot. The disable is exactly the same as an non FMS disable. Anyway the PDB is completely affected. The disable just shuts off the outputs on the roborio. (PWMs, Relays, and canbus enables.)
The robot enters the Disabled state at the end of each match and remains there until being powered off.
So all that’s working in Disabled is what you can depend on.
I2C/SPI/USB/Ethernet communications still work.
Joystick inputs are frozen, but other user communications, e.g., dashboard, are still relayed.
To shutdown co-processors you might use the match state/match time/robot state to automatically initiate a shutdown.
You’d need a different technique for a pit manual shutdown, since that happens at random times.
I suppose both could be accomplished by a manual switch on the robot itself that the drive team throws before turning off the robot whether in the pits or on the field.
That’d be necessary anyway for any power cycles requested by the field crew before match start.
The PDP has no switching circuitry on its outputs. When the robot is disabled, a control signal is sent out to motor controllers and other devices to tell them to stop (for things like PWM sockets, they are locked to 0 by the RoboRIO).
You can choose to hook into the Disabled state of the robot to shut off your coprocessor, however you have to be careful since the disabled mode is also called between transitions of the other states (i.e. Auto -> Teleop).
If you want to minimize the risk of corrupting your coprocessor’s filesystem, call sync each time you make a change to a file on disk to flush it out to disk immediately.
Hmm. I was hoping that 2018 FMS/WPILIB would flag that for “live match” or “not live match”. Is this still not the case?
Not sure how this relates to all the other times a shutdown or power cycle must occur…
I see that to be the greater problem.
And if you solve the greater problem, then the special case of a field match is covered.
Here’s what you get about match state in 2018.
Some data will be provided when running practice matches from the Driver Station, but some (e.g., valid match number) will be unique to an FMS match.
This is a LabVIEW example, but the same information is available in all languages.
This … is perfect. Thanks! 
Thanks all. So the power will be maintained through a custom circuit via the PD board after a match so a proper shutdown can be done on the co-processor. We will also add a convenient manual switch to initiate shutdown if the main breaker needs to be opened for any reason on the field or in pitts.
You right, something in co-processor code to do a manual power down on request and in the pits.
Good points I didn’t think about the Auto - Telop transition.
So the power will be maintained through a custom circuit via the PD board after a match so a proper shutdown can be done on the co-processor. We will also add a convenient manual switch to initiate shutdown if the main breaker needs to be opened for any reason on the field or in pitts.
You’ll want to make sure that orderly coprocessor shutdown does not take more than 2-3 seconds. Field staff will lose patience with a robot that takes a long time to exit the field, and you’ll miss out on chances to fix robot connectivity problems, if there are issues this year.
Hopefully you’re not doing this because your coprocessor fails if it suddenly loses power. I would not have a component on our robot that failed to restart properly after a power failure. There are techniques you can use to minimize the chance of filesystem corruption at power failure.
This also might be part of what you are looking for: DS Mode & Status
There is an FMS Attached T/F flag available on the robot.
Absolutely I agree and we are aware of those methods, among others, however layers of redundancy is the goal. We first avoid the condition then plan for it anyway.
One thing programmers have to consider is the risk that ancillary code/hardware such as this introduces bugs on its own. An extreme example is the US Space Shuttle - understandably, since lives are at risk, it has a complex self-monitoring system. Some faults that are detected are faults within that monitoring system itself, and not in the Shuttle per se, but still delay a launch.
You can go through the match cycle during testing by running a “Practice Match” from the Drivers Station.
Please note, though, rarely an Arena Fault (2017 Rules paragraph 10.8), which everyone calls a Field Fault, will happen during a match and the match will be restarted. 10.8 says “All reasonable effort is made to create the same conditions when replaying a MATCH.” I wouldn’t make any assumptions as to what FMS does in this case and you’d best be prepared for the worst case.
If the match is going to be replayed immediately, the field is reopened to teams to reposition their robots. Teams can also choose to power cycle their robots at that point, if it doesn’t cause further delay to the replay match.
The goal is the replay match is just like the original match.
In the event of a arena fault, the field staff will take the same steps to restart that match as they would as if it were your first time on the field.
I.E. You can expect the FMS to disconnect, and start the match over again.
Sorry, you’re right, of course. I was thinking of the aborted “Arena Fault” game itself, where FMS wouldn’t go through the complete game cycle.
