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?
Yes.
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
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:
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!
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
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:
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!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.