I’ve heard a lot about “building simple” being effective, but how does a team go about actually achieving that? My team right now is able to get to a point where we know what our objective is at a high level on kickoff (for example not going for high cones this year) but we struggle to translate that simple strategy into a simple bot sometimes.
I think this is a good video to watch. It’s quite long but very informative and imo can help a ton.
- Reduce degrees of freedom where appropriate (sounds like you are close if not there already)
- Make things “work” even if they are well out of tolerance (i.e. not sensitive to field misalignment, minor defense, game pieces in the way, minor damage, etc)
- Don’t sacrifice the speed or consistency in favor of minor gains in performance (see point 1)
Long story short: don’t build a glass cannon that only works in theory but suffers in reality (this is true for software too).
Not all DOFs are created equal. Rotary mechanisms are usually easier to make precise and fast than linear ones. This holds true until your moment arm gets past like 30” long, IMO.
If you find yourself wanting to reach past that, maybe re-evaluate your core strategy to build for cycle speed rather than max points output per cycle.
I totally agree that a simple rotary joint is much easier to build with little to no play than a linear extension. Because linear motion is generally based off a rotary motion, the linear has at least 1 extra layer of backlash. On the other hand a few degrees of backlash on a long arm will cause a lot more movement than the same amount of backlash in a small spool or sprocket driving a linear extension.
On average an elevator will have less backlash than similar arm due to far fewer stages of reactions required, and typically a tensioned final stage.
I am honestly in the camp of “Linear actuators are going to be faster and easier to position if they can be built for the application” carbon fiber tube (drone sizes) and higher end 3d printing can make this very doable. And provide a lot of design leeway.
If you are going to do a long arm make your lives easy and make those pulleys/ cable (capstan-esque) drives large diameters to tune out the backlash and reduce loading.
Building simple is harder than building complex, and there’s certainly an art to it. Over the years, I have learned that a very successful approach to building simple isn’t to try and simplify a complex solution to a problem, but instead to minimize the amount of problems you are trying to solve. This often means eliminating features and functionality in the early stages of your strategic analysis such that you have less to do. Remove things like turrets, extra scoring features, gimmicky systems like buddy climbs, or even entire functions of the game (only score low and middle, no high goals).
When I was younger, powerhouse mentors would tell me to “do less”, which often came across as condescending, as it felt like they were saying “you aren’t capable of doing more”. They were right, but they didn’t mean “you aren’t capable of doing more”, they meant “you don’t need to do more”. I think it was Mike Corsetto who said that Citrus celebrates every time they can remove functionality from their robot (or was it Adam? My memory isn’t what it used to be). Either way, this is a great perspective.
The message I’ve learned is that truly simple design starts with having less design that needs designing.
tl;dr: “Do less”
Please let me know when you figure this out
I’d like to think that my team has done this fairly well.
Our first major robot success was back in 2018 when we got 3rd place at Detroit Champs. The robot that did that was tiny and had 1 non-drivetrain Degree of Freedom (DOF). Although we weren’t able to do everything, what we could do, the vault and the switch (low goals), was fast. This caused us to get chosen by 2056 and 1241. Building a simple, fast robot worked.
Here is a photo of 2018 robot:
Now let’s look at the next year we had good success with our robot, 2022.
Here is a photo of that bot:
Notice any similarities?
We didnt use the optimal design (a hooded shooter), but we had just come back to the lab, and we wanted to build a simple robot. Once again, we had only 1 DOF and it was a design that we were confident we could accomplish. This robot may not have been the fastest scorer, but it could clean up random balls and play defense effectively.
Now let’s look at 2023:
We used a very similar design once again. We had started out the build season thinking of doing more (extension, pneumatics) but we found out that we didn’t have the knowledge or experience to build those more complex mechanisms. So we fell back to what we know. There are many improvements we have made over the years, going from a 775 on the 2018 pivot to a falcon on 2023, and many stability improvements, but the overall design is one that we know and can easily make. We have also used a pivot in other years (ex. 2016).
The overall message: Reducing DOFs can often improve performance and decrease build/repair time. Having good driver practice is more important than having the ideal robot, especially in early regionals. Or maybe not. Who knows?
Same applies to writing work emails
Note: this post is about system-level design. Mechanical simplicity requires a much longer writeup. Software simplicity is a separate topic on which I’m nowhere near qualified to comment.
I’m going to try to organize some of my thoughts on this into a post here, but feel free to poke holes in this theory. One of the most important things to understand when you’re talking about “simple” from a system level is degrees of freedom.
Degrees of Freedom:
A degree of freedom is, in a simplified way, any way that a part of a robot can move independently of another part. An arm can move independently of the chassis, a wrist joint can move independently of that arm, and the rollers on an intake can spin independently of that wrist. An intake roller on a wrist mounted to an arm has 3 degrees of freedom. You will often see “degree of freedom” written out as DOF.
Types of DOFs
For the purposes of this writeup, there are 3 types of DOF.
- Rotational DOF (discrete): This is a thing that rotates where you care about the position that the thing is in, like an arm.
- Rotational DOF (continuous): This is a thing that rotates where you don’t care about the position, like the roller on an intake.
- Linear DOF: this is a slidey thing that moves in a straight line, like an elevator.
System Layouts
Every FRC robot is basically a collection of DOFs mounted to other DOFs, eventually mounted to a chassis.
2910 in 2019 is a roller (continuous rotational DOF) mounted to an arm (discrete rotational DOF) mounted to the chassis.
1678 in 2023 is a roller (continuous rotational DOF) mounted to a wrist (discrete rotational DOF) mounted to an elevator (linear DOF) mounted to an arm (discrete rotational DOF) mounted to a chassis.
You can describe most mechanical systems this way, and most “good teams” that I know of start their robot design process by sketching out the DOFs. The very first pass at 1678’s 2023 robot was this sketch, showing the pivot on the back and telescoping elevator.
How Difficult is a DOF?
Each time you add another DOF onto your design, you have to design the mechanical linkage (the specifics of the bearings and structure and whatnot) and you have to power the motion. Power always has to make it from the battery out to the motor/cylinder, which means that in some way you have to transfer power to a DOF through all the ones that come before it. That power can be transferred electrically (wires), mechanically (belts), or pneumatically (tubes).
For Citrus 2023 specifically, that means the motor for the arm is hard mounted to the chassis, the power for the elevator has to make it through the arm pivot, the power for the wrist has to make it through the arm pivot and elevator, and the power for the intake rollers has to make it through the arm pivot, elevator, and wrist. Each of those power transfers requires design effort, is a part of the robot that can (and did) fail, and needs inspection and preventative maintenance in the shop and in the pit.
Quantifying Simplicity
Here’s my thesis for this post. You can get a good first-pass estimate for “how complicated is this design” by counting the highest number number of sequential DOFs on the robot. Because of the difficulty of power transfer, I would add 0.5 for each stage of an elevator or extra bar in a linkage. Looking at 1678 2023 again as an example, here’s the DOF count.
The 1678 2023 robot has 4.5 DOFs.
This robot was competitive and successful, but it really stretched our ability to build robustly. We barely made it. I spent most of this season on-edge waiting for the next failure, as compared to 2022 where I sometimes forgot that the robot could break. (Citrus 2022: 2.5 DOFs.) The e-chain that went through the elevator failed multiple times, and getting power out to the far roller was a nightmare to the point that we couldn’t pick up cubes a few days before our week 1 event. I’m comfortable saying that next year, we’re going to be looking for a robot that has fewer than 4 DOFs.
I just took a look at 6059’s 2023 robot, and I think I saw 3.5 DOFs. Next January when you’re penciling out your robot, if you see a DOF count bigger than 3 I would stop and think real hard about it. If you have to cut out some type of scoring capability to lower your DOF count to <=3, I would consider doing it. If you are comparing two different designs, I would favor the one with fewer DOFs.
Other Types of Complexity
There is a whole other discussion to be had about the relative complexity of the different types of DOFs, both in hardware and software. I have thoughts about mechanical complexity but they’re not well organized in my head yet, and I have only the roughest of mental crayon drawings about software complexity.
That’s a great way to quantify the complexity I hadn’t thought about! In hind sight we have been able to somewhat visualize the complexity but having a method to do so is very helpful especially come kickoff. Thanks!
Thanks! This has been floating around in my head all season, and it’s good to get it in writing. It’s really easy to tell yourself “it’s just one more rotation” when you’re designing, but having a hard number that you can’t lie to yourself about is valuable. This isn’t “the definitive complexity metric” but it’s the one that I think best fits what I know about simple vs. complex robots.
Great write up, and I will be using this to highlight to my students where some of our success this year came from. Our most complex parts were 2 dof (rotational continuous on a rotational discrete). We did make the intake arm and rollers coaxial though, and I’d say that could conceivably be worth an extra half point too. EDIT: maybe. Idk. It’s not actually complicated, but it can be?
Adam has presented a workshop on this topic a few times at various events, and gets in to some of the “how” and not just the “why”.
Not sure if this is most recent rev, but it is certainly pertinent and worth a watch:
The first step is to remember that teams aren’t very good.
2019 is a great example of this. At CVR that year, a Week 2 event, the median team was able to score just over 2 game pieces in one match. The median cargo specialist could do 3 cargo. This meant that it took about 30-50 seconds for a team to do a single game piece. If you were better than that, you got picked. So the bar for “being competitive” is actually very easy to clear, if you’re really pessimistic on Day 1.
Next, think of the last time your team was successful. How many DoFs did they have? The 1 thing to remember is that your robot has to be done early so that you can get driver practice. That means you cannot design a robot beyond your capabilities as a team, because if you overreach, you won’t get driver practice and your season is sunk. Past performance is the best indicator of future performance, and that means staying within the past limits of your team unless dramatic changes have taken place (like several new mentors or a new lab building). Take pains to make a single DoF robot, maybe 2 at most if you really, truly need it. Once you’ve mastered that skill by getting deep into elims as a first pick, then you can move on to one more DoF the next year. If your robot can manipulate a game piece and drive well, you’ll be a first pick or alliance captain.
One of my priorities on 115 this year was to convince the students to get the robot as simple as possible. Extensive layout sketches proved that a single 3-stage COTS elevator from WCP could place mid and high game pieces, allowing for the use of a fixed angle intake. We could have iterated more on the intake specifically, but the robot was quite competitive in season (don’t ask me about Chezy though ). I think if we had iterated the intake more, we could have had a better shot at Idaho and Champs. My goal for the coming year is 1.5 or even 2 DoF, more focus on auton vision, and hopefully even an iteration.
How would you quantify pneumatics in all of this?