Entries by team members

Recent Googles

How to Write Great Programs
Learning From Our Sponsors
Recently, Mr. Nick Duffill, from Gyronix, graciously sent us these few suggestions on how to write great programs. We decided to post some of his suggestions and add some of our own experiences. (His key points are in bold.)

Don't let the robot ASSUME anything.

This is great logic. Recently, we had been under the impression that our robot would fix the error of shifting slightly to the right if we pointed it in a different direction (even if the direction was completely the other way!) When that didn't work we tried reprogramming it, but that didn't help either. We went down the list until we had finally run out of options. Suddenly, we realized that our robot's batteries were almost dead. We changed them (unfortunately, the robot was too powerful for the program we had made) and fixed our problem.

Explain your program a step at a time to someone else. Often you can spot something yourself, just by explaining it aloud.

I wish we learned this lesson a couple of years ago! We had been programming our robot to do a basic challenge of driving forward for one second and stopping, just to test a new robot design we had built. Unfortunately, instead of programming it for 1.0 seconds we programmed it for 10. seconds. Unaware of our disastrous mistake, we hit the run program button. Needless to say, our robot traveled at incredible speed and finally stopped after smashing into a wall and completely breaking apart. We were disappointed and explained to the coach what had been supposed to do, that's when we looked over our program and found our mistake. That day we learned two lessons: pay attention to your program, and reinforce your robot so that it will be stronger and less likely to break apart on impact.   :-)

Try to think of all the different ways something could go wrong, and make a plan for each of them. However many you can think of, the robot can always think of one more!

We have no experience in this area, but we hope to put that theory to use. It sounds like a good idea!

Make one person responsible for testing.

Write down a ''test plan'' and check it off step by step each time you run your test.

Test, test, and test again. Testing is not boring! You must give the robot every chance to tell you if it is unhappy.

In the past, our robots seemed to have the aggravating tendency to run perfectly in all the tests every time...except for on the night before the competition. By that time, we are already tired and nervous and it really gets tedious. Somehow, our robot seems to fix itself in the competition, for we don't seem to have as much trouble as we had the night before!

Always test in the same way. Don't just test the parts you changed. Go back and test over, even if your sure it will work.
Another right before the competition story. Three days before the big competition at LEGO Land, we changed our arm and only tested the program that we thought should be tested. We were upset to find the next day (after we had run through all of our problems) that all of our programs had been affected. Thankfully, the changes were minor and we fixed it in time.

Always be alert when you're testing. Look for anything that seems a bit odd, and test it again.
I guess this means we shouldn't hold our meetings late at night!   :-)

Make a note of anything that went wrong, even if it happened only once. You might see a pattern over several tests.  

The best test of all works like this:

1. Find the most important person you know.
In this case, that would be the coach with the video camera.
2. Tell them: ''This works great every time. Watch while we show you how good it is. It never lets us down''.
We have indeed done this!
3. Repeat step 2

4. Run your demonstration. It will probably go WRONG! (The robot can tell how important your guest, and act up.)
I don't think I need to go into detail about this one.
5. Start apologizing and say ''It never did this before''. This is the BEST way to find out if something really works, or whether it only works when YOU are watching it. Now fix what went wrong in the demo!

Before fixing a bug, always make sure you can make the bug happen. When fixing bugs most of your time should go into being sure you can make it go wrong in the first place. If you can make it go wrong, then you can be sure you have to put it right.

Only ever fix one thing at a time, and test it again after each fix.
We won't even go there. (Seven girls crowded around one robot with LOTS of bugs...)

Sometimes, software acts up like it has a mind of its own.
Let's see. How many times has this happened? 1...2...3...4......

Sometimes it does ''Impossible'' things that it just can't do. This means... How you think it is working is not how it is REALLY working, you are probably ASSUMING something that the robot isn't, and it's probably just doing exactly what you told it.
Back to the mixed up seconds story.

To fix these, you have to make a guess about what could be going wrong. Try to think of three different reasons that it could be going wrong. Then, think about how you could test each one and prove it right or wrong. Test each one of your guesses, one at a time.

After reading this entry, I have been constantly reminded of the funny (though not so funny at the time) mistakes we have made in the past. I hope to put these ideas to use in this years competition. Who knows? It might save us from making some serious mistakes!

Here's the mind map that Mr. Duffill sent us: 20060909 - How to write great programs (From Gyronix).mmap

Posted by Amy at 08:13:00 PM on 10/05/2006
0 Comment(s)
No Comments Found

Discussion for this entry is now closed.