As we finish the year and get ready for 2025 Reefscape , I’m looking for feedback on how you manage the code for your older robots. As a 2024 rookie team, this is the first time we will be dealing with this.
I see that most teams have a separate code repository for each year. I originally thought that we’d keep a repository and associated Git history, and just use branches and tags to manage the transition, but have since “seen the light”, and plan to use a separate repository – though perhaps maintaining the Git history for the code that “carries over” from one year to the next.
However, we don’t just want our 2024 robot (“Latch”) to be a historical artifact – we want to keep using it at outreach events and other demonstration opportunities, as an opponent when we practice with our 2025 robot, as a driver training tool, etc. What do you do to keep a robot like that operational for one, two, three (more?) years? Do you leave the code 100% as-is, and would that cause any compatibility issues? Do you continue to update the code to the current 2025 (and beyond) WPILib and other vendor libraries, paying a “maintenance cost” to keep the robot operational? And if so, for the common code that they share, is there anything you do to avoid making the same updates to two or three (or more?) robots?
Thanks in advance for your suggestions and advice.
We end up using our old robots to teach new members how to write the software for them, which includes updating them every year. This means we end up with one repo per year per robot which is kinda a lot, but it’s manageable and you could archive them too.
We keep each robot’s code in a separate repository because it’s way better imo for organization.
As for code that carries over, you could write one general “commons” library that contains all shared code between robots and use it as a dependency in all of your projects.
A lot of our old robots get disassembled for parts and space so we wouldn’t ever need to maintain old code. However, if you do update code it usually doesn’t take too much effort. Just do it each time a new wpilib version is out and make sure to check the release notes!
Separated Repository so that you can keep the entire stack separated and consistent. Any common code you want to reuse, if enough, should be made into library and those will needed to be tested separately with each year’s “stack”.
Stack consists of:
Firmware for all HW devices
WPILIB specific year (that works with the above firmware) [min and max sub-versions]
Vendor-specific dependencies (if not part of WPILIB) - this is probably by far the biggest challenges to keep straight. [these need to match their corresponding Firmware above]
Any 3rd party specific year/version libraries (most are probably tied to a specific WPILIB version).
I always tell our programmers - mastering a language is only 10-15% of the work another 15% or so on mastering/learning your core libraries. all the rest are learning how to master debugging and managing the environment and the stack.
We maintain a separate repository for every year’s robot code. We’ll usually make some changes to old code mainly to either change driving speed or controls. If I’m updating old code or reimaging, that’s usually when I port it to 2025 in a separate branch, since I don’t like bothering much with installing old game tools or wpilib.
We currently have 3 robots still intact: our 2014 robot (code entirely rewritten in 2023 because it’s a very simple bot in its current state and was upgraded to a Roborio), 2022, and 2024.
We don’t maintain a common code library, usually we rewrite from scratch but occasionally have copied individual files from year to year (led code, swerve). I’ve only ever bothered maintaining git history between a pre-2023 offseason swerve project and our 2023 robot code.
The beta version of the next year’s WPILIB software and the various vendordeps come out a couple months before the end of the year, so you can use the last few months of the year to upgrade last year’s robot to the new version. You will still need to upgrade one last time after kickoff, but that is usually pretty easy. Parts of this updated code can then become the starting point for next year’s robot, if you like. If you plan to use any code from the previous year, don’t forget about rule R303, which states you must publicly post your code prior to the kickoff.
Lots of folks here recommending to build an in-house library, I’d like to push against that: building a library will just add unnecessary layers of complexity to your robot code and make it harder to maintain. One of the great things about FRC software compared to industry software engineering is that you can start over from scratch every year. You have no obligation to support legacy code and legacy software for customers, so don’t invent the obligation to do that by building a library to maintain year-to-year.
These days, the FRC software ecosystem is developed enough that it’s frankly easier to just copy-paste code year-to-year or to just rewrite stuff rather than developing your own libraries.
Regarding OP’s original question, I’d recommend updating all of your hardware to use the latest versions of WPILib, vendordeps, etc. Supporting multiple WPILib versions is overhead that’s not worth worrying about, and it locks you out of being able to use any old robot as a development platform for things like autos or vision.
Migrating old robot code to new WPILib versions shouldn’t be too complex - barring major changes like the Phoenix 5 → 6 migration. It’s worth paying the maintenance cost there in order to have multiple robots running the latest software versions. You can strip parts of your codebase out when migrating - a demo/development bot may not need autos or functional vision code. Sure, you may need to make the same changes across multiple robots, but those changes should be simple enough that even if it’s a bit of work, it should be fairly easy work.
We maintain a separate repo per robot. As long as the robot is assembled and working, we continuously update the code with vendordeps and WPILib updates so we can keep using it for demos and practice. Once the robot is disassembled, we archive the repo in GitHub. See Team Rosbots · GitHub.
Separate repo for sure. But when 2025 season starts have programmers update everything on last years robot to this years software and firmware. This process is usually harder than you might expect, but certainly way easier on a known working system. This puts programmers in a good position to tackle the new 2025 robot. NEXT year will be the year you have to make a harder decision about what to do with that 2024 robot. The goal should be continual improvement and hopefully by 2026 that 2024 robot won’t seem as awesome and you’ll be happy to rob parts from it.
, I’m looking for feedback on how you manage the code for your older robots. As a 2024 rookie team, this is the first time we will be dealing with this.