How do you measure mechanism complexity

Hey all, do you or your team have a way to put a number value to how complex a mechanism is on your robot?

In an ideal world, when my team is coming up with a robot concept I’d like to be able to estimate the complexity of the design as a whole and know when to raise a red flag that the concept needs to be simplified.

Below is what I’ve come up with so far:

Complexity = independently controlled degrees of freedom * precision multiplier * part multiplier

  • precision multiplier: 1 if only two positions (or on/off), + 2 for every degree of freedom that needs >2 positions or precise speeds
  • greater than 5 unique/major parts: +1 for every 10 parts needed
    • things like spacers or bolts wouldn’t be considered a major part
    • (not sure what number of parts should be, basing it off a gut feeling right now)

Some examples:

Mechanism independently controlled degrees of freedom precision multiplier Part multiplier complexity
Flywheel shooter(100% on off,Directly driven from motor) 1 1 1 1
Flywheel shooter with speed control 1 3 1 3
Flywheel shooter with active back rollers 1 3 2 6
Flywheel shooter with piston controlled hood 2 3 1 6
Flywheel shooter with continuous position hood 2 5 2 20
Single stage elevator(2 position) 1 1 2 2
Single stage elevator(3 positions) 1 3 2 6
2 stage elevator(3 positions) 1 3 3 9
Tank drive 2 3 2 12
mechanum drive 4 3 1 24
swerve 8 3 2 48

I’m not sure how to factor in if a mechanism is COTS or if we have an existing design to go off of. Would love to hear your thoughts/advice!


I don’t know that part number is quite the right metric. Perhaps some measure of manufacturing operations? I’m thinking something that captures how COTS parts, hand tools, power tools, etc. all have different levels of difficulty to perform them.

For existing designs, I might suggest a 1/2/3 of “we have an existing past design” → “many others have existing past designs” → “this is entirely new territory”.


I think many teams would have an easier time building a swerve drive base (your score: 48) today that creating a simple flywheel shooter (score: 1) because the flywheel requires custom designed side plates, motor mounts (probably with belt reductions), standoffs etc. That can accurately launch a ball. A swerve module requires assembly of a fixed set of parts, and four pieces of 2x1 with a few holes drilled in them.


There was a JVN blog that presented a fairly reasonable way to count degrees of freedom on an FRC robot.



@NShep98 I think you’re right, part number isn’t a great metric, though I think capturing the complexity of manufacturing operations could be tough to do consistently when looking at an initial concept. What do think of a manufacturing multiplier that’s 1/2/3 " COTS" → “modified COTS” (ie cots gearbox but on a custom WCD chassis) → “custom”?
I’m going to dub you’re existing design multiplier as the “experience multiplier” Thanks for the suggestion!

@mrnoble That’s a fair point, using a COTS swerve drive definitely isn’t 48x more complex than a custom made flywheel shooter. I think swerve should probably be looked at as having only 2 degrees of freedom since it’s just the same module repeated 4 times. The fact that it’s COTS vs custom should also be factored in. I would argue that because of the programming and electronics involved, a COTS swerve is still significantly more complex than a custom on/off flywheel shooter. The model below has the basic On/Off flywheel shooter at a 6 and a COTS swerve at a 20, does that seem more reasonable?

Complexity = Dof * P * M * Exp

  • Dof = independently controlled, non-repeated, degrees of freedom (ie 4 swerve pod drive train only has 2 Dof)
  • P = precision multiplier: 1 if only two positions (or on/off), + 2 for every degree of freedom that needs >2 positions or precise speeds
  • M = manufacturing multiplier: 1 if Cots, 2 if modified cots, 3 if custom
  • Exp = experience multiplier: 1 if team has successfully done before, 2 if done by other teams before and well documented, 3 if new design
Mechanism independently controlled, non-repeated, degrees of freedom precision multiplier manufacturing multiplier Experience multiplier complexity
Flywheel shooter( 100% on off, Directly driven from motor) 1 1 3 2 6
Flywheel shooter with speed control 1 3 3 2 18
Flywheel shooter with active back rollers 1 3 3 2 18
Flywheel shooter with piston controlled hood 2 3 3 2 36
Flywheel shooter with continuous hood 2 5 3 2 60
Single stage elevator (2 position) (partial cots) 1 1 2 2 4
Single stage elevator(3 positions)(partial cots) 1 3 2 2 12
2 stage elevator(3 positions)(partial cots) 2 3 2 2 24
Tank drive (cots) 1 3 1 2 6
Mechanum (cots) 1 3 1 2 6
Swerve (cots) 2 5 1 2 20

Without the parts multiplier there’s no differentiation of something like adding more active rollers to a flywheel shooter. Maybe there should be an extra 0.5 added to Dof if there’s a secondary motion driven off the active degree a freedom? (like multiple rollers on an intake)

1 Like

Total number of mechanical degrees of freedom is actually not a bad place to start.


Last year, we started estimating a complexity cost for our robot designs, which is maybe slightly different than mechanism complexity but I think the intent is similar. The quoted snippet below from our “670 Cost Model” document describes how we approached it. We took a couple of our recent robots as well as some others we’d seen at competitions and estimated after-the-fact complexity costs to sort of bootstrap understanding of how to use this and then applied it last build season as we were considering designs. We plan to do the same this year.

Complexity Cost Model

A cost model provides a basis for comparing the relative expected cost of potential robot designs. Cost models are commonly used in “agile” development, which is a horrible name that describes a process commonly used to develop projects (generally software projects) that are not well understood. “Agile” development teams commonly use one of a few different cost models. See What are story points and how do you estimate them? for an example. For evaluating cost, we should consider the full range of the proposed design. In particular, for estimating the cost of a robot design, follow this process:

  1. List the systems we’re proposing to build. Note that systems can be 100% hardware, 100% software, or any mix of both-as long as it is a part of the robot that’s handled or seen as an individual unit/piece/project/(?).
  2. List the interfaces/interactions between systems, to ensure that we are considering the full range of the work involved.
  3. List the actions and in particular the sequences of actions that the systems will have to perform, again to help ensure we’re considering the full range of the system.
  4. Considering the actions that it will have to support, estimate a cost for each element in the robot design that needs to be implemented to meet our goals. Costs should provide an aggregate view of the anticipated work for designing, building, software, testing, tuning and any necessary practice. The cost should consider necessary human resources as well as shop resources (e.g. tools that are in high demand) and space (e.g. practice field availability) where applicable. If some task is going to require an expensive resource (our lead mechanical mentor, the mech lead, the software lead, use of a limited tool in our shop for an extended period of time, lots of practice time, some other limited resource, etc.) the cost should go up relative to tasks that do not require expensive resources.

To assign costs to each element in the design, we will use the Fibonacci sequence, with the following definitions for each number in that sequence:

Assigning Costs:

1 - we could execute and add this during a regional practice day if we had to
2 - well understood and easy to execute
3 - well understood and medium-ish to execute (I don’t have a good definition for this one - someone define it better)
5 - well understood but expensive to execute
8 - not well understood but expected to be comparatively small
13 - not well understood and expected to be large
21 - no idea what we’re doing or how

It is normal and expected that cost estimates will change over time and that in particular they may be fuzzy earlier in the lifetime of a design/implementation. That is fine. That is good. As we spend more time on a design/implementation, we will get more clarity. We will make progress. We may change the design. Those are all fine. Those are all good. As we do, the Development team will update the system cost (or costs - particularly early on, there will likely be multiple possible designs under consideration).

From what I recall the system was effectively mechanical degrees of freedom.

Tank drive counts as 2, and I believe all holonomic drivetrains (mecanum, kiwi, h-drive, and swerve) were counted as 3.
Each independent pneumatically actuated function as 1, e.g. intake deploy would be 1.
Each independent motor driven axis as 1, e.g. intake rollers.

There were a handful of examples and counter-arguments presented, but it seemed like simply counting DoFs was good enough for FRC applications. It takes care of both code and mechanical complexity, until you get into those rare mechanical Rube Goldberg robots where 1 motor is doing 6 things.


When considering complexity, it’s not just building and programming, it’s also required driver expertise. COTS swerve may be easy to build, and not as hard to program as it use to be, but there is still a significant learning curve to driving it properly and controlling it during auto. It’s worth taking into account everything, from design to competition, when evaluating your options!


Swerve is a weird beast tho, if ur inexperienced at driving swerve ur kinda basically it driving an expensive over engineered tank drive.

1 Like

I have personally found swerve to be easier to drive than 6wd because you are not constantly do weird maneuvers to go where you want to do. A driver with 3 years of 6wd experience would likely find the switch hard but someone who wasn’t had had much driving experience at all might not struggle as much


Do you use field centric control or robot centric?


I think the key thing to look at is not complexity per se, but cost. $$ is certainly a contributor for most teams, but the biggest contribution to real cost is usually tmh (team-member-hours). Include design, build, re-work, programming, and drive team training. Obviously all will be estimates. After each season, look back at your estimates and compare them to actuals so you can improve your estimates year-over-year. Don’t take on a concept you aren’t reasonably sure you can deliver given your $$, time, and human resources. And have a plan for what to jettison if you find out that you are significantly behind schedule.


Is there a way to make cost estimates of novel challenges less subjective? And what level of detail do you use in those estimates? (days, weeks, hours?)

Last year I had assumed that the traversal climb was going to be a lot more difficult than it was. Our team had decided against doing it during kickoff weekend (after much debate) and then ended up adding it in under a week for worlds.

I feel like “mechanism complexity” isn’t a very solid unit of measurement. Instead of deciding how “complex” something will end up being, you should try and predict how capable your team is, and if they are able to accomplish whatever they are setting out to do. Capability and Ability are both subjective terms, but if I were to try and put numbers into it, it might look like this:

challenge: The level of difficulty your project has. Challenge will be calculated like this. if you are calculating a full robot’s score, do this for every subsystem independently, then add it all together

  • +X for every production technique (hardware or software) that someone doesn’t already know. If a mentor understands the technique to a degree of instructing a student, only add +1. If the student must learn this independently, add +7

  • +1 for every production sub-team that gets involved with the project. Example: if your project requires mechanical, electrical, and pneumatics; +3 challenge score

  • +1 for every software subsystem that gets involved. If your project needs vision software and autonomous programming, +2 challenge score

  • -1 for each process that is repeated elsewhere. If you are designing a part that requires a custom part, the first time would get +3 for using a unique system. However each time the same part is used again elsewhere, it is -1 due to the process already being mastered.

  • after all calculations are done, add +20 no matter what because designing and building something new is difficult, no matter the prerequisite skill

After you have the challenge score, try to get an idea for your team’s Capability by estimating these numbers on a scale of 1-10.

  • How helpful would anyone’s prior knowledge be (prior meaning if someone’s personal or job experience could assist here)?

  • How comfortable are students with learning new things?

  • How well will your team be able to handle unexpected problems related to the design and production of your project?

  • How well does your team manage time?

For each of the above fields, apply this rule: 1 = -5; 2-4 = -1; 5 = +0; 6-7 = +1; 8-9 = +3; 10 = +5 and total the results of each question into one Capability score.

For Ability, combine the results of the following questions. Yes = +1, No = -1

  • (only count if applicable to project) has anyone [student or mentor] learned how to use whatever machinery needed for production?

  • Can a mentor help the process along?

  • Does documentation exist for whatever you are attempting?

  • Does the student already understand the principles behind what they are doing?

And after all of those things are calculated/estimated, you can sort of get an idea of how easy a task will be. In general:
If Challenge > Capability + Ability, it won’t be easy, but not impossible.

If Challenge = Capability + Ability, you should be able to make it through just fine, but it will take effort

If Challenge < Capability + Ability, it should be smooth sailing.

Of course, these aren’t real numbers, or real summarizations. I made this concept up just now, but the only thing that is 100% usable is the general concept of “is the idea of your project more or less difficult to do and understand than your team’s ability to understand new concepts as well as their actual ability to preform the necessary tasks”. The actual numbers I just made are completely arbitrary, a guesstimate based on my experience learning robotics-fu.

Everything that we practice in robotics are all learnable concepts, it just depends on the time and effort your students are willing to put in. That’s not to say some things aren’t worth the time or effort, but that’s up for you to decide.

In my experience, no. I’ve seen many systems that try to appear objective, but ultimately the values and/or bins are based on experience (subjective data). The more experience you can put into the decision and the more consistency among both the challenges and the capabilities, the better those estimates tend to get. But sometimes you still come up with surprises. Practical fusion power is about 25 years away. And it has been for over 75 years.

Whatever works. Just remember to add enough context to be able to convert units properly. If your team members work an average of 15 hours per week and 3 of those hours are meetings, the conversion factor from shop hours to shop weeks is 12, not 40, and certainly not 168!

Yes, and also take into account where you can leverage existing designs such as COTS parts, well documented designs from other teams.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.