Onshape Best Practices continued?

Like many teams, our students are inexperienced vs. past years after not having in-person time to build a robot last year. We didn’t design a robot either because our design team focused on the game design challenge, which went well… but it’s not the same task as designing a whole robot in a couple weeks.

I really appreciated this thread Ty_Tremblay initiated about Onshape Best Practices more than two years ago. With all that has happened since then with Onshape (many more Feature Scripts, the MKCad app, etc.), I was wondering if a few people would share any refreshed best practices for how to use those things + folders, part studios, assemblies, etc. to collaborate across a design team on a full robot design. Thanks.


I’ll start off with the MKCad app. This is pretty much the best way to interact with MKCad and doesn’t require going through the old process of labeling every document. There’s a tutorial here to set this up: CAD Library | Onshape4FRC. Speaking of that site, it’s a good starting place for how-to-Onshape-for-FRC: Getting Started | Onshape4FRC

I’m also the developer of a bunch of featurescripts. Lots of them are very specific and depend on your design process, but probably the one that has the best ratio of time saved to specificity is Tube Converter, which lets you make hole-patterned tubes (including Versaframe) out of extruded blocks. I’ve also seen some people use the tubes with all holes in CAD but then only cut the required holes manually (saving time if you don’t have a router). Instructions for adding these scripts to your toolbar are also on Onshape4FRC.


For something like an FRC robot, where it’s a large document being worked on by multiple team members, it’s a good idea to separate all of your major mechanisms into different documents and consolidate them all into one “Main Robot” document.

This has the benefit of keeping load times down for all the students working on different mechanisms, and allowing finer versioning control in case you only want to revert changes done to one part of the robot.


I second this for more complicated robots and teams with less power computer resources (chromebooks).

To add to this tip, make any major layout sketches in the top-level robot document. You can then insert those sketches into the lower-level documents. These will then update when you create a new version of the main robot document.

Layout sketches don’t need to have every detail, but specifying the mounting locations for subsystems makes aligning everything correctly in the sub-documents much easier to manage.


First off - www.OnShape4frc.com should be used by every FRC team doing onshape, it has a lot of great content.

Spectrum has been keeping our notes from transitioning to OnShape in this document we have some of our workflows documented towards the bottom, it’s not more than notes at the moment but it may be helpful. - Spectrum Onshape Resources - Google Docs

Similar to what the people have said above, we set up a process for designing our 2021 robot in multiple Documents. Here are the notes I have for our process. We have only used it for one robot design so I’m certain there are ways to improve it but it did work well for us.

Multi-Document Robot

  • Create a document for each subsystem (drive train, intake, etc) and a document for your main robot assembly.
    • We numbered them 0. Main Robot, 1. Drivetrain, etc so they sort nicely in a folder.
  • In every document they will likely contain three tabs
    • 1 Assembly - this is the assembly used by outside documents, this includes all the parts and COTS parts for that subsystem and for main it has all the other subsystems inserted in to it.
    • 2 Part Studio - This is where the vast majority of parts for the subsystem will be created.
      • In main robot we use this part studio to create multiple sketches that each subsystem use to help start creating it’s geometry.
      • Subsystems may be broken up in to multiple part studio depending on their complexity and how integrated they are.
      1. Construction Assembly - This assembly is used for adding a full copy of the main assembly that you will use to make your part studio in context so you can reference other parts of the robot.
  • Ensure the origin of each part studio and assembly stays consistent so when you insert parts they are already in their correct locations and you can you use the group mate to simplify your process.
  • In the subsystem part studios, Derive the sketches from the Main robot part studio, that will help you keep items consistent.
  • Versioning and Updated Linked Reference will be the things you have to do the most to keep your documents synced. Version multiple times a session.
  • “Pin Reference” lets you stop an item from being included in the Uplated All Linked document list, this is very useful for items you don’t have ownership for like MKCAD items.
  • “Set as Primary Instance” is very useful for allowing you to update the context in a part studio. The option is in the assembly though.

Thanks all. Super helpful.

I think what may be hardest to explain is the overall workflow of starting with a conceptual design including rough blocked out space allocation /crayola CAD of the full robot… And then the iterative adjustments as detailed designs/CADs of mechanisms are work in progress by different students (including negotiations like “can I have another couple square inches in this area”, resulting in the overall robot CAD evolving & all WIP mechanisms needing to sustain compatibility)… and then the shift to actual mechanism CADs in the full robot assembly. Also how to predecide on linkages and have designers understand those constraints as well.

It seems like a session reviewing all documents of a completed robot at different save points (from beginning with just the master sketching and blocky conceptual CAD to the full robot CAD assembly complete) might be the best way to get this across. Anyone do this?

That’s what we are trying since this will be our first competition year in OnShape. I drew a robot from sketches through construction just to practice and refine a workflow. The students are just starting another robot design so we can learn our OnShape process together. We are using the multi-document method described by Allen above.



I think the word or phrase you are looking for is, “Showing Design Intent.” This is something that even many high-level companies struggle with, so do not fret if it is difficult to get the ideas across between your robotics team.

I would focus on teaching parametric modeling that shows design intent. What do I mean by design intent?

For example, say you originally design for 4" wheels on your drivetrain. You could sketch and model the wheel, dimension the center of the wheel 2" off of the ground, and that would look fine, like the wheel is sitting on the ground. But what if it is determined that 6" wheels are needed to complete the challenge at a later point? When you change to a 6" wheel now it sticks through the ground by 1" because you have the center dimensioned to 2" from the floor.

What should’ve been done is to model the wheel as tangential to the ground and all other geometry relative to that. This is how you show your design intent in your sketches and modeling. It was intended that the wheel be tangent to the ground, so it should be sketched such.

This is not possible with all features of a system, but try as best as possible. This is also a rather difficult thing to teach.

Onshape has a really great comment function that can be used to share design intent as well. Comment on a specific component of a sketch, part, or assembly and describe why it was modeled this way which may help you out.