"Show me how it doos."
James Clerk Maxwell at the age of 3
I've always had a fondness for James Clerk Maxwell, the famous mathematician, and I've always found it difficult to come up with meaningful names for my projects, so I decided to name my new robot project "Maxwell." Given Maxwell's inate curiousity about the world and how it works, I'm sure he wouldn't mind lending his name to a brand new robot soon to start discovering the world around it.
Doing some initial thinking about Maxwell (the robot that is, not James Clerk), I wanted to map out some discrete layers or functional levels. The exact purpose behind Maxwell isn't clear yet - and perhaps it never will be. But I'm willing to embark on the journey just for the sake of the journey itself and the learning that will come along the way. Still, a little advance planning never hurt, as long as it doesn't get in the way of having fun.
So, given that I don't have a clue what I really expect Maxwell to do, how can I go about doing any planning? I decided to set totally aside the "final outcome" for now, and focus on the basic "what" instead.
Initially I don't even want the "how" to be a factor. If I start taking the "how" into consideration at this point its constraints will automatically build limitations and restrictions into Maxwell that I might not be happy with later. For example, if I decide at this early stage that I want to use an IR distance sensor, then every decision about distance sensing after that becomes centered around the strengths and weaknesses of that particular approach. Over the years I've found it much more advantageous to approach problems from the other direction. In this case I would determine what I want to sense - say distance - then look at all the possible alternatives, narrow them down to about three or four practical approaches, then figure out what is the best solution for what I need to accomplish. I might still end up using the same IR distance sensor, or I might use something completely different.
A good example of this is Steve Hassenplug's Legway robot. Steve wanted to try his hand at a Lego version of the famous Segway. To solve the two wheel balancing problem at first he looked at gyroscopes, accelerometers, and other solutions. But, by focusing on the 'what' instead of the 'how', he realized that he could simply measure the distance between the ground and two optical sensors mounted on opposite sides of his robot. Instead of taking weeks to design and debug, Steve was able to put together a working version in one evening.
A good place to start is to group Maxwell's basic functions into groups. No matter what his final objective is, he will need to sense the world around him, move somehow, and communicate. Otherwise he might as well be an expensive brick.
Within each functional group I've listed the subfunctions that immediately came to mind in the rough order that I might go about implementing them. This, like all things in life, will change over time.
Sense - Proximity sensing will be important for Maxwell to avoid running into things or crashing off the edge of tables or stairs. It might also play a role if he wants to be a soccer player when he grows up (don't laugh - the folks at the San Jose robot club are working on soccer robots.) Being able to sense light and sound could also be of great practical importance. I'm not a big fan of line following robots, but who knows - I might want Maxwell to do that kind of thing at some point in his development. Sensing position, especially absolute position in some world coordinate system could present some major challenges, but I don't want to automatically rule it out at this early stage.
Move - Maxwell should be mobile. He should be capable of moving around under his own power - at least as long as the charge on his batteries holds out. And it would be useful if he could grip or interact with other objects physically in some fashion.
Communicate - Maxwell should be able to communicate in someway with the outside world - blinking leds, beeps, whistles, perhaps even with a voice at some point. That type of functionality is great for monitoring and debugging, and it adds a great deal to the overall experience of playing with a robot. Being able to feed back his data and observations to another computer - say my laptop PC - would be great.
I want to use this as a basic structure that I can build on as Maxwell evolves. I tend to believe that as Maxwell becomes more and more complex some functionality may need to be off loaded to one or more co-processors. For example - many simple 'first' robots use the processor/controller chip to directly control the drive servo/motors. This usually entails putting the processor into a short delay loop to kill time during each one of the moves. A simple robot doesn't have to deal with many inputs, and doesn't have to make quick, on-the-fly decisions. On the other hand, if Maxwell wanted to be a competitive robot soccer player, he would have quickly sense the world around him, track the ball, perhaps avoid the opposition, and be fast on his feet (wheels.) There wouldn't be anytime to waste going around in delay loops just to control a servo motor pulse width. If and when Maxwell gets to that level, I will have to implement some type of co-processor scheme, and I know I won't want to be faced with redesigning everything from scratch. Keeping Maxwell's functional grouping in mind as I develop the hardware and software may (hopefully) make expansion and change much easier later on.
At least that's what I hope...