What do programmers do at the start of the season?

When the season starts, (for most teams), the first weeks are spent without a need for programming. Code only starts to become relevant much later on, once a bot is built (sometimes one day before competition). My question is, what do you do during that time? Do you help CAD? Or do you code before the bot is even built - even in the prototyping stage?

I know there are teams that can make a bot in 4 days, so this is not exactly meant for them…

Do you have the option to leave your previous robot assembled, even just as a drivetrain?


if you have access to a functioning drivetrain start auto paths


If one of the requirements your team sets for the robot is vision detection of the goal and/or the game piece, then programmers should get a test setup with the camera you intend to use (i.e. Limelight) and start developing that functinoality

1 Like

You need to be writing your code effectively as soon as possible. Simultaneously, you don’t want to waste time programming mechanisms that aren’t eventually part of the design. Some things that can be done before the new robot design is even finalized, using 2025 season as an example:

  • update all development software and (preferably) control system components to 2025
  • If your drivetrain design will be functionally the same as 2024, try to develop/update drive code from 2024 to 2025.
  • Begin planning out auto paths, and once your auto planning app is updated with the new field, try to drive those paths with your old robot.
  • If you use vision, look at field CAD and find good mount points for cameras.

Sim everything


Update all your computers, check for new driver’s station software, Rio firmware, hardware clients for your motors…

Prep and test your drive code. Work on vision. Auton pathing.

Lots of stuff to work on before they let you have the actual bot!

1 Like

I work on our scouting website, not robot software, so here’s my best attempt at an answer. From what I can remember we begin writing basic code for the things we expect to be on the robot, obviously this code is going to be untested and likely need some big changes, but it serves as a good basic template to work off of and lets us visualize what the code is going to look like. For example (iirc) we knew we were going to have a shooter for our bot, and we knew that it would basically involve spinning motors up to a high speed then using other motors to push the note into them, so some people on software wrote basic code to do that.

(Imho) Even if none of your initial code makes it onto the robot, this is still a good way of preparing to have the robot and getting people who might be rookies or less experienced team members more comfortable with writing robot code.

Again, take this all with a grain of salt, I may be misremembering or misinformed.

help prototyping. the more hands you have, the more mechanisms you can prototype, the faster the robot gets built.

most of the programming that can be done at the beginning of build season can be done without needing access to a shop, so save that stuff for home

1 Like
  1. Prototyping - understanding the mechanisms you will be writing code for is invaluable. It also gives you an opportunity to influence the design (what sensors do you need to control it properly and where).
  2. Set up computers/environment - this can be done outside of meetings or be updating while prototyping (get it started and go prototype)
  3. Start figuring out the auto paths you will need to develop
  4. Figure out what vision targets are going to be used. Start advocating for camera positions in the robot design; nothing is worse the developing a vision solution and not having a great place to put the camera (e.g. arm blocks it half the time).
  5. If you’re going to do any machine learning, start getting a data set together or find a community data set to contribute to.
  • Update development and robot software as it is released and available
  • Update firmware on controllers and other electronic hardware as updates are available
  • Get your prototype drive base running with current software and firmware - modify code to keep up with current-season API changes, deprecations, or additions
  • Help the build team test benchtop prototypes with Rev Hardware Client or Phoenix Tuner
  • Develop prototype software to enable running of prototypes that have made it to the prototype drive base
  • Start to develop, program, and test auto paths - start to add subsystem actions as prototype mechanisms become available on the prototype base
  • Start to configure your scouting software
  • Consult with the build team on camera positions as well as sensors that seem necessary from a programming perspective - ensure that cameras/sensors are being incorporated as the robot is being designed rather than trying to force-fit them last-minute

My team usually brainstorms what subsystems, commands, controls, etc. we’ll need and do as much on those as we possibly can. If you have a shooter and you know the motor configuration you’re going to use, you have the ability to write most of the code before there is even a full design together.

Another thing we did this past season was to use our most recent bot (off-season 2023) and implement some vision stuff we hadn’t tried before. For example, there was about a week where I was getting “target lock” (driver has translation controls but robot rotates to face apriltag) working before we even had a design for the bot.

At the very beginning of the season, programming members should be involved throughout the entire strategy and design process.
Even during mechanical prototyping, they should be present and either learning if they’re inexperienced or providing input from a software perspective if they are experienced.
Only once you’ve really entered the fabrication phase and the designs are more solidified so to should programming begin working on coding those designs, utilizing modeling and simulation where possible.

Our team builds “tabletop” bots that represent a single subsystem to program. So before our shooter is built we assembled a Radio, Rio, PDP, etc, with two motors to represent the shooter. We could then use that to get basic robot code started

Hit the ground running with software. Update all of your team laptops and robots with the latest software, get any old robots you have usable as development platforms. Auto paths and vision can be done using an old bot.

Figure out optimal auto paths and dial in your processes so that you can get all of this up and running within hours of getting your hands on your comp bot. If you can get your hands on mechanism prototypes too that’s great. Figure out how to control your mechanisms with prototypes so that you’re ready to go once you have the actual product in your hands.

Generally, in my past 2 years, I’ve done the following once I get a chance to:

  • update all software once it comes out
  • start a barebones robot project with maybe a drivetrain setup, or nothing at all
  • read the WPILib New For 2025 docs page, internalize its contents for future reference

Then, I’ll focus more on helping with concepts and prototypes. Ideally, your code should be functional enough to help manually actuate prototypes without fiddling around in RHC/Phoenix Tuner, especially if they’re more complex than one motor. We’ll write some skeleton subsystems containing basic functionality that we can quickly iterate off of that we don’t mind discarding.

We (as a code subteam, not the entire team’s strategic mass) didn’t really think about autos until mid build season, but that’s probably not ideal and more of a side effect of a lack of programmers, and wanting to get solid teleop control first.

We also used some free time to begin work on a scouting app, but ran out of time and our old one was primitive enough that we scouted on google forms this year around, to decent enough success.

On our team we have other programming projects, such as arcinator, our scouting app etc so our programmers usually work on those. We also train our new members.

Write your software requirements, wire up and test various sensors, work with Apriltags, investigate new driver station software toolkits, build new software modules for motors and support prototyping using that software. Build a new driver station control panel.

So much to do early in build season!