we tapped into robotInit and made sure a corresponding (possibly empty) robotInit() gets called in every subsystem.
did the same for the autonomousInit(), disabledInit(), testInit(), teleopInit(): they all call a modeChanged() method in Robot that's calls a modeChanged() method in every subsystem.
same for all the *periodic() functions: they all call a method in Robot that calls a periodic() method in every subsystem (which take care of subsystem specific network table puts). The Robot.periodic() takes care of robot-wide telemetry (we have a "record network tables to disk" app on our driver station).
Robot has a getCurrentMode() and getPreviousMode() for everyone to use.
If we add a subsystem to the robot, we (just once) make sure it has empty robotInit(), modeChanged(), and periodic() methods, and we make sure that they get added to the list of called routines in Robot.java.
It seems like overkill, but the net effect is that *all* code for a subsystem is either in the subsystem or it's commands: none of it is off to the side in Robot.java. Consistency between subsystems cuts down on silly mistakes. Not having to remember to look in Robot.java for code that does subsystem-specific initializations or periodic() processing; cuts down on silly mistakes.
for example, in our drive subsystem (I'm paraphrasing...)
Code:
public void modeChanged() {
if (Robot.getCurrentMode() == RobotMode.TELEOP) {
// drive subsystem specific set up at start of Teleop
setReverseMode(false);
}
}
This might be overengineering, but we do like the consistency and modularity.