This past fall our team presented a Basic Command Based Java course at the VA FRC Workshops that VirginiaFIRST organizes every year. This summer I’d like to put together an intermediate to advanced presentation and would like some input on what are some things people would be interested in learning about if they were to attend a course on something like this.
The basic course covered:
The basic srtucture
Subsystems
Commands
Writing a basic drivetrain and autonomous.
Some more advanced topics I was thinking about are:
Creating reusable commands
CommandGroups
PIDSubsystems and PIDCommands
Case based CommandGroups
What other topics do you think would be useful? I’d also like to use this as a research opportunity for our team for things that we have not figured out the best practice for yet, and we can post our results here as we find them, even if it doesn’t make it into the final presentation.
I for one have been converted into a huge proponent of robot builder.
Sooo…
Creating a Project in RobotBuilder
Maintaining a Project in RobotBuilder
Using Git to manage a RobotBuilder based project.
Interrupted vs Finished Commands
Planning for Edge Cases (i.e. no hot goal)
Extendable Commands (may be more advanced than intermediate)
Analog Buttons (many teams don’t utilize the xbox triggers because they’re analog)
Command - Subsystem Dependencies and Interrupts.
Creating a Project in RobotBuilder
Maintaining a Project in RobotBuilder
Using Git to manage a RobotBuilder based project.
We used RobotBuilder our first year and were not big fans of it, but maybe that’s because we weren’t using it correctly. Its something we can look into and see what we can come up with.
Using Git to manage a RobotBuilder based project.
I love this suggestion and will probably just expand it into “Using a repository to manage your code.” This is something that we finally started doing more of this year and it has help. we haven’t completely figured out our best process yet but we’re improving.
Yes. 100 times yes. I can’t even count how many teams have asked for help in the pits saying they made one change that broke their entire robot but have no version control system to fall back on.
We should teach proper version control system usage BEFORE we teach people how to program.
(and oh yeah, save yourself some headache and just use git.)
The thing we’re struggling with right now is when to branch, when to tag, etc. We just haven’t figured out the best process for us yet. What do you guys do?
Typically, everything lives in master. Sometimes we will tag at the end of an event so we can dial the comp bot back to where it was (as we change code a lot between events), but most times we forget to do this. Usually there is only a small group of developers using one laptop to write code, so keeping branches in sync isn’t really an issue.
If a student is working on a feature that is easy to break off, I will have them make a branch that we can pull in later. An example of this is something like a tiny HTTP server or your vision code. Define the interface then let them hack on the implementation in a branch.
The main rule is don’t commit code that breaks the build!
Ok, so it sounds like you’re doing pretty much the same thing we’re doing. We keep a trunk version and a branch version. Once we’re sure the code is working in the branch the way we want we’ll merge it into the trunk. We also do a lot of code changes between competitions (adding in a 3rd ball pickup to our 2 ball autp after week 4 and adding in CheesyVision for hot goal 1 and 2 balls currently), the first thing we did was tag our competition code from week 6. I’ve heard of teams that make tags after each meeting, this just seems excessive to me but we’re still trying to hash out our best practice.
The pain in the butt thing we ran into this year was our practice bot is using 2 solenoid cards instead of 1 like our competition bot is using because of a lack of correctly voltaged solenoids, so making sure we don’t merge in our address changes can get annoying. We currently have 2 working branches open, one for competition and one for practice so we’re not constantly having to make sure we have the right addresses in. Keeping both branches and the trunk in sync is a bit annoying.
This is actually one of my biggest qualms with robotbuilder, is that it doesn’t support feature branching that well.
Typically I find that the drive train and the mechanisms are separate enough that, as a general rule, work on them (and they’re commands) can be split into separate branches.
I personally prefer a mechanism based package structure for this reason. Something like this:
This allows you to quickly branch the mechanism (subsystems and commands together). It also helps to isolate the modifications that are being done.
Obviously there are still modifications that have to be made to core class (i.e. OI) but these are typically simple enough that they shouldn’t require a branch.
I also encourage a “test before you commit” even for the local repo. This ensures that the students verify their work before submitting it. I also wait to do a “code review” until they are ready to publish their work.
We don’t have the luxury of a multi student programming team, but I would love a model where you have a student who is responsible for each mechanism, and one responsible for the “robot”.
I personally prefer a mechanism based package structure for this reason. Something like this:
We create new packages for commands for each of the subsystems so they aren’t all stuck in the base commands package. Makes it much easier to find what you want.
blah.blah.blah.blah.drivetrain.commands
My biggest complaint about RobotBuilder when we first used it was that it declared all of our motors and sensors in the RobotMap class instead of in their respective subsystems. Does it still do this?
We also found things easier using a mechanism based package structure.
Also, we have a naming system
SS_ : Subsystem
C_ : Command
CG_ : Command Group
This way, we know what is what. And we can have similar named Commands and Command Groups, if we need that
C_Pickup
CG_Pickup.
What I want to see more of, is people getting out of their comfort zone with coding. Getting them to try new things, instead of doing the same old simple, boring code.
For example, I’ve been making a custom Library (Much Like atalibj that I found earlier this week), and the main point of it, is the Custom main robot class. It runs smoother, and faster than the WPILib version, and adds in some more automation to the robots. https://github.com/WestwoodRobotics/RoboLibJ
Also, If you are using an IDE, Making custom templates is a really good idea.
I have A custom template for the Subsystem Class that automatically fill in the super() constructor, writes singleton code, writes a static{} block, adds in an ITable and ITableListener for custom values, creates some extra methods for the ITable.
We do it a bit differently. Master is kept as the latest working/tested code that can be deployed to the robot and guaranteed to work. And only Mentors are allowed to push to master as an understanding by all programming members.
Everything else is done in branches. Every feature is branched and pull requested. The programming mentors review the branches, and either make comments, or merge it into master once the code was tested.
Now sometimes during a competition, we will work in master, but we will push to github into a new branch. And then follow the same process.
I have all of my students setup using eclipse and egit (what i personally use on my Ubuntu FRC laptop), although some students on our team use gitGui on Windows for managing their comits. We rarely ever tag, but we should.
Note: The above is the ideal scenario on our team, I hope I get to see the day that it actually works like that. LOL.
As for maintaing multiple versions of the code. The Poofs wrote a pretty neat library called a ConstantsFile I belive. It is an object that you can use to declare variables in RobotMap and then overwrite them using a textfile that lives on the CRio. If the textfile doesn’t exist, it just defaults to the hardwritten value in code. I am sure someone on 254 can explain it better.
Essentially, you can maintain one code base for your comp bot and practice bot, if you wrote your variables such that they can be updated on RobotStartup via a text file, and have that text file live on the practice bot cRio. This would allow you to keep the same single source and the text file on the practice bot does the heavy lifting for you. You can accomplish this using the Poofs method, or implement your own.
As for advanced topics for command base:
Commands are loaded during their instantation on RobotInit. How to pass a value to a command in realtime during robot run.
Default commands, and how/when to use them
CommandBase programming philosophy. When to make something a method/function within a subsystem, when to make it a command, when to make it a command group.
And of course, no programming class is complete with a proper “how to comment code” discussion.
What I want to see more of, is people getting out of their comfort zone with coding.
This is one of the reasons I want to do this as an exercise, to come up with ideas of ways we can implement new practices and how to perfect the ones we currently have while also providing resources to other teams to use to improve their skills.