I’ve wondered about the publishing code preseason thing and whether teams reuse code or start from scratch each year. Obviously some things will need to be changed but I’m wondering if it will help to have sections already ready, like drivetrain and vision.
1 Like
Our goal year-to-year is to reuse what works, improve what bothered us, and only make from scratch what we need to. We always have a number of simpler tasks to get less experienced students up-to-speed, but we strive to continuously improve as a team rather than reinventing the wheel every year. In preseason training, we do projects that give everyone an opportunity to build core systems from scratch (drive train, driving controls, etc), but then we use this as an introduction to the larger “production” codebase.
To facilitate this, we clean up, generalize, and migrate code from our main source files to a perennial library we can import into the following year’s codebase.
As an example, we developed a basic swerve chassis subsystem over summer of 2021 from scratch. Then in 2022 season, we imported this subsystem into our 2022 project and added additional functionality for a new IMU, autonomous path following, etc. Going into the 2023 season (code not yet released), we stripped out some 2022-specific code that sneaked it’s way into the subsystem and then imported it into the 2023 project where we’ve added additional refinements and spline path following.
Other components are even more generic (like asymmetric debouncers, angle math functions, etc) and just go straight into our libraries where we can write tests and make the code immediately available to developers. This helps in a similar way to how WPILib allows us to get moving faster by allowing us to focus on the hard problems specific to our robot and less on re-developing code that’s been done many times before.
4 Likes
Around 2016, 449 got tired of rewriting our code every year and resolved to put repeated abstractions in a persistent library. The library has an uninterrupted history since, though i don’t think much/any of the original code remains at this point (especially after the team moved to Kotlin).
It’s been a huge boon to our team. Our students get a lot out of learning how to manage a living, multi-year software project, and our team wastes less time reinventing things.
While we don’t have any libraries, a direction I’d like us to go especially with our custom designed swerves. We have reused our drive code the last few years with minor tweaks. It was as simple as dropping the subsystems and command into the new project and had our working base.
My only advice is to make sure you are keeping it all out in a public form per this rule. Github is a great source that many teams use.
R303 *Create new designs and software, unless they’re public. ROBOT software and designs created before Kickoff are only permitted if the source files (complete information sufficient to produce the design) are available publicly prior to Kickoff.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.