How many days do your programmers get with a fully built robot before stop build day?

[JonKiddy]

Hello. I'm the lead programming mentor for Team 4930 and I'm looking for some advice. Our team isn't using any formal methodology/model for programming but I'd like to introduce students to Agile/Waterfal/Scrum/etc. However, after thinking about it some more I've realized that none of those may work due to how our team builds the robot.

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is when the majority of the programming happens, but I'd rather be testing our code on a robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

[BigJ]

We design, test, and prototype code with other systems or older robots. Our experiences with a "fully assembled" robot, by which I mean the robot we intended to have on Stop Build Day, range from around 5 days to -5 days (practice bot being fully assembled around a week later) :) I would say the normal time over the past 10 years I've been involved is a 2 day average.

[FrankJ]

:confused: We give the robot to the programmers on day 1. After the code is done and tested, we build the rest of the robot. Even doing this way, the programmers seem to want to change every thing after the robot is built. :yikes: On a more serious note, the robot is never complete until close to stop build. We assign channels & IO as early as possible and stick to them. We have a second roborio with a test bed to test programming concepts.

[SoMe_DuDe904]

Hello. I'm the lead programming mentor for Team 4930 and I'm looking for some advice. Our team isn't using any formal methodology/model for programming but I'd like to introduce students to Agile/Waterfal/Scrum/etc. However, after thinking about it some more I've realized that none of those may work due to how our team builds the robot.

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session done by the programmers; talons aren't on the stated channels, wires aren't connected, etc. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is where we really do the majority of the programming, but I'd rather be testing on our robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

This sounds pretty normal for most teams. I know my team likes to build a shadow bot along side the main bot. This allows them to tweak code and play with it as the students are building the robot. They also then have something to mess with in the dead time between build and competition.

I know this isn't conducive to teams with minimal funding or newer teams that are just trying to put a working robot on the floor. If that is the case, then you really want to aim for a design early in the process that will give your programmers 4 days to a week with a fully functioning robot and multiple weeks with bits and pieces (assigning channels and IO, playing with motors and pneumatics, ect.). Programming is super important to the success of the robot.

[gblake]

...
Most of that day ends up being an electrical/mechanical QA session done by the programmers; talons aren't on the stated channels, wires aren't connected, etc. ...You don't have to wait until the last minute to check these things. As soon as every wire/cable get put into place, check it. If it doesn't match the spec, either tell the assembler to fix it, or decide to change the spec (and your code).

We design, test, and prototype code with other systems or older robots. ...Do this, "ignore" the mechanical parts of the old robot. and just ensure that the logic in your new code can make the right devices twitch in the correct sequences when that new code is given the correct sequences of inputs from a driver station, or from sensors. If the old (or FTC, VEX, Arduino, ...) robot has usable sensors, that is nice. If not, buy spare sensors (or at least spare cables), steal sensors off of this new robot, and/or create dummy sensors (in software) that inject recorded/simulated data into your new code.

Also, put lots of info into simple "configuration" files. Using those, practice moving your codes' core functions/objects from one robot to another by (mostly) only changing the configuration files. The result should evolve into an architecture (one that actually works in robots, in addition to looking pretty on whiteboards) that separates the stuff the robot and drive station mechanical teams might get wrong from the stuff the software team might get wrong; and the fixes for any mechanical mistakes should be (mostly) simple configuration file edits.

Blake

[virtuald]

We utilize the pyfrc simulator extensively, so that we can test the code's logical functionality before the actual robot gets built.

[Cash4587]

I'm not sure how we've been successful dong this, but in the past 4 years, 0 days. We have yet to finish and bag a complete robot. In the past 3 seasons our programmers have been able to squeeze in enough to make us competitive on our practice robot and at competition. I have never been more proud of them this year when they wrote vision code almost entirely at a regional.

[MamaSpoldi]

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session done by the programmers; talons aren't on the stated channels, wires aren't connected, etc. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is where we really do the majority of the programming, but I'd rather be testing on our robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

Our goal is always to have the robot functioning about a week before Bag Day, but... this rarely happens. In the last few years the software group has gotten the robot anywhere from 1 to 4 days before bag day. But often we are able to get in some testing of individual mechanisms as they are completed. This comes from working cooperatively with the electrical and mechanical teams. Or more specifically, from everyone realizing that by working together we get a better result that benefits the whole team.

Realistically, assigning channels to devices is generally the least of your worries. Changing the device channel is a simple task, the testing of more complex algorithms for controlling mechanisms with sensors, etc. require more time with an actual mostly-functioning robot. The first step in tuning our control systems requires system ID data to be gathered. This is a non-optional step in allowing the code to be properly implemented and mechanism to be properly controlled. And this data cannot be gathered without a functional system.

But this does not mean that the programmers just sit around doing nothing until it is built. You don't have to wait until the systems are completed to talk to the designers about how it is expected to work and begin working on the code that will control them. Certainly many constants, etc will need to be defined and/or tweaked after the robot is ready but there is a large amount of coding that can be performed in the meantime. For example, the classes for each mechanism are defined and implemented with the framework for the control system expected including options for calculating the components that will be used as part of the control system (e.g. previous position values, velocities, and accelerations). Yes, it is often true that while we are writing code for the expected mechanism the entire idea is scrapped and re-designed which often requires the software to be mostly or completely re-designed as well but the original effort is still a helpful learning experience especially for novice programmers.

[GreyingJay]

How many days?? More like how many minutes :p

We were just about able to finish the robot before bag and tag, so the software team had very little time with the finished robot before it went into the bag (literally minutes). However, the practice robot was finished a couple of days after that and the software teams had several days, shared with the drive team, to practice and optimize code. And throughout the build season, the teams had many weeks of access to a driving Kit of Parts chassis (but only a stand-in manipulator bolted on).

We made things a bit easier by dividing the software into functional chunks.
- basic driver and manipulator control, using the Java Command Based Robot - team of 3 students
- autonomous commands, sensor fusion and calibration (gyro, encoder PID etc) - team of 3 students
- pan/tilt servo control of on-board camera for vision tracking - one student
- Raspberry Pi running our custom TrackerBox software for target tracking - team of 4-5 students

This division of labour allowed groups to work without everyone needing to use the drive base at the same time. It wasn't perfect, of course, and we will adjust for next year. There was a mad dash at the last minute to do "systems integration" and combine all these products into one, final piece of robot code. This is where we way underestimated the time needed. We were actually still scrambling to integrate our software well into qualifications during our first regional at GTR Central. All our practices, and the start of quals, we were actually still running our hastily written "test" code which had none of the autonomous or vision code. Between matches we would deploy our integrated codebase and continue debugging it.

By Q22 we finally had it functioning, and the students made the (wise) decision to lock it down and use what we had for the rest of the weekend rather than risk additional "live" system testing and tweaking. Between GTR Central and North Bay we spent many hours fine tuning the robot code further, including adding and tweaking all our autonomous routines.

[Alan Anderson]

What is this "fully built robot before stop build" of which you speak? :confused:

TechnoKats programmers get access to the robot regularly during build. Closed-loop control system tuning is often an important part of the robot's ability to perform. In some years, we've actually gone so far as to reserve an entire day each week where software has priority access, and the only "build" work permitted on the robot is to fix hardware problems discovered (or occasionally created) by the software group. The mechanical group gets to keep busy making replacement or upgrade parts, or working on the practice robot.

[bigbeezy]

Do teams have any dedicated "programming only" days? For instance, you say that no matter what the Wednesday before Bag programming gets the robot for the night. No matter the state of the robot, that build day is for programming only.

Kids, well people really, are used to cramming for a deadline. So making an artificial one about a week out tells your mechanical kids that things need to be assembled and electrical that things need to be wired. Not 100% done, not pretty, just functional so that programming can get some of their work moving forward. I haven't done this specifically, but we do use our Week 0 event as this artificial deadline. Basically, we are inviting a ton of people and we need something to show and its the only time when we have our full field assembled. Does it put more pressure on us earlier? Yes, but in doing so we give ourselves time to figure out what things work and where we need to really focus for the final 3 days.

2015 we were really good about getting programming on the robot early and often. Had things pretty much fully operating during week 5. 2016 not so much...

[EmileH]

Here's what I've always tried to do with my team to save programming time while not restricting the mechanical team.

Say it's 2016 and we have two manipulators that require complex programming: an intake with a motor with PID to angle the intake and a catapult shooter powered by surgical tubing, winched down by another motor using PID.

This method does require a few extra mechanical kids in your shop to build these subsystems.

(this would be around week 2-3, once the design of the robot is just about complete and machining has begun)

Prototype both of those subsystems fairly accurately with wood (doesn't have to be exactly like your robot but similar enough that you can test as you would on the real robot), and while your mechanical team is assembling the real robot, use a spare RoboRIO or another set of electronics to get the feel of how those complex subsystems behave and then start writing some software. Doing this will make programming the real thing much easier as you technically can just copy and paste the software and make minor tweaks.

The reason we never prototype drivebases is because they're always the same...tank drives are quite simple to program, and you can use the same code every time you need to use a tank drive. The only instance in which a drivebase would be prototyped would be if it's a holonomic or a complex system (swerve, kiwi, mecanum, etc.)

[GeeTwo]

If our programmers needed a fully built robot before bag day to get any work done, we'd just sit there on the carpet.

They usually have a couple of days with a fully built (though subject to change) drive platform around week 4, but now that we're building two robots, we're tweaking our manipulators right up to competition. In 2015, we were "fully built" before bagging. In 2016, the key pneumatic cylinders for our launcher had not yet been received at bagging - they absolutely were installed on the competition robot on Thursday.

[Chris Hibner]

Hello. I'm the lead programming mentor for Team 4930 and I'm looking for some advice. Our team isn't using any formal methodology/model for programming but I'd like to introduce students to Agile/Waterfal/Scrum/etc. However, after thinking about it some more I've realized that none of those may work due to how our team builds the robot.

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is when the majority of the programming happens, but I'd rather be testing our code on a robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

You can unit test all of your software on a PC prior to getting the robot if you architect your software to allow it. This is a great introduction to how software is developed in the real world (at least for embedded systems, which your robot is).

The architecture to do this is quite simple: do NOT allow any calls to the IO from within your software unit. The inputs should stand alone, and the outputs should stand alone, and then they are passed in and out of your control functions/classes. All things that you're not sure of should be made constants that can be tuned once you get your robot. Then you only need to write a quick wrapper to your function to fully exercise the function in Visual C++ Express or a Java environment on a PC. The only thing you need to do once you get your robot is test your IO, tune your constants, and fix the issues in which your control strategy assumptions don't match reality.

We've been doing software that way for years, and it works great. It's also a great introduction for the students to embedded programming, since just like the robot we never get the real hardware until it's way too late.



Do teams have any dedicated "programming only" days? For instance, you say that no matter what the Wednesday before Bag programming gets the robot for the night. No matter the state of the robot, that build day is for programming only.

We do. The Sunday before ship is "Autonomous Day". We use the entire day to tune the autonomous control loops and tweak in the autonomous routines. Unfortunately, quite often not all of the robot features we need are done on that day, but we can at least get all of the sensors and control loops dialed in.

[gerthworm]

Our team structure is the same. It's varied year to year, but what I've found from my 6 total years of doing robotics for various organizations: The robot is never truly finished. No matter how good or professional your other teams are, there is always something to be improved. Presuming people are enthusiastic about perfection, getting the robot for some quality software time is pretty hard.

We found two modes of operation were really useful this year:
1) mini-sprints: In parallel, the robot is constructed, and software is written. Major milestones (drivetrain written, manipulator added, etc.) are marked in software version control. As soon as the robot is mostly functional, there is a joint effort where software loads on a new program, does some tests, makes some observations. As soon as software knows what to do, they get off the robot and give mechanical & electrical a time estimate till the next time they need the robot (5 minutes? 15? an hour?). Mechanical/electrical then do whatever tasks they can in that timeframe, and get back out of the way for software to do their next iteration. Working like this allowed us to make lots of small mechanical tweaks that made a big difference at the end of the day.

2) Shift-based work: For longer software projects, such as tuning shooter/intake sequencing or autonomous routines, Software just needs the robot for a long stretch of time with little interference. These things were accomplished "after-hours" - effectively, non-software teams went home to get some sleep, and software came in later to get done what needed to happen. Most mentors stuck around for the whole time, but this allowed the students not to be super burdened. I'm hoping to improve how we organize this this year with better up-to-the-minute communication of schedule, as a mechanical failure has great potential to hose up pre-set meeting plans.

[Team34Guy]

That's a good one......programmers getting a fully built robot. lolz

Seriously, much like some of the other teams have noted, we usually have code and test it on older bots(or the secondary bot if it's ready). This set up has worked for us. Our build and programming teams work real well with each other and we often times stop build and load new code to check out things as we go.

[maxnz]

I can't speak for other years, but I think this year was the best year for the programming team (for multiple reasons).

We got a spare control system through FIRST Choice and Andymark, and let our programming team use those on a dummy board. They actually used the board from last year's robot to program it in Java (while we used the new one to program in LabView, the language we have used for multiple years). Once the robot was ready for the electrical components, we disassembled the Java board and decided to use Java for the robot. The LabView board was repurposed for Java, and the team kept working. Once the robot was completely finished (last weekend of build), they just needed to check some values for the potentiometer that was used for our arm. We didn't have anything too complex (like vision tracking), only the potentiometer. And they only needed to read the values on the smart dashboard while we were practicing driving to get their readings.

[sraque]

We typically have 3-5 days before bag day where the robot is essentially complete. We have an open house the Sunday before bag day for sponsors, parents, and community so it needs to be working. Those days are used for overall system testing, not just software. Some things we do starting from the first week of build to be prepared are:

1. We develop and configuration manage an Interface Control Document (ICD) covering all I/O ports and operator controls during the design.
2. We develop and configuration manage a set of use cases with the drive team and system designers so everyone is clear on how the robot is intended to function and what the operator controls do.
3. We have a spare control system that is used as a test rig. It is equipped with sensors and motor controllers to aid in verifying the software. Some sensors are replaced by potentiometers and limit switches so we can simulate certain parts of the behavior. Sometimes we have spare motors on there too if that helps debug certain behaviors. This test rig is also mountable on several old drive systems (common bolt pattern with wing nuts) so we can do some drive testing
4. Our first code release is "test code" that is used to test each individual actuator as the robot is being built. The controls for test code are usually different than the operational controls because they are focused on moving only one actuator at a time and under risky conditions (like checking motor polarity, seeing there is no mechanical binding, etc.). This verifies ICD compliance and helps debug mechanical issues in a controlled fashion.
5. We have a practice robot we call "Beta".

We still have huge challenges getting time for closed-loop control tuning. The practice robot never behaves quite the same way.

[Ky0t3]

On our team the programmer actually is coding throughout and will upload periodically to the bot to test it works correctly, like if we just finished a mechanism that we are gonna use. We will all stop building while he's uploading and then watch to see if it works and critique the way it's controlled or the way it functions. By the time we get to stop build day out coding will have been done for a while, even if the bot needs a few more things.

Sent from my LG-H900 using Tapatalk

[DonRotolo]

It depends. From -10 to +15. We aim towards the latter, which was the case in 2016. ("Fully-built" is relative. Fully-Functional might be more accurate)

It is always not enough, and we strive always for more

[Wasabi Fan]

I know this is an old(ish) thread, but surprisingly I don't see any mentions of what my team does, which I think it pretty valuable: we write extensive unit tests. All the code from the motor controllers/DIOs upward can run on a development PC, so we can be confident that our code works even if we can't test it. We write tests to test math helpers, individual commands, command chaining, and overall flow, so all we need to do when we get our hands on the robot is make sure that none of the I/Os were swapped or disconnected. Obviously it's best when we get a good chunk of time for real testing and tuning of PID and such, but we make do when we are low on time with the practice bot.

[xjschwen]

We get only a few minutes each build day. This will be normally only 10 minutes or so with maybe 1-2 downloads. As the build team is building a component we are programming it so that we can test both the software and mechanical as early as possible.

It is basically an Agile way of working

We setup a board bot that has the right kind of motor controls and IO.

We set it up on a rolling cart and are able to push it/spin it for work with gyro control.

For the early season work this is actually better than having a real bot because it does not drive away and we do not bend/burn anything.:yikes:

As we get closer to the end of build season we took one day about 5 hours to fully tune speeds, and sensors etc with just the programming team. 2016 was the first year this was done.


This method of working also ensures that we have a minimally complete bot early in the season. Since the Mechanical and the Software have to function as a system, having one "Complete" without the other is a waste of time.

As for the hours on a complete robot... that would be 0 hours. We were still bolting things to the bot at competition and our climbing winch was not functionally complete enough to test until the last few matches at States.

Jeff

[Chris Hibner]

I know this is an old(ish) thread, but surprisingly I don't see any mentions of what my team does,...

Then you didn't read very carefully: https://www.chiefdelphi.com/forums/showpost.php?p=1592779&postcount=14

(Sorry - I couldn't help but be a smart @$!)

But you are right - PC testing is the way to go.

[Brian Michell]

Since the beginning of our team, we never got a day with a fully built bot before bag 'n tag. We did however, build a second bot that was not identical, but close enough to make sure we had a decent, reliable autonomous and robust control system.

[adciv]

We've gotten better about getting the robot to the programmers before bag n tag. But we're still doing the 2nd bot for auto and control. A chunk of what we do would not be possible without the 2nd robot to debug and develop code on.

[BDRessler]

My Team Allocates two weeks, but I honestly was testing my code for the first time at our first regional this year. This year is a bad example though because we had a lot of issues with ordering parts and sending them off to be machined. In a normal year I should get approximately four days.

[Max Boord]

Due to our odd meting schedule of 1 day a week, 1065 does things a little unconventionally. We set out our goal for the day I.E build the intake or build the drive base and when that is finished (generally around 4pm) the robot is handed over to the programmers to test the new code they developed for the added component. Then whenever they are satisfied or around 7pm ish we pack it up and head home for the week.

[Jonny_Jee]

during my time on the team, we gave our programmers the last five days of week five to program the robot + auto. more often then not they would complete their goals early which gave us plenty of time for driver practice, durability testing, efficiency revisions, bumpers, etc.

[Cothron Theiss]

We didn't exactly set out at the beginning of the season to do this, but we actually let the driver/programmer drive almost every build session we had this season (once we had an operational chassis). Each night, one mentor (a few would rotate out so as to lessen mentor burnout), me, the driver, and one of three other build members would stay from 30 minutes to an hour after everyone else left to test code and get in driver practice. If a sub-assembly wasn't operational, it was either removed temporarily or strapped down so we could drive. All season long, our programming mentor worked on vision code for a low-goal autonomous, but it never got close enough to completion to try out on the robot. Other than that, all of our code was pretty battle tested by the time we bagged.

[Mitchell C]

Our build team gives the programmers little to no time with the robot. We usually get around 20 mins of the Thursday/Friday of comp depending on how the robot is coming along.

[Hitchhiker 42]

This year, our programmers had much more time than previous years. The programmers received the robot Thur/Fri before bag & tag. Then, we attended Suffield Shakedown on Sat, and Mon/Tue were a little bit of a scurry to quickly switch a component from a motor (window motors are bad for high loads we found) to pneumatics. Overall, I was mostly satisfied with the time we got.

[Cothron Theiss]

(window motors are bad for high loads we found)

After putting one or more window motors on all four robots I've helped my team build, I can assert that window motors are bad for just about everything.

[GeeTwo]

After putting one or more window motors on all four robots I've helped my team build, I can assert that window motors are bad for just about everything.

I have 4 18-year old window motors and 4 11 year old window motors that have done a great job of occasionally raising and lowering car windows and are still going strong. On FRC robots, we have mixed experience: When we have just tossed them at a problem, we've had the worm gearbox fly apart faster than the arm it was driving (trying to lower the bridge in Rebound Rumble). When we've done the math and used them in situations within their torque and speed capabilities (e.g. raising and lowering our rung deflector for Ultimate Ascent), they have performed well. If it's too big a job for a servo, and a BAG motor would require a third VP stage or two high-reduction VP stages, consider the humble worm-geared window motor in your kit of parts.

[tjwolter]

Rookie Team last year. I got the Build team to hand over the competition 'bot with one week to spare. Of course when you have that much time to tweak and troubleshoot you do break some things....but that's the time to break 'em. We were out of the chute ready at competition. Our software kids never did quite debug a few minor issues but hey, we were rookies..

[CalTran]

Definitely far less than they deserve. We aim for a week, but usually they get 24-48 hours.

[adciv]

Of course when you have that much time to tweak and troubleshoot you do break some things....but that's the time to break 'em.
We routinely discover what needs to be made "more robust" during programming. The programmers argument is if they're breaking something, the drive team will break it during a match. Finding failure modes and correcting them before competition will improve your rankings more than anything else.

[Hitchhiker 42]

A lot of teams do a second practice robot. Our team hasn't done one yet, but we want to this year. Is there any advice you'd give to a lower-budget team on doing this?

[Michael Corsetto]

A lot of teams do a second practice robot. Our team hasn't done one yet, but we want to this year. Is there any advice you'd give to a lower-budget team on doing this?

Use the kitbot and buy a second kitbot. Now you have a practice robot.

Build your scoring mechanisms you want to tune under the withholding limit. Then move that from comp bot kitbot to practice bot kitbot between events.

If you want to do practice robot on a budget, this is a great way to do it.

To OP:

Our robot programmers generally get the first robot at day 30 of Build Season. They almost always have one practice robot available during the Competition Season. They get two full robots for at least a few weeks during competition season. Often, one of the two practice robots is stolen by mechanical to fix items or test modifications.

-Mike

[adciv]

A lot of teams do a second practice robot. Our team hasn't done one yet, but we want to this year. Is there any advice you'd give to a lower-budget team on doing this?

Here's how we do it now:
Build proof of concept drive train. The programmers get this for testing and driving around and for sensor integration. This was very useful this year as we found out we needed to redesign for the moat. Eventually this gets reworked into the practice robot. Quality is usually less than we'd like but we learn how to build the robot. Once that's largely settled, the competition robot is built. The competition robot gets more care and is generally higher quality as we've learned how to do it from the practice robot. Programming may only get a few days on the competition robot but it's largely finding the small differences between the two at this point and taking that into account in code.

The key thing is getting to the point you can build both during build season. If you can't, build the competition robot first and then work on reducing your time over the years to get the 2nd robot up and running. Also, you need to try to build them as identical as possible. If the competition robot has a mistake in it, you might need that mistake on the practice robot so include it.

[ASD20]

A lot of teams do a second practice robot. Our team hasn't done one yet, but we want to this year. Is there any advice you'd give to a lower-budget team on doing this?

There are two types of practice bots that teams build: prototype bots and replica competition bots. Prototype bots are built first and then the lessons learned from them go into building the competition bot. These are not exactly the same as the competition bot, since revisions are typically made after it is built. Replica bots are built at the exact same time as the the competition bot and are usually identical save for a paint job or other cosmetic things.

It is important to know which type of practice bot you want to build. I think most teams go more of the prototype bot route, though some will upgrade it after bag to make it as close as possible. Warning: if you go this route and have the intention of using it after bag to program, YOU WILL NOT be able to transfer code and have stuff just work. (side story: This year we did this and our first competition match of the season we drove backwards in auto. Turns out our practice bot had the intake on the other side and that is what the programmers programmed our auto to.) I have plenty of other stories where that came from and this was our first year building a practice bot.

Regardless of what type of bot you build, I would say to expect to spend equal or greater than what you spend on your competition bot. Not only do you need to buy another control system, you will find yourself having to buy more of things that you had one bot's worth of just lying around in the shop. Ultimately if you are trying to build a second bot with near-identical functionality, you will need to get near-identical parts. There are areas that you can save a little money, like using older motor controllers, but I would say the best case scenario is you plan to spend 2x and you end up slightly under budget.