How do teams that do little or no CAD work?

There is one thing no one has mentioned yet. Just build the thing! Yes, it definitely isn’t as effective and your designs can’t be as complex. However, it does work. This past season, one of my very hands on students decided to develop a hatch mechanism. We didn’t have the resources to develop multiple CAD projects at once, but we did have an abundance of box tubing. He went to work, and 11 prototypes later created a design that functioned quite well. Once 2 pieces ended up being CADed for piston mounts.
We could have spend time designing the exact details the mechanism, and it wouldn’t have been finished. Each team has a number of “resource credits”. These can be anything from mentor distribution, workshop space (many would kill for what we have in space), parent support, etc. We didn’t have the credits to spend CADing this mechanism along with others.

This idea was past to me by @Danny_Blau, who’s current team just had a great season. Why? Because this year, rather than building a metal robot in a wood shop, they build a wooden robot in a wood shop. They understood they didn’t have the credits to allocate to building an all metal robot, and rather used them to perfect their design in other ways.

To have a really successful year, you have to know where to allocate those credits without overshooting. For us, it was only allocating CAD to certain areas, and using our other resource strengths to make up for it.


If I remember correctly, when we visited 624 before the 2018 Houston champs they told us that they only started CADing the entire robot in 2018 and they only used to CAD small parts of it before. They won 9 regionals and were finalists on 5 from 2009 (first win) until 2018 without full robot CAD, and they always have had great performance in Champs.

A lot of them don’t work, but for the most part they function off of crude sketches(I’m guilty of this as well lol).


Paper, whiteboard, verbally explaining.

Thanks for the replies. The title of the post doesn’t mean I don’t think building a robot with little or no CAD can be done. I’m just curious how it is done and I’m always looking for best practices that may help our team…

Context: Our team is highly time-constrained compared to other teams, and full detailed CAD can be very time consuming… Plus, we have many students interested in working hands-on, but only a few students who seem interested in investing time to become deeply skilled at CAD.

We will definitely continue to use CAD for quick iterations of 2D/geometry analysis - we can do this with just one or two CAD’ers, and the time effectiveness of this practice is amazing. I recommend it to all. However, I’m less certain about detailed CAD of the whole robot, given our current group of students and their interests.

Maybe early during build/competition season we could use game/scoring analysis & 2D/geometry analysis to decide on strategy & the basic robot design concept (i.e. what mechanisms). Then allocate space/location to each mechanism, and some mechanisms will be developed via detailed CAD (e.g. tricky things like 2019 climbing) while others are developed via just iterative physical prototyping/testing (e.g. 2019 hatch panel handler or cargo intake arm). Of course, linkage/fit ends up being trickier than if everything were resolved in CAD, but overall maybe this kind of approach will be better if we only have 2 or 3 CAD-ers and a couple dozen non-CAD-ers.

Thanks again for sharing perspectives & experiences.

Yup, at least through 2015, the team didn’t use a whole lot of CAD. We made a lot of carefully sketched drawings on graph paper that was used for machining parts and integrating systems.

I would say the reasoning behind this was largely related to our manufacturing capabilities. Back then, almost every part on the robot was made manually, without the use of CNC or other digitally controlled machines. So we would just draw everything because that’s what we had always done, and it worked pretty well.

(Note: in years prior to when I was on the team, 624 used to build out of a sponsor’s shop, so we used CAD then. Later, the team moved to a location closer to our school, and I believe the team lost access to some of the machines we used to have. I think that’s when the decision to go to paper and pencil was made.)

Since 2015, the team’s available tools have expanded to include more advanced machines, so there’s been a greater benefit to CAD, since it’s necessary to make use of the machine.

How did 1293 do it? Pretty poorly.

There were manual drawings done of many key parts, then everything was run on manual machines (and more than most of that, by the kids). Lots of little changes, lots of redone pieces, lots of angle brackets that only fit in one place, lots of snowman holes, etc etc etc.

Fortunately, this season we gained access to a plasma cutter and Wifi that lets us run Onshape. I think the difference in robot quality compared to most of the last decade of 1293 robots speaks for itself.

I’m sorta ashamed to admit this, but I’ve somewhat recently made 1:1 drawings in Photoshop that worked out pretty well for throwing together quick visuals to test ideas. It’s pretty much the same thing as using paper and pencil, but I’ve been using PS for nearly 20 years, so it’s easier for me. It’s not a CAD substitute and mostly works for chassis, superstructure, and basic articulation, but I can get a good idea of placement, scale, cut lengths and angles.

On the other hand, I’ve seen some pretty bad CAD models and I’ve seen teams build from said models. I’ve also seen teams deviate from good CAD for various reasons during fabrication and then repeatedly refer to said design afterward even though it’s drastically different. This is where CAD becomes theater, people are basically spitballing but with a drawing to lend the process gravitas.

Where it really matters is when you’re jobbing parts out to be cut or machined, especially if you’re doing custom gearboxes or something with tight tolerances. If you’re using a lot of Versachassis and other COTS components, you can survive with a design other than CAD.

1 Like

How I prefer to iterate through designs.

Cobble together a Proof of Concept using misc stuff around the shop and napkin drawings

Make a rough mock up in CAD to visualize foot print and motion (This step could and has been done without CAD either via White Board and Math or just a larger prototype if you have the resources)

Make some final drawings for manual machining

CAD any NC machined parts ( No way to really avoid this step if you want to use NC machines to produce parts)

You can write gcode by hand or use a conversational language like Prototrak, skipping the CAD and CAM steps. We used to do this before 95 got into CAD in a big way.

Nothing to be ashamed of doing. Leaning into the skills you already possess can be quite effective. If I recall my program kernels accurately PS is akin to AutoCAD (both vector based, not parametic) which has limitations, but they can be a useful tool.

Ahh yes I’ve lived with too much luxury in 3D print land. I did have to write a few programs by hand for sheet metal and plate things. That is always fun to do the math on.

Designing by hand has been how things have been done for centuries, and it’s still a valuable skill. The less complex your robot is the less you may need to cad it out to design it. Personally I rely quite a bit on CAD as I have zero hand drafting skills, and I have been able to create massive improvements on my team by cadding the robot first. It allows you to analyse the fit and packaging and items in both a 2d and 3d space with a lot less effort than drawing a scale model. CAD can allow a lot more complicated designs to be achieved with a lot less of a headache than hand drawing out all the details and movements, so personally I could never go back to designing robots without CAD, and I recommend it even if all you need is 2d sketches. The sketch tools in Solidworks are extremely powerful, and can be a big upgrade from drawing them by hand. Making a good cad came turn making a robot into building a lego set after everything is fabricated /bought.

1 Like

The SuperNURDs didn’t have CAD until at least 2013. We built pretty good robots anyway (for the time at least; the general average quality of bots has gone up a lot since then). When I was on the team in 2012, we seeded 19th and won the San Diego Regional as the second pick of the #1 alliance.

We did a lot of whiteboard sketches, a lot of paper sketches, and a lot of prototyping. I remember blocking out sections of the robot (i.e. the intake + conveyor gets a 1.5’x3’x8" prism at the front, the shooter gets a 1’x1’x2’ block on top of that, etc) pretty early on, as soon as we had a rough idea of what type of robot we wanted to build. Our general strategy was to mock up a quick prototype of each subsystem as fast as we could, and iterate a LOT, working concurrently on making it work and making it fit.

We also limited our ambitions to what we could reasonably do without CAD. Our drivetrain was pretty boilerplate (simple 6W tank with pneumatic tires), and we didn’t have any custom gearboxes. We decided early that we weren’t going to try shoot for the top goals (there were 3 levels that year), and designing a way to get on the bridge was “only if we have time after everything else”. Our machining capabilities in house were drill-press and bandsaw, so we didn’t need CAMs. We had a machine shop sponsor (thanks, Meziere Enterprises!) who made a couple of the trickier parts for us; we sketched out basic (not to scale!) drawings on scratch paper for them and drove over to explain what we wanted. We didn’t leave enough space for an electrical board, and our electrical lead and mentor ended up building 3 or 4 tiers of “condos” for the electronics, behind the conveyor, at the last minute. We also didn’t leave very much time for software development; we had very limited auton, few sensors, and no “automated buttons” (i.e. push this button and the elevator goes to the low goal height); everything was manually controlled by the joysticks. We were badly overweight, and cheesed out every surface of our robot, including a night spent at the Meziere shop disassembling the robot so they could lightweight some stuff for us. We were still overweight, and our salvation came the night Mr. Meziere himself showed up at our classroom with aluminum nuts and bolts (they squeaked and bound like crazy, but got us under 120!). We called those nuts and bolts fairy magic, because they were practically weightless.

I think the key to designing with little or no CAD is to know that nothing will work the first time (or the second, or the third, or possibly the tenth). Expect to build several iterations a week of the main subsystems, and to start building Week 1. Plan your build season to leave yourself time at the end to fix weight and size violations. Limit your scope up front - without CAD you shouldn’t try to do everything; whether that means a simple drivetrain, only shooting for low goals, not climbing, or something else will depend on the year, but something will have to give. Similarly, decide at what point in the build season mechanical has to be done and the robot turned over to the electrical, software, and drive teams. There’s not a clear distinction between prototypes and “final” systems the way there is when you CAD the whole bot before building it - the mechanical team will keep making better prototypes, and tinkering with the mechanisms, and making improvements indefinitely; they won’t be “done” with the robot until you cut them off.


I’ve done one robot with no CAD (2013) and one with barely any CAD (2014). In both cases, they were sloppier robots with many extraneous holes, but it really didn’t affect their ability to be competitive. However, adding CAD would have helped us add a few more extra features, like cut down on frisbee jamming in 2013 and score with our intake closed in 2014, by cutting down on overall iteration time. At the time though, our mentor resources were spread too thin to manage CAD on top of the robot build, which is lower on the pyramid in the hierarchy of needs.

When you’re operating in that world, for us anyway, it was a ton of guessing, checking and redoing the same stuff 2, 3 or more times. You definitely get to fully understand your robot.

I say this all as an ex-student CAD lead. You’re going to get more bang for your buck at the lower resource levels by skipping it (like we did in 2013 & 2014) probably and instead doing more prototyping.


It’s been 11 years since we built a robot without CAD, but back then it was “one step at a time.”

We started with the drivetrain (KOP), and a whiteboard sketch of the active mechanism we wanted to stick on it. From there it was buying metal, cutting it roughly to shape, and figuring out the details one at a time. We had a fold-in-half elevator in 2007, so we knew we needed a hinge. So, we stuck the two halves of the structure together, found a hinge at Home Depot that fit, drilled it out, and bolted it on. We figured out that we needed a latch so we sketched out a latch, cut it, and bolted it on. We knew we needed to move the carriage up and down so we put a gear rack on the side of the elevator. That “one foot in front of the other” process went on until we had a robot. Lots of sharpie, lots of drills, lots of hacksaws.

1 Like

Choosing a Drivetrain
Though drive train is one of the most important parts of your robot, it can also be the easiest to cut out CAD for. Many team sink tons of hours into their drive train building custom which could definitely be used in other place. Unless you already have a drive train that you are very familiar with, consider using a kit bot chassis. Sure, it may not be the absolute best, but the ratio of additional work to actual benefit isn’t worth it if you feel that time is a struggle. Optimizing coding and electrical placement often leaded to more consistent performance and are highly overlooked when teams try to make their drive train better. Improving those areas are hands-on skills that might be of interest. Though it’s a little out- dated, always remember, “Build simple, Bag early, get Milkshakes”.

Mechanism Design
Prioritize the game objectives and stick to that. That way, you can focus the little CAD you currently have on making one thing really well as opposed to multiple things ok.

Rapid Prototyping
As soon as the game starts, start playing with the game pieces. One of my fellow mentors, Mike Klinker, brought with him a beautiful concept from his past team. Rather than forcing game manuals on everyone, let students choose whether they want to read rules or start prototyping. The rule keepers can pour over how to play the game, while the prototypes can try to find the best mechanisms to play. Instantly in-taking game pieces, controlling them, and then scoring them will almost always be a part of the game.This really helps keep the energy alive. This would definitely be of interest if your students are very hands on.


I challenge this logic. CAD should be a foundation of the pyramid of good, flexible, design work, not on the top. I would opine that teams who take extra time to fully model their robot ultimately save time compared to those that do not because iterative efforts go into performance improvements instead of just making the mechanism fit/work.

This was 95’s experience at least.

I used to agree, but having put it into practice in 2013 when you only have 1-2 mentoring resources and limited money, we saw a higher performance increase putting that mentor time into facilitating trial and error on prototyping and construction instead of CAD. After we were performing at a high level without CAD, we added it back in to further improve team performance. Basically what I’m getting at is in the hierarchy of needs of building a robot that does very well competitively at all resource levels, CAD is somewhere on the list below spending lots of time on prototyping, informed strategy and a great driver and above advanced controls and precision machining.

I don’t believe this often works in the real world where we have much longer timelines and aren’t job-shopping all our parts, but sometimes best practices in FRC don’t often match the real world (for instance, we have had far more success having no sub teams than having sub teams—who would do this in a real 40-person business?). And even then, CADing is still best practice, but I’ll take a reliable stack of COTS with a great driver over a CADed alternative if that costs less resource time and is going to perform equivalently from a mechanical standpoint.

We CAD now (and CAD everything) because we have the resource mix to do it. It’s not the right choice for every team though.

During my tenure with 3946, we never had enough students with enough CAD experience to keep up with the hand-drawn and calculated and iterated build, much less get out ahead of it. They almost kept up with the build in 2017 and we were hoping that CAD would contribute to productivity in 2018, but both students and the mentor who did the CAD left the team before the 2018 build season.


I’ve been there. In 2014 we were dropped by our founding school (1997-2013) a few weeks before build season. I was one of two coaches. Not two technical coaches, two coaches. We (I) modeled the whole robot. We had more than two weeks for driver practice and programming because everything on the robot went together first-try after prototyping the important features. This enabled us to join the ‘3 ball auto’ club that year, which was a rare feat.

Was it insisting “everything must be modeled” that lead to our relative success that year? I think so, but not directly. Insisting that every major part be modeled sped up our fab time by reducing mistakes and oversights, which was nice. More importantly it forced us to dial back our scope to a design that we could model in time. Controlling the scope through modeling of our robot kept us from overstepping our resources (you know, that approach @Karthik keeps championing that many teams still ignore).

Here is our 2014 robot:

It had a total of 13 non-COTS part files.

I acknowledge that this is a single case, not data a general trend, but the results for our team were a stunning improvement.


I’m sorry that your former team struggled to implement CAD in a useful manor. To me that indicates ‘spend more time learning CAD’ not ‘forget CAD because we can draw faster.’

1 Like