The following is our public CAD and Code. We moved to OnShape this year to increase the accessibility of the CAD, and we feel it was a resounding success. Team members will answer any questions about the CAD and code.
The holes lead to groves/passageways that we shot hot glue into after assembly. Unlike the elbow joints of the elevator, these parts had to be assembled without glue then after final assembly, shot with glue.
The initial weight was 100ish lbs. we added 20lb. plate underneath the belly pan for stability.
Main changes from St. Joe to Worlds:
Larger/taller curved rack (we call it the “Hedgehog”).
Lots of little changes to the elbow gearboxes to make them more durable.
Added a camera on top of the elevator for better viewing of the April tags during auton.
Larger bevel gears in the end effector (the claw).
How did this change your CAD architecture? We are looking to switch to OnShape this upcoming year from Solidworks and I’ve been studying how many teams are using master sketches to drive the major geometry. Did you use this method or did you find something else worked better for your team? Do you have any advice for moving into that transition?
How do you generate the gear profiles to print (including the bevel gears)? Is this using OnShape?
What was being checked during this health check? Can you go into more detail on how it was being checked? (sorry not well versed enough in code to dig into it through GitHub)
It was very neat to dig into the CAD. Thank you for releasing these resources for teams to learn from.
Landon, hello! This is probably way too much info, but here goes -
With OnShape we were able to have multiple people working on the same sub system simultaneously. We started with master sketches to drive the robot architecture, and then each sub assembly got its own sketch. We did not do a great job updating the master sketch, and that created some problems when prototyping with unknown driving dimensions. It also allowed our students to get some CAD done when they had down time in school or at home, so that was cool. The biggest thing for me as a mentor was they could start cadding in minutes, not hours, and the barrier for entry computer wise is next to nothing. Next year, we plan to do some pair cadding in groups of 2 for sub assemblies.
The feedback we got from our kids with the CAD training is that the built in tutorials are not great. I will be doing some custom tutorials that are a little more involved and FRC relevant, similar to a few series that existed last year. If there is interest we can make these public, but there will be a lot of 2767-specific workflow things (carbon fiber, chromoly, etc.).
My advice is have one person owning the top assembly and working with each of the kids on adapting their design both to the actual robot (keeping prototypes moving as quick as possible) and to the overall architecture. Continuously changing the main sketches to know where everyone’s space claim is not an easy task.
Gear profiles were all from feature scripts this year. Feature scripts are amazing and a huge benefit to OnShape. We found a bevel gear pair feature script, and there is a built in spur gear one. We have drawn full involute profiles in the past, but we opted to give the feature scripts a try in the offseason and they have worked wonderfully. Occasionally we have to add greater than nominal backlash to make things run smoothly, but printing lets us iterate quickly there.
I will let one of our programming students speak to the health check as I am not involved in that side of things.
Definitely not too much info - thank you. The subassembly sketches were not derived or linked to the master sketch then? I can understand that people changing the main for all kinds of different reasons could cause interference problems if not careful. Did you have everything in one document in folders to organize or separate documents linked together? I’m still getting used to the Part Studios and document setup.
Sub assembly sketches were not derived. They likely will not be this coming year either, as we want one person driving the main assembly and no possibility of the sub assembly people changing something without visibility of the impact to the main assembly.
Part studios and assemblies were a huge adjustment for the mentors (I freely admit it took me four times to get from “I want to learn OnShape” to “I actually want to use OnShape”), but the students understood the workflow from the beginning. I think it is intuitive if OnShape is your first time learning CAD, but for those of us who have experienced other CAD systems it is akin to a new language of code, and there are bumps in the road.
What we did and will continue to do is each sub assembly got a separate folder and its own separate document. The first tab was the top level assembly, and we tried to standardize assemblies went before part studios. The part studios with multiple parts were like that because they referenced geometry of related parts.
You can do in context modeling, but you have to remember to update the context, which we found was not intuitive given everything else auto saves. If parts reference each other we just stuck them into the same part studio to avoid that. Parts like gears and pulleys got their own part studios. We did not use folders much, but we are trialing them on our off season project now.
When we had multiple intakes going simultaneously, we had all of them in different documents in our intake folder. We also utilized the version tree “branch” when we deviated from the document significantly. Comments on different versions was something helpful when we were mindful enough to do it, as otherwise you find yourself combing through versions trying to find the old version of something.
All of the driving is driver control but there is stick limiting in picking up and placing pieces. As for the mechanisms, most of them are sequenced and automated. However, it falls on the drive team to start the sequences. There are manual controls in case of failure to fall back on. As for set points, on our elevator we have 24 setpoints with around half of those being used for sequences and the other half is the final setpoint. The elbow on the arm has 25 setpoints with around 8 of those being used for sequencing. The hand on the arm has 9 setpoints. Finally, the shoulder has 20 setpoints with around 7 of those being used for sequencing.
Honestly it’s not as bad as you may think vs mechanically equivalent cots or putting the work in to subtractive based methods. Not the cheapest option, that’s for sure, but there is something to be said for understanding the material and something else to be said for Onyx being part of/complementing a team aesthetic.
The pricy bit is the printer, but that’s really not a lot different than a tricked out cnc router. One time costs and don’t “count” towards the robot.
I don’t want this to devolve into a onshaped thread, but I want to see that I was told by a senior student last year to never use context because of how confusing it is. If it is done right it can be amazing but with so many CADers it becomes inevitable that there will be problems.
I personally never use context for designing parts for the robot. The two times I have ever used context is when making a mini model last year’s and this year’s of the robots.
For healthchecks we run each axis of the robot open-loop and record current and velocity. The goal of this testing is find failures before they affect matches. For example, in 2022 we found additional friction building up in our turret before it got to the point where it affected any performance under closed loop control in matches.
Once the command finishes running and recording each axis, we are able to open the results in a jupyter notebook or pull up historical data for comparison. Here are a few example pictures from this season