I just discovered command based programming, but the code is written in TimedRobot mode. Is it bad to have the command and subsystems file? Should I switch the format completely to a command based robot?
Also, what are some benefits and disadvantages of using a command based robots? It would also be very helpful if someone could provide a bit of source info.
TimedRobot is simply a way for you to know approximately how fast your code will be executed. For WPILib, it’s once every 20ms. It’s fully compatible with Command-Based programming, and in fact is recommended to be used this year.
Command-based essentially allows you to organize your code into separate classes and pass off some management logic to wpilib. It adds a bit of complexity in that you need to understand how it works, but allows much much cleaner code. I recommend using it once you want more than basic robot functionality.
See the ScreenSteps Live section on command-based programming for a good overview. There are a lot of other good resources out there for how to properly use Command-based robot programming.
I very much recommend using different folders for your subsystems and commands. It helps us to keep everything organized. We use the regular robot folder to hold our Main, Robot, OI, and RobotMap, and most everything else is housed within the subsystems and commands folders.
EDIT: As for the second question, the link @Royce posted above is the best place to start.
I also recently learned about RobotMap, what are some of its uses and how important is it? Sorry about all of these basic questions. I did read the screensteps and stuff but still have a bit of trouble understanding them.
We went a bit ahead and have a subsystems package that holds a package for each subsystem. Each sub-package holds a Subsystem class, a constants file and a ports (=RobotMap) file and a package with all the subsystem’s commands.
The robot package only holds the Main.java, Robot.java and OI.java files.
Command-based is sort of a layer that sits on top of either TimedRobot or IterativeRobot.
Both TimedRobot and IterativeRobot are supposed to execute the *periodic() method appropriate to the mode roughly once every 20ms. TimedRobot bases this on a timer that’s run on the FPGA; IterativeRobot bases this off of the driver station sending data. Because TimedRobot doesn’t have a wireless link or Windows involved in the loop, it’s much more consistent in timing – you don’t get jumps of 19ms/21ms/etc…
Royce highlighted some of the advantages of Command-based, which I fully agree with. I much prefer command-based, and vouch for it, however, here are some realistic disadvantages:
You need more lines of code to get running in the first place, especially for a robot that only drives, and only has teleop mode – however, it is more efficient in the long run, even in terms of lines of code
You must understand and follow the rules (invariants) of the framework, which requires learning what they are – this is a time cost and mental overhead
You shouldn’t mix command-based and non-command-based code in the same project unless you have deep understanding of what the command-based code is doing beneath – thus, a little Command-based means all command-based, which may require extra learning and thus temporarily prevent people from contributing to the project
We use robot to hold all of the ports for out motors, solenoids, and even some constants. Basically, it just has a list of static variables, so anywhere in our program we can say RobotMap.DRIVE_MOTOR_ONE_PORT and we’ll get the port for that motor. You can see an example of last year’s RobotMap. This way, if you have to change a port for a motor, you know exactly where it is and you don’t ever have to worry about searching through your code to find where you initialize that motor (or solenoid, etc).