CAD People, where do you normally start your design?

Hi everyone!
Our team is in the process of turning our concepts into real CAD models and prototypes, and I was hoping to use this long weekend to get some sort of ‘rough draft’ of our bot in CAD. I have enough experience to know what I’m doing, but I am the first on our team to try and design a bot in CAD and am uncertain of what to do first. We are also using Onshape this year, along with MKCad to get common parts;
So, my question for CAD people is, where do you normally start? How do you break down that design process into manageable chunks? Do electronics and motors come first, or the fixed chassis maybe?
I really appreciate your help, and good luck this season!
- Jack, 8230


I typically start with a drivetrain. I use more or less the same drivetrain design on every robot, with a few small tweaks, so most of the variables are already pinned down.

Afterward, typically some high-level sketches to hack out a geometry and prove to myself that it all fits together. I’ll often make “Crayola CAD” assemblies - lumpy, geometric, garishly colored solids which claim roughly the correct amount of space for each subsystem, so that I can tell if there’s going to be an interference on a subsystem I haven’t designed yet.

The usual next step afterward is the robot frame, and typically the “transit” mechanism. On a lifting game, that’s the elevator (or arm or whatever), and on a shooting game, that’s the indexer. The transit mechanism is often the most critical part of a robot and requires the most time and tuning to get right, so it’s key that it gets started early.

I usually then get started on the intake/outtake mechanisms after that. Typically the “delivery” mechanism (shooter, manipulator) comes earlier because it can often live independent of the remaining mechanisms.

Intake and endgame are typically the last two mechanisms - usually because the location and functionality of those mechanisms are very well-known and they are less picky than the first two.

Electronics comes last. I use a belly pan and lay them all out, sometimes as I go along, and then locate all the electronics in one go.

At the end, I might spend a few hours checking all the travels and doing a large amount of tuning to make sure everything looks and functions as expected. In a real season, I try to “release” mechanisms to fabrication as soon as I can, and build enough adjustability into them that this tuning process doesn’t require a complete rebuild of the system.


If I understand where you’re at in the process, my advice is usually “set up for where you’re going and start with what you know”. (Note I’m a Solidworks professional and have no OnShape experience, so my terms might be odd.)

Is your question just “what’s the parabolic arc generally look like from here to here?”, and all you know is the game field? Then maybe you just give yourself a 2D plane on the field CAD or a blank sketch with some reference geometry for the origin and target.

Is your question “what’re my overall intake/outtake bounding boxes on this chassis shape?” Slap in the drivetrain with bumpers and add important reference geometry / field elements. What’s your max height, max extension, goal height, etc. “Black box” the robot and mockup the intake and outtake and/or maybe the endgame (strategy/priority/difficulty dependent) – these are usually the most constrained by outside elements. This can be largely 2D; extrude roughly when you need to. Approximate; don’t engage in details until you actually need them or want to capture them from prototyping.

If your question instead is more physical, like “how can the indexer link between the intake and shooter prototypes?” think about the key geometries of both and what parameters you’re measuring and adjusting by. Then mock them up using those and stick them in an assembly with some CARGO. Play around.


Whatever it is, plan for change. When you make a constraint, think about what you want to capture most. Is it that your floor intake roller height depends on the CARGO diameter? Then you can dimension it off of the diameter of the CARGO, not e.g. the floor. (This example is a geometry experiment, not your final CAD, where you might instead know e.g. your bracket dimensions.)

Or maybe (probably) you’re more confident that your drivetrain will be symmetrical than in its overall width. So use that as the constraint where possible rather than something absolute (e.g. a mirror plane instead of dimensioning everything from the righthand side).

If it’s a more ‘real’ model, say you want to do the layout for an electronics bellypan, think about what reference geometry you’re going to want in order to mate that bellypan into its parent assembly. What are you liable to want to change about the electronics? Want to swap out the motor controller? Let’s ensure the options share reference planes and constrain using those. Want to change the number? Does that change the spacing or not? Set up the driving pattern that way. And what’s liable to change in the robot that affects the bellypan? How can you make that change as seamless as possible, and what can be updated automatically? What do other components want to “know” about the bellypan? Bounding box clearance? Let’s make some reference geometry for that.

In all cases, set good datums, stick to consistent conventions, make and name smart references, pay attention to tolerances. Avoid duplicating work wherever possible. (e.g. if you’re writing the same number for a hole position twice, just define it off the other hole.) …Ok, there’s actually a lot of “in all cases” advice, but those are a few.


Hey TechBison, thanks for asking this. Plenty of people and teams are in a similar place, including ours.

I have studied this topic, but I’m still inexperienced. I have a related question for experienced Onshape robot designers: For COTS parts that require space like everything else, how do you typically represent them in the primary sketching / crayola CAD / space allocation and later transition to the actual inserted COTS parts in Onshape?

It seems like the steps are something like…

  1. primary sketches to drive design intent
  2. extrude sketches to crayola CAD / space allocation, including bodies representing COTS parts to be inserted later
  3. insert crayola CAD / space allocation bodies into an assembly and use that as context for sub-system part studios (if they’re in the same document… if sub-systems are in different Onshape documents, I think you may need to insert crayola CAD into a full robot assembly in each document to be used as context there to realize the advantages of multi-doc approach…)
  4. do sketching and custom part modeling in the sub-system part studios, using the “ghostly images” of the crayola CAD / space allocation as context
  5. insert COTS parts & custom parts into a given subsystem assembly as progress is made
  6. insert the subsystem assemblies into the full robot assembly
  7. by doing the above, replace crayola CAD with detailed sub-system CAD as it becomes available (just hide the crayola CAD bodies I assume? or should that assembly really be a different one, and in that case how does one handle the context shift?)
  8. update context in the subsystem part studios, observe, adjust
    and iterate iterate iterate… something like that? This is what I’ve described to our students (we’ve decided to go single document because just 3 students are contributing), and if I’ve gotten something horribly wrong I’d like to clarify for them.

Typically I begin with a good master sketch of things I’ll want as driving variables, such as ball compression this year. I’ll then mock up frame components, either tube stock or sheet metal parts. I heavily use multi-part part studios in Onshape, as I’ve found these allow me to rapidly mock up relatively complex assemblies while keeping integration in mind.

Let me share a few examples for a concept I worked on last week.

Here’s a master sketch of a ball, with the main frame tubes arranged around it to start.

Next I’ll extrude the main frame geometry and create a sketch of where I want major elements to be, in this case I sketched the places I wanted stored balls, and the places I wanted wheels, gears, and belts.

Finally I’ll add power transmission components, you can do this by using derived parts, featurescrips, or by mocking these parts up yourself. I did not reach the stage of adding motors in this concept by the time I abandoned it, but that would have happened next.

Then you can insert this into your assembly, usually I have a plan to integrate it throughout, that is updated as I go.

This is a very high level example; I usually like to answer the bigger questions (structure, spacing, motion components) first before worrying about the smaller ones (specific structure + hardware, shaft constraints, etc.)

This is also just one example of the process I usually use to concept and generate ideas. I always start with a 2d paper sketch before I begin this crayola CAD process.

Edit: Here’s another solid example of concept CAD to start, this is from my team’s 2021 skills challenge robot.

You can see that the motors and wheels are all mocked up relatively primitively, and there are no shafts. Certain ideas were pursued and fleshed out more than others here as well, which is evident through the varying levels of detail.

Basically to answer the question of where to start… just start. Any method you can have to quickly get your ideas into 3d will be massively helpful, and will give you an intuitive understanding of those ideas and how they’d actually need to be implemented IRL. Getting as many of these viable concept ideas into CAD is a good plan as well, this’ll help keep you from getting locked into any one concept in the beginning.


This is extremely helpful, thank you. I’m hoping to relay this to the 2 other team members doing CAD (we also just have 3 contributing students, myself included), and get started on our crayola space allocation ASAP!

@TechBison, just to be clear, I listed those steps out in order to get some more experienced folks to confirm I’ve understood well what others have shared. I would not necessarily use those steps with others just yet. I have a feeling another person or two might comment and point out any flaws in what I wrote. (Thanks in advance to anyone who does.)

We’ve been using a top-down approach to CAD for the past few years and it’s worked very well. We’ll start with a “blockbot” to define the robot’s overall size/shape and allocate space between mechanisms.

During our in-season CADathon, each mechanism starts with a Master Sketch part that defines all of the geometry form the mechanism through a series of sketches in all 3 dimensions. Each part in the mechanism then imports the relevant sketches from that MS part so all of the geometry automatically updates. The mechanisms are then combined together into the total robot model, and any interferences that slip past the blockbot stage are dealt with.


Hey Clayton, I’ve been looking for a way I could reach you, do you have an email I could message?

DM sent.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.