I frequently talk about the importance of prototyping. A prototype is anything which helps a designer learn about the problem they’re trying to solve, or about a potential solution to that problem. In FRC many of the prototypes we build are physical mockups of robot systems. However, for years I’ve talked about the importance of using CAD for prototypes. This is partially because I’m not a very skilled craftsman, and struggle to put together anything “in real life” which will actually work. It is also partially because as most designers know, CAD can be a powerful tool for systems integration!
In the early stages of the FRC season I love to do something I often call “Crayola CAD” to prototype mechanisms.
Crayola CAD vs. Layout Sketches
When I talk about “Crayola CAD” I’m talking about drawing crude 3D parts in SOLIDWORKS to test out how designs will fit together. You can mate these crude parts together to simulate how they’ll move or slide or pivot. You can see how they’ll “fit” with game objects and field objects.
I call it Crayola CAD because I’m thinking about “my first scissors” I had as a little kid. They were like real scissors, but more crude and colorful.
Fun Fact, I’ve used the phrase “Crayola CAD” in professional work situations several times without thinking and caused some major confusion as a result.
Other designers do similar work in 2D Layout sketches, I do things this way also - but sometimes I like seeing it in 3D. I like to drag the parts around and “feel” how they fit together. I also think this makes for more intuitive screenshots when I’m trying to communicate over Slack with the rest of the team what the heck is going on inside my head during the systems integration discussions.
To help illustrate the various ways 148 has used CAD for prototyping in the past, I’m going to share a few historical examples. Interesting to note, as subsystems are refined, sometimes they are added into the crude “Crayola” models. In some of these examples you can see full detailed sheet-metal systems next to big colorful linkages. I love how this organic evolution occurs!
2008 Day2 System Concepts
While no one would expect the 148 robot from 2008 to need any form of prototype CAD, building Tumbleweed wasn’t always the plan. Searching through some archives on the 148 server the other day I actually found the CAD mockups I made the day after kickoff, showing several different system concepts.
You can see, I was trying to see what configurations would grab that (giant) ball, reach high enough to put it on top of, or beyond the overpass bar, while still staying within the extension restrictions and starting height limit. Crude stuff, but taught me a lot. It’s fun to look at how some of these concepts mirror some “famous” real-world robots from that year.
2015 Before MFBR
In 2015 the concept of “2 robots” was discussed very early in our design process. (The Boss still talks about being on #OGteamGemini). However, we did explore lots of other alternatives before settling on Batman & Robin.
Meet Two-Face. This complicated gentlemen was able to build two 6-stacks simultaneously while parked at a loading station (it builds the back stack first, then the front stack). It is ridiculous, but we probably could have made it work. Thankfully the time-studies proved that the actual time spent driving to delivery a stack wasn’t the major source of lost time, and as such this robot fell into the graveyard of dead JVN designs. (We also realized it was a freaking aircraft-carrier of a robot, and would struggle to move around on the field).
Anyone who hates on the 2015 game needs to at least recognize how cool it is that concepts like these existed. Most games do not allow that kind of creativity. (JVN sad face.)
2016 Drivetrain Wheel Configuration
I have a lot of examples from 2016 - I guess during that game we did a lot of prototyping in CAD (or maybe I just did a better job saving screenshots). One major challenge was to determine the configuration of the wheels on our drivetrain.
Our goal was to climb over all the different obstacles. We wanted to do it without resorting to “drive fast, and jump over them dukes of hazard style”. We wanted to be able to go slowly, and ensure we had driven wheels in contact at all times during the crossing.
We drew crude versions of the obstacles and crude images of the drivetrains. Then we played with how those drivetrains would transition over the obstacles - showing each stage of the crossing. (That moat is a pain in the rear end.) We had to watch how the front bumpers would clear things during the approach to the obstacle, and also make sure the back bumpers wouldn’t hit the ground as the robot tilted upwards.
In the images above you can see the representations of three defenses, and several drivetrains (we tested lots more, but I only have some of the screenshots). We were able to quickly iterate through wheel sizes and placements. Standard ones, but also weird ones. “What happens if we add a small wheel in the middle just to help it get over the wall.”
2016 Ball Path + System Layout
We had several system configurations in 2016. They were nicknamed after characters from the movie “Dodgeball”. Most of them were designed to go under the “low bar” obstacle. How would everything package together?
It’s one thing for me to draw “Mi-Chelle” in my notebook, but how would this fit in an actual robot configuration? Everything fits fine when I picture it in my head!
2016 Climbing Mechanism
We did something bad in 2016. We didn’t really plan the climber mechanism. We had some thoughts, and the design team kinda decided: “well, whichever group gets done with their part first can start to pencil in the climber.”
As a result the catapult and intake were underway, we had basically settled on “Fran” as the concept, and the drivetrain was done… before the climber was started.
You can see this concept packages the climber into a fully detailed drivetrain. We were able to test this crude concept alongside the “real” field CAD. (Every year I go into the field CAD assembly and strip out the key elements to test against without needing to open/load the full field.)
I didn’t even remember until I looked at these, the original climber has more sheet-metal stages, and a linear “spring out” hook in the initial geometry. That changed pretty early on, but these proof-of-concept images still show the original design.
2017 Intake + Hopper
In 2017 during the first week we had one big question: “Can we pickup the gears and the balls using the same intake?” Well yes, it turns out we could do that. Our initial proof of concept? A mockup in CAD to show the different heights and how it will all package around a wrist joint.
Designing a Robowrangler assembly almost never starts with a sheetmetal component. More often than not, it starts with something like the above concept.
Later that season, we had to package the expanding hopper. A similarly crude assembly was built.
You can see our original “hotdog roller” ball feeder, which was replaced with the “pineapple” style feeder, and would eventually be supplanted by the “dye rotor” style feeder during the great 2017 rebuild.
Also notice, there is no drivetrain in this mockup. The different design groups had some defined envelopes some key interface points, and we were supposed to stay out of each others’ way. There is a subtle blue cylinder poking out of the bumpers on each side. This is the location of the intake’s “wrist joint”. The intake design team just left this in place (and tweaked it every now and then) so the drivetrains group would know where the attachment needed to be placed.
We tell budding 148 designers “start with what you KNOW, then draw a guess of what you WANT, then refine things slowly based on what’s most important to you.”
Sometimes a big colored block is a good way to define “what you know” before you start penciling in the details. Always make your early iterations crude, they’re trying to teach you something.