Reverse Engineering, experiences, advice

[SenorZ]

Our rookie year was chaotic. We only had about 12 regular students and a handful of occasional participants. This put a heavy burden on myself and my fellow mentor to do a good deal of design review (a.k.a. redesigning) and planning for the students.

I felt that a good way to introduce new and prospective members of the team to robotics is to reverse engineer our LogoMotion 'bot. Taking apart the robot and looking at the function of each part, and how they interconnect should be a good learning experience. I also want new students to develop a preference of what role they want to serve on the build team: electrical, programming, drive system, etc.

Has anyone done this in the past? If so, do you have any advice?

[DonRotolo]

Somewhat related comments:

I think deconstructing your last bot is a great idea, but add the goal of reassembling it again. It will make a dandy test mule for ideas.

As for mentor overload in the design arena: Instead, teach the kids how to follow a prioritized and iterative design process. By that I mean the should...

First, understand the Game and what it takes to win it, including nuances of strategy. Maybe only one or three kids will understand these nuances, so let them explain to everyone else. (We all know what it takes to win a baseball game, the game's been here for years. But think of some of the strategies that are used: Would a bunt be an obvious play or a nuance? Think of the Game in those terms)

Second, decide what Tasks the robot must be able to perform to win the Game. This is a great brainstorming activity. No mechanisms (you have to control that with an iron fist) just capabilities.

Third, once "everyone agrees" (or at least there's a majority) on the Capabilities, then determine which ones are most important, and list them in order. This is important, as it determines which Capabilities are lost when design tradeoffs must happen (e.g., Crunch Time).

Fourth, brainstorm Mechanisms to perform those Capabilities. This is the fun stuff, go wild for a day or two. (For 1676, this happens on the first Tuesday & Wednesday of Build Season).

Then, let the proponents of a Mechanism go prototype it. Cardboard, styrofoam, wood, whatever - "Proof of Concept". 2 Days.

Friday or Saturday is Design Review, where the Mechanisms are selected.

Them for the next 5 weeks, everyone is fabricating Mechanisms they know a lot about. If you get some kids well-trained, assembly can happen in week 3-1/2, with furious re-fabrication and final assembly in week 4-1/2.

Then the drivers get it to break it, and if they are successful, you build the better, stronger mechanism part in week 5-1/2, slap it together and crate (or bag) it.

(Programmers start in Week 2 BTW because the mechanisms are defined already).

Hope this stimulates some discussion.

[SenorZ]

Much appreciated. I was also thinking of using pulling an old game from years ago, which none of us are familiar, and do a mock kick-off... see what the kids come up with, then compare to championship robots.

[Phyrxes]

Originally Posted by SenorZ

Much appreciated. I was also thinking of using pulling an old game from years ago, which none of us are familiar, and do a mock kick-off... see what the kids come up with, then compare to championship robots.

We just did that with our new students and it seemed to work really well, by making any "skill building exercises" related to a project the students were more engaged than past years.

After planning out what kind of "ball shooting mechanism" they wanted to build we watched the finals at the championship.

At the end of the day we had a first iteration mechanism, that doesn't work very well, and the students have a plan for the second iteration for the next meeting.

Over the course of the day we introduced them to basic design and strategy, our shop, and got them working together collaboratively.

[Brandon Holley]

The mock-kickoff is a great exercise for your team to do. It allows you to really dig into a problem that will be very similar to what you will be doing when actual kickoff rolls around.

The best part about a mock-kickoff is if you do it in a way where students don't know it was actually an older FIRST game. Because you are a young team, you have the ability to present a game as if you designed it yourself. The reason I bring this up is that after you have gotten what you want to out of the mock-kickoff, you can surprise everyone and show off some robots playing that particular game you "made up".

This will allow students (and mentors alike) to see some of their potential ideas succeeding or failing in the actual game.


Another extremely useful exercise is to take dominant robots from years past and revere engineer them. Find out why that robot did so well in competition. What aspects of their design were integral to their success? Did they approach the game in a completely different way than everyone else? What were their weaknesses? You can also boil down to the nitty gritty details of their specific mechanical design and determine if its something your team could do.

Reverse engineering other teams robots will also intimately expose you to many other teams robots as opposed to just your own. You may be able to get a feel for what tends to work, and what doesn't.

Good luck!

-Brando

[mathking]

We have had good success with reverse engineering. We take photos during the process, which can be used as references later. This has proven particularly useful for the electrical team. As Don said, putting it back together is good too. In general we have the new kids put it back together, mentored by the veteran high school students.

[Ian Curtis]

Originally Posted by DonRotolo

Somewhat related comments:

I think deconstructing your last bot is a great idea, but add the goal of reassembling it again. It will make a dandy test mule for ideas.

As for mentor overload in the design arena: Instead, teach the kids how to follow a prioritized and iterative design process. By that I mean the should...

.snip.

(Programmers start in Week 2 BTW because the mechanisms are defined already).

Eep! Your programmers should be involved from the very beginning! A robot is a systems challenge, you need to make sure the mechanical people know where to put those pots and encoders, and the software people need to know what kind of response rate they'll be getting from the mechanism and what kind of automated functions they'll be expected to generate. In particular, most teams do not have programming geniuses that can make complicated mechanisms easy to control so its vital that subteams work together to generate a design that can be fully fleshed out mechanically and robustly coded. Many a decent arm has been rendered ineffective by a jumpy non-linear response to driver inputs, and I've lost count of the number of Mecanum drives that end of spinning in circles in a corner of the field.