During the 2019 season, I took notes on best practices that either made our robot better for the 2019 season, or will most likely be implemented on our 2020 robot and make us better. This list is the 10 most important, in no particular order, with the challenge level for each.
1) Use Static IPs on Driver Station Computers (Very Easy)
As I mentioned in a previous post, using static IPs can significantly reduce your connection time at the field, which will make your life easier and keep events on schedule. Since setting your IP is super easy, you should try to do it on all devices your team has. This change is so quick, you could easily get it done in a matter of minutes, and it will save you lots of headache and anxiety at competition.
2) Motion Magic and PID on Everything / Spend Time Wiring (Somewhat Difficult)
My FRC team primarily used bang-bang controls for 23 years. While FRC continued to become more advanced, our programming team was unwilling and unable to change. This year, I led an effort to use Motion Magic (linear motion profiles) and PID on many subsystems. The results speak for themselves, with the effort required for our robot operators decreased and our reliability significantly increased.
We had to use Motion Magic this year because we had subsystems that would conflict with each other. Even though we will try to avoid this problem in the future, it still is worth the effort, and our software was even able to compensate for some (minor) electronics issues.
Electronics did make our life a lot harder. We made the mistake of rewiring our robot two days before bag, and we suffered with the consequences for the rest of the season. We should’ve had a well-documented electronics standard that we followed and we should’ve given them more time to wire.
The other problem is that we did not use PID on everything, but rather on stuff that we thought we needed it on. For example, our cargo outtake was controlled with Percent Output on old Victor SP motor controllers. Towards the end of the season it would’ve been convenient to have a PID-based system so we could shoot consistently and avoid the fallout of some wiring issues. Next year, one of the best things we could possibly do to have a reliable robot is to have good wiring with PID on every subsystem.
3) Establish a Common Directory Structure for Code (Very Easy)
This was one of the most fundamental changes that we made last year in terms of code quality. By establishing a common directory structure, every function was easy to find and it forced us to compartmentalize our code. We decided to use Robot-Subsystem-Command format, and structure stuff as follows:
/com/pack/age/ Robot.java Main.java OI.java Constants.java subsystems/ Drivetrain.java ... commands/ SubsystemA/ CommandA.java ... SimilarCommands/ CommandB.java ... ...
In past years, it has become very easy to lose or confuse files because we used to just keep everything at one or two sub-directory levels. However, now it is super easy to find exactly what we are looking for. It probably would be a good idea to plan this out and have it documented, so that everyone knows where to put code and where they can find files! If you are looking for how we laid out everything last year, I highly suggest you check out our 2019 repository. The most important thing is that your structure works for your programmers, so that everyone can find code and have people stick to the structure.
4) Funnel State Transitions (Somewhat Difficult)
As part of our Finite State Machine implementation, we decided that our code would focus on having transitions follow a basic trunk routine where some actions would be disabled if not needed. This allows us to have one high-level transition process which reduces code errors. On our last year code, we had one Command Group that handled all transitions, and everything is changed in variables to enable and disable certain sections.
5) Establish Auto Driving and Vision Alignment Before Build Season (Somewhat Difficult)
Autonomous driving can be a difficult challenge. There is a reason why points are usually multiplied in autonomous. That being said, your team should not wait until the start of Build Season or even worse once your robot is completely finished to develop Vision and Auto Driving. Currently, I am working on making an autonomous program on a test robot that will allow me to easily port it once the game starts. Since it is almost certain that next year’s game will have a dedicated autonomous period and lining up with vision can be very helpful, you should get started as early as possible to save time down the line.
6) Always Use CAN Motor Controllers (Very Easy)
CAN Motor Controllers will save your life. As mentioned in item 2, we made the mistake of using PWM controllers on our cargo manipulator. When everything is CAN-based (ideally with encoders attached directly to motor controllers), you can have the motor controllers do most of the computation, which makes writing code easier and reduces RoboRIO CPU usage.
Even though CAN motor controllers are more expensive, they are completely worth it. With these motor controllers, you can use more sophisticated programming, such as Motion Magic with encoders connected directly connected to the controller. Some examples of CAN Motor Controllers are:
7) Use a Button Board (Somewhat Easy)
The photo above is of our button board, and it is what allowed all of the Finite State Machines to work. It allows the operator to just press one button, and the robot figures out how to get to that point. The operator can go from any point to any other. The board has a Texas Instruments microcontroller that plugs into the driver station computer. The use of the button board with state machines has significantly reduced the opportunity for error from our drivers.
As you can see on the bottom left corner, there is a switch that goes between auto and manual mode. Our robot has a back-up joystick (a standard hand-held Logitech) that can be used if the button board fails, though that wasn’t a super big issue. I would recommend having a back-up since when it did fail, we weren’t completely out of the match.
One other thing that is worth noting is that when plugged in to some computers, the board must be unplugged before booting the computer (this behavior was shown on an X240, W540, T470, and T580, but we haven’t tested on any other computers). If you are planning on using a button board, you should keep this in mind.
8) Have Checklists and Iterate Them (Somewhat Easy)
Checklists give your team organization and makes sure that you don’t forget anything. They aren’t fun to write or run, but they will make sure that your team doesn’t make any silly mistakes at competition. My team has checklists for:
- Pre-match (short)
- Pre-match (long)
though you can make a checklist for anything. The other important thing is to iterate your checklists. If you ever find something that is missing or needs to be changed, make sure to write it down and then update the checklist as soon as you can. My team used to have a set of Packing and Pre-match (long) checklists for each event but we have since migrated everything to one master so that there is one source of truth for checklists. To make the best use of your checklists, print out a bunch of copies and physically check off each box every time you run it. Not only does this establish a record that you ran the checklist but it also makes it clear if you forgot to run one of the steps.
9) Plan Before You Code (Somewhat Easy)
Planning your code may seem like a waste of time, but it actually plays a critical role in the development process. On my team, we write our code around our planning diagrams, which helps reduce errors and means that the only job of a programmer is to implement the logic that has already been designed. Creativity is helpful when programming, but that creativity should be done during the planning phase rather than the implementation phase. By merely implementing what was designed, there is a clear set of standards for what needs to get done, a clear way for other people to see what the code does, and an easy way to avoid bugs.
Planning before coding was one of the most important steps last year for having reliable software, and getting started is easy. Most of our robot code started out as a flow chart on a whiteboard, so there is no excuse to avoid diagramming.
If you want to take it a step further, you can use test-driven development to make sure that all of your code sections do what they are supposed to before the code ever actually runs. My team, due to a lack of people, hasn’t had the time to get TDD working, but it could be a good option if you have more people on programming.
10) Git is Your Best Friend (Somewhat Easy)
Version Control isn’t fun. Especially once Merge Conflicts get added, sometimes it feels like the benefits don’t outweigh the effort. Despite this, effective version control can save you massive amounts of time, and a well organized repository can make progress easy to follow. Make sure that you have a good understanding of branches, and that all of your programmers use a lot of branches. Branches can help compartmentalize your code development and make it easy to follow and revert problems.
When I joined FRC and when I mentored a VEX team, we did not make good use of version control. FRC had bad conventions with Git and the VEX team used copies of files with different names, which were synced with Dropbox. Both formats did not allow for easy collaboration, and data corruption was a frequent concern with the VEX team. An effective use of Git has been one of the most important ways that both teams managed to stay organized later on.
I learned Git from tutorials by Atlassian (creator of Bitbucket), which I highly recommend if you want to become better.
Not on Programming?
Our team uses GrabCad for CAD version control. If you have multiple people doing CAD, I would highly recommend you check it out.