My knowledge of FRC Robotics Coding is outdated and I wanted some help to catch up.
I was a coder when I was a student in FRC and have now rejoined my old team as a mentor. The team got shut down for about two years after covid so we are still rebuilding. I am the only mentor that really understands coding enough to teach students. I don’t code professionally but understand at least the basics. We can code a functioning robot but understand that we need to improve to be competitive.
Command Based: I saw command based and tried to make it work but for whatever reason I could never make a motor move. What are the advantages of Command Based over Timed as it sounds like Command is preferred?
PID: I feel like everyone uses PID for everything even when it isn’t really needed. In the past we and teams I knew used it almost exclusively on drive train motors. Is this change mainly due to improved hardware and software allowing for better control of all motors?
Vision: as a student I didn’t touch vision other than a bit of debug support. Are there any good sources for a beginner guide to vision as the only thing I can find is how to jump into the deep end using a co-processor and a bunch of 3rd party software.
3rd party software: we are using github but are there other 3rd party software that have become so obvious to use that no one really mentions them?
Having never used Timed Robot I can’t really tell you the differences off the top of my head. But the big thing to Command Based paradigm is having the command scheduler running for each of your subsystems, and being able to run commands in sequence or in parallel with each other.
Great resources lie here :
To me it’s just more accessible than ever, and having methods of offloading those PID controllers to the motor controllers and their built in APIs has made it more approachable than ever.
Having moved away from Retroreflective targets for Apriltags, its now more accessible to determine a robot’s pose on the field from a relative and known position. Limelight 3 and PhotonVision are your go to resources for this for COTS / Open source options.
Git, is still the big go too as mentioned… there’s some neat tools available this year in WPILib like AdvantageScope for logging and replay that I personally think is going to be the next big thing.
Hope that helps, and welcome back!
P.S - Definitely check out Open Alliance posts from the past few years. Lots of awesome resources available from a lot of great teams.
No idea what I was doing wrong with Command-Based but I suppose thats just coding
More PID controls makes a lot of sense when you can offload everything.
PhotonVision seems promising as we have a PI3 we can load it onto. I’m not confident in being able to teach all that to the coders mid season though. If you have something even more basic that would be great, but from what I am seeing there really isn’t a gradual learning curve into vision.
I think you are missing a big one, which is autonomous pathing (bleeding into teleOp pathing). PathPlanner is the most direct way to generate and organize auto paths. This year you have Choreo to generate optimized paths, with the option to build full autos through the GUI of PathPlanner. Both have reasonably good docs.
You can make reasonable strides for autonomous with just a gyro and encoders. With brushless motors, the encoders are much easier to access than years ago. Visual odometry with AprilTags with Photonvision or Limelight can improve your pose estimate but isn’t needed strictly to do autonomous. However, finding your shooter speeds and angle might benefit from some visual rangefinding and alignment using the Apriltags if shooting away from the subwoofer.
PID is not the only option, there are more tools for model-based controls. Also, having simpler controls for less precise mechanisms is fine, like for intakes. Tools like sysid are available to determine some tuning parameters like feedforward values which can be combined for PIDF schemes. This year the code generation for sysid has changed to run within the teams code rather than standalone, but the analysis tool still is part of the WPILib installation.
Ahh yes, “what is command based”. That’s the story of my life right there.
My team decided to switch to command-based from iterative this year, and I can confidently say it has made the management of the code so much easier. I’m not trying to shill or anything here, but our ChargedUp repository has an iterative (main) branch and a command-based branch (which was never run at a competition, but has been run on the robot and has proven to work) and the amount of stress that went away when switching to command based is just unthinkable.
Quick disclaimer though, if you decide to look into that code, there are still some things that are done in that code using iterative logic that don’t need to be that way, but this was my transition away from that style of programming so I took a shortcut or two using what I already knew worked.
Command-based proved its power to me the most in autonomous, as having to iterative-ly manage all of our robot’s states to check if we have or have not done something yet was an absolute MESS to code, and especially to debug. From what I am hearing and testing so far with command-based, all of the worries about when you have done a task vs when you want to do a task pretty much float away. The best way command-based has been explained to me is “making state machines except there aren’t really any states,”-- and while that isn’t exactly what command-based is, the switch from iterative to command-based was a really good feeling. I can now get freshmen to feel comfortable making a subsystem (or even a basic command) since everything is so abstracted all they need to focus on is creating the motor object and creating skeleton methods to make that motor move. The commands handle the logic behind it, and it’s overall made our code look and feel much cleaner. It goes hand in hand with good source control, funnily enough. With iterative, however, I found myself trying to teach them the basics of Java more than focusing on the FRC part of coding, as they are very distinct. Command-based lets me focus more on having them think logically, as the code translated a bit easier from a newcomer’s brain into text.
I recommend having students transfer the repository of this year’s code (during the offseason) into command-based so that they can get a realistic feeling of how different it is from what they are used to and how each little detail finds its way to transfer over (or dwindle away) from iterative. For reference, it took me three days of dedicated work to get it done for my 2023 robot. At this point in the season, I would stick to the programming style you started with since going into command-based will be a lot at first.
I hoped this helped, and didn’t scare you off too much since it is a big text wall.
TLDR: command based gud
