Robowrangler Design - Systems Integration

Scott McMahon from FRC2468 recently asked me to blog about how the Robowranglers do systems integration.  I demurred: "It's not a very good process.  The process is organic.  The process is informal.  Showcasing our dysfunction may not be as educational as you'd expect or hope.”  Scott rebutted: "...every team should celebrate who they are and how they get things done; quirks and all.  There is no perfect mix."  Scott seems like a pretty wise man, and I should probably just do what he says.

Maybe you shouldn't take our word for it.  Check out the narrative from Day 16 to see how our organic process can breakdown and require a bit more iteration...

Note: This post ended up much longer than I expected.  In trying to explain this topic for outsiders, I ended up going broad and abstract in quite a few places.  I apologize.  “Brevity is the soul of wit.  I'll write a better version some other time.

Here we go…

 This picture is the best image I could find of an example Robowrangler Systems Integration plan.  It's our  2009 robot: Tornado  drawn early in the design process, and it is surprisingly accurate.  If you're looking for more detail than this, maybe you should ask a team with a less organic approach to things.

This picture is the best image I could find of an example Robowrangler Systems Integration plan.  It's our 2009 robot: Tornado drawn early in the design process, and it is surprisingly accurate.  If you're looking for more detail than this, maybe you should ask a team with a less organic approach to things.

The Systems Integration of a Black Robot

This is going to get a little weird, bear with me.

The process is organic.  The process is informal.  The Robowranglers have no "level-2 approval meetings" pre-scheduled at regular intervals.  There are no specific timelines or milestones beyond the deadlines imposed by the competition.  The process is a living thing, and the robot is a living thing, and we never really know how it's going to play out each year. 

As I sat down to write this out, I had to meditate on how this actually works.  Since we don’t have a fixed process, what has been consistent from year-to-year?  Is this entire system at risk of “organically” imploding at some point?

Ultimately, I think it boils down to five elements, and is inherently tied to our larger design process.  You can’t separate the systems integration part of the process from the rest of the design.

JVN’s 5 Elements of Systems Integration:

  1. HeadCAD
  2. Designer Hive Mind
  3. Prototyping Lessons
  4. “Huddle-Up” Direction
  5. Steady Leadership

HeadCAD

To truly understand Robowrangler systems integration, you're going to need to climb into the brain of a Robowrangler designer.

It all starts almost subconsciously.  On kickoff day as we talk through the game, as we talk through strategies, as we talk through specific mechanisms, inevitably the designers on the team start to think in terms of a "full robot".  (See the writeup I did on the Robowrangler kickoff plan.)

We call these half-formed HeadCAD versions of the Robowrangler robot: "System Concepts".

We try not to jump into system concepts too early.  I tell everyone "think about WHAT the robot will do before we think about HOW the robot will do it."

Then later I'll say things like "think about different intakes, but don't worry how they'd fit in a larger robot, focus on this small part of the problem first."  I know most people don't take my advice.  How do I know this?  Because I have NEVER been able to follow my own rule...

I immediately start to picture a robot in my head.
We all do.  The mentors do, the students do.  The veterans do, the rookies do.

For me... early on, the robot is probably an amalgam of some past robots I've seen, and might include some crazy idea I’m fixated on for the new game.  As we learn more about the game, I start to hone in on the functions which seem most important and that robot evolves in my head.  As our prototypes give us data, I start to substitute the failed mechanisms in my head for the ones that are working in the lab, and the system concepts organically envelops them.  And then... I talk about it.

Designer Hive Mind

We all talk about what we're thinking, we share the revelations we're having.  FRC system designers are a crazy breed.  If you're consumed by a really challenging and interesting problem, it's hard to shut down that part of your brain which is working on solutions.  

During FRC season I can't listen to podcasts or audiobook, because I'll zone out thinking about the robot and realize I haven't heard any of it.

I can't stop thinking about robots.  I can't stop talking about robots.  I LOVE talking about robots.  I'm not alone.  If find myself walking past Madison or Carlos or Jessi or any of the designers in the hallway at work... I can't help but stop them and brain-dump everything I've been thinking about.  "Oh man, I had this crazy idea for using a hip-joint like we did on the 2011 robot, but instead of driving a 4-bar you drive the first stage of an elevator, but that totally doesn't work at all, so then I started thinking about..."

You get the idea.

We all brain-dump to each other.  Half of the stuff doesn't even make sense: it includes raw, unformed ideas.  That's part of the magic.  As we individually try to come up with a system concept that fulfills our goals, we’re also working together and influencing each other.  In trying to describe this to outsiders, I’ve used the term “hive mind”.  We form a Designer Hive Mind and percolate together.

Is there any formal structure to the hive mind?  Not really.  Some designers will end up focussed on one particular challenge or one area of the robot, and may end up eventually "owning" the details of that subsystem.  Others may bounce to whatever seems interesting at the moment.  Someone may have an idea totally unrelated to what they're working on: of course, they'd better share it!

At some point... one of the system concepts is going to start to stick.
When?  Why?  How?  I have no idea.  The process is organic.  The process is informal.
It just happens.  Maybe a prototype will do something amazing and that prototype becomes the idea around which a robot is formed.  (The pneumatic catapult in 2016 was a prototype that worked so well, we couldn't ignore it).

Side Note: You cannot imagine how much we hated this prototype catapult.  Unfortunately it was too good to kill and went on to become the heart of one of our most successful and dominant robots ever.

Or maybe a strategy is created that feels so perfect it infects the team.  ("How do we make Batman the best scoring robot in the world?  We give him a sidekick.")

Side Note: That is a 100% accurate representation of the conversation which lead to the insanity which became "Batman & Robin" in 2015.

The best system concepts are like viruses.
They infect one designer's brain and then are passed around the hive mind, evolving as they go.
The best ones are the ones that force us to believe in them.  The ones that make us feel like "we need to do at least one more prototype to see if this works.  We can't NOT try this one."

Just because a concept sticks for a while, doesn't mean it will stick forever.  Often times during week 1 a group of people will get stuck with the same system virus and to them, that's the robot.  They start talking as though it's a foregone conclusion.

"Look, we know we can't include that type of intake, because it's in the way of the 4-bar."
"In the way of the 4-bar where?  What 4-bar?  On the hypothetical robot which ONLY exists in YOUR head?  Maybe we should use my intake idea and ditch your 4-bar!"

But as we get new information, everyone's perception of the robot shifts...

So what makes a concept "more real"?

Prototyping Lessons

When I was a younger participant in FRC, we put too much emphasis on HeadCAD.  The process would go on just like I describe above, until the Hive Mind churns out a solution - then we’d build it.  Sometimes we would finish building it right before Stop Build Day, and throw it into the bag without ever really testing it (let alone practicing with it).

How did we decide on the solution?  Just based on smart people sitting around thinking?  Yes, and… based on rhetoric.  A persuasive designer with a powerful argument and strong rhetoric can influence the entire hive mind.  This method sucks.

Being persuasive does not make you right and being right does not make you persuasive.
— Woodie Flowers, Kickoff 2018

How do we know which solution is best?  How do we find the pro/cons for each option?  Simple, we test them.  We learn about them.  How?  Prototyping.

This is engineering, we don’t use rhetoric to win arguments, we use test data.
— John "No, I'm not JVN I'm his father" Neun

Anyone who has sat through “Robowrangler Design” understands that Prototyping is a tool we use to LEARN something about a potential solution.  A prototype can take many forms, it is any tool we use to understand our concepts.  A prototype can be a physical wooden mockup, it can be a miniature robot built from VEX EDR parts, it can be a crude version of the robot drawn in CAD, or it can be a scoring spreadsheet designed to test out game strategies.

Side Note: If I ask a Robowrangler student a direct question in front of the team and they don't know the answer, many of them will just say: "Prototyping" and hope it is correct.  It's not a bad method, statistically speaking.

But, it worked in CAD...
— The sheepish defense of every designer in the face of a failed prototype

Probably the most important part of  Robowrangler systems integration is our prototyping.

The lessons we learn here feed the hive mind.  They help system concepts stick.  The prototypes show us what works, so we’re relying on test data more than the most persuasive arguments.  The prototypes will help designers refine their individual HeadCAD visions of the robot and all of a suddenly the hive-mind as a whole starts to have a picture of the robot.

Huddle-Up Direction

Who is in the Hive Mind?  Anyone who wants to be.
What about those people who don’t think like system designers, how do you get them engaged?  We try to get them to think like system designers, if only temporarily...

The Robowranglers routinely have “Huddle-Up” meetings, in which the whole team sits in a circle on the field and discusses important topics.  (Sometimes the circle is just a sad shape which approximates a circle, and sometimes the topics aren't all that important at all - often we're just joking around.)  These Huddle-Ups are great for talking through system concepts, discussing lessons from prototyping, talking about design trade-offs, and ultimately setting direction as a team.

Our team also uses Slack as a communication tool.  There is a #mech-design channel where anyone can follow the discussion and chime in (though… not everyone wants to be engaged in the details of system design, some people just want to hear reports from the design team, then hash it out in a Huddle-Up).

 Look at that beautiful Crayola CAD hopper from 2017.  " This will totally work, it's just a slider and a thing... right? "

Look at that beautiful Crayola CAD hopper from 2017.  "This will totally work, it's just a slider and a thing... right?"

Our meeting on Day 15 was a great example of how the Huddle-Up can work.  We talk through things as a team, then set direction.  Ideally the direction is easy to set since our prototyping has made one system concept much more desirable than the others.  If not… we just pick one.  At some point in the process, we need to start moving towards the goal, even if we don’t know exactly how the direction will change.

At some point in every project there come a time when you’ve got to shoot the engineer and just build the thing.
— Every Project Manager, Ever

How do we know when to make the decision to move forward?

Steady Leadership

Since the Robowranglers have been around since 1992, we’re fortunate that our leadership group is fairly experienced.  Our mentor group is very experienced, and includes a lot of very passionate “live for robots” type people.

Most importantly, we’ve managed to build a program that somehow produces class after class of very strong veteran students.  With a few exceptions, the Robowrangler “Professionalism at all times” mentality has permeated the team.  Veteran students provide “peer-pressure” mentorship of rookie members and help them understand the Robowrangler Values.

I don’t know how this started, and if asked to create this same culture on another team I would have no idea how to do it.

This "steady leadership" is important, because one of the tenets which keeps the whole thing from falling down is: “Trust the Process.”  That is easier said than done, and probably wouldn’t be possible if we had turbulent direction.

But wait… I thought this was about systems integration?

So when does the systems integration happen?  All you've talked about is idea generation and refinement!
Well, that’s the tricky part.  It happens all throughout the process I described above.  The system is generated as the individual components are generated.  It all happens together, since in this process one can't really happen without the other.

Some Specific Systems Integration Events:

There might be some point in the process where as lead engineer I ask “Who wants to work on what?” and we divide up some of the prototyping work and design work.

At some point in the process there might be a meeting where we talk about motor allocations.  “Okay, so you’re planning for 6x 775pros on the lift… and I’ve got 6x more on the climber - I don’t know if this robot is going to work out.”  Similarly, we will talk through sensor placements and planning.  We'll discuss control schemes and autonomous strategies.

At some point in the process there might be a meeting where we divvy up the robot's physical space, although this is typically happening naturally within the hive mind for each of the developing system concepts.  We don't do too much of a breakdown.  The process is organic.  The process is informal.  Using the initial system design of 2017's robot Rogue as an example...

2017.JPG

"Okay, so we like the intake prototype that does both balls & gears in the same mechanism.
We'll put that in the front of the robot.
The shooter will be somewhere on top - maybe in the back or middle.  How far back do you think we can shove it?
Drivetrain will need to have an opening in the front for the intake pass-thru.
At some point someone will need to figure out the hopper structure, it'll probably end up incorporating the climber and maybe help support the shooter.
What feed are we using?  Are we using a turret?
Let's keep prototyping and see where we end up - just leave some space back there and we'll figure it out later...
"

This exact conversation didn't happen in 2017, but one like it did.

After this, the actual people doing the CAD will divide up the work and get to it.  (You don't need to actually touch a CAD mouse to be on the design team).  Individual designers will stay in touch with the hive mind and work out issues among themselves.  There is a lot of give and take.  If a big issue is found, it gets bounced up to a larger group of designers, or maybe even bumped up to a full Huddle-Up meeting.

There is power in having a shared vision BEFORE the detail work gets moving.

What's our secret?

The people.  The talking which leads to a sort of hive-mind.  The way we're comfortable in letting things organically develop.  The way we're willing to let things evolve while we throw more information from prototyping and strategic analysis into the brains of our designers.  The entire natural evolution of things is such a natural extension of our iterative mindset.

When I am working on a problem, I never think about beauty but when I have finished, if the solution is not beautiful, I know it is wrong.
— Buckminster Fuller

The design moves rapidly once an idea becomes strong enough.  When the right system concept is introduced to the hive mind, it feels like it integrates itself.

How does your team do it?  Hit me up.  Can you give me a better answer to give Scott?  I'd love to hear a more formalized version than our organic, evolving, informal method.