One day Steve Jobs was given a presentation by Apple engineers on the status of a major project. He listened, frowned, and replied, “We still don’t have a product.”

That’s the issue that has been haunting me the past couple of years. I have a robot, now I have a kit. But do I have a product?

A product is not just a collection of parts. It’s not just a collection of parts that function well together. A product is something that people want to buy.

A while back I honed my soldering skills with a ‘eurosiren’ kit. It was very informative, as far as learning to solder goes. But when I was done, I turned it on for about two seconds and then turned it off and put it away.

A soldering kit qualifies as a product, but I don’t think the same concept of a kit-for-the-sake-of-learning-by-making is going to work for little Grisbot. That eurosiren soldering kit only cost $15. Will users be satisfied spending $25 (or more) to build a robot that merely follows a preset path? I don’t know, for that price point I think people expect a greater level of functionality when they get done with it.

So today I was thinking, “Maybe I could make it into a game.” The idea is to draw obstacles on the screen, then make an obstacle course on a table (or hard floor). Presumably, the obstacles would be something like, but not necessarily, lego bricks. But merely drawing the path on the screen wouldn’t be enough. The robot has to be calibrated for turns and moves as well.

So I sketched out a multi-screen computer interface like so:

Per the game aspect, points would be assigned according to the complexity of the course and how many tries it takes to program the robot correctly to complete the course. The computer-based program would communicate with the robot through screen flashes. It should be written in something easily accessible, like Scratch or the browser-based version of Processing. As for the microcontroller-based program, that would take a revision of what I have now, but not a big one.

If I can come up with a couple more gamelike elements, say like hooking a ‘prize’ and returning it to base, I might just indeed have a product.

* * *

So what happened to my intent to make a calibration routine? Well, manual trial-and-error calibration is going to be part of the game now.

But just to let you know, I did do some programming on how to stuff calibration values into EEPROM so that they can be automatically retrieved and don’t have to be entered manually each time the robot is turned off and on. The main problem is converting variable types from unsigned long (for time measurements) into bytes (for EEPROM storage).

Here is the preliminary program I drafted, which I may yet get around to debugging and using:

The tricky thing is to make sure the read/write commands don’t burn out EEPROM. The ATMega328 EEPROM is good for 100,000 cycles, which can last decades if you’re using the commands only once per program run, or it can last seconds if you accidentally include them in an infinite loop.

But I’m off on a new tangent, so maybe I won’t have to worry about that for now.