2012-10-31

Android x86

One realization i got while working with the software stack for the robot was that the software will have to be distributed over a pretty heterogeneous mix of hardware. Each hardware will run a piece of the software that each perform a part of the processing needed for the robot.

Some of the hardware/software components are on a low level, and need to run real-time and have a very narrow and predictable set of responsibilities, while others are on a higher more administrative level.

Deciding which authority is given to the components and how they communicate will be an ongoing and difficult task. Several strategies exist. One is distributing the decision making the farthest possible way down, so that each component has as much as possible authority to solve problems on their own, giving the robot more resilience to errors in communications.

The opposite approach is of course to centralize as much as the decision making as possible in one central device that then commands the other subsystems, making the decisions more informed, and quicker, but making the solution more vulnerable to single point of failure.

I think that both strategies have both weak and strong sides, and that I will have to make a decision in each separate case whether to put authority centrally or distributed. In other words, an intelligently configured hybrid may be the best solution.

"What does this have to do with Android"? you may ask.

Well, the software that will be put on the embedded low-end hardware will be mostly purpose built and even firmware in some cases, but at the higher levels we will need something really flexible, yet efficient and modern. Something awesome. And that is in one word: Android.

Illustration photo HP tx1000 convertible tablet


That's why I am building Android for x86 to fit my HP tx1000 convertible tablet computer right now. Hopefully it will let me develop a central, top-level, main brain app that can command all the other subsystems big and small in perfect unison.