CommandRobot discussion

[spacey-sooty]

There has been some discussion about how a CommandRobot might be implemented and why. It seems to be a generally positive change to move away from RobotContainer and TimedRobot to a single unified class with clarity about its purpose. From the discussions that I've seen there are still some questions to be answered:

1. Should it extend IterativeRobotBase or TimedRobot?
2. How much of IterativeRobotBase should it exposed? (eg. making RobotPeriodic or TeleopPeriodic final)
3. How much of the RobotContainer structure should be maintained? (eg. still have a configure bindings function?)

[UserC2]

From how my team (2609) uses RobotContainer and TimedRobot, I think:

1. TimedRobot, because TimedRobot adds a few methods necessary for a Command-Based robot (e.g. startCompetition()), although these could be moved into IterativeRobotBase.
2. robotPeriodic() and teleopPeriodic() could be marked final to force teams to use commands (and use addPeriodic() for any functions that should run repeatedly)
3. RobotContainer has getAutonomousCommand() and configureBindings(), which could both be eliminated as they are called once and never used again: getAutonomousCommand() is called once in autonomousInit(), and configureBindings() is called in the constructor. If teams had a long list of bindings to configure or a long method of choosing their autonomous mode, they could create their own function (no need to require teams to use one).