Monday December 8, 2008

Why didn't we win the FLL programming award?

By Doug Frevert

The Setup

15 division 2 FLL teams competed at a regional event. Five of the teams were nearly equal in programming, yet only one received the Programming Award. At lunch, with just over a half of the judging completed, I commented that several teams were bunched together at the top. Someone commented that several excellent teams remained. This judge's worst nightmare, "How to pick between different brands of wonderful."

The E-mail

Hi Doug,

We are the fll_team, the first team you judged at the regional tournament (we had red polos on). We are always trying to improve our programming skills and would appreciate any ideas you have to improve our programs. We would like to know what the team who won the the programming award had that we didn't especially because you said you couldn't imagine seeing something better and we finished fourth in programming.

To refresh your memory, we had a go straight program using proportional control and we had a decision program using the NXT buttons (thanks for telling us that they also counted as sensors) to choose which program to run. We had the forklift robot that lifted the house vertically using a clamp arm.

We are attaching the program for you to look at.

We appreciate any feedback you can give us.

Sincerely,
fll_team
H, J, B, K, Z, A, S

This is a wonderful summary of the teams programs, and I did say that I didn't expect to see anything better. I can only imagine their disappointment.

My Response

H, J, B, K, Z, A, S,

I did say that, and I wasn't wrong to say it.

5 teams ended up bunched together at the top.

Each team used a master control program that used the NXT buttons to jump between programs. Most added text to the LCD panel that described the mission and mission setup. One even added a voice to tell the operator.

Each team used comments in their code.

Each team used MyBlocks (SubVi's and local subroutines in the case of the one team using RoboLab).

Several teams converted distances to degrees of rotation. (Note: I'm ambivalent on this having merit, but if the kids can explain why it's better, then it is.)

One team overcame a memory problem (the RoboLab team). I didn't give that team the award, and didn't offer them as a Judge's award because the programmer I interviewed could not give me any details on how they solved the problem. (Even though, by looking at the code I had a very good idea.) That team did not get the programming award.

Another team had a "keep going straight" solution, and I know I ranked them higher; but not because their straight solution was better. It was because they had solutions for:

  1. We rebuilt the robot and forward is now backward.
  2. We need to reset the "how far have we gone" values for all the motors
  3. I also liked their solution to the puzzle of aligning the arrows.

So that leaves, the winner, why did they win?

  1. They used MyBlocks to avoid duplicating code. (Every top-notch team did.)
  2. They never duplicated code. (None of the others went that far, at least not as I remembered.)
  3. That difference allowed the programmers to jump quickly within their code and explain things. I couldn't go deep into their code and stump them.

They also impressed me for showing code without any silly artifacts. There is a very strong suggestion that more code will impress judges. They didn't have anything they added for no reason.

I should note that their code contained an oddity that I don't coach and wouldn't suggest. But I know it works, and it's more preference than a problem.

Which leaves, what can we do to improve?

  1. Don't be the first team of the day. I'm sorry, judges are human and the first team is the hardest to judge (for me).
  2. Be at the top of your game. Show the judge what you're proud of. Show the problem you worked hardest on. I was dying to try to give the team with the memory problem an award. I was hoping to see a spark of anger or frustration or the joy of success; instead I sensed embarrassment -- too bad.
  3. Be prepared to guide the judge to the code that makes your robot succeed. Ten minutes is too little time to examine all the code. That doesn't mean you'll need to talk for ten minutes straight. I'm going to interrupt when I see something interesting. Answer the questions asked and then get back the code you want to show off.
  4. Refactor your code. The code that works, go through it and remove any duplication. When you're done, the code should still work and should be easier to explain to a judge. (If you do this, tell the judge why you did it. Because I said so, doesn't count.)

Warning: some judges reward teams for having a plan for backing up programs and sharing programs between team members and laptops. I didn't ask even one question about it on Saturday.

A Final Word

So, if I do all of this, am I going to win the programming award? Yes.

And no, because the bar just keeps getting higher.

Doug

This was originally written for the NXT Blog section of www.hightechkids.org. During the redesign of that site, it's here.