Robot: a Czech neologism approximating the English word for "servant". It is a word that has caused considerable confusion over the years, since neither science fiction authors nor engineers could agree what the word was to signify. Today it covers a huge number of applications, from medical micromachines monitoring and regulating human medical problems to machines designed to guide the production of machine parts. There have been suggestions that robots might evolve, becoming part of artificial evolution. Winged robots have been designed to learn how to fly using evolutionary algorithms to do more than just flap helplessly.

Geeks Build Robots
At the other end of the spectrum, robot building has become a respectable hobby for geeks of all ages and continents. Lego Mindstorms was a surprise hit of the late 1990s, making robotics and robot-like behavior that could be implemented by the silent - or not so silent - geek majority. That mobile robots could be built from off-the-shelf parts wasn't a new idea, but very few companies sold parts that could make a plug-and-play robot. Robots that could clean, vacuum, guard the pantry or get out of the way of arrogant organics cost less than laptops these days. Wireless cards and small VIA motherboards make mobile robots with a huge number of fairly intelligent decision and manipulation abilities affordable.

There is the field of robotic combat, but given that most combat robots are remote-controlled and irrelevant to personal or industrial robotics, we shall not pay very much attention to them.

Geeks are Adolescents
Lego Mindstorms made an appearance not so much because of its popularity, but because it illustrates an important truth: robotics appeals to and is accessible to 12 year-olds. Although it does not follow that robotics research is accessible in the same way programming or mathematics can be accessible to teenagers, the ability to hack and design semi-autonomous devices with interesting behaviors has created a virtual industry covering almost all ages and ethnic groups.

Home Brew Robotics or the Bloody 70s Again
The Home Brew Robotics club located in San Jose in Northern California harks back to a proud tradition of hack-yourself technology made prominent by the Home Brew Computer Club of the late pre-PC age. Hacking robots actually relies on the ability to hack motherboards - and even more importantly, it relies on the ability to source the correct parts. White Box Robotics in Pennsylvania has been created to permit sourcing parts that are broadly compatible with the major standards in the PC world. The idea has found imitators, but most other stores prefer to sell proprietary robots; few sell robot parts in appreciable quantities or parts that adhere to popular standards.

What are Little Robots Made of?
Which, quite naturally, leads us to the all-important question: what are the constituents parts of a robot, regardless of whether it is a humanoid robot, an animal-like robot or an unmanned vehicle? First, a robot needs sensors. Second it needs effectors, i.e. wheels, legs, or wings and actuators, e.g. motors of any kind to drive effectors. Thirdly, it needs a system enabling the robot to move, although production robots have been built that did not have the ability to move. Fourthly, it needs a computer system evaluating all inputs and deciding on appropriate responses. Naturally, the robot needs controllers for all system parts, which means software has to be written.

Robotics is Not a Science
The craft of robotics can be roughly divided into mobile robotics and manipulator robotics. The latter part deals with the construction of extremely sophisticated haptic devices capable of multiple degrees of freedom and object manipulation. Mobile robotics tries to construct systems enabling locomotion. Now it seems almost funny to see robots with 6 legs or 3 wheels negotiating dangerous locations, but we shouldn't forget that much of robotics has to obey rules of kinematics and stability that are far more difficult to implement than it first looks. Nature had a few billion years to figure out how to teach a dog to run. Robot designers are not allowed to take more than a few years at best.

Robot designers live at the crossroads of many fields of enquiry. Mechanical engineers have to communicate with computer vision specialists and artificial intelligence programmers have to talk to electrical engineers. Cooperation between departments, universities, companies and individuals has been common in the field for many years, but since the late 1990s it became fairly clear that some countries seemed to be more comfortable with cooperative research directed on a national or even international level than others. Japan and the US had a proud record of state-directed research, libertarian propaganda to the contrary notwithstanding. Japan's record in consumer and industrial robotics is outstanding, a development that tends to be hidden behind cutsey robot dogs like the Sony AIBO and slightly gross fast food adverts involving Japanese single men and their household robots.

EU Robotics
The reality for robotics researchers was less amusing. There were no interface standards that could be reliably deployed and commercial control software kits turned out to be tied to the hardware they were coded for. In late 2000 a heterogenous group of European university departments, strongly motivated by complaints voiced over the years on the EURON (European Robotics Network) mailing list, and financed by the European Union, formed a large group of university-based programmers from Belgium, Sweden and France. They decided to design and code an open source robotic control software kit, called the Open RObot COntrol Software or Orocos.

We will go to Orocos, Not Caracas
Orocos is divided into two parts; the more general module collection covers general machine control. Its evolution and success led developers to generalize the robot control API such that robotics concerns could be ignored to some extent. The more robotics-specific "Open Robotics Control Software" has a stronger emphasis on robot kinematics for haptic robots and dynamics for motion. This does not mean, however, that Orocos-based applications will compile on all hardware or operating system the roboticist cares to run. Device drivers and hardware control are separate concerns. Orocos provides some device drivers, but they are hardly more than reference implementations. This is, however, not a problem for robotics programmers who are likely to make fairly swift work of writing device drivers.

Now Orocos is nothing like, say, the Linux kernel, which after some configuration and adding a number of tools, runs on pretty much any 32-bit and quite a few 64-bit architectures once would care to think of. Indeed, Orocos is likely to use the Linux kernel itself via a real-time interface to talk to hardware. Orocos is meant to be a framework for robot and indeed machine control generally. Sensor processing algorithms and device drivers are definitely not part of Orocos. On the other hand, Robot control applications have to be written by programmers using the framework, but at the same time, Orocos provides a baseline robotics researchers can work with.

The toolkit has been written with strict object-oriented design principles in mind and the language used throughout is C++. For non-realtime applications, vanilla Linux kernels version 2.4 and 2.6 can be used to install and run Orocos-based applications; vendor-supplied kernel variants are unlikely to be usable out of the box. Although Orocos supplies operating system abstractions, major work would need to be done to get it to work on real-time kernels that stray too far from Linux-like kernels. Still, it provides a C++-based framework whose backers encourage further contributions, particularly in humanoid robotics.

Player
A completely different approach was taken by the platform and language(!)-independent "Player" project. It focuses exclusively on sensors and actuators and it tries to establish a client-server-based framework to permit TCP-based communications between robot-based devices. This means that communications and control are pretty much platform and hardware independent, with only minimal sacrifices in terms of speed and efficiency.

Player is POSIX-based, and quite unlike Orocos is unashamedly harking back to the Unix tradition. Multiple clients can run and manage multiple sensors and actuators. There are clients written in languages as far apart as Tcl, Python, Java and Lisp. The fact that several clients can be instantiated at once is due to the fact that the pthreads (POSIX threads) library has to be included in an all Orocos-based applications. Development and indeed compilation of Player has to happen with gcc installed, which makes porting to different architectures fairly straightforward.

Player runs on a number of robot and computer architectures and as an additional bonus allows programming for the Segway Human Transporter. It was created at the University of Southern California under DARPA and NSF contracts - in some ways it is a continuation of previous operating system projects like BSD Unix, although the problem domain is radically different.

Why Humans Simulate Robots
Robotics is a field where developers do not rush headlong into hardware design or even building. Mechanical inventiveness is important and if the robot is likely to be given more complex behaviors, the robot has to be able to compute movements and goal-directed behavior, sometimes in a multi-robot environment and within an irregular landscape. Simulation is extremely important and since much of the development has to happen on a software basis, it is often possible to build software simulators so precise that hardware implementations exhibit few failures.

Why Robots Play on Stage
Player is the basic foundation on which robot development and simulation environments can be run. "Stage" is the GPLed simulation environment run on top of Player. Stage provides a 2D environment where mobile robots, sensors and various inert objects can be displayed and their interactions modeled. The emphasis is on cheap and dirty simulations of multi-agent environments, rather than 3D simulations of realistic environments. Virtual sensors and robot controllers can be tested without having to play around with a real robot; the Stage client does not distinguish between the real thing and their software representations.

There is a certain advantage in using virtual environments and virtual robots: it is possible to simulate devices the researcher might not have available. Some might be complex to implement like differential steering or a multi-wheel configurations.

Robot simulation on Player can be made realistic though by the simulation software Gazebo: it does not emphasize multi-agent interactions quite as much and stresses the importance of realistic interactions and rigid body physics. It is also much easier to manipulate virtual objects, something that the original developers of Player are still trying to incorporate in the original platform.

Player, Stage and Gazebo have all been GPLed and DARPA and the NSF have financed their initial development. Stage and Gazebo would work with different robot device servers although all of them run on PC and PPC architectures.

Robots Must be Standardized, Andrew
The slow drive towards robotic software standards has of course had the more pleasant effect of enabling hobbyists and small industrial robotics. The automation of production lines, which is where most robots were to be found quite recently, does not relate much to the world most people live in. One could make jokes about Robomowers and Robovacuums, but these are already commercially available in Japan and the US. But to establish truly workable standards, organizations like the Robotics Engineering Taskforce (RETF) have to work towards their goals for a number of years.

Open source programmers and hardware hackers have been and will be deeply involved in development of small, sophisticated robot applications. More importantly, the expansion of modern education has led to a huge increase in engineering practitioners who are perfectly capable of delving into fields like manipulator robotics or even computer vision. Household robotics is just one very narrow field that led to a huge number of idiosyncratic hackers building little helpers keeping the house in order and the family amused. Isaac Asimov's robotic dreams have to wait for a few years.

Some roboticists argue that the time for reference implementations has come; to come up with more APIs and to get public agreement on their efficacy is a process likely to take years. POSIX standards for real-time programming already exist and are on occasions used in robotics. Realtime kernels and standards are a dime-a-dozen and with ecos and RTlinux, fully GPLed real-time systems are not difficult to come by.

When it comes to kinematics and dynamics, it is definitely not as simple as coding up a number of mathematical routines that can be used out of the box. Too many robot configurations are possible and there is little agreement on optimal robot configuration or even robot size.

OAP
But there are problem domains that are rather more well-defined than others; and, curiously, they seem to lend themselves to reference implementations. The Open Automaton Project (OAP) is one such example. The purpose of it is simple enough, namely the assembling of PC-based home and office robots from off-the-shelf parts. The spending limit for OAP robotics troublemakers is supposed to be $ 2000 and the software toolkits are all running on Linux. This adds a certain degree of complexity to the project, given the fact that, e.g. infrared sensors often need different "operating systems" like the proprietary OOPic to run at all. But software like Player is used and seen as the platform from which to extend the robots functionality.

It is not unusual for such systems to run 2 or even 3 operating systems depending on the degree of realtime responsiveness and predictability needed. To some extent it also depends on the degree to which a particular sensor OS has attracted attention from programmers interested in Free Software. TinyOS and other efforts are directed towards sensor networking rather than realtime data collection or device control and are not considered realtime operating systems in the strict sense.

The question remains as to whether robotics platforms can be standardized in the same fashion as internetworking was standardized in the not-so-recent past. There are some similarities: multiple devices have to communicate via preferably standardized interfaces. Mobile robots have to be able to network with and to perceive each other. Networking has tried and tested standards, but quite a bit of work has to be done to establish the minimal functionality a robot has to show to be seen as a robot at all. One can only wonder what will happen when humanoid robotics is finally turning into more than a science fiction cliche.

The Shadow Robot Company
GPLed robotics software and GPLed robot implementations and robot schematics are one thing. Building a company around the very same software is another. Fundamentally, software written in C or C++ is inherently portable as long as it runs on any system that's roughly POSIX compatible and uses gcc and the autotools for compilation. When it comes to developing parts of a robot that can do humanoid manipulation and the developer uses Debian Linux, gcc, C/C++ and a few realtime networking protocol implementations, a considerable amount of skill and idealism is required.

The company is located in England and it is called - in a Babylon 5 sort of way, for you Science Fiction addicts out there - the Shadow Robot Company. They have produced a number of products, but there are two projects, which are frankly nothing short of astonishing. The company has tried for the last 12 years to produce a biped robot and in this Sisyphean task has made impressive advances. Before we can all go off and toast the appearance of Commander Data in our century and wonder what time portal he has fallen through this time, this is a project to discover the laws of walking, to build hardware for it and to find computationally feasible algorithms to control the process beyond standing and staggering for a few steps. Again, we have to remember that nature took hundreds of millions of years to enable upright walking on two legs. Here, a bunch of courageous roboticists use CANbus, PIC controllers, and wooden skeleton that fairly accurately mimics human anatomy and Debian Linux to build a walking robot.

The company also developed a robot hand (Shadow Dexterous Hand) that has elicited admiration in many quarters. In some ways it imitates a human hand with some precision although it is likely that a human hand has less degrees of freedom than its artificial cousin. It must be said that neither the biped nor the Dexterous Hand use any of the robot control libraries or standards presented in the article, but Shadow's code has been GPLed. The Hand is made of steel, aluminium, acetyl and various other materials; the actuators are driven by a rather unique invention called an air muscle and the overall contraption looks as if it only needed some skin to pass it off as almost human. Its uses are many: from medical applications in telemedicine to laboratories, equipment testing and of course, entertainment, the Hand can be used independently and as part of a larger humanoid composite.

Only long-term dedication within a fairly small dedicated engineering team made this possible: we can safely rule out the possibility that a multinational corporation or an industrial research lab would have been able to produce robot parts of this quality. Sony's efforts in this regard were impressive as well, but cutting edge products are not available to a larger audience and the code and schematics are not available to an open source programmer. For the moment, humanoid robotics is a niche market. May it become ubiquitous.

Frank Pohlmann

References
Lego Mindstorms http://mindstorms.lego.com/eng/default.asp?domainredir=www.legomindstorms.com
Open Automaton http://oap.sourceforge.net
Homebrew Robotics Club San Jose www.hbrobotics.org/
Robot Evolution
www.frc.ri.cmu.edu/~hpm/project.archive/robot.papers/2000/robot.evolution.html
www.wired.com/news/technology/0,1282,54900,00.html
Orocos www.orocos.org
Player, Stage and Gazebo
http://playerstage.sourceforge.net/
http://playerstage.sourceforge.net/gazebo/gazebo.html
The Shadow Robotics Company www.shadow.org.uk/index.shtml
Sony's Aibo www.sony.net/Products/aibo/index.html
CANbus www.canbus.us/
Realtime kernels and realtime control
http://sources.redhat.com/ecos/
www.rtai.org/
www.fsmlabs.com/