Preventing "Garbage In, Garbage Out" in FRC

[Ian Curtis]

In college, one of my friends had a professor for CFD/FEA who had made it a central theme of the class to avoid "Garbage in, Garbage out." Taking the phrase a step further, can you really understand the output if you don't understand what the process the model goes through is?

Thanks to educational discounts, there is a ton of really powerful software available to teams. How do you make effective use of it? What kind of training do you make available to students to help them understand the kinds of decisions they are making? You can't cram 4 years of class into 2 weeks of design, or even the 24 weeks of FRC you get in a HS career.

Put another way, what do you get out designing another West Coast Drive if you don't understand the difference between a cantilevered and simply supported beam? Do students need to know that, or can you hand down enough rules of thumb that they get an intuitive understanding so that the right kinds of decisions just get made?

Same thing goes with OPR. If you use it in your scouting methods, do you have kids that understand the linear algebra? Or is it more of a handwavy "This is how it works, this is where it might break down" that comes from the top?

I'm sure there is a goldmine of experience here.

[DampRobot]

Engineering is not physics. I don't think it should be either.

As engineers, we use rules of thumb every day. Be it tooth strength, aluminium density, motor curves or almost anything else, what we "know" is simply a set of assumptions that are good enough ~%95 of the time. However, there are always statistical anomalies, and we shouldn't try to discount them.

Teaching students rules of thumb isn't a bad technique, it's teaching them how things are done in the real world. If student's ask why, usually their inquisition should be indulged, but we don't need to understand everything about a system to use it, at least not in the way a physicist might. Ask an engineer why a certain alloy of steel has a breaking strength of 25000 psi, and the would most likely answer "because it is." True, it would be great for them to understand at the most basic level (i.e, statistical performance of metallic bonds) why this is true, but it really isn't necessary.

Perhaps I haven't addressed your main point, but I would conclude with this: Engineering rules of thumb don't form the garbage that goes into the making of the robot. They take the garbage of the real world and turn it into more pure, if slightly diluted, data.

[Alan Anderson]

Originally Posted by DampRobot

Ask an engineer why a certain alloy of steel has a breaking strength of 25000 psi, and the would most likely answer "because it is."

I suggest that the correct answer is "because the CRC Handbook says so."

[Jon Stratis]

Most often, it's not the software teams use that makes a difference - it's the process the team goes through. Two examples:

A few years ago, we built a mecanum drive train on one of our robots. When it came time to program it, it would have been really easy to use the built in mecanum module and call it a day. However, rather than do that, we pulled over a white board, and went over how it all works. As a team, we came up with two separate algorithms that should work, and implemented them (along with the built in one). We handed it to the drivers to try out, and while they picked the built in one as being easiest to use, the team learned how it actually worked, instead of just plugging it in.

Last season before we started building anything, we went over every allowed motor (except the ARA donation). We talked about what the values meant and how you can use them to determine which motor to use for which application. As a result, we only burned out 1 motor, and that was in an unanticipated situation that wouldn't occur on the field (a 50 ft ethernet cable we used as a tether got caught in one of our shooter wheels). Compare this to the previous year, where we burned out a half dozen or so FP motors and countless minibot motors. We didn't do the same level of training on motors that previous year.


When building a robot, you don't have the time to dive into the specifics of every aspect. But if you take the time to dive into some aspects and show the students how some of the important decisions are made, it'll help them to understand and apply the process to other decisions later on in life.

[Ether]

Originally Posted by DampRobot

Ask an engineer why a certain alloy of steel has a breaking strength of 25000 psi, and the would most likely answer "because it is."

..

[Tom Line]

Originally Posted by Ian Curtis

Put another way, what do you get out designing another West Coast Drive if you don't understand the difference between a cantilevered and simply supported beam?

The statement above is a prime example of why you challenge the students to think using critical analysis.

In fact, I've challenged people who posted comments like "west coast drive is lighter".

The response to that should be a question: both have to survive the same total forces on the playing field. Explain why, then, one would have to be any heavier than the other. Chassis with dual-supported axles (inner and outer rails) don't have to deal with the torsional forces West Coast do: hence you can use lighter material. In addition, they don't require bumper stand-offs.

Never allow your students to get away with an answer that amounts to "because it's better". Have them prove it to the best of their ability, and when they're wrong, ask them to figure out why they're wrong.

[Ian Curtis]

Originally Posted by DampRobot

Engineering is not physics. I don't think it should be either.

[snip]

Perhaps I haven't addressed your main point, but I would conclude with this: Engineering rules of thumb don't form the garbage that goes into the making of the robot. They take the garbage of the real world and turn it into more pure, if slightly diluted, data.

I totally agree with you, but like you said that's not really what I'm after. Tom hit it right on the head of how to shift people from the "Let me CAD up another copy of a WCD without any understanding of what I'm doing" vs. a "Let me design a widget that I can actually explain."

Judging from Jon and Tom's comments, it sounds like it just comes down to challenging people. "Why did you do that? (and I copied it off someone else's CAD doesn't count)"

[DampRobot]

Originally Posted by Ian Curtis

I totally agree with you, but like you said that's not really what I'm after. Tom hit it right on the head of how to shift people from the "Let me CAD up another copy of a WCD without any understanding of what I'm doing" vs. a "Let me design a widget that I can actually explain."

Judging from Jon and Tom's comments, it sounds like it just comes down to challenging people. "Why did you do that? (and I copied it off someone else's CAD doesn't count)"

The people that are doing truly innovative things don't post them on Chief Delphi immediately. If you see a lot of designs that aren't particularly valuable on CD, it's because those with the valuable ones don't go throwing on the web before they can take advantage of them.

[Tristan Lall]

Originally Posted by Alan Anderson

I suggest that the correct answer is "because the CRC Handbook says so."

Personally, I'd go to the ASM Handbook in preference to the CRC one for material strength information.

[MichaelBick]

Originally Posted by Ian Curtis

I totally agree with you, but like you said that's not really what I'm after. Tom hit it right on the head of how to shift people from the "Let me CAD up another copy of a WCD without any understanding of what I'm doing" vs. a "Let me design a widget that I can actually explain."

Judging from Jon and Tom's comments, it sounds like it just comes down to challenging people. "Why did you do that? (and I copied it off someone else's CAD doesn't count)"

I agree with the idea of challenging people, but remember part of innovating is copying. For example, it is fine to copy the way other teams have done a WCD. However it is then important to challenge the students to understand why teams do a WCD like that.

[Aren_Hill]

Originally Posted by DampRobot

The people that are doing truly innovative things don't post them on Chief Delphi immediately. If you see a lot of designs that aren't particularly valuable on CD, it's because those with the valuable ones don't go throwing on the web before they can take advantage of them.

Some things are quite nice to keep in the back pocket till useful

[Ian Curtis]

Originally Posted by DampRobot

The people that are doing truly innovative things don't post them on Chief Delphi immediately. If you see a lot of designs that aren't particularly valuable on CD, it's because those with the valuable ones don't go throwing on the web before they can take advantage of them.

It's not necessarily innovation, it's having students understand what they're doing. No doubt Aren Hill has a 17 degree of freedom mechanism that lets him swerve around the field while capping a tetra and hurdling a trackball (and that's awesome!), but what I want is a sophomore who can CAD a Kitbot on Steroids and understand why 1114 did what they did.

What I'm after is how teams push students at an early stage to go after that understanding so they can build that crazy stuff down the road.

[Tom Line]

Originally Posted by MICHAELABICK

I agree with the idea of challenging people, but remember part of innovating is copying. For example, it is fine to copy the way other teams have done a WCD. However it is then important to challenge the students to understand why teams do a WCD like that.

Copying is the most sincere form of flattery.

I've always been extremely impressed with teams that copy and then give homage to the team that the copied from. Essentially it's an admission that "Your design is so awesome that we had to use it!"

As an example, how many teams copied the ramp launcher in 2011? The stinger in 2012?

Heck, Winnovation's lift system in 2010 forced us to do a rethink that got us to the Newton finals, 1 match away from Einstein that year.

[Lil' Lavery]

Originally Posted by DampRobot

Engineering is not physics. I don't think it should be either.

As engineers, we use rules of thumb every day. Be it tooth strength, aluminium density, motor curves or almost anything else, what we "know" is simply a set of assumptions that are good enough ~%95 of the time. However, there are always statistical anomalies, and we shouldn't try to discount them.

Teaching students rules of thumb isn't a bad technique, it's teaching them how things are done in the real world. If student's ask why, usually their inquisition should be indulged, but we don't need to understand everything about a system to use it, at least not in the way a physicist might. Ask an engineer why a certain alloy of steel has a breaking strength of 25000 psi, and the would most likely answer "because it is." True, it would be great for them to understand at the most basic level (i.e, statistical performance of metallic bonds) why this is true, but it really isn't necessary.

Perhaps I haven't addressed your main point, but I would conclude with this: Engineering rules of thumb don't form the garbage that goes into the making of the robot. They take the garbage of the real world and turn it into more pure, if slightly diluted, data.

There's a massive difference between simply "accepting" material properties without knowing "why" and accepting design philosophies/methods/tools without understanding how and why they exist.

[DampRobot]

Originally Posted by Lil' Lavery

There's a massive difference between simply "accepting" material properties without knowing "why" and accepting design philosophies/methods/tools without understanding how and why they exist.

True, but the point remains. Some knowledge is extraneous to the process of design.

Even the omnipresent design principle "more simple is more effective" has more behind it than even most good designers know. It's just a, well, simplification of the design axiom "minimize information contained in a design." Although understanding this can make a designer better, it really isn't necessary in most cases. For most designers, it's enough to intuit why the "simple is better" theorem is true, rather than doing the more formal deduction that a simple design will usually (but not always) contain less information.

More and deeper understanding is always better, but there's a point where a certain level of understanding is good enough. Why does one plus one equal two? I believe the proof requires set theory, and I certainly wouldn't claim to understand it. Like I mentioned above, "It just is" is a good enough explanation in this case.

I agree that people need to think more before posting one more WCD. Even 254's drive isn't perfect for every game (they do change it every year) and it certainly isn't optimized for every team. Those posting the rather hackneyed WCD clones would do well to understand what aspects of the drive (milled out gears, good tensioning system and a few other things I chose not to name) make it extremely high preforming. Same with swerve drives, who's designers mistake their presence among winning teams with a swerve drive's necessity for winning. (I should know; I unsuccessfully campaigned to have one that I designed built my Freshman year.)

Not to emphasize the typically overemphasized metacognition too much, but designers need to understand what understanding is of high and low importance in order to be good designers. Knowledge, like all things, experiences diminishing returns at some point.