FIRST Engineering Principles

[Rick TYler]

I've been thinking about some guiding principles for our FIRST team. These will be in two parts -- people and engineering approach. Here are my thoughts about engineering.

The First Engineering Principle of our team will be: We will build simple, reliable robots that finish every match and perform one or two things really well.

1. We will place reliability first in all of our design decisions.
2. We will develop a simple, robust chassis approach, and we will do so before the season starts.
3. We will limit the functions we tackle to two or three things at the most, and will focus on doing ONE thing really well.
4. We will finish constructing our robot early and will allow two full weeks for testing and training.
5. We will not waver. We will build the robot we designed and will make only minor design changes as we build.
6. We will always keep the construction deadline first in our minds.
7. We will never lose a match because we violated these principles.


Thoughts?

(Thanks to my teammates on 1294 and to mentor Larry Barello of Titan Robotics Team 492 for his sizeable contribution to this.)

[coastertux]

Sounds good!
A few more principles:
KISS (Keep It Simple Stupid)
Make sure all designs are feasible to build in the alloted time and weight constraints.
Make sure the designs are easy to fix in short periods of time.
Make sure the programmers will be able to make your feat of engineering work how you want it to.

[KenWittlief]

you are off to a good start. What you are really trying to do is impose requirements on your design team.

To make things more clear, and to help sort out your thoughts, do two things:

1. Change 'will' to 'shall'. Each shall denotes a requirement.

2. Now take each requirement and decide what test you are going to use at the end of the year to determine if your team has meet the requirements? Some things will start to jump out at you, for example: how do you test for 'early' or 'robust' ? People like to toss squishy words into requirements, but then how do you know if you succeeded? For example: we will make it better. How do you test for 'better' ? When you figure out what 'better' really means, put that down instead - be specific.

Once you have decided what you want your requirements to be, then the more difficult part comes, you must figure out how your team will do those things? You must come up with a design process that makes those things possible, otherwise all you have is a wish list, with no plan of action.

[Rick TYler]

Originally Posted by KenWittlief

you are off to a good start. What you are really trying to do is impose requirements on your design team.

Thanks for your comments. I am, in fact, trying to set up a strategic direction for our team that includes the following:

Vision
Mission
Principles of Teamwork
Engineering Principles

These will inform the next step which includes (this is NOT all-inclusive):

Team roles
Design and build goals
Competition goals
Design methodology
Build methodology
Testing/training methodology
Other competitions (web, animation, CAD) methodology
Tournament methodology
Measurement and planning cycle

It may sound imposing, but I hope to scale all of these to the task at hand. At work, I deal with multi-zillion dollar products and large teams of professionals. The FIRST methodology we develop will, I hope, expose the students all these things to get a flavor of how structure can help, while limiting its sheer volume so that they don't have to spend all their time doing administration.

I really take to heart your comments on measurement. The "Engineering Principles" list is both too low-level and too high-level at the same time. I'm still noodling on how to scope this and I appreciate everyone's input. (KISS is important, tux, thanks for the reminder.)

[Greg Ross]

Rick,

Is this just a formalization of principles you've already put into practice? Or something you are wanting to implement? I'm wondering how they have worked out for you in practice.

[DonRotolo]

Originally Posted by Rick TYler

It may sound imposing, but I hope to scale all of these to the task at hand. At work, I deal with multi-zillion dollar products and large teams of professionals.

First off, you are on a good path. After spending all day the Monday before ship still designing the robot, I came to the conclusion that next year, things shall be different (thanks Ken ).

The greatest issue I see is that, at work, you're dealing with professionals, while at FIRST you have high school students. Tell a professional to go do some relatively complex task, and the next day, you have something that's well thought out and helpful. Our kids simply don't know how to do most tasks, especially in design (in the broad sense), yet.

OK, so what to do?

We started Pi-Tech, a training ground for FIRST team members, and it's my intention to get other Mentors to teach the kids - in the off-season - what they need. Not to be experts, but so they at least have a clue. It worked OK this year, with a focus on physical things (gear ratios, mechanisms), but one parent taught how to do QA and integration on software - that's what he does for a liiving. Our code came out much better for it, too.

Building on your work so far, once the goals are defined, one can think about the specific skills that are needed to accomplish some part of them. For example, one of the issues we constantly face is kids sitting around "I don't know what I should be doing". To solve that, we came up with the idea of a taskmaster: Someone who oversees every tiny piece of the jobs at hand, and who kids can go to and get a job to do. A human job jar, perhaps, one who knows the skill levels of the kids and gives them something appropriate.

Here's the problem: No kid can do this, not one of them understands all the facets of the process well enough to be the program manager. Assigning a task to a student who doesn't have the necessary skills will be a waste of materials. The kid hits a roadblock and just goes home, stays away for a day, and progress comes to a halt, or worse we can't use whatever it is they did... The kid doesn't know enough, isn't general enough, and we don't have the mentors to give one-on-one all the time - there's a big gap here, and I don't know how to fill it.

Professionals, on the other hand, just take the assignment, learn what they need to know (or state they are wrong for the job) and go to it.

I guess my point is, what works at work might not work at FIRST. I think that it can be made to work, but you need strong team leaders, who direct others in their work, plenty of mentors to explain the details, and lots of pre-season training so they understand what you mean by, say, "measurement and planning cycle".

Although there are a million ways to organize a project such as a FIRST robot build, I am sure most teams do not know the first thing about it. What you are trying to do might take a few years to get right, but in the end it will create a championship team. Maybe the robot will be awful, but you'll have one heck of a TEAM - and isn't that what this is all about?

Let me know how I can help.

Don

PS: Can you keep both reliability and construction schedule first?

[Gdeaver]

One principle- KISS and this year we added the KIC principle. (keep it cheap)

[coastertux]

Originally Posted by Gdeaver

One principle- KISS and this year we added the KIC principle. (keep it cheap)

Keep it Light would be a good one...although the acronym isn't very FIRST like...

[Gdeaver]

If you KISS it and KIC it, the robot will natural come in light.