Last year, our team was ambitious, and we wanted to create a “perfect robot.” However, we were limited by the time of the competition as we attended BCVI in week 1 and had multiple ideas, so we could never finalize our bot. Halfway through a design, a new and “better” design would be suggested, and we had to start over with the new design. Our budget and time were limited, so we could not prototype all our designs. The mechanical parts of the bot will always take longer to do which leaves little time to test and adjust auto. It was more or less a chaotic build season. As the new season is coming, I wanted to learn more about improving our build season to make it less chaotic and create a functioning bot on time.
6 Likes
Designing a “perfect robot” should be used as a theoretical goal and strategy purposes not a model of what to design the robot to do.
Set a hard deadline for robot architecture. For my team 10 days has worked for us for about two years. I would figure out quickly if something a “perfect robot” would do is going to create unnecessary complexity with your team. Examples are trapping(2024) and intaking tipped cones(2023), and mid to traversal climb(2022).
1 Like
How do you enforce deadlines?
I agree with this ! On the idea of deadlines, they have also worked well for us for the past couple years. We have a set of goals to get done per week, and divide our team in subgroups according to what needs to be accomplished. For example, we usually get ideas down and start designing by the end of week 1, then finalize prototypes and start to build towards the end of week 2.
Especially if your time is limited, I would at least take the first few days after kickoff just dedicated to organizing what parts of the game is most important to your team to achieve. Once those ideas are finalized, then start designing around those solidified ideas. Sticking to a consistent schedule is super helpful and diminishes (if not eliminates) the surprise element of running out of time.
We start with this a few days before kickoff. Fill it in and try to stick to it. Note the milestones. I can’t find a pic of a finished calendar for us, else wise I would share it. Leave plenty of time for commissioning! Your team’s calendar will be very different from every other teams calendar.
4 Likes
Two ways to approach this part of the problem.
First, there is nothing inherently wrong with scrapping a current design to go in a different direction, but not on a limited time frame like FRC has. If you are going to make large changes like that, they need to happen as early as possible to avoid redundant work being done on stuff that won’t be used. Put more time in the brainstorming and ideas gathering stage early before starting on anything else and work on mechanical fab/assembly of the stuff you know is least likely to be changed later. If you can, give your mechanisms ‘pivot points’ that you can go back to and adjust or change. Not pivot as in an arm, but pivot as in go in a new direction. Make generic brackets with multiple mounting positions, etc.
In the end you need to ensure you have some sort of functioning robot that can score points even if plans A-Z didn’t work. Follow a basic hierarchy of needs for the robot. Focus on the core (drivetrain and electrical components) first because those are usually stable. Then you can add additional mechanisms as they get solidified without feeling like you are taking steps backwards on the overall robot progress.
Second, so you decide instead to only do one new prototype mid season, how do you pick the right one for your situation? Pugh Matrix!
https://www.frczero.org/engineering_design/design_process/creating_a_prototype/#pugh-matrix
By listing out the prototype ideas (ideally earlier the better as mentioned above) you will get them all on paper and hopefully get them all now instead of another pop up later. You can think through the steps involved with each and grade them. Based on your final scores and gut feelings you’ll know you’re making the best decision you can with the resources and time you have or you can see that none of the options are reasonable to do with what resources you have and keep what you already did.
1 Like
Pick a date that your programming team needs the robot to get the software fully working and debugged. Prior to your first event. Base this on previous experience, if they claim they can do it faster do not believe them, caffeine does not slow tine the way they think does, so use historical evidence. Once this date is established have the design and manufacturing team aim to finish the robot a week before that date. If you do that you should be able make it work.
The old engineering adage I like to use is “Better is the enemy of good enough”
This means if left to their own devices a designer will never finish a job because they always have a better solution hypothetically available. The 1% improvement is not going to do anything for you unless you are winning a division or gunning for Einstein.
If you want to make those improvements, finish the design and get something working then while your team programs and practices with the 1st iteration make the improvement aa a bolt on so you can upgrade between events or if it’s ready in time.
3 Likes
@Bjorn did a great job breaking down 4481’s process in our 2025 build thread, you can also look back at how our process ran in our 2024 build thread.
2 Likes
This seems backwards to me.
We prototype early to winnow our design ideas down to the most promising one(s) in order to SAVE time and money. The further you are along in the process, the more expensive (in money and time) changes get.
Are you prototypes “too nice”? Our opinion is they should have enough fidelity to prove/disprove the idea and no more. An Example:
2 Likes
This is true on an apples-to-apples basis. But there are also oranges in the basket.
A team with a lot of students, a lot of rapid prototyping equipment, and a willingness/ability to burn prototyping material can prototype and test more things than a team who can’t afford that.
It’s not that the second team is doing the same number of explorations just more expensively; they’re doing fewer explorations (at least those with any physical manifestations).
4 Likes
The biggest thing that I’ve learned was that you need to know when to give up on a design. You need to have a point where you stop iterating on a design and figure out that it won’t work how you want it to. There’s always another way to attack the problem, so if you have to fail in creating a design up to your standards, fail fast.
3 Likes
Look again: Six students, recycled wood from previous year’s bumpers and field elements, polycarb scraps, old robot parts from the bin, and old drills. Effectively zero dollars spent. No laser cut parts, no army of students, no special prototyping materials.
If your students can drill holes, cut wood anywhere approaching a line, and put in screws, this is within reach.
2 Likes
It can be hard to set aside that better design. One approach if your team is large enough is to continue to run with the existing design, focusing on getting a robot built and running to allow testing and driver practice. While this is happening, allow a subteam to evaluate the better design. If the subteam creates something that is demonstrably better than the existing design, see if you can retrofit that into the existing robot or a practice/beta chassis if you have one. This doesn’t have to be done by the first competition. In these days of no “bag” restrictions on robot build, I’ve seen teams show up to a week 5 competition with a completely different robot than they had in week 2.
Depending on the design, if you can use a jigsaw you can replicate most of what a laser cutter does using printed out to correct scale templates and taping them in place over your materials. Then trace the lines with the saw just like a laser would cut from the machine path program.
Even that is way fancier than we ever get.
Honestly, the closer this stuff looks to something a drunken hillbilly cobbled together out of the junk rusting out in the front yard, the better. Anything more is probably spending too much time on looks that don’t matter at this phase.
3 Likes
Red-Green 'Handyman's Corner' level of build quality? Use what you've got lying around and just tape the stuff together.
Variable Wheelbase:
https://youtu.be/e7LuHW4BIlU?si=1IxZS6wePpMPReel
Automated Fence Painter:
https://youtu.be/8HOD2pLG3Pw?si=4TT51PhKF-NYczSe
Perpendicular Parking:
https://youtu.be/Q8sG65eHmTo?si=iQ99dc7vkk-5h2E0
4 Likes
General speaking we don’t really have an enforcement mechanism but what we did have was a what happened when you don’t have a a deadline. In 2022 we switched robot architectures 4 times over 4 weeks at it caused our CAD to be so messy and the robot to be so rushed and in general the architecture didn’t work anyways.
In 2023 we actually were still debating on the night of the 10th day after kickoff and our one of our mentor really wanted us to reconsider one other architecture due to our familiarity with arms/pivots. At the end of the night we still hadn’t decided and it was getting late so I agreed to only continue debating till the noon the next day but I told them if we did not reach I consensus that since I was Captain/Design/CAD lead that I would pick and be over with it. Long story short I did not have to invoke that power but if you needed a hard enforcement that could be the way.
1 Like
What do you mean when you say robot architecture? is this just general planning of what will be on the robot or concrete positions for each mechanism?
So I think the best way to define architecture is what type of mechanisms are you planning to use and their general locations on the robot. You should have decided if you are use a arm vs elevator, a pivot intake vs a four bar, etc
3 Likes
In addition we create an architectural sketch which has key dimensions (robot bounding box, extension bounding box, etc) that everyone can reference. Note that the bounding boxes may be smaller than the legal limits (eg we’ve decided we’re building a robot that goes under the “stage”).