If I only had a brain...
In a lot of ways, the "intelligence" embodied by a robot can be viewed as a distributed attribute that starts with mechanical components and extends up through actuators and sensors, their local drivers and controllers, various subsidiary controllers, to (usually, but not always) a central, high-level coordinating controller.
It is the central controller and its programming, that is popularly considered to constitute the intelligence of a robot. This is not the only way of thinking about robot intelligence. There is a long tradition, most famously introduced by Rodney Brooks (Wikipedia), of considering intelligence as an essentially distributed phenomenon that emerges from the cooperative interaction of system components. There is much to be learned from this view, both philosophically and as a model for biological intelligence. However, current practice and technology, and possibly human modes of thought, favor concentration of computational resources and centralized coordination of activity. In other words, most contemporary robots, even if they contain sophisticated subsidiary controllers, end up with a coordinating "brain".
Asimov's robots had "positronic brains" that handled everything and mysteriously enforced the three laws of robotics (Wikipedia) at some sort of fundamental level. This magic kept people (and robots) safe. Unfortunately, Asimov's "laws" are not something anyone knows how to define or implement in terms of current technology. "Robot central controller" is basically synonymous with "programmable general-purpose processor with computationally complete instruction set", aka a computer. The three laws of robotics thus exist only insofar as they are programmed by the constructor, and thus they are generally absent and/or buggy. Well-engineered special-purpose processors for handling power, communication, and motor control, often have some low-level safety and functionality guarantees built in (e.g. they will shut down if they overheat). Perhaps this is a start, but it is a long way from recognizing a human being and determining that some operation might harm it.
A consequence of the Church-Turing thesis (Wikipedia) is that a computational complete device can be programmed to compute anything that any programmable device can compute (subject only to resource limits). So it can run buggy, damaging, or malicious programs. It is also an (interesting) fact that general programmability doesn't take much structure to achieve. It has proved quite difficult to design non computationally complete instruction sets that are useful outside of very narrow domains. In fact more than one special-purpose language has unexpectedly turned out to be computational complete, or became so with the addition of what seemed a harmless convenience feature.
It is well known to computer programmers that new programs (and second, third, and fourth revisions...) are almost never "correct" in the sense that they work as envisioned. Robot controllers are no exception to this rule. The difference is that classical computers have little influence over the physical world, and thus present little direct risk of physical damage or injury no matter what program they are running. A robot, which by definition is designed to interact strongly with the physical world is another matter. A poorly controlled robot can physically damage itself, its surroundings, and injure bystanders. There is a reason that most current robots are either so small and light that they can cause only minor injury, or firmly bolted inside of cages or human exclusion zones.
One of the great challenges of robotics is to produce robot systems that will execute "safe" commands, but abort or modify "unsafe" ones. In some sense, this is clearly impossible, since there can always be some danger the robot does not "know" about (contrived from the halting problem if nothing else). But even solving severely restricted problems, such as having a robot arm move around flexibly, but not collide with a generic static environment is incredibly difficult. And that's without bugs in the program.
One simple approach to safety is to make robots slow, weak, and physically robust, so that no matter what they do, they are unlikely to seriously damage themselves or co-located humans. We will emphasize this approach in CSC 297. Another is to confine them in no-go zones, which at least keeps humans out of danger. In any case, it should always be assumed that a robot may do, at any time, anything it is physically capable of doing.
For the purposes of this course we will consider the "brains" of a robot to be whatever general-purpose processors the constructor can program in order to help implement whatever it is the robot does. Everthing else we will consider "brawn". Note that this is a bit of a constructor-centric threshold. Lower level controllers, for instance often have "programmable" parameters. As long as the components are used in a "black box" mode, implementing simple, well-defined behavior, we'll consider them part of the brawn. A bit more problematic is the case where the constructor is programming low-level control algorithms into general purpose processors. We'll take these processors to be brain, since their function is not narrowly contrained from the point of view of the constructor.
So how does a computer become part of a robot? As mentioned in the section on motor control, much of the art and challenge of robotics lies not in identifying computers, actuators, and sensors as individual components, but in forging functional connections between them. Computers manipulate abstract bits; actuators and sensors deal in physical reality. They inhabit fundamentally different worlds that are not historically well-connected. And as Hamlet had it, there's the rub (Wikipedia).
In the beginning, if you were a robot constructor, you made your robot out of components designed for industrial automation. (Or if you were really crazy and had years of time and millions of dollars to hire engineers, you designed and built your own components and their interfaces from scratch.)
Industrial components came with proprietary interfaces, and to use them you generally had to buy proprietary software to talk to them and often proprietary hardware to run the proprietary software on. This severely limited flexibility. And was very expensive. Also the software was generally written with a specific application in mind, which was usually not quite right for what you wanted to do. But since it was proprietary you could not modify it to do what you really wanted, or even find out how what it did do was actually implemented. Robot constructors in those days spent a lot of effort reverse-engineering proprietary systems and hacking around their limitations.
If you wanted to program operations that were outside the scope of what was envisioned by the engineers of the system you had bought into, your only choice for computation was a mainframe computer, which had its own operating system to get in the way, and needed all sorts of hardware and software add-ons so it could direct the proprietary automation system you wanted to control. And that mainframe and its power system were not moving anywhere, so forget mobile systems with closely-coupled control (unless you put it in a truck, and yes, early constructors did this)
Things have improved in the last 30 years. On the computational side, the mainframe gave way to the mini-computer, which gave way to the desktop, which gave way to the laptop (which you could reasonably put into a mobile robot). Today we have the smartphone, which if not ideal for controlling robots, embodies technology that is.
On the actuator/sensor side, standards for automation components have gradually become widespread and relatively open. As computer-controlled systems have entered every aspect of consumer technology from toys to televisions to cars to stoves and refrigerators, the variety of available components has exploded, the price has plummetted, and manufacturers increasingly adhere to widely accessible standards.
From the point of view of the amateur constructor, an even bigger role has been played by the radio control toy and hobby market. There have been RC plane (and boat and vehicle) enthusiasts for a long time (Wikipedia). The original technology, however, was rather clunky and application specific. The development of tiny, inexpensive, digital microcontrollers revolutionized the industry. Components became smaller, cheaper, faster, more accurate, more standardized, and more easily available. They also started to become electronically programmable, and thus a lot more flexible. And easily accessible hobyist information forums (fora?) developed on the internet. Suddenly building your own RC whatever, or modifying a stock vehicle to do something interesting was a whole lot easier.
Because they all conform to a single, simple control standard, RC standard components (Wikipedia) are easy to use with minimal infrastructure and technical background. Basically, the standard uses a 50 Hz PWM signal to encode a single analog value, which can represent position, angle, speed, intensity, or any other one-dimensional quantity a component can be designed to actively maintain. The control signals can be easily generated by inexpensive analog ICs (such as the 555 timer chip) and simple microcontrollers.
RC servos provide accessible position control for small robots of all sorts. Small, powerful, speed-controlled electric motors for RC planes and cars are good for anything that has to move fast. Throw in lightweight, inexpensive digital accelerometers and gyros, and rechargable Lithium Polymer batteries, and autonomously stablized toy quadcopters can be bought or built for under $100. The RC standard also spawned amateur interest in larger, usually remote controlled, but sometimes semi-autonomous mechanisms such as those in battlebot contests, and high-school "robot" competitions. This market drove down prices and increased accessibility of larger automation-suitable components
In the first decades of the 21st century a hobby market developed for
artifacts that are definitely robots in our sense of the word
(interacting with the physical world under adaptive, internal control).
The LEGO Mindstorms system
was an early player, but there are now a number
of more flexible and less "toylike" platforms on the market.
Add relatively inexpensive 3-D printers that allow easy reproduction
of complex physical parts, and
all in all, it looks like a golden age for the amateur robot constructor.
OK, back to the rub. Just what hardware is available to the constructor for robot brains? Basically there are three choices: microcontrollers (like Arduino provides), PCs or larger systems (like your laptop), and "card computers" (like the Raspberry Pi). It is not an exclusive choice. Any or all of these component types, in any combination may be suitable for a given robot application. It often seems to happen however, that a constructor ends up programming primarily at one level. For that constructor then, the "brains" lie there.
The classic choice for embedded computation is a microcontroller (Wikipedia). For simple, self-contained robots that don't need to do vision or other compute-intensive tasks, microcontroller brains are very attractive. The Arduino boards we will be using in this course are microcontrollers fitted with accessible pin-outs and just enough additional circuitry to give them some protection against destruction by novice constructors and provide an easy programming interface.
Basically, a microcontroller is programmable, general-purpose processor-on-a-chip with interface circuitry that facilitates dealing with sensors and actuators in real-time rather than batch-processing digital data. Typically microprocessors have built-in digital inputs and outputs, D to A and A to D converters, and one or more accurate clock circuits. On-board operating systems are tend to be minimal or absent, and are often limited to low-level boot-loaders needed to get the processor up and running.
Microcontrollers often utilize variations of the Harvard architecture (Wikipedia) with distinct instruction and data memory spaces, rather than the familiar Von Neumann architecture (Wikipedia), where instructions and data share a single address space. Because microcontrollers are generally responsible for executing only a single program, as opposed to workbox computers that may timeshare resources among dozens of applications, instructions in microcontrollers are accessed mostly sequentially, and are generally not re-written during execution. This allows programs to be stored on various sorts of programmable read-only-memory (ROM), which is non-volatile, compact, and far more energy efficient than full-capability random-access-memory (RAM). Early microcontrollers often had only a few tens of words of RAM. Even modern microcontrollers may have only a few kilobytes of RAM compared to hundreds of kilobytes of program ROM.
Microcontroller clock rates are frequently much lower than those on workbox computers, often as low as a few MHz or even kHz (rather than the GHz typical of PC processors). The advantage is much lower energy consumption. This reflects a basic philosophy in embedded computation which is not to pay for more computational resources than you need. High clock-rate microcontrollers are available for applications that need them.
Modern microcontrollers typically reside on a single chip, though some external power-conditioning components are usually used to ensure robust operation. 8-bit architectures are common, but 16, 32, and even 64-bit architectures are available. Simple ones cost tens of pennies, and quite powerful ones are available for a few dollars.
Traditionally, microcontrollers were programmed by embedded system engineers. This generally involves use of a special piece of hardware known as a "programmer" that communicates with the chip over a special, built-in serial link, using a chip-specific protocol to write the instruction memory and perform other initialization functions. Originally, programmers were provided by the chip manufacturers, and were accompanied by proprietary software providing assembler or compiler functionality allowing the engineer to write programs above the binary code level. Obtaining official programming hardware and the system software supporting it was not easy for non-professionals, and could be expensive.
Microcontrollers tend to be relatively simple for computers, so reverse-engineered programmers and supporting software sometimes became available for commonly used chips, especially after amateurs started to take an interest. The industry has also undergone a slow consolidation, with a handful of programming standards becoming fairly widely adopted outside of the company that originally developed them. An example is the built-in serial protocol known as ICSP for In Circuit Serial Programming. This was developed by Microchip for its PIC family of microcontrollers, and is used on AVRs (the chip in Arduino boards) and Parallax Propellor microcontrollers as well. So called "PIC progammers" are now widely and inexpensively available. Other programmers can be obtained that support a variety of chip families, though there does not yet seem to be a "universal" programmer.
What made microcontrollers easily accessible to the amateur however, was the development of the Arduino system (Wikipedia). This began at the Interaction Design Institute Ivrea in Italy around 2005. The developers took AVR microcontrollers, put them on a board that provided pin-out headers, power conditioning, and a USB-compatible serial interface, and combined the board with an open-source software-development environment that allowed C++ code augmented with a few special functions to be compiled and downloaded to the AVR from a Mac, Windows, or Linux PC. Suddenly programming fairly powerful microcontrollers was both easy and affordable for the amateur.
Arduino was not the first such hobby-oriented system. It was preceded by over a decade by the BASIC Stamp system (Wikipedia) developed by Parallax, and marketed through consumer outlets such as Radio Shack. The Stamp processors were quite limited however, having only a few tens of bytes of RAM. Moreover, the BASIC language was interpreted on-chip, which made programs extremely slow. A major motivation for the development of Arduino was, in fact, the developers' frustration with the limitations of BASIC Stamp as a teaching and experimental platform.
If your robot is big, or if you want to invest in learning to use high-bandwidth wireless channels (e.g. Bluetooth or WiFi), you can use a laptop (or even a desktop) computer. The advantage is you have a lot of computation available, enough to do image or sophisticated audio processing, and standard software development tools are available. Workbox machines also have convenient modes of user interaction - keyboard, mouse, screen windows, are easy to connect to other hardware and to networks via standard wired and wireless channels, and have effectively unlimited storage.
The down side is that stand-alone computers are basically too highly developed to perform crude operations like running motors or reading sensors. They generally only talk to other smart devices. To run a motor or read a sensor from a laptop, you generally need at least one layer of intermediate hardware. Some high-level sensors (cameras, audio recorders) and expensive or complex actuators (high-level servos, robot arms) are available with built-in USB interfaces. Such components can be useful if you have the money, and are probably the best choice if you plan to use computer vision or speech recognition, but for more novel applications you often get stuck with an interface that does not provide exactly what you want.
Another downside of a standalone computer is that it is never entirely yours to command. It's a complex, "living" device that has a lot to do, from listening to the keyboard and mouse for commands from its master, to keeping the screen live and up-to-date, disks and printers running, internet connections active, notification services in order, etc. etc. etc. In other words, it has an operating system that is part of its being. This can and does get in the way of doing anything that needs real-time precision better than a few tenths of a second. Like swinging a bat or putting a foot down, or picking up an egg.
Standalone computers are also relatively big and power-hungry. Batteries last only a few hours. If you ever demo a robot with an on-board laptop, you'll find one of your biggest concerns is keeping the battery from running down at critical moments. They are also relatively expensive. $1000 is cheap if you are on a government contract, but if you are an amateur robot constructor, you may only have one laptop and it's got all sorts of valuable stuff on it. You probably really don't want to put it on that experimental underwater vehicle you just cobbled together.
So suppose, for whatever reason, you've decided you want to control a motor from your workbox. If it is an old-fashioned desktop, it may have have have a RS-232 serial port. There are ways of hacking this using serial read/write commands built into the operating system and accessible from C and other programming languages, to turn on an LED or throw a simple transistor switch. This is a highly sub-optimal approach.
The simplest reasonable option is to obtain a digital-to-analog (D to A) converter box. This is a piece of hardware that connects to the computer via USB, Bluetooth, WiFi (or even through a main bus backplane card, though this is becomming rare). It has a set of addressable outputs that can be set to output a specified analog voltage with at least several milliamps drive capability. To use it, you need to install driver software and possibly link libraries that provide access from your favorite programming language. One protocol is to provide access via serial reads and writes to a named device. The "analog" outputs may, in fact, be PWM signals, or configurable as such. If so, they may be usable to directly drive PWM capable H-bridges or other devices. More complex D to A converters may permit a time-series of values to be specified, and output as a waveform.
The reverse device is an analog-to-digital (A to D) converter box, which does just what you think: it samples an analog input value and makes the result available in digital form to a host computer. Analogous driver and program access issues apply. Many A to D converters permit a time-series of samples to be taken, stored, and then transferred to the host in a chunk. This is useful for sampling audio and other waveforms, but makes the interface more complex.
More advanced robot hardware is, of course, available to be connected to generic computers: cameras, pan-tilt-zoom platforms, grippers, arms, right up to entire robots. That is the point of a general PC. However, the more sophisticated the piece of hardware, the more complex (and often unfriendly) becomes the user interface. Often the devices basically want the whole computer, and don't share well if you want to integrate several together. The interfaces are still often proprietary, opaque, and difficult or impossible to get inside or modify. They are often system-specific, especially as you move away from consumer-level, merchandise, and many play well only within what amounts to a proprietary operating system. Purchasing pre-cooked systems can save you a lot of work, but it come with its own set of headaches. No free lunch, even for robots.
The final option is something so new that the class doesn't really seem to have a name yet. "Microcomputer" would seem appropriate if it hadn't already been repeatedly used for the smallest thing yet ever since the first hulking under-your-desk boxes showed up in the mid-1980s. So maybe "card computer", because they are the size of a credit card.
These devices, exemplified by the Raspberry Pi (Wikipedia), Beagleboard (Wikipedia), and Galileo (Wikipedia) systems, are basically full computer systems on a credit-card sized board. They have processor speeds on the order of 1 GHz, megabytes of onboard RAM, gigabytes of Flash storage, and sometimes even high-resolution graphics processors and video screen drivers. They run full-featured Linux, Mac or Windows operating systems. They use only a couple of watts of power. You can put one on a small, battery-powered robot. They are flabbergastingly compact pieces of technology, and they can be had for $50. They exist because of another flabbergastingly compact piece of tecnology: the smart-phone.
What makes these systems interesting, aside from the almost unbelievable scale factor, is that they are designed for embedded systems development. In addition to support for ordinary PC peripherals, they have digitial and analog IO pins designed for micro-controller-like interaction with sensors and actuators. In a sense, they provide a middle ground between heavy-weight PCs, and microcontrollers.
Because they are complex, multi-functional systems, they have an operating system that must be worked with and around. Working with them is considerably more complex than with an Arduino. Like a PC, they are not ideal for real-time control. Since resource allocation is through the operating system, accessing the I/O pins is not quite as simple as with microcontrollers. On the plus side, you don't need to add extra hardware to turn on a motor or control a servo. And all that processing power has potential. While not as powerful as a full-blown PC, there is enough crunch to perform simple vision and audio recognition tasks.
It remains to be seen just how useful these little systems will be
for the amateur robot constructor.
They certainly seem to have enormous potential.
It will likely come down to robustness and ease of use.
If the OS is crash-prone, or the hardware flaky, or a good, stable
IDE never takes off, (or if big brother decides such things should not
be in private hands),
then the potential may never be realized.
However, if you need on-board smarts, they could be the answer.
One of the first hobby-accessible micro-controllers, has been around since the early 90s. Still found in educational and simple hobby kits. Use of interpreted PBASIC is serious impediment to speed, and limit of 26 bytes for variable storage severely limits the type of programs that can be run and the number and type of sensors and effectors that can be used. Is dominated by Arduino in almost all respects. Only possible advantage is extremely small DIP form factor. Probably not the best choice for even a semi-serious amateur constructor.
Logical successor to BASIC Stamp. Development began in Italy in 2005 at Interaction Design Institute Ivrea. Basically development boards and interactive development environment (IDE) for various Atmel microcontroller chips. Open hardware architecture and software IDE resulted in a large online support community. Numerous arduino/compatible clones are available in addition to "official" Arduino boards. Arduino also supports "shields" which are pin-compatible boards that can be stacked on top of Arduino boards to provide additional hardware functionality. Basically a really nice platform for the amateur robot constructor.
The PIC family of microcontrollers, currently made by Microchip Technology, dates from 1975, and has evolved through many generations. Many different models are currently manufactured, and pin-compatible versions of previous models continue to be made both by Microchip and other manufacturers. PIC originally stood for Peripheral Interface Controller, which became Programmable Interface Controller and then Programmable Intelligent Computer. But everyone just calls them PIC processors.
PIC microcontrollers are still primarily programmed using a hardware PIC programmer. The serial protocol employed is called ICSP (Wikipedia), for In Circuit Serial Programming. Because the same protocol is used by the Amtel AVR and ARM chips in the Arduino, a considerable amateur interest in programming PIC chips has evolved. The result has been that PIC programmers supported by open-source software have become inexpensively available.
Using PICs is still a lot more roll-your-own than using Arduino, but the interested constructor might consider it, since a wide variety of chips is available for a few dollars or less. The chips are "naked", that is not mounted in a development board, but if you have a bot that needs lots of microcontrollers, the price differential alone might make the effort worthwhile.
First widely available hobby-accessible card computer. Developed in the UK out of Cambridge University, starting 2006, by the Raspberry Pi Foundation. Intended to facilitate teaching of computer science in primary and secondary schools. First boards available 2011.
Beagleboard is an open hardware architecture for embedded system development supported by Texas Instruments and Digikey. BeagleBone(2011) (Black Rev-C, 2014) is the recent card computer release. The platform was initially aimed at educational institutes and the Beagleboard Foundation is a non-profit group that coordinates development and promotion. Indirectly of course, the enterprise is promotion for TIs ARM hardware, but it is a rather nice, well-developed system.
Beaglebone supports stacked extension cards analogous to Arduino shields, but called "capes" instead. Several have been released.
Intel's open-source answer to Beagleboard. Rumor has it that the platform is slightly less cooked than BeagleBone as of 2014. It lacks a video card, so is not quite a stand-alone computer. On the other hand, it incorporates compatibility with the Arduino IDE by default, and is pin-compatible with Arduino shields. Otherwise, basically an equivalent system.
Back to Robot Construction main page