Time-efficient build quality

My team used to have a member who was all about build quality. Parts that weren’t exactly constrained were his sworn enemies, and he would use standoffs wherever possible to ensure that every single part of the robot is precisely and exactly constrained to each other. We didn’t have shoulder screws back then, so standoffs were our best bet.

This was a mixed bag: on one hand, we got to have a top-notch build quality on our robots, but on the other hand, we had to spend two-to-three months on every single build, which didn’t leave us with much time to code auton, do driver practice, etc. We had to pull all-nighters right before every single competition, just to finish the robot.

Seeing how other teams actually have good autons, I’m lead to believe that this isn’t the norm, in more than one way. The existence of good autons denotes, for one, that people don’t take the entire season on building, and for another, that good build quality is achievable without taking too much time.

How do you get good build quality, time-efficiently?

use CAD.
model your entire robot before you even start building. I’ve found the most efficient way to get a high build quality robot is to spend a few weeks making sure you have a perfect CAD model, and then build the entire robot super quickly, using your CAD as instructions basically. I built my late season TT robot over one weekend from a CAD model that only took 2 weeks. And my change up robot is mostly from a CAD model (though I did improvise on the pooper, hoarder, and hood, I just got lucky and it all worked almost the first time).


Big facts. Cad is your best friend when experimenting with designs. Just make sure these designs will work as in the past I have cadded designs that didn’t work in real life.

1 Like

I’m already doing CAD, I’m more interested in methods for ensuring that everything is constrained and rigid.

are you looking for build quality tips then?

1 Like

The building time taken is definitely a problem. Like many people on this post have commented, CAd helps a lot. But I would also like to add that planning is just as important. I find it helpful if my team makes a timeline before starting the project to help track our time of Cadding, building, programming, and driver practice. This way you won’t be tempted to start rebuilding in inappropriate times and instead become more prepared for every competition as you planned every step there.

1 Like

What you’re saying is fairly normal. The solution is to have experienced coders, a library of functions, 2 robots( one new, one old for programmers), or to allocate time better.

1 Like

Problem with having two robots is not having enough parts for two robots


To make stuff constrained and rigid you just have to use parts like shoulder screws and make sure that you have plenty of bracing. Bracing can come in the form of spacer boxing in crucial areas and boxing a c-channel with another c-channel in areas that must not twist. I will post here a picture of my extremely rigid drivetrain from last year. One thing I would generally avoid is connecting major structures by stuff like standoffs because they are subject to loosening by vibration (loctite could negate this) and can bend the metal somewhat easily if hit. They have their roles though so don’t be afraid to try them.

Also about build speed good build quality in CAD should make it easy to build in physical form. If the robot is 100% finishes in CAD, then building should only take about 8 hours depending on your speed.

My team used to take 2-3 months to get a halfway working design cause nobody at my school knew anything about CAD. We’d get subpar robots and have no time for anything else. CAD and knowledge from the forum is what is saving me this year now that I’m down to nearly a team of 1.



The red circles represent everywhere there is spacer boxing. This robot’s drive was built in about 3 days of work from 2 people without any CAD (didn’t know it then). Just by these pieces of bracing it is essentially 100% rigid (I cannot make anything flex using my hands) and far sturdier than necessary. Sure it would get damaged if it fell off a table or got hit by something, but nothing that will appear in competition can affect it. The screws are tightened enough that I highly doubt pieces would get out of true even after many competitions.


just do good


You could alleviate not having enough testing time by trying to keep robot subsystems modular and easily upgraded. That way upgrading it is easy and most of the time the programmers can have the bot. Subsystems can be developed off of the bot.


People spend too much time thinking about how to do this or how to do that. Just be good


Dont intentionally design your robot to be modular, because you will end up making sacrifices in order for that to happen. If a change in a system requires a change in an entire robot, than so be it, the other parts of the robot weren’t designed for that. This all being said, there wont often be a case where a specific system needs to be changed so much that it requires an entire redesign.


Vex robots are naturally modular. The only time they’re not is when you have bracing between subsystems. Just don’t place screws in hard to reach places without any thought.


Especially not this year I think because once you have the correct drivetrain specs and have the intakes in the right place, the only other subsystem really is the rollers and they are so easy to move around and reposition compared to things in past years. Robots should be much more inherently modular this year.

Last year you couldn’t exactly just decide to move your tray pivot or arm without serious repercussions to other parts of the robot.

1 Like

True. For example we had to redo our indexer and we didn’t even have to change where the structure was for it. Different size of sprockets and different amounts. And the only other thing that changed is how they were powered and connected.

1 Like

I feel like my point was misunderstood

The idea here is that if you purposely design systems with the goal of being able to change them out later (based on the idea that a redesign is inevitable) then you will trade functionality/reliability for modularity.

But, my claim was not that a system redesign should never be done, simply that a robot in VRC should not intentionally be designed with modularity in mind

Now this is all because of my misinterpretation/your own misrepresentation of your post. As you later clarified

If this is all you were talking about in your initial post than I have no problem with that.


Bruh, you just have to be right: “I’m only misinterpreting because of your own misinterpretation of your own words” . I meant exactly what I said. Design the bot so that any subsystem can be replaced easily. This helps with development and fixing parts during competitions. Do a complete rebuild only when you can’t modularly swap on a new component anymore.

Don’t put words in my mouth. Its no longer a conversation if you do that.

1 Like

This is often correct, and if you have good build quality you generally only need to unscrew 2-4 screws in order to detach a subsystem

1 Like