Objective

Have an OnShape account inside your team's organisation, open a shared document, and be able to explain in one sentence why a cloud-native CAD tool is the correct choice for a team building a robot together.

Concept

OnShape is a CAD tool that runs entirely in a browser. That single sentence is what makes it different from every traditional CAD tool. Traditional packages install on one machine and save files to one disk. If a teammate wants to work on the same part, they have to wait for a file to be emailed, or check it out of a shared drive, or pray that nobody overwrites anything. OnShape runs like a shared document: two students open the same part studio, their cursors appear in each other’s viewport, and they edit the same model at the same time with no merge conflicts. For a team that meets twice a week and has four students touching the drivetrain, that is the difference between a functional CAD workflow and a broken one.

📐 Engineering tip. The collaboration model is the reason OnShape wins over every other option for a team-based build. A student can open the team’s CAD from any device with a browser — no install step, no licence seat, no file transfer. That accessibility compounds across a season.

A few practical consequences flow from the cloud-native model. The tool is free for educational use, so cost does not gate access. It runs inside any modern browser, so any device the team already owns can open the team’s CAD without an install step. A new member can sign up on Monday and be drawing parts on Tuesday. The document has full version history built in, so you can see who changed what and roll back a bad edit from three weeks ago. Named branches let you experiment without breaking the current design. Share links work the way you expect — paste a URL, the right people get access.

For this strand, OnShape is the only tool we teach. Fusion 360 is fine if a team has already committed to it, but teaching two tools trains indecision — students end up fluent in neither. Pick one, teach it deeply. OnShape is the pick because of the collaboration model, which is the single most important factor for a team-based build environment.

Guided practice

1. Open onshape.com in a browser.
2. Click Sign Up. Choose the Education plan. Enter your school email address (your team should standardise on everyone using their school email — do not sign up with a personal address).
3. Check your email for the verification message and click the link. Set a password.
4. Your team captain or mentor will invite you to the team’s organisation. If they have not yet, ask for the invitation before continuing. Accept the invitation from the email link.
5. Log in. You should now see a Documents page. At the top, switch the view from “Owned by me” to the team organisation name. The team’s shared documents appear.
6. Open the document your mentor has designated for L0.1 practice (usually named sandbox or new-member-onboarding). The document opens to whatever tab is default — probably a part studio.
7. Explore. Do not click anything destructive. Move the camera around (middle-click drag to rotate, scroll to zoom). Identify the Feature tree on the left and the main viewport in the centre. You will learn the rest of the interface in L0.2.
8. Your exit state: a verified OnShape account, confirmed membership in your team’s organisation, and a successful open of a shared team document with the ability to navigate the viewport.

Independent exercise

From the Documents page, find the team document that contains the current competition robot’s CAD (ask your mentor if you cannot find it). Open it in read-only mode. Spend five minutes exploring the tabs at the bottom — note how many part studios, assemblies, and drawings the document contains. Do not edit anything.

Common pitfalls

• Signing up with a personal email instead of your school email. You will miss the team invitation and have to re-sign up.
• Clicking into a random team document and editing something. Read-only first. Edit only in documents you have been explicitly told are for practice.
• Not accepting the team organisation invitation. Without it, you will see your own documents only and none of the team’s shared work.
• Expecting an install step. There is none. If a browser tab opens and shows a 3D viewport, OnShape is running.

Where this points next

Next up: L0.2 — The OnShape UI Tour. A guided walk through the five core regions of the interface so you know where every button lives before you start modelling.

Objective

Name the major regions of the OnShape interface — Feature tree, toolbar, viewport, tab bar, Parts panel — identify which tab type you are in (part studio, assembly, drawing), and undo any mistake without losing unrelated work.

Concept

OnShape’s interface looks busy at first because it has to cover several different workspaces — part studio, assembly, drawing — from the same base layout. Once you know where the five core regions are, and you know that each tab type rearranges two or three of them, the interface becomes predictable. This tutorial is a guided tour. No modelling yet — just orientation, so later tutorials can say “click Sketch in the top toolbar” and you know where to look.

The five regions are: the top toolbar, which holds feature creation tools (Sketch, Extrude, Fillet, and so on); the Feature tree on the left, which shows the timeline of operations that built the current state; the viewport in the centre, which shows the 3D geometry; the Parts panel on the right (part studio only), which lists the parts that currently exist; and the tab bar at the bottom, which lists every part studio, assembly, and drawing in the document. Tabs are how you navigate between different workspaces without leaving the document.

One concept matters more than any other: features stack up as a timeline. Every action you take in a part studio — every sketch, every extrude, every fillet — creates a feature, and features appear in the Feature tree in the order they were created. You can insert new features in the middle of the tree, you can edit old features and watch the downstream features update, and you can roll back to a point in history to see what the model looked like then. The timeline is the single biggest difference between OnShape and a mesh-editing tool, and once you internalise it, the interface makes sense.

📐 Engineering tip. Undo works differently than you might expect. The standard undo shortcut undoes the most recent action, but if you went down a branch and want to undo without losing unrelated work, use the Version Graph (bottom-left corner) — it lets you jump to a named earlier state. For routine mistakes, undo is fine. For “I just wrecked two hours of work,” the Version Graph is the answer.

Guided practice

1. Open the practice document from L0.1. Click a part studio tab at the bottom of the screen — you should see the 3D viewport fill the centre of the screen.
2. Identify the top toolbar. It is the row of icons near the top of the window, above the viewport. Hover over each icon — a tooltip appears. The leftmost group are sketch-related (Sketch, lines, rectangles, circles). The next group are feature-creation tools (Extrude, Revolve, Sweep, Loft). The group after that is for modifications (Fillet, Chamfer, Shell). Do not click anything. Just hover and read.
3. Identify the Feature tree on the left side. If the document has existing features, they appear as a list. Right-click any feature — a context menu appears with Edit, Suppress, Rollback, and so on. Close the menu without choosing anything.
4. Identify the viewport in the centre. Middle-click drag to rotate the view. Scroll to zoom. Right-click drag to pan. Press N to reset the view to the default. Get comfortable — you will use these gestures constantly.
5. Identify the Parts panel on the right side. If the document has parts, they appear as a list. Click a part name — it highlights in the viewport.
6. Identify the tab bar at the bottom of the screen. Each tab is either a part studio (cube icon), an assembly (pair-of-gears icon), or a drawing (paper icon). Click between tabs. Notice how the top toolbar changes — assemblies have different tools than part studios.
7. Find the Version Graph. Bottom-left corner of the screen, next to the tab bar — it looks like a branching icon. Click it. A panel opens showing the document’s history. Close the panel by clicking the icon again.
8. Practise undo. In a safe place (do not do this in a real team document — use the sandbox from L0.1), make a small edit like changing a view, then undo it using the standard undo shortcut.
9. Your exit state: you can point at the top toolbar, Feature tree, viewport, Parts panel, tab bar, and Version Graph without hesitation, and you have successfully used undo at least once.

Independent exercise

Open a different document in read-only mode — ideally the team’s current competition robot CAD. Spend five minutes touring it. Count how many tabs it has. Open the Feature tree of its main part studio and scroll through the history. Note how many features deep the tree goes. This gives you a sense of scale for a real team project.

Common pitfalls

• Hunting for sketch tools in an assembly tab. Sketches live in part studios. If you are in an assembly and cannot find the Sketch button, you are in the wrong tab type.
• Accidentally right-clicking a feature and suppressing it. Suppressed features disappear from the viewport and come back only when un-suppressed.
• Forgetting the N key to reset the view. If your camera is lost, N (for “normal view”) puts you back.
• Relying on the standard undo shortcut for large rollbacks. It works for the last few actions but is not a substitute for the Version Graph.

Where this points next

Next up: L0.3 — Team Document Organisation. From the interface to team conventions — how to name documents, how to branch, and who should have edit rights to what.

Objective

Your team has agreed a document-organisation model (one per robot, one per subsystem, or one per season), a naming convention for tabs and features, a branching strategy for working versus released states, and an edit-rights model — all written down and applied to at least one real team document.

Concept

An OnShape workspace without a convention is a workspace that will cost you hours of “which document has the drivetrain?” questions by mid-season. The tool gives you power — unlimited documents, infinite tabs, branches, versions, permissions — and that power is useless without a team agreement on how to use it. This tutorial is about making the agreement, not about OnShape features. The features are five clicks. The agreement is the thing.

There are three reasonable document-organisation models. One document per robot puts the whole robot in a single OnShape document with tabs for every subsystem. Pro: everything is linked and updates cross-subsystem. Con: performance degrades on very large documents, and edit collisions get more frequent. One document per subsystem puts each subsystem — drivetrain, lift, intake — in its own document with its own tabs. Pro: cleaner separation, faster documents, easier permissions. Con: cross-subsystem checks require copying parts between documents. One document per season keeps everything in one document across the season, using branches to separate “v1 of the robot” from “v2”. Pro: longitudinal history. Con: the document becomes large, and old material is hard to find. Pick one model. Write it down. Do not change it mid-season.

📐 Engineering tip. The naming convention is more important than the organisation model. A consistent prefix system — PS_ for part studios, A_ for assemblies, DWG_ for drawings, S_ for sketches — costs nothing and saves hours of guessing by mid-season.

Branches are a version-control feature that lets you work on a risky change without breaking the current design. Create a branch called experimental_intake_v2. Make your changes on the branch. If they work, merge the branch back into main. If they do not, delete the branch and nothing was lost. Use branches for anything that might not work. Do not use branches as “my personal copy” — that is what drafts and user permissions are for.

Edit rights are the last piece. In a team organisation, you can grant Can View, Can Comment, Can Edit, or Owner permissions per document. The default should be Can Edit for active builders on that subsystem, Can Comment for mentors, and Can View for everyone else on the team. Principal designers get Owner on the documents they are responsible for. This prevents accidents and makes accountability clear.

Guided practice

1. Convene a short team meeting with at least two other people on your CAD team. This is a team tutorial, not a solo one.
2. Decide the document-organisation model. Vote if you have to. Write the decision down in your team handbook or a shared document: “For this season, we use <model>.”
3. Decide the document naming convention. Draft a template with placeholders: <team>_<season or subsystem>_<purpose>. Write it down.
4. Decide the tab naming convention. The PS_ / A_ / DWG_ / S_ prefixes from the previous Tier tutorials are a good default — adopt them explicitly. Write it down.
5. Decide the feature naming convention. A simple rule: “Every feature in a part studio Feature tree must be renamed from its default before the part studio is shared for review.” Write it down.
6. Decide the branching strategy. Default suggestion: main is the current committed design; any risky change gets a named branch; branches are merged or deleted within two weeks. Write it down.
7. Decide the edit-rights model. Name the CAD lead and grant them Owner on the team’s primary documents. Grant Can Edit to active CAD team members. Mentors get Can Comment. Everyone else gets Can View by default.
8. Apply the agreement. Pick one existing team document. Rename it to match the new document convention. Rename every tab to match the tab convention. Go into at least one part studio and rename the features to match the feature convention. Set the permissions.
9. Share the written agreement with the whole team. The handbook entry is the artefact — if it is not written down, it is not a convention.
10. Your exit state: a written team-handbook entry covering the five decisions (document model, document naming, tab naming, feature naming, branching, edit rights), plus one real team document that has been renamed, re-tabbed, and re-permissioned to match the new agreement.

Independent exercise

Open three more documents that your team owns. For each, audit whether it matches the new convention. Produce a short list of documents that need to be renamed or reorganised and assign each to a team member with a date.

Common pitfalls

• Picking a convention and not writing it down. Undocumented conventions last about two weeks.
• Mixing organisation models. A team that starts with “one document per subsystem” and then makes “one big robot document” next to it has the worst of both worlds.
• Granting Edit rights to the entire team by default. Someone will delete something important. Default to Can View and grade up.
• Never using branches. If your team’s work always happens directly on main, an experimental change will eventually corrupt the production model.
• Branches that never merge. An experimental_intake_v2 branch that lives for three months is not a branch, it is a fork — decide and commit.

Where this points next

Next up: L1.1 — Sketches Are the Whole Point. Tier 1 begins. You will finally start using OnShape for its highest-leverage purpose — sketching the robot before anyone cuts metal.

Objective

Explain — and demonstrate in OnShape — why a 2D sketch is the single most valuable artefact CAD produces for a VRC team, and create one that answers a real design question before any metal is cut.

Concept

Most new CAD users treat CAD like digital sculpture. They load a parts library, drag in C-channels, try to make something that “looks like a robot,” and then spend three practice sessions building it without ever checking whether the robot can actually do what it needs to do. That is not what CAD is for. CAD is a planning tool. The planning happens in 2D sketches, long before any 3D part exists.

A sketch is a disposable drawing. Its job is to answer a question: does my drivetrain fit the sizing box? Does the game object clear my intake mouth? Is there room for the gear reduction I want between the motor and the wheel? Each of those questions costs nothing to ask on a sketch plane and costs hours to ask on a real robot. A good robot is not a robot whose dimensions were guessed — a good robot is one where every dimension traces back to a sketch that proved the dimension would work.

📐 Engineering tip. The vocabulary is small on purpose. Circles stand for connection points, axles, wheels, and pneumatic pivots. Lines stand for C-channels, standoffs, and arms. Rectangles stand for game objects, battery, motors, and the sizing box itself. That is all you need to answer 80 per cent of the design questions you will ever ask.

The mindset matters more than the tool. Sketches are cheap. Make a mess. Draw the same mechanism three different ways. Copy the document and change everything. If you catch yourself being “careful” with a sketch, you are using it wrong. The sketch is the cheapest thing in the entire design pipeline — treat it that way.

Finally, a sketch is never a deliverable. Nobody grades your sketch. A builder will not fabricate from your sketch. The builder fabricates from the real parts that come later. The sketch exists so that the parts that come later are the right parts.

Guided practice

1. Open your team’s OnShape document (from L0.3).
2. In the top-right create menu, select Create → Part Studio. Name it planning-sketches.
3. In the Feature tree on the left, click the Sketch tool (the pencil-and-square icon in the top toolbar) and select the Top plane when prompted. The view should snap to a top-down orientation.
4. Using the Rectangle tool (centre-point rectangle is usually easiest), draw a rectangle centred on the origin. Click the first click at origin, then drag to any size.
5. Double-click the width dimension and type the maximum footprint your current season’s sizing constraint allows. Do the same for the length. The rectangle should now snap to that exact size and turn black (fully defined).
6. Switch to the Line tool. Draw two horizontal lines inside the box to represent the outer edges of your drivetrain C-channels. Dimension the spacing between them.
7. Switch to the Circle tool. Place four circles — one at each wheel location. Dimension their diameter to your chosen wheel size, and dimension their centres to the inside edge of the C-channels.
8. Click the green tick to accept the sketch. Rename the sketch in the Feature tree to S_sizing_box_and_drivetrain.
9. Your exit state: a saved, fully-defined 2D sketch named S_sizing_box_and_drivetrain inside a Part Studio named planning-sketches. No 3D geometry yet. No parts. Just the sketch.

Independent exercise

Still in planning-sketches, start a second sketch on the Top plane called S_sizing_box_v2. This time, draw the same box but position the drivetrain differently — narrower, wider, or offset. Compare the two sketches side-by-side in the Feature tree. Pick one; explain to yourself (out loud or in the notebook) why.

Common pitfalls

• Trying to make the sketch “pretty.” If you are adjusting line weights or colours, stop.
• Skipping dimensions. An undimensioned sketch is a suggestion, not a plan. Every line should either be constrained to a dimension or to another line.
• Over-constraining. If OnShape turns something red, you have told it two contradictory things. Delete a constraint and try again.
• Starting in 3D. If you find yourself extruding before the sketch is done, you have skipped the step that matters.
• Being precious. The second you feel protective of a sketch, make a copy and change something.

Where this points next

Next up: L1.2 — Sketching a Drivetrain Footprint. The same mindset, applied to a fully-dimensioned drivetrain layout with wheels, motors, and gears.

Objective

Produce a fully-dimensioned 2D drivetrain sketch that proves your chosen wheel size, wheelbase, motor placement, and gear reduction all fit inside your current season’s robot footprint limit.

Concept

A drivetrain is the one subsystem where “eyeballing it” almost always fails. Wheels must sit inside the frame rails. Gears must mesh. Motors have to not collide with anything. The centre of rotation has to be somewhere you can predict so your autonomous turns land where you expect. A sketch lets you prove all of that before you commit to a single hole in a C-channel.

The trick is to sketch in a layered order that matches how constraints actually stack up in real life. Outer boundary first — the sizing box. Inner boundary second — the frame rails that will carry the wheels. Then the wheels themselves, because their diameter determines how much room is left for gears and motors. Then the gear train. Then the motors. If any layer does not fit inside the previous layer, stop and resize — do not compromise the outer layer.

📐 Engineering tip. Circles are the star of this tutorial. A circle is a wheel. A circle is a gear pitch diameter. A circle is a motor footprint. Two tangent circles represent a pair of meshing gears. If two circles that are supposed to mesh do not touch in your sketch, they will not mesh in real life, either.

Guided practice

1. Open planning-sketches from L1.1. In the Feature tree, right-click the sketch tool and create a new sketch on the Top plane. Name it S_drivetrain_footprint.
2. With the Rectangle tool, draw the sizing box first. Use your current season’s maximum robot footprint for width and length. Add the two dimensions.
3. Inside the box, draw two horizontal lines representing the outside faces of the left and right drivetrain C-channels. Dimension the outside-to-outside width of the drivetrain.
4. Add two more horizontal lines offset inward by the C-channel wall thickness (use 0.1 inch as a placeholder). These give you the inside faces, where the wheels live.
5. With the Circle tool, place four wheel circles — two per side. Dimension their diameter. Dimension the wheelbase (front-to-rear centre distance).
6. Fully constrain each wheel circle to the inside face of the frame rail using the Coincident or Tangent constraint, so the wheels automatically reposition if you change the frame width.
7. Add a circle for each motor, placed at the motor mount hole location you intend to use. Use 2 inches as a placeholder diameter for the V5 Smart Motor footprint (verify against your own measurement before committing).
8. Add meshing gears: draw two circles tangent to each other, dimensioned to the pitch diameters of the gears you plan to use. Constrain one gear concentric to the wheel and the other concentric to the motor.
9. Place a Point at the centroid of the four wheel circles. Add construction lines (toggle Construction in the toolbar) from that point to each wheel to make the centre of rotation visible.
10. Click the green tick to close the sketch. The sketch entry in the Feature tree should now read S_drivetrain_footprint and should be fully black (fully defined).
11. Your exit state: a dimensioned, fully-defined S_drivetrain_footprint sketch that visibly fits inside the sizing box, with wheels, motors, gears, and centre-of-rotation marker all in place.

Independent exercise

Make a copy of S_drivetrain_footprint (right-click the sketch → Copy, paste into a new sketch). Rename the copy S_drivetrain_footprint_alt. Change one major dimension — wheel diameter, wheelbase, or gear ratio — and watch what cascades. Record which dimensions update for free and which break. Pick the version you would build and write one sentence explaining why.

Common pitfalls

• Forgetting to leave clearance between the wheel and the frame rail. Wheels need a bearing hub and a little air.
• Dimensioning the gear spacing by hand instead of tangent-constraining the pitch circles. Tangent is correct; typed numbers drift.
• Placing motors without checking clearance from the wheel. The motor body sticks up, but in a top-down sketch you will forget until you build.
• Using construction lines for things that should be real, or real lines for things that should be construction. Construction lines do not extrude later.
• Leaving the sketch under-constrained. Any blue line is a line that can move when you do not want it to.

Where this points next

Next up: L1.3 — Sketching Game-Object Interaction. The same mindset, but now the robot and the game object share the sheet.

Objective

Drop a sketched generic game object into a mechanism sketch and prove, before any metal is cut, that your robot can pick it up, carry it through its full range of motion, and place it where it needs to go without colliding with itself, the field, or the game object.

Concept

The drivetrain sketch from L1.2 answered a question about the robot. This one answers a question about the robot interacting with the world. That distinction matters, because most mechanisms fail not because the robot is wrong in isolation — the drivetrain turned fine on the bench — but because the robot and the game object were never drawn together on the same sheet. A team will happily spend two practice sessions building an intake that cannot actually admit a game piece, because nobody took the thirty seconds needed to draw the two shapes next to each other first.

📐 Engineering tip. The rule is simple. Any mechanism that touches, lifts, carries, launches, or places a game object is required to be sketched against the game object. Not described in a meeting. Not imagined. Sketched. And not once — sketched at every state that mechanism will pass through: start state, intake state, carry state, score state, reset state. Five sketches per mechanism is not overkill; it is the minimum to prove that the mechanism works at every point in its cycle.

Circles and rectangles do almost all the work. A generic game object is a circle if it rolls and a rectangle if it stacks. A robot mechanism is a line-and-circle skeleton — lines for the arms and C-channels, circles for the pivots. Overlay the two. If any of the robot geometry intersects any of the game-object geometry at any state other than “the robot is gripping it,” the mechanism is broken. Fix it now in the sketch, not in three weeks on the field.

Guided practice

1. Open planning-sketches (from L1.1 and L1.2). Create a new sketch on the Front plane and name it S_mechanism_vs_object_start. A side view is what you want, because almost all robot-on-object collisions are vertical.
2. Using the Rectangle tool, draw the sizing-box side profile on the origin. Dimension its height to your current season’s maximum starting height and its length to your footprint length.
3. Still in the same sketch, draw a second rectangle (or circle, if your season uses a ball) representing the generic game object at its field-floor position. Dimension it to the approximate size of your season’s game object. Place it directly in front of the robot.
4. With the Line tool, sketch the skeleton of your intake or arm: a line from the pivot (a Point) to the end effector. Add a Circle at the pivot to make it clear visually.
5. Using the Dimension tool, dimension the arm length and the pivot height above the drivetrain top surface.
6. Click the green tick. Rename the sketch S_mechanism_vs_object_start.
7. Right-click S_mechanism_vs_object_start in the Feature tree and choose Copy. Paste into a new sketch on the same Front plane. Rename the copy S_mechanism_vs_object_intake.
8. Open the copy. Move the end of the arm line to the intake position (on or just above the game object). Keep the pivot fixed. Keep everything else identical. This is the same mechanism, one frame later in time.
9. Repeat two more times: S_mechanism_vs_object_carry (arm at mid-height, game object attached to the end effector) and S_mechanism_vs_object_score (arm at score height).
10. Open each of the four sketches in turn. At every state, check: does any robot line cross into the game-object rectangle when it should not? Does the game object exit the top of the sizing box when it should not? Does the arm collide with the drivetrain C-channel?
11. Your exit state: four saved, fully-defined sketches — S_mechanism_vs_object_start, _intake, _carry, _score — each showing the robot skeleton and the game object together, each fully black (fully defined), and none showing an unwanted intersection.

Independent exercise

Pick any other mechanism on your planned robot that interacts with a game object — a scoring mechanism, a loader, a blocker. Sketch it at three states against the game object on the Front plane. Name the sketches with the same S_<mechanism>_vs_object_<state> pattern. Find at least one geometric problem you would not have noticed without the sketch, and write it down.

Common pitfalls

• Sketching the mechanism in isolation. The whole point is that the robot and the object share the sheet.
• Only sketching the start state and the score state, skipping the in-between. Most collisions live in the middle.
• Forgetting the sizing-box ceiling. A state that exits the box at the top is a rules violation as surely as one that exits at the side.
• Dimensioning the game object “loosely.” Use the real game object’s actual dimensions, not a round-numbered approximation. A quarter-inch error compounds.
• Copying a sketch and then editing the original by accident. Always rename the copy before touching it.

Where this points next

Next up: L1.4 — Sketching Pneumatic Geometry. Where distance a and distance b decide whether your piston can actually lift the arm.

Objective

Produce a parameter-driven OnShape sketch of a pneumatic-actuated arm that lets you iterate piston mounting geometry — distance a, distance b, and stroke length — and watch the full arm range of motion update live.

Concept

Pneumatics look simple on paper and punish teams in practice. A cylinder extends a fixed distance. That distance, transmitted through a linkage, produces an arc of motion at the end of an arm. Four numbers decide whether that arc is usable or useless: the cylinder’s stroke length, the distance from the arm pivot to the cylinder’s pivot on the frame (distance a), the distance from the arm pivot to the cylinder’s pivot on the arm (distance b), and the angle of the arm at rest. Get those four wrong and the arm will not move far enough, or it will move too far, or the piston will try to push through itself. Get them right and the arm does exactly what you planned.

📐 Engineering tip. As distance a decreases, range of motion goes up but leverage goes down; distance b is where you trade leverage against angle range; the piston pushes hardest when it is perpendicular to the arm and weakest when it is nearly parallel. A thirty-minute sketch with variables can save a week of drilling the wrong holes.

The power move here is the OnShape variable. Instead of dimensioning distance a as “2.5 inches” directly in the sketch, you define a variable called dist_a with the value 2.5, then use #dist_a as the dimension value. Do the same for dist_b, stroke, and arm_length. Now when you want to test what happens if you move the cylinder mount half an inch, you edit one variable and every dependent dimension updates. The sketch becomes a calculator.

Sketch the pneumatic linkage twice: once in the retracted state and once in the extended state, overlaid on the same plane with one as construction lines. The angle between the two arm positions is the range of motion. That angle is the number your drive team actually cares about. Everything else on the sketch is in service of that one angle.

Guided practice

1. Open planning-sketches. From the Feature tree menu, click the Variable tool (looks like #) and create four variables in order: arm_length = 10 in, dist_a = 2.5 in, dist_b = 2 in, stroke = 2 in. These become live parameters for the sketch.
2. Create a new sketch on the Front plane named S_pneumatic_arm.
3. Place a Point at the origin. This is the arm pivot — the fixed joint where the arm rotates on the robot frame.
4. With the Line tool, draw the arm as a single line starting at the origin and going up-and-to-the-right. Dimension its length using #arm_length (type #arm_length into the dimension box).
5. Place a second Point on the arm line, #dist_b inches from the origin. Use the Distance dimension tool, and type #dist_b. This is the piston-to-arm attachment point.
6. From the origin, draw a short construction line (toggle Construction in the sketch toolbar) horizontally to the right, length #dist_a. At its endpoint, place a Point — this is the cylinder’s fixed pivot on the frame.
7. From the cylinder pivot point, draw a Line to the piston-on-arm point. This line represents the cylinder at its current position. Measure its length by adding a driven (reference) dimension — driven dimensions sit in parentheses. Call that length L_retracted in your head; you will compare it to the extended length.
8. Now draw the extended state. Copy the arm line and the piston-on-arm point, rotate them about the origin (Transform → Rotate in the sketch toolbar), until the cylinder-to-arm line length equals L_retracted + #stroke. OnShape will snap — look for the tangent indicator — or you can use a Distance constraint typed accordingly.
9. Add a driven angle dimension between the retracted-arm line and the extended-arm line. This is your arm’s range of motion.
10. Click the green tick. The sketch should be fully black (defined). In the Feature tree, rename it to S_pneumatic_arm.
11. Now iterate. Double-click the dist_a variable in the Feature tree and change it from 2.5 to 1.5. Watch the angle-of-motion number move. Change dist_b next. Change stroke last. Write down the angle each change produces.
12. Your exit state: a fully-defined S_pneumatic_arm sketch driven by four named variables (arm_length, dist_a, dist_b, stroke) with a driven angle dimension that updates live when you edit the variables.

Independent exercise

Pick a real arm on your planned robot — an intake flipper, a wall-stake mechanism, a deflector, whatever pneumatic mechanism you intend to build. Use the real cylinder stroke length your team has in stock. Set arm_length to your real arm length. Find the combination of dist_a and dist_b that gives the arm exactly the angle range your mechanism needs — no more, no less — while keeping the piston within 30 degrees of perpendicular to the arm at its hardest working state.

Common pitfalls

• Dimensioning with numbers instead of variables. You lose the entire iteration benefit the moment you type 2.5 instead of #dist_a.
• Forgetting that distance a and distance b are measured from the arm pivot, not from each other.
• Drawing the extended state by guessing the angle. The extended state is determined by the stroke length, not by how far you want the arm to go. Let the geometry tell you the angle, not the other way around.
• Using a real line instead of a construction line for the frame-side cylinder pivot distance. The frame-side pivot is not a physical line on the arm — it belongs to the frame — so it must be construction.
• Sketching only the retracted state. Without both states overlaid you cannot read the angle range, which is the whole point.

Where this points next

Next up: L1.5 — When to Throw a Sketch Away. How to run a three-version study, compare against criteria, pick a winner, and archive the losers without regret.

Objective

Run a three-version sketch study of any mechanism concept, compare the three versions against named criteria, pick a winner with evidence, and confidently delete or archive the losers without sentimental attachment.

Concept

A team that has never thrown a sketch away has never really used sketches. A competitive robot goes through many different CAD iterations and several different electronics layouts before anyone settles. The number is higher than you think. Most teams reach version three and stop, because version three “feels” finished, and then they spend the rest of the season fighting the consequences of decisions they made while they were still learning the problem.

Throwing a sketch away is not a failure. A sketch’s job is to teach you something. The second the sketch has taught you — “this wheelbase is too long,” “this pivot is in the wrong place,” “this gear ratio will not fit” — the sketch has done its job, and the only thing left to do is make a new one that applies the lesson.

📐 Engineering tip. The workflow is a three-version study. You sketch three fundamentally different versions of the same mechanism — not three tweaks of the same idea, three genuinely different approaches. You evaluate each against the same criteria. You pick one. You mark the two losers as archived. You proceed with the winner, and the winner only. This is the same mental move as a decision matrix from Chapter V, except you are doing it at the sketch level, before the matrix is even needed.

The test for whether you are doing this right is social: you should be able to explain to a teammate, out loud, in under sixty seconds, why the winner won and why each loser lost. If you cannot, you did not really compare them — you just drew three pictures.

Guided practice

1. Pick a mechanism for which you have not yet committed to a design. An intake, a scoring arm, a lift, a deflector — anything you have an open question about.
2. Open planning-sketches. Create a new sketch on the Front plane named S_study_<mechanism>_v1. Sketch a first version of the mechanism using the same layered approach from L1.2 and L1.3 — sizing box, frame, mechanism skeleton, game object at critical states.
3. Close the sketch. Right-click it in the Feature tree and choose Copy → Paste. Name the paste S_study_<mechanism>_v2. Open the copy and change it fundamentally — different pivot location, different arm count, different drive source. Do not tweak v1; replace it.
4. Repeat for S_study_<mechanism>_v3. Three truly distinct versions. Not three variations — three designs.
5. Open a blank OnShape drawing or a piece of paper, and draw a three-column comparison table. The criteria: Range of motion achieved. Clearance against the game object at every state. Parts count estimate. Buildability (do you have the stock and the skill?). Risk (what breaks this design?).
6. Fill in the table for each of v1, v2, v3. Use numbers where you have them and words where you do not.
7. Pick the winner. Write a single sentence underneath the table: “v2 wins because it is the only version that clears the game object at the score state with the current arm stock.”
8. In the Feature tree, rename the two losers with an _ARCHIVED_ prefix — for example _ARCHIVED_S_study_intake_v1. This keeps them retrievable but makes it visually obvious they are not the current plan. Do not delete them yet — you might want to show them in a design review.
9. Rename the winner S_<mechanism>_CHOSEN — no version suffix. This is now the sketch that subsequent tutorials (Tier 2 part modelling) will pull dimensions from.
10. Your exit state: three sketches in the Feature tree — two prefixed _ARCHIVED_, one named S_<mechanism>_CHOSEN — plus a written one-sentence rationale for why the winner won.

Independent exercise

Repeat the three-version study for a second mechanism. Time yourself. The first study should take 60–90 minutes; the second should take 40 — not because you are cutting corners, but because the rhythm of “draw three, compare, pick, archive, name” should now be automatic. If your second study takes longer than your first, stop and ask yourself whether you are being precious.

Common pitfalls

• Drawing three tweaks instead of three designs. A three-inch difference in wheelbase is a tweak; a tank drive versus a holonomic drive is a design. If your three versions all look similar, you have not explored the space.
• Deleting the losers instead of archiving them. You will want to bring them into a design review (L5.1) to show the reasoning.
• Skipping the written rationale sentence. If you do not write it down, you will rewrite it from scratch every time someone asks.
• Picking a winner because it is prettiest. The criteria are about fit, clearance, parts count, buildability, risk — nothing on that list is aesthetics.
• Going back and polishing v1 after you picked v2. The loser is dead. Do not re-touch it.

Where this points next

Next up: L2.1 — What a Part Studio Is. Tier 2 begins. The winning sketch becomes the parametric spine of a real 3D part.

Objective

Create an OnShape part studio, produce a simple 3D part by sketching a profile and extruding it, understand how features stack up in the Feature tree as a history timeline, and explain in one sentence the difference between a part studio and an assembly.

Concept

Tier 1 was about sketches. Sketches are 2D and they plan. Tier 2 is about parts. Parts are 3D and they describe real metal and real plastic that will exist on the robot. A part studio is the OnShape workspace where parts are born. You open a part studio, you sketch a profile on a plane, you extrude that profile into a 3D shape, and you iterate on that shape with additional features — more extrudes, cut extrudes, fillets, patterns — until the shape matches the real part you want to build.

📐 Engineering tip. The important mental model is that a part studio is a history. The Feature tree on the left is not a list of objects; it is a timeline of operations. If you go back and edit Feature 1 — say, change the width of the original sketch — every feature after it updates automatically, because each feature is a function of the features before it. This is the single most powerful idea in parametric CAD.

A part studio can contain multiple parts. A single part studio can hold a C-channel, a spacer, and a custom plate, all modelled from different sketches on different planes, all updating together when shared variables change. Teams often start with one part per part studio, which is clean but limits the amount of shared state you can express. As you get comfortable, you will put entire subsystem families into one part studio.

Finally, the part studio is not the assembly. You cannot mate parts to each other inside a part studio — they just float in space next to each other. The assembly, which you will meet in Tier 3, is where parts connect and move. Get in the habit of thinking “studio for shape, assembly for motion.”

Guided practice

1. Open your team document. Click + in the bottom tab bar and choose Create Part Studio. Name the new tab PS_first_part.
2. The part studio opens with three default planes — Top, Front, Right — visible in the Feature tree on the left. Click the Sketch tool in the top toolbar. When prompted, pick the Top plane. The view snaps to top-down.
3. Using the Rectangle tool, draw a rectangle centred on the origin. Dimension it 2 inches by 1 inch. The rectangle should turn black (fully defined). Click the green tick to exit the sketch. A new entry Sketch 1 appears in the Feature tree.
4. In the top toolbar, click the Extrude tool. A dialogue opens. Select the rectangle you just drew (OnShape usually pre-selects the most recent sketch). Set the depth to 0.5 inches. Click the green tick. A new 3D block appears in the viewport. Extrude 1 appears in the Feature tree.
5. Click the Fillet tool. Select the four vertical edges of the block. Set the fillet radius to 0.125 inches. Click the green tick. The block’s corners round off. Fillet 1 appears in the Feature tree.
6. Now demonstrate the timeline. Double-click Sketch 1 in the Feature tree to edit it. Change the rectangle width from 2 inches to 3 inches. Close the sketch. The 3D block updates automatically — it is now 3 inches wide, still extruded 0.5 inches, still filleted. You did not have to redo the extrude or the fillet.
7. Undo the edit so the part is back to 2 inches, and save the document.
8. Your exit state: a part studio named PS_first_part containing one part — a 2″ × 1″ × 0.5″ filleted block — built from three features in the Feature tree: Sketch 1, Extrude 1, Fillet 1.

Independent exercise

Create a second part studio PS_second_part. Build a triangular plate: sketch a three-sided polygon on the Top plane, extrude to 0.25 inches, and fillet the corners of the top face (not the vertical edges). Then go back and edit the original sketch to make the triangle larger. Confirm the extrude and fillets update. Save.

Common pitfalls

• Trying to fillet before extruding. Fillets operate on 3D edges, not 2D sketch lines.
• Leaving a sketch under-constrained (blue lines). The extrude will still work, but any later edit will make the part jump unpredictably.
• Deleting a feature in the middle of the tree and expecting the later features to survive. Later features may break because they referenced the deleted feature; fix them or rebuild.
• Confusing the part studio with the assembly. If you find yourself trying to make two parts move relative to each other in a part studio, you want an assembly instead.

Where this points next

Next up: L2.2 — Modelling a VEX C-Channel. The same workflow, applied to the bread-and-butter structural part your robot is built from.

Objective

Model a VEX C-channel from scratch in OnShape — including the U-shaped cross-section, the length you want, and the full VEX hole pattern — or, if your team uses a community VEX parts library, import the same C-channel and understand what the library’s model contains.

Concept

C-channels are the most common structural part on a VEX robot. They form drivetrain rails, superstructure towers, lift arms, and almost any long rigid member. Every other part you model eventually has to mate against a C-channel, so knowing how to create and edit one — whether by modelling from scratch or by pulling from a library — is foundational.

The VEX hole pattern is on half-inch centres. That half-inch is the master dimension of the entire VEX metal catalogue — every standoff length, every shaft spacing, every gear centre-to-centre distance traces back to it. When you sketch the hole pattern, use a variable called hole_spacing set to 0.5 inches. Everything else — the length of the C-channel, the position of the first hole, the position of the last hole — should be expressed as multiples or offsets of that variable.

🔧 Build tip. Modelling from scratch has one big advantage: you understand every dimension because you put each one there. Using a community library has a different big advantage: you get the whole catalogue in thirty seconds. For this lesson you model one C-channel from scratch, because the modelling exercise teaches you where the dimensions live and why they matter. After this lesson, whether you continue modelling from scratch or switch to a library is a team choice — both are valid.

Guided practice

1. Create a new part studio named PS_c_channel. Before drawing anything, click the # (Variables) tool and create two variables: hole_spacing = 0.5 in, channel_length = 10 in. You will use both in the sketches.
2. Sketch the cross-section. Click Sketch, select the Front plane. Using the Line tool, draw a U shape: a horizontal line at the bottom (the back web, 1 inch wide), then two vertical lines rising from its endpoints (the flanges, 1 inch tall). Dimension the web width to 1 inch, the flange height to 1 inch, and the wall thickness to 0.063 inches using the Offset tool (Offset the U profile inward by 0.063 to create the inside wall). Close the cross-section into a closed profile. Check that it is fully defined (black). Click the green tick.
3. Extrude. Click Extrude, select the closed U profile, and enter #channel_length as the depth. A long U-shaped body appears. Green tick.
4. Sketch the hole pattern on the back web. Click Sketch, select the outer face of the back web of the C-channel. Place a Circle of diameter 0.172 inches (the VEX hole clearance diameter) near one end. Dimension the first hole centre to #hole_spacing / 2 from the end of the channel and to #hole_spacing / 2 from the web edge. Close the sketch.
5. Linear pattern the hole along the length. Click Linear Pattern. Select the circle from the previous sketch as the feature to pattern. For the direction, pick an edge of the back web running along the channel length. For the distance, enter #hole_spacing. For the count, calculate how many holes fit — floor(#channel_length / #hole_spacing) — or enter 20 and adjust. Green tick. The web now has a row of evenly spaced holes.
6. Add the second row of holes if modelling a 2-wide channel. Repeat step 4 with the second row, or use Linear Pattern in the second direction at the same time.
7. Add the flange holes. Sketch a circle on the outer face of one flange, dimension it, and linear-pattern it along the flange at #hole_spacing. Mirror the flange pattern to the other flange using the Mirror feature with the Front plane as the mirror plane.
8. Rename features in the Feature tree for clarity: Sketch 1 → S_cross_section, Extrude 1 → E_channel, Sketch 2 → S_web_hole, Linear Pattern 1 → LP_web_holes, and so on.
9. Save the document. Your exit state: a part studio named PS_c_channel containing one C-channel part of length #channel_length, with the full VEX hole pattern on the back web and both flanges, driven by the hole_spacing variable, with all features named legibly in the Feature tree.

Independent exercise

Change channel_length from 10 inches to 17.5 inches. Confirm the extrude and all hole patterns update — the number of holes should grow. If any pattern breaks (pink error icon), fix the feature count. Save as a second part under the same part studio if your team supports that workflow, or create PS_c_channel_long as a copy.

Common pitfalls

• Sketching the U as separate lines instead of a closed profile. Extrude requires a closed loop.
• Modelling the wall thickness wrong. Real VEX steel is closer to 0.050 inches; aluminium is closer to 0.063 inches. Use the one you actually have.
• Placing the first hole directly on the end of the channel. Real C-channels have half a hole-spacing of edge distance.
• Patterning features with a fixed count that does not scale with channel length. Count should be driven by the length variable.
• Forgetting to mirror the flange holes. A C-channel with holes only on one flange will bite you in assembly.

Where this points next

Next up: L2.3 — Modelling a Custom Plastic Part. The same part-studio workflow, turned onto custom polycarbonate — a mounting plate with holes derived from a sketch.

Objective

Model a custom polycarbonate mounting plate in OnShape with all dimensions driven by a single sketch, all mounting holes aligned to the VEX half-inch grid, and the resulting part exportable as a flat 2D profile ready for a laser cutter or CNC router.

Concept

Plastic is the right answer for a lot of VEX design problems. Use plastic rather than metal in low-strength applications — funnels, minor bracing, sandwich plates, alignment tabs, anything that does not need to carry structural loads. Plastic is lighter, faster to fabricate in-house, and does not eat into your team’s metal budget. Chapter III L3.6 covers which plastic to pick and when; this tutorial is the CAD expression of those decisions.

A custom plastic part has a different modelling shape than a C-channel. A C-channel is a profile you extrude along a length. A plastic plate is a 2D shape you extrude once, at the thickness of the stock you will cut from. Your part studio workflow reflects this: one master sketch contains the entire 2D outline and every hole position; one extrude feature converts that 2D outline into a 3D plate. That is almost all of it.

📐 Engineering tip. The critical discipline is that every hole must sit on the VEX half-inch grid. If you want to bolt the plastic plate to a C-channel, the holes must align with C-channel holes or the plate is useless. Use the same hole_spacing variable pattern from L2.2, or snap sketch points to a reference grid. Never eyeball hole positions — the plate will not bolt up.

The sketch should also be laser-cutter ready: simple closed outer loop, inner hole circles as closed loops, no stray lines, no construction lines polluting the final geometry. The easier you make the DXF export job in L4.2, the cleaner the cut. Finally, thickness matters — use a variable like #plate_thickness so you can switch between 1/16″, 1/8″, or 1/4″ stock without touching every feature.

Guided practice

1. Pick a real use case. For this walkthrough, assume you need a mounting plate that bolts a sensor bracket to the top of a drivetrain C-channel — a small rectangular plate with four mounting holes to the C-channel and two additional holes for the sensor.
2. Create a part studio named PS_sensor_plate. Add variables: plate_thickness = 0.125 in, hole_spacing = 0.5 in, plate_length = 2.5 in, plate_width = 1.5 in.
3. Sketch the plate outline. Click Sketch, pick the Top plane, draw a centre-point rectangle at the origin. Dimension it #plate_length by #plate_width. Add a small fillet to each outer corner — use the Fillet tool inside the sketch, radius 0.125 inch.
4. Stay in the same sketch and add the mounting holes. Four circles aligned to the half-inch grid: place the first circle #hole_spacing in from one corner, dimension it 0.172 in diameter (VEX clearance). Copy or re-place three more circles at #hole_spacing intervals so the four mounting holes match a C-channel pattern. Add two more circles wherever the sensor needs mounting; dimension them to whatever the sensor’s datasheet requires.
5. Close the sketch. Verify it is fully defined (black). Rename in the Feature tree to S_plate_outline.
6. Click Extrude. Select the closed outer profile (the rectangle with holes). Set the depth to #plate_thickness. Green tick. A thin plate appears. Rename to E_plate.
7. Add a chamfer on the top-edge perimeter if your design calls for it (optional). Rename to CH_edge.
8. Assign the part a material in the Parts panel (right side). Right-click the part, choose Assign Material, and pick Polycarbonate from the standard library. This is not cosmetic — material assignment lets L5.2 compute mass correctly later.
9. Save. Your exit state: a part studio PS_sensor_plate containing one part — a polycarb plate with outline, mounting holes, sensor holes, and material assignment — entirely driven by the variables plate_thickness, hole_spacing, plate_length, and plate_width.

Independent exercise

Design a second plastic part: a sandwich plate that spans between two C-channels to support an axle. The plate should have two axle-pass-through holes sized for your real bearing block outer diameter, four mounting holes to the C-channels, and a cutout (interior pocket) to save weight. Use the same one-master-sketch discipline. Assign Polycarbonate material. Save as PS_axle_sandwich.

Common pitfalls

• Using multiple sketches when one would do. If your plate outline, mounting holes, and sensor holes are in three different sketches, an edit to the outline will not reposition the holes. One master sketch keeps everything linked.
• Hardcoding plate_thickness. You will stock 1/16″ next season and every plate in your document will need manual updates.
• Mounting holes off the VEX half-inch grid. A plastic plate that will not bolt to a C-channel is scrap.
• Forgetting to assign material. Your mass calculations in L5.2 will be wrong.
• Adding chamfers or fillets as 3D features when they were supposed to be on the flat outline. A chamfer on a vertical edge cuts into the exported DXF profile.

Where this points next

Next up: L2.4 — Parametric Design. Variables, driven dimensions, and the payoff of changing wheel_diameter once and having every dependent part update.

Objective

Define OnShape variables at the part studio and document level, drive sketch dimensions from those variables, and demonstrate the payoff — changing wheel_diameter from 4 inches to 3.25 inches and watching every dependent part update.

Concept

Every previous Tier 2 lesson sneaked variables in under the cover of other goals. This lesson makes them the point. A variable is a named number that lives somewhere in your OnShape document, and a parametric design is one in which every important dimension is a reference to a variable, not a typed-in number. When you change the variable, every feature that references it updates in a single solve pass. This is the whole payoff of parametric CAD and the thing that separates CAD-as-planning-tool from CAD-as-digital-sculpture.

📐 Engineering tip. A non-parametric design has 4.0 typed into twenty places in the feature tree. When you decide to switch to a smaller wheel, you find and edit all twenty places by hand, and you miss one, and the model is now internally inconsistent. A parametric design has #wheel_diameter in those same twenty places, and changing the variable once updates all twenty. The time saving on a single edit is large; the time saving across a season of iterations is enormous.

OnShape has two scopes for variables. Part-studio variables live inside one part studio and are available only inside it. Document-level variables are available across all part studios and assemblies in the same document. Use document-level variables for anything that more than one part cares about — wheel_diameter, hole_spacing, drivetrain_width. Use part-studio variables for numbers that only one part uses — plate_thickness for one specific plate.

The naming discipline matters. Variables should be named for what they mean, not for what they are. wheel_diameter is good; wd is bad; x is worse. Future you, looking at this model six months from now during a design review, will thank present you for spelling it out.

Guided practice

1. Open your team document. Create a new part studio named Variables — this one holds shared variables, nothing else. At the top of the Feature tree, add these variables using the # tool: wheel_diameter = 4 in, hole_spacing = 0.5 in, frame_outer_width = 16 in, frame_inner_width = 15 in, drivetrain_length = 13 in.
2. Create or open a part studio called PS_drivetrain_rail. Confirm that typing #wheel_diameter in a sketch dimension here resolves to 4 inches.
3. Sketch a simple drivetrain rail profile: a rectangle #drivetrain_length long by 1 inch tall. Extrude it 1 inch wide. The rail is a proxy — a real C-channel would use the tutorial from L2.2, but this simpler rail lets you focus on the variables.
4. In the same part studio, create a second part: a wheel proxy. Sketch a circle of diameter #wheel_diameter on the Front plane and extrude 0.5 inches. This wheel will move when the variable moves.
5. Now open PS_c_channel from L2.2. Find any dimension that should be driven by hole_spacing and replace the typed-in value with #hole_spacing. Save.
6. Demonstrate the update. Go back to the Variables part studio. Double-click wheel_diameter and change it from 4 in to 3.25 in. Press Enter.
7. Open PS_drivetrain_rail. The wheel proxy is now 3.25 inches in diameter. It updated without you touching it.
8. Restore wheel_diameter to 4 in. Now change hole_spacing to 0.5 in (no change) and confirm nothing breaks; then try setting it to 0.45 and observe what happens to PS_c_channel. Restore it to 0.5 in when done.
9. Save the document. Your exit state: a part studio named Variables containing at least five named document variables, and at least two other part studios whose dimensions are driven by those variables, with a demonstrated round-trip that confirms editing a variable updates every dependent feature.

Independent exercise

Identify every typed-in dimension in every part studio you have built so far (C-channel, custom plate, drivetrain rail). Replace as many as you can with references to document-level variables. When you are done, write down the list of variables you ended up with. Then change one of them (your choice) and verify the whole document updates cleanly. Any features that break — fix them.

Common pitfalls

• Creating the same variable twice, once at the document level and once at the part studio level. The local one wins silently, which will confuse you later.
• Naming variables after the tool instead of the meaning. dim1 is useless. wheel_diameter is useful.
• Typing 4.0 into a dimension box when you meant #wheel_diameter. The model still works — until you change the variable and watch half the features update and half not.
• Forgetting units. OnShape variables have units. Setting wheel_diameter to 4 instead of 4 in can produce silently wrong geometry if the default units do not match.
• Making a variable for a dimension that genuinely has one use. If sensor_hole_x_offset appears in exactly one sketch and will never change, it does not need to be a variable.

Where this points next

Next up: L3.1 — What an Assembly Is. Tier 3 begins. The parts you built in Tier 2 come together into assemblies that actually move.

Objective

Create a new OnShape assembly, insert parts from a part studio, understand the difference between a fixed and a floating instance, and explain in one sentence what an assembly is for versus what a part studio is for.

Concept

A part studio is where shapes live. An assembly is where parts meet. That is the entire distinction, and teams that get it confused waste hours trying to make motion happen in a part studio or trying to cut metal in an assembly. Neither works. A part studio models shapes — it is the place where a sketch becomes an extrude becomes a fillet. An assembly moves those shapes relative to each other — it is the place where a wheel rotates on an axle and an arm pivots on a frame.

📐 Engineering tip. Every assembly has a concept called the ground. The first instance you insert is normally fixed to the ground automatically, which means it cannot move — it is the anchor. Everything else floats until you add a mate. Fixing and floating is the primary diagnostic tool of assembly work: if something is moving when it should not, it needs another mate; if something is not moving when it should, you probably over-constrained it.

An assembly in OnShape is a list of instances plus a list of mates. An instance is a reference to a part from some part studio — you insert a C-channel into an assembly and you get a live link back to the part studio. Edit the part studio later and the instance updates. The mate list says how instances connect: this face is fastened to that face, this axle rotates in that bearing hole.

The practical rule is that you build assemblies in the same order you would build the real robot. Frame first. Drivetrain next. Subsystems last. Not because OnShape forces you to — it does not — but because any other order forces you to go back and re-anchor things when the earlier components change.

Guided practice

1. Open your team OnShape document. In the document tab bar at the bottom, click the + and choose Create Assembly. Name the new tab A_sandbox.
2. The empty assembly opens with an Instances panel on the left, a Mates panel below it, and the main viewport. At the top of the Instances panel, click Insert.
3. In the Insert dialogue, browse to a part studio you created in Tier 2 — the C-channel from L2.2 is ideal. Select a part and click the green tick. The part appears in the viewport.
4. Notice the lock icon next to the part in the Instances panel. That means it is fixed to ground. Right-click the instance and choose Unfix. The lock disappears. Try to drag the part in the viewport — it now floats freely in 3D space. Right-click and choose Fix again. Drag; it no longer moves.
5. Insert a second part from the same part studio. This one comes in floating. Drag it around the viewport. Confirm it can translate and rotate freely while the fixed instance stays put.
6. Save the assembly. OnShape persists to the cloud, but assembly state transitions happen in memory until you save — get in the habit.
7. Your exit state: an assembly tab named A_sandbox containing two instances, one fixed to ground and one floating, saved to the document.

Independent exercise

Create a second assembly named A_sandbox_02. Insert four different parts. Fix exactly one. Try to answer two questions by experimentation: what happens when you insert the same part twice (does it come in as the same instance or a new one)? What happens when you try to fix an already-fixed instance?

Common pitfalls

• Trying to add features like extrudes inside an assembly. You cannot — features belong to part studios.
• Leaving multiple instances fixed to ground. Only one thing can be “the frame,” everything else is mated to it.
• Inserting parts by drag-and-drop from a search box and accidentally bringing in the wrong revision. Always use the Insert dialogue for intentional work.
• Forgetting to save. OnShape persists to the cloud, but assembly state transitions happen in memory until you save.

Where this points next

Next up: L3.2 — Mate Types and When to Use Each. The mates themselves — fastened, revolute, slider — that make an assembly actually move.

Objective

Look at any VEX subsystem and immediately name the correct OnShape mate for each connection — fastened for bolted structure, revolute for rotating joints, slider for pneumatic pistons, and a handful of edge cases — and apply each correctly in an assembly.

Concept

A mate is a rule about how two instances are allowed to move relative to each other. Pick the wrong mate and your assembly either cannot move at all or moves in ways that are nothing like the real robot. Either failure makes the whole assembly worthless as a planning tool — you cannot check range of motion on a model that does not move, and you cannot check interference on a model that moves wrong. Getting mates right is the difference between a 3D model that earns its keep and a 3D picture that looks pretty and teaches nothing.

OnShape exposes several mate types; four of them will cover roughly 95 per cent of what a VEX team ever needs:

📐 Engineering tip. The discipline of picking the right mate is identical to the discipline of picking the right sketch constraint: you are declaring, in machine-checkable form, what is supposed to be true. If the instance moves wrong after you add the mate, the mate is telling you something about the real connection you had not noticed.

Two more mate types exist and are worth knowing without memorising: Cylindrical (rotation plus translation along the same axis — rare in VEX) and Ball (pure three-axis rotation — almost never useful on a robot).

One more principle: mate in the same order as assembly. Fasten the frame together first. Revolute-mate wheels onto the frame second. Fasten gearboxes to the frame third. Add pneumatic sliders last. If you try to mate a wheel to a frame rail that itself is still floating, you will spend ten minutes chasing a ghost.

Guided practice

1. Open A_sandbox from L3.1. Delete its contents by selecting the instances in the panel and pressing Delete. You now have a clean assembly canvas.
2. Insert two C-channel parts from your Tier 2 part studio. The first will be fixed to ground automatically.
3. In the Mates panel, click the Fastened mate button (it looks like a padlock icon). A dialogue opens asking for two mate connectors. Click a hole on the first C-channel (OnShape snaps a mate connector to the hole centre), then click a matching hole on the second C-channel. Click the green tick. The two C-channels are now rigidly joined at that hole. Drag the floating end of the second C-channel; it will not move.
4. Insert a third part — a wheel, or a simple modelled cylinder if you do not yet have a wheel part. Click the Revolute mate button. For the first mate connector, click the axle hole of a C-channel. For the second, click the centre of the wheel’s hub. Click the green tick. Drag the wheel in the viewport; it should rotate cleanly about the axle axis and nothing else.
5. Click the Slider mate button. You will need two small rectangular test parts for this. For the slider mate’s first connector, pick the face of one block; for the second, pick the matching face of the other, with a shared axis. Click the tick. Drag; the blocks should slide along the shared axis and not rotate.
6. Click the Planar mate button. Insert a flat plate-like part. Pick its bottom face and a C-channel’s top face. The plate should now be able to slide around and rotate on top of the C-channel, but not lift off it.
7. Save the assembly. In the Mates panel on the left, each mate has an icon showing its type. Hover over each to confirm.
8. Your exit state: a single assembly A_sandbox containing at least one of each of the four primary mate types — Fastened, Revolute, Slider, Planar — each verified by dragging the dependent instance to confirm its degrees of freedom match the intended connection.

Independent exercise

Open a new assembly A_mate_quiz. Insert the parts needed to build a simple bolted frame (two C-channels and a crossbrace), one wheel, and one pneumatic piston. Apply the correct mate type for each connection without looking back at the guided practice. Then drag-test each connection. For every one that behaves wrong, fix the mate. Write down any mate you had to correct and why.

Common pitfalls

• Using Fastened for a joint that should rotate. The model will look correct and be useless for motion studies.
• Using Revolute with the wrong axis — picking a hole edge instead of a hole centre gives you rotation about a tangent line, not the centreline.
• Over-mating. Two revolute mates on the same wheel will either fight each other and fail to solve, or silently lock the wheel. One wheel, one revolute mate.
• Trying to make a gear mesh into a mate. OnShape has a Gear mate relation but it is not a primary mate — it is a relation between two existing Revolute mates. Build both revolutes first, then add the Gear relation.
• Picking mate connectors on parts that are still floating. The solver will pick a nonsense position. Always fix or fasten the parent before mating the child.

Where this points next

Next up: L3.3 — Assembling a Drivetrain. All four mates at work on a full drivetrain assembly, in the same order you would build the real robot.

Objective

Assemble a full tank drivetrain in OnShape in the same order you would build the real robot — frame first, then wheels, then gear train — with correct mates at every connection, an exposed gear ratio, and a model that moves the way the real drivetrain moves.

Concept

The doctrine of Chapter III L2.1 is “build the frame first.” That rule is not about build order for its own sake — it is about building from the most structurally anchored component outward, so that every subsequent piece has something rigid to mate against. The same rule applies exactly, without translation, to CAD: assemble the frame first, then mate the wheels to the frame, then mate the gear train to the wheels and frame, then mate the motors to the frame. If you try to shortcut that order — for example by inserting a motor and then trying to figure out where the frame should go around it — you will be redoing work within fifteen minutes.

🔧 Build tip. A drivetrain assembly must expose its gear ratio. If the model has a 72-tooth driven gear and a 48-tooth driving gear, the model should move such that the wheel rotates at 48/72 of the speed of the motor shaft. OnShape’s Gear mate relation does this for you, but only if you have revolute-mated the shaft and the wheel first. A drivetrain model that spins the wheels at the same speed as the motors is lying to you.

Once the drivetrain is assembled, you will rotate the wheels through a full revolution and watch for collisions. Catching a wheel-against-C-channel collision in CAD is worth ten catches on the real robot, because the real robot has already been drilled.

Guided practice

1. Open your team document. Click + in the tab bar and create a new assembly named A_drivetrain.
2. Frame first. Insert the two drivetrain frame rails (long C-channels) from your Tier 2 part studio. The first comes in fixed. Insert any crossbraces your design has. Using Fastened mates, lock every crossbrace to both frame rails at the correct hole positions — pull the hole positions directly from your S_drivetrain_footprint sketch in L1.2. Drag each rail after every mate; the frame should become progressively more rigid until dragging does nothing.
3. Verify the frame is square. Use the Measure tool (top-right toolbar) to measure the diagonal between opposite corners. Both diagonals should be equal. If they are not, one of your crossbrace mates used the wrong hole.
4. Wheels next. Insert the first wheel instance. Use a Revolute mate to attach it to the frame: click the centre of the wheel hub for the first connector, then click the centre of the corresponding axle hole in the frame rail for the second. The wheel should snap into position and rotate freely when you drag it.
5. Repeat for each wheel. Do not copy instances — insert each wheel separately so each gets its own mate.
6. Gears next. Insert the gears for your drive reduction. Mate each gear with a Revolute mate to whichever shaft it lives on. Then add the gear-meshing relationship: in the Mates panel, click the Gear relation button. Select the two revolute mates for a pair of meshing gears. Enter the tooth ratio — for example 48:72 — and apply. Drag one gear; the other should now rotate at the correct ratio.
7. Motors last. Insert each V5 Smart Motor. Use Fastened mates to lock each motor body to the frame at its correct mounting position. Then add a Revolute mate between the motor output shaft and the gear it drives, plus a Gear relation to tie the motor shaft to whatever it meshes with.
8. Drag-test. Grab any wheel and rotate it through a full revolution. Watch the gears spin. Watch the motor shafts spin. The entire drivetrain should move as one coupled system.
9. Run a quick visual interference pass. Rotate a wheel through a full revolution while watching for any visible overlap between the wheel and the frame, the wheel and a crossbrace, or two gears that should not be touching.
10. Save the assembly. Your exit state: a saved assembly named A_drivetrain containing the frame (fastened together), the wheels (revolute-mated to the frame), the gear train (revolute-mated with Gear relations exposing the correct ratio), and the motors (fastened to the frame with their shafts revolute-mated into the gear train).

Independent exercise

Copy A_drivetrain to A_drivetrain_alt (right-click the assembly tab → Duplicate). In the copy, change the gear ratio by swapping one gear pair — for example, change a 48:72 reduction to a 36:84 reduction. Update the Gear relation tooth values. Drag-test to confirm the new ratio behaves correctly. Then answer, in writing: does the new gearing still fit in the space your original sketch allowed? If not, which sketch dimension would you have to change first?

Common pitfalls

• Inserting wheels before the frame is fully fastened. The wheels will revolute-mate to a floating rail, which means the whole system wiggles.
• Forgetting to add the Gear relation. Revolute mates by themselves let the gears spin independently, which is wrong.
• Mating to hole edges instead of hole centres. Hover until OnShape snaps the mate connector to the centre point.
• Using a single wheel instance copied four times. If one wheel is supposed to be slightly different, copies will hide the difference.
• Treating the drivetrain as a throwaway sandbox. This assembly is the foundation for the robot-level assembly you build next.

Where this points next

Next up: L3.4 — Assembling a Mechanism with Motion. The same principles, applied to a four-bar lift where revolute mates at every joint let you animate the full range of motion.

Objective

Assemble a four-bar lift in OnShape with correct revolute mates at every joint, animate its full range of motion, and verify the motion against the sketches you produced in Tier 1.

Concept

A drivetrain has exactly one degree of freedom per wheel, and all those degrees of freedom are simple rotations. A lift is harder, because a lift is a linkage — four rigid bars connected at four pivots, where the motion of any one joint determines the motion of every other joint. The classic four-bar lift is the canonical example: two parallel input arms pivot about the frame, and their far ends support an output link that carries the end effector. If all four mates are correct, raising the input arms raises the end effector along a translated path that stays parallel to the frame.

📐 Engineering tip. If any of the four revolute mates is wrong — wrong axis, wrong hole, wrong part — the linkage will either lock up completely (over-constrained) or flop in a way that no real four-bar ever could (under-constrained). A four-bar is an unforgiving test of whether you picked your mates correctly, which is exactly why it is the right next lesson after L3.3.

A working four-bar assembly also lets you check range of motion against the sketches you produced in L1.3. You sketched the mechanism at its start, intake, carry, and score states. You can now drag the assembly through the same states and verify, in 3D this time, that your sketch was right. If it is, you have cross-validated your planning sketch against a moving model. If it is not, one of them is wrong and you need to find out which.

Guided practice

1. Create a new assembly named A_fourbar in your document.
2. Insert the frame rail that will carry the four-bar pivots. This comes in fixed.
3. Insert the two input arms — the bars that pivot on the frame. Use a Revolute mate for each, connecting the pivot hole of the arm to the pivot hole on the frame rail. Both arms should now rotate freely.
4. Drag one input arm. The other will not follow yet, because they are not yet linked. That is expected.
5. Insert the output link — the bar that connects the tips of the two input arms. Apply two Revolute mates: one between the output link’s first hole and the first input arm’s tip hole, one between the output link’s second hole and the second input arm’s tip hole.
6. Drag one input arm now. The second arm should follow, driven by the output link. The output link itself should stay parallel to the frame rail as the arms rotate. This is the defining behaviour of a parallelogram four-bar — if your output link tips or tilts, one of the mates is wrong or the bar lengths are mismatched.
7. Insert the end effector — a modelled plate, hook, or intake stub. Fasten it to the output link with a Fastened mate.
8. Drag the linkage through its full intended range of motion. Watch the end effector move.
9. Animate. In the Mates panel, right-click the revolute mate on one input arm and choose Animate Mate. Set a range (start angle to end angle) and a duration. Play the animation.
10. Open your S_mechanism_vs_object_* sketches from L1.3 and compare. At the intake state, is the end effector at the same height above the field that your sketch predicted? At the score state? If the numbers disagree by more than half an inch, find the discrepancy and fix whichever representation is wrong.
11. Save the assembly. Your exit state: a saved assembly A_fourbar whose animated motion matches your L1.3 planning sketches at every sampled state.

Independent exercise

Copy A_fourbar to A_fourbar_alt. Change the length of the input arms by 20 per cent — either by editing the part in its part studio or by inserting a different arm part. Without touching the mates, re-animate. Record how the output path changes. Was the path still parallelogram, or did it tip? Why?

Common pitfalls

• Mating the output link to only one input arm. Without the second revolute mate, the linkage has a free degree of freedom.
• Mating the output link rigidly (Fastened) to the input arms instead of revolute. A fastened output link cannot rotate relative to the arms — the whole linkage locks.
• Mismatched input arm lengths. A parallelogram four-bar needs both input arms to be the same length.
• Forgetting to animate. Dragging by hand is not the same as playing an animation — animation will reveal mate jitter and solver failures that hand-dragging hides.
• Not cross-checking against the Tier 1 sketches. The assembly is supposed to confirm the sketch, not replace it.

Where this points next

Next up: L3.5 — Interference Checks. OnShape’s interference detection tool, which catches collisions you could not see by dragging.

Objective

Run OnShape’s built-in interference detection on any assembly, interpret the results, and decide whether each reported interference requires a redesign, an adjustment, or (rarely) acceptance.

Concept

An interference is any place where two parts occupy the same physical space at the same time. In the CAD model, OnShape will happily let this happen — it will show you two solid bodies overlapping as if they passed through each other. In reality, matter does not cooperate. A wheel that overlaps a frame rail by a sixteenth of an inch in CAD is a wheel that will not fit in the physical robot.

📐 Engineering tip. The human eye misses most interferences. Dragging an assembly by hand catches the large and obvious cases but will not catch, say, a screw shank overlapping a bearing bore by twenty thousandths of an inch — which is exactly the kind of problem that causes a wheel to bind. OnShape’s dedicated Interference Detection tool checks every pair of solid bodies and reports every overlap, regardless of how small.

The workflow is simple: run the check, read the list, fix each reported item, run again, repeat until the list is empty. What matters is how you triage the list. Three categories: adjust (move a part by a small amount), redesign (the mechanism as conceived is not geometrically possible), and accept (the “interference” is a modelling artefact like a bolt thread technically overlapping a tapped hole). Accepts should be rare.

Interference checks are cheap to run and expensive to skip. Catching a wheel-against-crossbrace collision in CAD costs a minute. Catching the same collision on a built robot costs a practice session, a drilled hole in the wrong place, and potentially a replacement C-channel.

Guided practice

1. Open A_drivetrain from L3.3.
2. In the top toolbar of the assembly workspace, find the Analysis menu (sometimes called the Evaluate menu) and select Interference. A dialogue panel opens on the right.
3. In the Interference panel, leave “All bodies” selected and click the green tick / compute button. OnShape will compute overlaps between every pair of instances.
4. Read the list. Every entry is a pair of instances and a volume of overlap. Click the first entry. The viewport will zoom to and highlight the interference.
5. Diagnose. For each reported interference, decide which category it belongs to — adjust, redesign, or accept.
6. Fix the first real interference. For an adjust, go back to the part studio, find the sketch that drives the hole position, and edit the dimension. Return to the assembly — the instance will have updated. Re-run the interference check.
7. Repeat until the interference list is empty or contains only accepts.
8. Now repeat the whole process on A_fourbar from L3.4. Because the four-bar moves, interferences can be state-dependent — something that does not overlap at rest might overlap at the top of the arm’s travel. Drag the mechanism to a mid-range state and run the check again. Then drag to the top of travel and run again.
9. Save both assemblies once their interference lists are clean.
10. Your exit state: two assemblies — A_drivetrain and A_fourbar — both passing a clean interference check in at least three positions of their range of motion.

Independent exercise

Pick any assembly in your document. Deliberately introduce an interference by editing one part in its part studio — make a frame rail slightly too wide, or move a hole by half an inch. Re-run the interference check and confirm that OnShape catches the defect. Then fix it. This exercise builds trust in the tool: you want to see it catch a known problem before you rely on it to catch an unknown one.

Common pitfalls

• Running interference detection once and trusting the result for ever. Any time you edit a part or a mate, re-run the check.
• Running interference detection only in the rest state on a moving mechanism. Most real interferences live at the endpoints of travel, not at rest.
• Accepting interferences that are actually real because the list is long and you are tired.
• Missing interferences between a newly-inserted part and an existing one because you only checked “against selected” — always run against all bodies.
• Not documenting the accepts. An accepted interference without a note will be re-flagged next week.

Where this points next

Next up: L4.1 — Drawings a Builder Can Actually Use. Tier 4 begins. The now-validated assembly becomes the source of dimensioned drawings a build team can actually work from.

Objective

Produce a dimensioned 2D drawing of any VEX part from a 3D OnShape model, with correct views, correct dimensions, correct tolerances (±0.03125″ minimum), and enough information that a teammate with no access to the model can fabricate the part from the drawing alone.

Concept

A 3D model is not a build artefact. A builder at the band saw cannot read a solid body. A builder can read a 2D drawing: a set of orthographic views with dimensions, tolerances, and notes. The drawing is the handoff — the moment the CAD leaves the designer’s screen and becomes a real piece of metal or plastic.

🔧 Build tip. A drawing must have enough views that every feature is seen at least once. A drawing must have every dimension the builder needs to cut the part, and no dimensions that are redundant or misleading. A drawing must specify tolerances — at least ±0.03125″ (1/32″) between moving parts. And a drawing must be named in a way that matches the part it describes.

The standard view layout is three orthographic views — front, top, right — plus an isometric for visual reference. Front view shows the part’s largest profile. Top view shows how the part lays on a table. Right view shows the third dimension. Isometric is there so the builder can orient the part in their hand before they start measuring. Dimensions go on whichever view shows the feature most clearly — a hole is dimensioned in whichever view shows it as a circle, not an edge.

The last principle is that drawings and models must stay linked. OnShape’s drawings are live — they update when the part updates. Produce the drawing once, keep the association, and when the part changes the drawing follows. If you ever find yourself manually editing numbers on a drawing to match a part change, stop — you are about to hand a stale drawing to a builder.

Guided practice

1. Open a part studio with a real part in it. PS_sensor_plate from L2.3 is a clean starting example.
2. In the tab bar at the bottom, click + and select Create Drawing. OnShape prompts you to pick a template. Choose a standard letter-size (or A4) template for now.
3. The drawing workspace opens. A View Insert dialogue appears automatically. Select the part from the part studio. OnShape offers preset view arrangements — pick “Front, Top, Right + Iso.” Four views land on the sheet.
4. Reposition the views if they overlap. Click a view’s border to select, then drag to move.
5. Click the Dimension tool in the top toolbar. Click two edges, two vertices, or a circle’s edge — OnShape adds the appropriate dimension. Work through the part methodically: overall length, overall width, thickness, every hole diameter, every hole position. Do not dimension anything twice in different views.
6. In the title block at the bottom-right corner of the sheet, fill in: part name (PS_sensor_plate), revision (A), your name, date, material (Polycarbonate, 0.125″), and default tolerance (±0.03125″).
7. Add a note block above the title if the part has special callouts — for example, “Holes to match VEX half-inch grid.” Use the Note tool.
8. Check the drawing: every feature shown at least once, every dimension present, tolerances stamped, title block filled. Use the print preview to see how it will look on paper.
9. Save the drawing. It lives in the document as its own tab. Name the tab DWG_sensor_plate_A.
10. Now demonstrate the live link. Open the part studio and change plate_length from 2.5 in to 3.0 in. Return to the drawing tab. Every dimension and every view has updated automatically.
11. Your exit state: a saved drawing tab named DWG_sensor_plate_A containing front, top, right, and isometric views; every dimension a builder would need; a filled-in title block with a default tolerance of ±0.03125″; and a confirmed live link to the part studio.

Independent exercise

Create a dimensioned drawing for the C-channel you built in L2.2. This is harder because the C-channel has two different flanges and a web, and you will need to decide which view shows which hole pattern. Name the drawing DWG_c_channel_A. When you are done, show it to a teammate who has never seen the part and ask them to describe what they would do if asked to fabricate it. If they can, your drawing worked.

Common pitfalls

• Dimensioning the same feature in multiple views. Redundant dimensions confuse the builder and create inconsistencies when the part changes.
• Missing the isometric. The iso is there for spatial orientation, not measurement — leaving it off forces the builder to mentally rotate three views.
• Forgetting to fill in the title block. A drawing without material and tolerance is a drawing the builder has to come ask you about.
• Dimensioning to a visual edge that is not actually a feature. Dimension to real geometry only: hole centres, face edges, clearly-defined vertices.
• Manually retyping dimension values to “clean them up.” You have broken the live link. The drawing is now a lie the moment the part changes again.

Where this points next

Next up: L4.2 — Exporting for CNC and Laser. The flat-file handoff — DXF export for parts that go to a machine instead of a human with a band saw.

Objective

Export a flat plastic part from OnShape as a DXF file, verify the export in a DXF viewer, apply a consistent file-naming convention, and hand the file off to a laser cutter or CNC router with zero ambiguity about what is being cut.

Concept

Plastic parts go to a machine, not a band saw. The machine reads a DXF file — a 2D vector file that describes the cut profile as closed paths. Your job in this tutorial is to take the 3D plate from L2.3, extract the flat profile, export it as a DXF, and verify that the DXF says exactly what you intended. The verification step is not optional. A DXF that opens with a missing hole or a broken outer loop will produce a broken part, and the operator will not necessarily catch it before the machine runs.

📐 Engineering tip. The cleanest DXF workflow in OnShape is through a drawing. You produce a drawing with a single top-down view of the part, suppress dimensions and borders, and export the drawing as a DXF. Alternatively, you can export a sketch directly, but the sketch-export path sometimes includes construction lines or stray reference geometry. Drawing-based export is the disciplined default.

Naming is its own discipline. A DXF on a shared drive is useless if the operator cannot tell what it is from the filename alone. Use a convention like <team>_<subsystem>_<part>_<rev>_<material>_<thickness>.dxf. The operator should be able to read the filename and know which team sent it, what subsystem it belongs to, what part it is, what revision, what material to stock, and what thickness. Save the convention in your team handbook and never deviate from it.

One last sanity check: open every DXF you export in a separate DXF viewer before you send it. Many free viewers are available (LibreCAD, eDrawings, online DXF viewers). The viewer tells you what the machine will see, which is not always what OnShape showed you.

Guided practice

1. Open PS_sensor_plate from L2.3. Confirm the part is current and the material is set to polycarbonate.
2. Create a drawing for the part if you did not in L4.1. For DXF export, the drawing only needs a single top-down view. Create a new drawing DWG_sensor_plate_DXF.
3. Insert a single Top view of the part — no other views, no dimensions, no title block (or a minimal one that will be ignored on export).
4. Click File → Export (or the Export button in the drawing toolbar). Choose DXF as the format. Select which view to export — pick the top view. For units, pick inches to match VEX conventions.
5. Choose where to save. Name the file with your convention: <team>_<subsystem>_sensor_plate_A_polycarb_125.dxf.
6. Click Export. The DXF downloads.
7. Open the DXF in a free viewer. Check: is the outer profile a single closed loop? Are all four mounting holes present as closed circles? Are the two sensor holes present? Are there any stray lines outside the part?
8. If the viewer shows a problem, go back to OnShape and find the cause. Common causes: construction lines in the source sketch that leaked into the drawing, or a second sketch that was accidentally visible in the view.
9. Once the DXF is clean, save it to the team’s shared drive under the canonical folder. Send the operator a short message including: filename, material, thickness, quantity, due date.
10. Your exit state: a clean DXF file named per the convention, verified in a DXF viewer, saved to the team shared drive, with a handoff message sent to the operator specifying material, thickness, and quantity.

Independent exercise

Export a DXF for the axle sandwich plate from the L2.3 independent exercise. Use the same workflow. Before sending, open the DXF in a viewer and look for at least one thing that is not quite what you expected. Fix it. Send.

Common pitfalls

• Skipping the viewer check. An unverified DXF is a DXF you are about to hand a machine that does not understand hesitation.
• Exporting from a sketch instead of from a drawing, and catching construction lines in the export.
• Naming DXFs with generic names. plate.dxf will cost you a part. Use the convention every time.
• Forgetting to confirm the units. OnShape can export in mm or inches. A mm-exported part loaded into an inch-expecting laser will be 25.4 times too small.
• Leaving the title block on the drawing before DXF export. Title blocks become vector lines in the DXF and will be cut as part of the profile.

Where this points next

Next up: L4.3 — Iterative CAD and Build Loops. What you do after the part comes back from the machine, and how to update the CAD to reflect the real physical part.

Objective

Run a CAD-build-measure-update loop on any physical part: build from the CAD, measure the real result with callipers, compare to the model, and update the model so that the CAD matches reality within your measurement tolerance.

Concept

CAD cannot predict reality. It predicts an ideal. The part the machine produces is close to the ideal but never identical, and the robot built from those parts has accumulated error from every cut, every bent C-channel, every slightly-off drill. A CAD model that does not get updated to reflect reality drifts from the real robot, and the longer the drift goes on, the less useful the model is. At the extreme, a CAD model that does not match the real robot is worse than no CAD model at all, because the team will trust it and make decisions from it.

🔧 Build tip. The discipline is a loop. You build a part from CAD. You measure the real result. You compare the real measurements to the model. Where they disagree, you update the model. The loop runs every time you build something non-trivial — custom plastic plates, cut-down C-channels, anything where your CAD specified a dimension and the shop tried to hit it.

Callipers are the core tool. Digital callipers cost almost nothing and read to 0.001 inches, which is finer than you need for VEX. Use them. Measure the part in at least two places (to catch asymmetry) and measure it against the dimension you specified on the drawing — not a random edge.

One more principle: when the real part disagrees with the CAD, it is not automatically the CAD that is wrong. Sometimes the machine produced a bad part and the correct action is to recut, not to change the model. Sometimes the model was optimistic about a tolerance the shop cannot actually hit, and the correct action is to loosen the CAD. Knowing which it is requires comparing multiple parts from the same CAD — if all five parts are wrong in the same direction, the model is wrong; if one is wrong and four are right, the machine had a bad day.

Guided practice

1. Pick a real part your team has recently built from CAD. A plastic plate from L2.3 is ideal, but a cut-to-length C-channel works too.
2. With digital callipers, measure the following: every dimension you listed on the drawing from L4.1 or L4.2. Record each measurement next to the nominal CAD dimension in a small table. Example: plate_length nominal 2.500 actual 2.487.
3. For each dimension, compute the delta (actual − nominal). Flag any delta larger than your shop’s typical tolerance — for most VEX shops this is about ±0.010 inches for laser-cut plastic, ±0.020 inches for hand-cut metal.
4. For each flagged delta, diagnose. Is the CAD wrong (the model specified something the machine cannot hit)? Is the machine wrong (a one-time error)? Or is the tolerance too tight (the CAD should allow more slop)? Measure a second identical part if you have one.
5. Update the CAD. Open the part studio. Find the feature that drives the out-of-spec dimension. Either change the nominal (if the CAD was wrong) or change a tolerance note on the drawing (if the model is fine but the drawing demanded too much precision). Save.
6. Re-run the assembly. If this part is used in A_drivetrain or A_fourbar, open the assembly and confirm it still solves. If interferences appear because the updated part is now slightly different, run L3.5’s interference check and fix.
7. Document the change. In the Feature tree, add a note on the modified feature: “Updated <date> to match as-built measurement 2.487”. Future-you will want to know why the dimension changed.
8. Your exit state: a measurement table comparing nominal CAD dimensions to as-built actuals for at least one real part; an updated part studio where any out-of-spec dimensions have been either corrected or re-toleranced; a dated note on each edited feature explaining the change.

Independent exercise

Pick an entire subsystem that your team has built — drivetrain, lift, intake — and run the loop across every custom part in it. For each discrepancy, decide: update CAD, or fix the real part? Write your decision down.

Common pitfalls

• Measuring once and assuming the result is representative. Measure at least twice on different parts or different features.
• Updating the CAD without dating the change. Six weeks later, nobody will remember whether the model reflects reality or a hopeful guess.
• Updating variables instead of feature dimensions when the error is local. If only one part is off, do not change a document-level variable.
• Ignoring small deltas. A consistent 0.005-inch offset on every hole is a systemic machine error and worth flagging.
• Treating the CAD as authoritative after the build. Reality is authoritative. The CAD is trying to match reality, not the other way around.

Where this points next

Next up: L5.1 — CAD-First Design Reviews. Tier 5 begins. The CAD model becomes the artefact a team presents at a design review.

Objective

Walk a team through a design idea using the OnShape model as the primary artefact, following a structured presentation sequence — problem brief, sketches, alternatives considered, trade-offs, chosen design, feedback and next steps — and produce a reviewable CAD state that feeds Chapter VI notebook documentation.

Concept

A design review is the moment where a team presents a proposed design to peers, mentors, or other teams, and defends the decisions they have made. In a healthy club, design reviews happen on a schedule — roughly once per sprint, or every three to four weeks. The structure has five beats: problem brief, review of brainstormed ideas, design matrix summary, proposed solution, feedback and next steps.

The core mistake most teams make in a design review is presenting “everything we did this week.” That is a status update, not a design review. A design review presents decisions: what we are proposing, why we considered alternatives, what we rejected, and why. The CAD model is not the deliverable of the review — the decision is. The CAD is the evidence that the decision was made with eyes open.

📐 Engineering tip. The CAD state you want at review time has three layers. First, the Tier 1 sketches — the three-version study from L1.5 that shows the alternatives you considered. The archived _ARCHIVED_ versions are not an embarrassment; they are the record that you explored the space before you committed. Second, the chosen design expressed as sketches, parts, and an assembly. Third, the interference check results from L3.5, because a design you have not verified is a design you cannot defend.

The presentation runs in a strict sequence. Start with the problem brief — one or two sentences. Then show the _ARCHIVED_ sketches from the three-version study; for each, state in one sentence what it was and why it lost. Then show the chosen sketch and explain why it won. Then show the chosen part studio and assembly. Then show the interference-clean state. Then stop talking and take feedback. Total speaking time should be ten to fifteen minutes, including questions.

The outputs of a design review feed directly into Chapter VI (Engineering Notebook). The notebook entry for the review records the problem brief, the alternatives, the decision, the feedback received, and the next-step commitments. The CAD is referenced from that notebook entry with a specific version (OnShape has named versions — create one before the review and reference it by name).

Guided practice

1. Pick a recent design decision your team has made or is about to make. The mechanism you did the three-version study on in L1.5 is ideal.
2. In OnShape, open the document. Click the Version Graph button (bottom-left, looks like a branching icon). Create a new version with the name review_<date>_<mechanism>. This freezes the current state so you can reference it even if someone edits the document tomorrow.
3. Open a blank presentation template. The deck needs exactly six slides: problem brief, alternatives considered, decision matrix summary, chosen design, verification evidence, feedback and next steps.
4. Problem brief slide. One or two sentences. “We need an intake that can admit the generic game object at field-floor height and carry it to our existing conveyor at a height of 8 inches.” No more.
5. Alternatives considered slide. Take screenshots of your three _ARCHIVED_ sketches from L1.5 and drop them on the slide side by side. One-sentence label under each.
6. Design matrix summary slide. The table from L1.5, cleaned up. Rows: range of motion, clearance, parts count, buildability, risk. Columns: v1, v2, v3. The winning column highlighted.
7. Chosen design slide. Screenshots from OnShape of the S_<mechanism>_CHOSEN sketch, the part studio, and the assembly. Describe what you are looking at in one sentence each.
8. Verification evidence slide. Screenshot of the interference check results from L3.5 showing a clean pass. Screenshot of the animation from L3.4 showing the mechanism at start, mid, and end states. This is where you prove the design is geometrically possible, not just imagined.
9. Feedback and next steps slide. This slide is empty at the start of the review. You will fill it in during the meeting. Leave space for five or six bullets.
10. Run the review. Present in the order of the slides. Keep to time. When you finish presenting, stop talking and write down the feedback. Turn feedback into concrete commitments — not “we’ll look into it” but “we will re-sketch v2 with the revised pivot location by Friday.”
11. After the review, update your Engineering Notebook (Chapter VI) with the problem brief, the alternatives, the decision, and the feedback. Reference the OnShape version by name.
12. Your exit state: a named OnShape version review_<date>_<mechanism>, a six-slide design review deck completed through slide 5, a filled-in slide 6 produced during the meeting, and a notebook entry referencing both.

Independent exercise

Run a peer-to-peer review with another team in your club. Present your design to them using the same six-slide structure. Then listen to theirs and give feedback using the same structure. Both teams should leave the meeting with written next steps. Record, in your own notebook, one piece of feedback you received that you would not have noticed on your own.

Common pitfalls

• Presenting everything you did this week instead of the decision you are asking to be reviewed. A review is not a status report.
• Hiding the _ARCHIVED_ sketches. They are evidence of rigour, not embarrassment. Show them.
• Skipping verification. A design without interference-check evidence is a design you are asking the reviewers to trust blindly.
• Running long. Fifteen minutes maximum, including questions. Longer reviews lose focus and produce worse feedback.
• Not creating a named version before the meeting. The moment a teammate edits the document, the review references something that no longer exists.

Where this points next

Next up: L5.2 — CAD as a Weight-Optimisation Tool. Using the same CAD state to find metal that is not doing structural work and removing it.

Objective

Use OnShape’s mass evaluation tools to measure the weight of any part or assembly, identify metal that is not doing structural work, remove it, and verify through re-measurement and interference-checking that the lighter design still solves its original problem.

Concept

Early-season robots are heavy because the designers were focused on making the thing work at all. Mid-season robots get lighter because designers go back and ask, of every piece of metal on the robot, does this piece do structural work? If the answer is no, it goes. If the answer is “barely,” you measure how much it is saving, and you decide whether that much savings is worth the weight.

🔧 Build tip. This is not the same as overbracing. Chapter III L2.5 teaches you when you need more bracing, not less — and the answer there is “when flex is hurting you.” This lesson is the other half of the same idea: when flex is not hurting you, the extra metal is weight for no reason. A disciplined team applies both lessons together. You brace where it matters. You remove metal where it does not.

OnShape measures mass directly. Every part with an assigned material produces a real mass number. The Mass Properties tool sums mass across any selection — a single part, an assembly, the whole robot. You use it in a simple loop: measure the current mass, pick a candidate for removal, remove it, re-measure, re-check interference, repeat. Keep a running log of what you removed and what you saved. The log feeds your notebook.

The hardest part is the discipline of not guessing. You will be tempted to add pocket-holes and lightening-patterns into a part because they “look like weight savings.” Measure first. A 0.25-inch diameter hole in a 2-inch plate saves a gram. A 1-inch diameter pocket in the same plate saves an order of magnitude more. The numbers tell you where to focus.

Guided practice

1. Open your drivetrain assembly A_drivetrain from L3.3. Confirm every part in it has a material assigned — if any part is missing a material, the mass number will be wrong. Fix missing materials first.
2. In the top toolbar, open Analysis → Mass Properties. A panel opens showing the total mass of the assembly. Record the number as your baseline: baseline_mass = X lbs.
3. Pick one candidate for optimisation. Start with a crossbrace — crossbraces are often overbuilt. Right-click the part in the assembly and choose Open Part Studio; the part studio opens in a new tab.
4. Look at the crossbrace. Ask: is every hole in this part carrying a fastener? Is the full length necessary? Could a shorter piece do the same structural job? Would a 1×1 L-channel do what this 2×1 C-channel is doing today?
5. Make a concrete edit. Either shorten the crossbrace, swap it for a lighter stock shape, or — if genuinely redundant — delete it entirely in the assembly.
6. Return to the assembly. The instance updates. Re-run Mass Properties. Record: after_mass = Y lbs, delta = Y − X.
7. Re-run the interference check from L3.5. Removing metal should not have created new interferences, but an aggressive edit might have.
8. Re-run the animation from L3.4 if the modified part touches a moving mechanism. Confirm motion still works.
9. Decide: keep the change, or revert? If the savings are real and the design is still sound, keep. If interference appeared or motion broke, revert and try a different candidate.
10. Repeat steps 3–9 for at least three more candidates. Keep a running log in a notebook entry: candidate, savings, kept or reverted, reason.
11. Save the assembly under a new name — A_drivetrain_light — so the original is preserved and you can compare.
12. Your exit state: two saved assemblies — A_drivetrain unchanged and A_drivetrain_light with at least three weight edits applied — a measured delta in total mass between them, and a written log of each edit and its savings.

Independent exercise

Pick a completely different subsystem — a lift, an arm, a superstructure tower. Run the same loop: measure, identify candidates, edit, re-measure, verify, log. Aim to save at least 5 per cent of the subsystem’s mass without creating interference or breaking motion. Write down the three biggest single savings.

Common pitfalls

• Optimising parts that do not have materials assigned. Mass numbers will be zero and you will “save” weight that was never there.
• Removing metal that was holding a subsystem square. If you delete a crossbrace and the frame diagonal measurements change, you just introduced a new problem.
• Guessing at savings instead of measuring. Use the mass properties tool before and after every edit.
• Optimising too early. The first-build version of a robot does not need weight optimisation. Save this tutorial for mid-to-late season.
• Overwriting the original assembly. Always save the optimised version under a new name until the team agrees the optimisation is sound.

Where this points next

Next up: L5.3 — CAD for Range-of-Motion Validation. The final check — a full range-of-motion validation on every moving subsystem before the robot is committed.

Objective

Run a full range-of-motion validation on any moving subsystem: animate the mechanism through its complete travel, check the sizing-box limits at every state, check for self-collisions, and produce a checklist-backed artefact that proves the subsystem is geometrically legal and mechanically sound before the real robot is committed.

Concept

A range-of-motion validation is the last check before a design is frozen. You have sketched. You have built parts. You have assembled. You have run interference checks at a handful of states. You have even optimised for weight. Now you verify that the mechanism does what it is supposed to do at every point in its travel, not just the endpoints — because a design that is geometrically legal at rest and at maximum extension can still hit a rules violation or a self-collision somewhere in the middle.

📐 Engineering tip. The checks are mechanical and boring, which is the point. A checklist is more reliable than your instinct. The checklist for any moving subsystem: (1) full range of motion sweeps cleanly; (2) at every state, the mechanism stays inside the current season’s sizing constraint; (3) at every state, no part intersects any other part; (4) at every working state, the end effector can do its job against the relevant game object; (5) the forces are in reasonable directions at every working state.

You can automate some of this. OnShape’s animation feature from L3.4 will drive a mate through a range, and you can run interference detection at any point in that range. A more thorough check samples the mechanism at ten positions across its travel and runs interference at each. Ten is enough to catch state-dependent problems. Five is not.

The validation is the input to the notebook and to the design review. If you cannot check every item on the checklist green, the mechanism is not ready to be built. If you can, you have a defensible claim that the design works. The checklist is the artefact that the notebook refers to and that the team cites when someone asks “how do you know this works?”

Guided practice

1. Open the assembly you most want to validate — A_fourbar from L3.4 is the canonical example. If your team has a different mechanism ready, use that.
2. Open a new entry in your notebook or a new text file titled validation_<mechanism>_<date>. Create a five-row checklist: Full range. Sizing box at every state. Self-collision at every state. End effector position. Force directions.
3. Full range check. In the assembly, right-click the driving mate and choose Animate Mate. Set start to the mechanism’s rest position and end to its maximum extension. Play the animation. The motion should be smooth, monotonic, and without jumps or solver errors. If it plays cleanly, check the first box.
4. Sizing box check. This requires a sizing-box reference in the assembly. If you do not already have one, insert a rectangular prism part whose dimensions equal your current season’s starting-size envelope, fasten it to the frame at the appropriate origin, and set its visual style to translucent. Now drag the mechanism through its full range and watch whether any part exits the translucent box at any state. Check the second box only if the mechanism stays inside at every state.
5. Self-collision check. Sample ten positions across the full travel — start, 10%, 20%, ... 100%. At each sample, freeze the animation and run an Interference Detection pass (L3.5). Record any interferences found. Check the third box only if all ten samples are clean.
6. End effector position check. For the states that matter (start, intake, carry, score), verify the end effector is in a position that can actually do its job. Use the Measure tool to get the exact height of the end effector relative to the field floor at each state. Compare against the dimensions of the game object or field element. Check the fourth box only if every operational state is reachable.
7. Force direction check. At each working state, sketch a mental force vector — the direction the mechanism is pushing or pulling. Ask whether the drive (motor, piston) is oriented to deliver force in that direction efficiently. For pneumatic mechanisms, cross-reference your L1.4 pneumatic sketch. Check the fifth box only if the forces make sense.
8. Save the checklist with the assembly version named. Any unchecked box is a finding — write it in the checklist with the specific state or measurement that failed.
9. Your exit state: a saved, dated validation_<mechanism> checklist with five items evaluated, each either checked with supporting evidence or flagged with a specific failure state, plus a named OnShape version validation_<date>_<mechanism> capturing the assembly state at validation time.

Independent exercise

Run the same validation on a second mechanism. If your team has a drivetrain, a lift, and an intake, run all three. Compile the three checklists into a single subsystem readiness summary — the kind of artefact you would paste into a design review as the evidence for the verification slide from L5.1.

Common pitfalls

• Sampling only the endpoints. Most real failures live between 30% and 70% of travel.
• Skipping the sizing-box reference because “we know it fits.” The whole point of the check is that “we know” is not defensible evidence.
• Running the checklist in your head instead of on paper. Checklists only work when they are written down and ticked.
• Checking a box without evidence. If you cannot point at a measurement, an interference result, or a screenshot, the box is not checked.
• Treating the validation as a pass/fail gate with no gradations. A check that fails at 85% travel is different from one that fails at 15% — note where, not just whether.

Where this points next

This lesson closes the CAD strand. The student who has completed it can use CAD as a planning tool, a modelling tool, an assembly tool, a handoff tool, and a strategic validation tool. The next time a design question comes up, the answer is a sketch — and the sketch points back to L1.1.