Am I Using Command-Based Correctly?

[PopeRyanI]

Hello all,

After reading a lot about it on this forum, I decided to try out using the Command Based framework for our FRC robot. In years past, my team mostly just wrote code using the SampleRobot base class and put all of the code in one file (well, and the headers). As a result, I was curious about the Command Based model because of its emphasis on dividing up the code which helps with having multiple people be able to program at the same time, something we have not done very much.

I recently tried to port our offseason robot code over to the Command Based model. It is not perfect and does not have an autonomous, but does work for the most part. I posted it here: https://github.com/ryanp73/CommandBasedRobotExample/tree/master/src

I looked at numerous examples from other teams online and eventually came up with this code. One of the things I noticed that initially stopped me using this framework was the presence of the boilerplate code and especially just the inefficiency of having so many files; however, I still like how it prevents repetition in addition to the easier ability to run things for set periods of time and run things concurrently.

So to return to my question: am I doing this correctly? What suggestions would you give to improve this code and/or do things differently?

[Jalerre]

As far as I can tell, you are using the command based template exactly as it is intended. The only suggestion I have is to set constants labeled PWM1, PWM2, DIO1, DIO2, ect in your Robot Map and then set your motor controller and sensor variables to these constants. It makes things a lot easier if wiring changes in the future and increases readablity.

[lethc]

Looks good, I think you used the command based framework really well.

I think you'll really see why command based is great when you put in your autos - it's really easy to string together autonomous routines using the commands to control individual subsystems.

[PopeRyanI]

Awesome, I'm glad I did this correctly. I'm looking forward to using this approach in the build season. Now I need to start teaching the other programmers how to use it. This will definitely help us be able to have more people working concurrently.

The only suggestion I have is to set constants labeled PWM1, PWM2, DIO1, DIO2, etc in your Robot Map and then set your motor controller and sensor variables to these constants. It makes things a lot easier if wiring changes in the future and increases readability.

That's a good idea! I hadn't thought about doing that before, but it will definitely help with the problem of readability.

I think you'll really see why command based is great when you put in your autos - it's really easy to string together autonomous routines using the commands to control individual subsystems.

Yeah, that was the part that really intrigued me the most when I first looked into command-based was the easier ability to create autonomous routines, especially without repeating myself.

One other thing I just wondered about is how people manage workflow with multiple programmers. My team uses Github a lot, but we have not really dealt with multiple people working on the same project at the same time. My initial thought was to have people create their own fork and then send pull requests when their code is ready to test on the robot. Then the head programmer (me) would merge their pull requests and incorporate their new commands and subsystems into the Robot and OI files. Thoughts on this system?

[DaveFrederick]

I highly recommend you try out the WPITool called "RobotBuilder". This tool is great and really simplifies the creation of basic robot code. Here are some detailed instructions. FRCSIM is an additional tool to support code development. It is getting better but is a little difficult to understand.

I have attached a document which provide a detailed step-wise process to use RobotBuilder. All Feedback is welcome.

Dave Frederick
Team 1895 Mentor
Manassas, VA

[PopeRyanI]

I highly recommend you try out the WPITool called "RobotBuilder". This tool is great and really simplifies the creation of basic robot code. Here are some detailed instructions. FRCSIM is an additional tool to support code development. It is getting better but is a little difficult to understand.

I have attached a document which provide a detailed step-wise process to use RobotBuilder. All Feedback is welcome.


I have looked into RobotBuilder but I don't think we will ultimately use it. I appreciate the instructions you attached, but it just seems a little tedious to use. It would seem easier to just create the files when we need them, especially if things change or get added so that we don't have to keep going back to the program to modify it. I didn't know about it before, but now I definitely want to look into FRCSim and hopefully use it during season.

[GeeTwo]

One other thing I just wondered about is how people manage workflow with multiple programmers. My team uses Github a lot, but we have not really dealt with multiple people working on the same project at the same time. My initial thought was to have people create their own fork and then send pull requests when their code is ready to test on the robot. Then the head programmer (me) would merge their pull requests and incorporate their new commands and subsystems into the Robot and OI files. Thoughts on this system?

That's pretty much what we use. The hardest part with something like this is getting the individuals to commit to their online fork frequently (preferred every hour or two of editing) so that it is not lost. (Make sure they understand that "commit" does not mean "cannot be undone"!!)

We also have a rule that only code in the master or another "common" fork is deployed to the robot or hardware test platform. Given the limited number of RIOs around, anything worth testing is worth having in a public pool of code.

As with any project, it is always easiest to manage merging the changes if each thing is only being worked on by one person (or at least in a single fork). Of course, that "thing" may be rather small, and involve overlapping files, so one person might be working on the PID loop, another on the encoder interface, and a third on the driver (main loop).

Have a test plan, particularly include regression testing (that is, test that previous bugs that you have fixed weren't inadvertently re-introduced). Run this test suite weekly or after each major upgrade (e.g. new subsystem or refactoring of code) seems pretty stable, whichever comes first.

Edit: And if you have a specific wiring and/or pneumatics subteam, teach them how to access the info they need from your repository (e.g. pinouts), or provide them a hardcopy update whenever this info changes. Work with them to also get things like their color coding into the repository, whether they make the changes, or submit them to a programmer. It'll make both of your lives easier!!

Edit2: And let me also recommend Robot Builder - as a first step. We use robot builder to create all of the little nitnoid pieces that tie a new subsystem or command in to the infrastructure, then write all the specific code in whichever IDE we're using that year. Our first few years, manually inserting new subsystems caused us much more time to correct than if we had started with robot builder.