What to put in disabled() and robotinit()?

Technical Java
1

Hello all,

In my quest to better understand the control system of the robots, I have noticed that the default disabled and robotinit functions are usually running. I am aware that this is acceptable, but was wondering what could these functions could be used for. I have seen the camera initialized in robotinit() in the sample vision code, and from my understanding nothing will run that is put in the disabled method. What sorts of things does your team program in these methods?

Thanks,
Zaque.

2

Our understanding is that:

  • robotInit() is called only once per reboot/deploy (don’t put any code in here that you want to run without rebooting the robot).

  • disabled() is called when you transition between states.

  • You can not execute any code in either of these methods which actuate devices on your robot. In other words, you can probably read sensors, but you can’t drive motors or pneumatics.

When using the SimpleRobot framework, we typically implement robotInit() for the following purposes:

  • Construct the various parts used in the robot (Talons, Relays, Counters, etc).

  • Perform initialization tasks that only need to be done once per boot (initialize gyro, set up camera, etc).

  • The addition of our own System.out.println() message so we can see that our deploy was successful and ready to run in the NetBeans console.

Often we don’t implement our own version of disabled(), but when we do we use it for purposes that don’t involve controlling motors or pneumatics. Sometimes we will update the smart dashboard for sensor readings (for example, if we want to see how accurate the gyro is, we can put the value to the smart dashboard and have a few kids pick up and rotate the robot a few revolutions while the robot is disabled).

We’ve found that the SimpleRobot framework is excellent for quickly creating small programs to test specific electrical components. As projects grow and become more complex, switching to the CommandBase frame work pays off in the end.

3

Here are some of the things we’ve put in disabled and robotInit:

robotInit:
Read preferences to determine if practice robot flag has been set
Read autonomous file
configure sensors that need additional configuration beyond the constructor

disabled:
read and display sensors (It’s really handy to verify a sensor is working without enabling the robot)
check for changes in autonomous file
select autonomous mode

4

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…)


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.

5