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.


Our virtual training last night was over how we plan to organize our 2022 robot in OnShape The video and slides go over much what I described above and some new things we are planning to try.

Video: https://youtu.be/ilz_nPLf86U
Slides: D3.1 OnShape Robot Organization - Google Slides


I have been implementing this same strategy with my FTC team. Onshape makes it really easy to start all in one document and then split folders off as necessary.

1 Like

Thanks for sharing this. I think our design team will be able to do some of what you shared but not all, due to inexperience and too little training time. We’ll at least do primary sketching and derivative sketching, and at least a simple form of space allocation. I doubt we’ll fully realize the potential of things like shared variables and in-context editing (as powerful as it is) this year. I also expect our hygiene around where we pull in parts and reference them (& avoiding duplicates, etc.) will not be great. I think it’s likely we’ll design mechanisms referencing primary sketches that roughly fit into allocated spaces, with ideas about where & how they will connect, but then the actual connecting & integration of everything might be hacked and messy. Some integration problems will probably even be resolved in the real world and then need to be reflected back in the CAD afterward. A lot of learning will take place.

What you shared provides a pretty clear picture of where we need to go as we gain experience. Appreciate it.

1 Like

I am trying to decide between a single document for the entire robot with folders for subsystems or different documents for different subsystems. My main concern is minimizing load time, as many students will be doing CAD on school-issued Chromebooks.

Does adding a full copy of the main assembly to each subsystem document negate the benefits of improved load times achieved by keeping each subsystem within its own documents?

I don’t know the answer to that, we have never done it the other way.

Having individual documents per mechanisms let’s the comments and revisions work so much better that we never did the whole robot in one document.

Inserting the full assembly into the subsystem documents should have a better load time than keeping everything in one document because the inserted assembly is a version and not the “live” main assembly. Our general rule is that versioned instances of parts/assemblies should always load faster than the main workspace.

There’s another workflow that I’ve been meaning to test out to accomplish a similar multi-document structure:

  • Create a new document for the subassembly.
  • Create one dummy part - I’ve started using a “reference cube” (thanks 1678!)
  • In the top-level document, insert that dummy part into the main assembly. I usually fasten it to the origin.
  • Right-click on the dummy part and select “Edit In-Context”. It’ll jump you back to the subassembly document and open a new context.
  • Create a sketch or some feature to lock in the context, and then click the “Create version and update in Assembly”.

While I haven’t tested it as much as I’d like yet, this allows you to maintain in-context references across documents without having to insert the main assembly into each document. Might be worth a try if you’re looking at new workflows.


We’ve been testing a few different workflows along the lines of deriving master sketches instead of ever using in context assemblies. I don’t have much to share on it just yet but our current favorite workflow is something along the lines of drawing all masters sketches in a single main document part studio and then deriving those sketches into other documents to reference.


This ends up being a huge issue and does not play nice, especially with many people editing various parts of the single document as each change triggers constant updates/rebuilds. It gets to a point that is essentially unusable very quickly.

Separate documents by subsystem and a document with the full assembly is much better.

1 Like

I’ll definitely have to test that workflow out, as I think updating the context may feel a little cleaner than updating an inserted assembly. Would load times be similar for both, as they are both versions and not live?

We have a pretty small CAD team, so I thought maybe we would be okay to keep it in one document, but I’m thinking we take the advice of using multiple documents.

Thanks all!

The workflow where you create in-context references across documents should load faster because there would be no construction assembly to load, just the contexts. Those context may take a few seconds when the doc first opens, but it’ll be snappy from there.

The teams I’ve worked with in the past have also had small CAD teams with 2-4 designers active at once, so I’ve always gotten away with a single document. I do think finding a multi-document workflow that works for you and year team is the most future-proof plan!

1 Like

This is how we did it on 4911 in 2021 and 2022 and I really liked this workflow. I put a presentation together for 971 a few months back with an overview of the document structure and other “best practices” we implemented on CyberKnights: FRC Onshape Best Practices - Google Slides


When you do this, are you able to edit both assemblies in context?

Meaning, if I am working on a shooter, will I also be able to see the drivetrain while working on it, and when I am working on an intake will I be able to see the latest versioned snapshot of both the shooter and drivetrain? Then, in the main robot document, will I be able to see the last updated version of all three?

This has been our biggest hurdle working with assemblies and subsystems. It works beautifully the an assembly in parts (Thanks for the wonderful tutorials everyone), but to do this with assemblies and other assemblies would make MKCAD significantly more helpful.