WHY?

Hi to the TCA fans, and thanks for checking out my spot.

The big question was finally asked...why?
An admirable query to be sure.

There are a couple of reasons. Most of all, for a geek like me the oportunity to build my own robot was too exciting to pass up. On that line of thought the idea of being able to build something no one else has yet mastered is almost more exciting than having a whole block of chocolate all to myself. Almost.
The personal reasons for accepting the invitation to tackle this project are actually rather boring though. I found when I had a year off study (the first since i started school, age 5) that I lost interest in a lot of things. By not having something that was keeping my brain busy I was losing the motivation to keep it busy myself. In short I was getting bored. The geek factor was big, and another draw card was the fact that I was jumping from second year diploma level to third year degree level by invitation. Who could turn down such an ego trip, honestly? The Air Force would pay me back every cent of the cost of the paper, as long as I proved it was work related and as long as I passed the course. Free education rocks. And it looks good on my service record. It looks good on my personal file and my CV if I ever make one. The time management and research skills alone would pump my CV to overfull. There are many pro's.

As to why a robot which does nothing more than balance? When I have explained to others I am involved in a project to build a balancing robot, they ask me - "So what does it do.?" And I reply "It balances." I don't think many people really comprehend the sheer processing power reqiured to stop this puppy from falling over. These four processors will be working at speeds of 8MHz, that means it carries out a seperate complete instruction every 125 nano seconds. Even so, I am unsure it will be fast enough.
Our supervisor has chosen a project that requires an immense amount of processing power because once we have completed it he will improve on it. He will remove our standardised and interchangeable daughterboard (with an Atmel ARM computer processor on it) and replace it with a similar board which uses FPGA technology.

I'm not sure I should go down this track or I might be typing all night. The more a person knows about digital technology the easier it is for me to explain, so I imagine it will be best not to get too technical. Let's look at it this way;
A standard processor is filled with little sub systems - counters, timers, analogue to digital converters (ADC's), communications systems, input and output ports, real time clocks, and all sorts of other miniscule gadgets. A programmer reads through the manual and learns how to use programming code to turn on and off these subsystems, controlling them and saving values for later use to get the results we want. To balance this robot, my lab partner and I will program the chip to turn on an ADC, process the gyro input and save it. This will be repeated with the other gyro. Then the program instructs the processor to filter and error-check the inputs. The new values are saved, collated and sent via a 'series communications' subsystem up to the daughterboard. The processor on the daughterboard is programmed to receipt these values and carry out the mathematics, then return the values.
Every move must be covered by us, the programmers. We control, through our code, every subsystem within the processor.

FPGA.
Field Programmeable Gate Array.
An FPGA has no subassemblies. It is an array of switches which can be turned on or off to form pseudo systems. My supervisor took a plain FPGA chip and set it up so that within that one physical device there were two - two - pentium processors. There was plenty of room left for more devices. It's technical but trust me when I say using switches makes FPGAs very fast too.
Now, we can run conventional coding techniques through FPGA's. We can set them up to contain all those sub-systems and then program it as I detailed above. Or we can get a computer to run evolutionary programming.
We give the computer a set of parameters.
"In a five minute period, the robot must not fall over."
The computer blasts the blank FPGA with a random sequence of ones and zeros. Computer runs the robot and the robot immediately falls over. So the computer deletes half of the random code, replaces it with a new random code and tries again. Again the robot falls over. After trying this for a few hundred generations, the FPGA manages to send a message to spin the motors and the robot doesn't fall over until three seconds have passed. The program has been improved.
The computer keeps the good code and scraps the rest, generating more random binary until perhaps the motors move at a better speed or in unison or until the sensors are being read and filtered and corresponding instructions are being sent to the motors. We are talking millions of generations of code, hopefully only taking steps forward - evolving. The computer will keep working until the robot balances on its own for five minutes.
All the programmer has to do is enter in the initial parameters and monitor the progess. And on top of that; once it is complete the FPGA is extraordinarily efficient at running the program and faster than comventional processors.

Back to the initial question - why?
Why? Ultimately to display the enormous processing power of FPGA's and the advantages of the 'evolutionary programming' technique. And yes, a droid will appear from the future to kill my supervisor. But not me because I'm not taking the FPGA paper next year, though I would like to.

I hope that answers the question?