Let me add a couple of comments.
The framework started in Team 281 before the command driven robot was introduced by FIRST. As Sigma7 mentioned, we find it's easier to understand for new programmers and it tended to have fewer issues (at least for us) than the Command driven robot (e.g. memory/object accesses between threads). These problems were especially prevalent when the subsystems needed to communicate with each other.
I will say we haven't tried a command driven robot since the first year, and it looks like it has improved since then, so take this with a grain of salt. But we've been using it for many years and it has worked well for us.
By the way Sigma7, I've improved the base class (RobotSubsystem) for this year so that it automatically registers the subsystem with the main robot at the time of construction. Each of the IterativeRobot methods looks something like this now:
Code:
TeleopPeriodic()
{
// Do any operator input changes here
// Loop over subsystems and let them do their work
for (std::list<RobotSubsystem *>::iterator it = m_subsys.begin() ; it != m_subsys.end(); ++it) {
(*it)->TeleopPeriodic();
}
}
Everything is done relatively automatically. Our 2013 Entech code (also on Google Code) was the inspiration for the work. I'll post a baseline if anyone is interested.