MAPS AND NAVIGATION
Seeing an object, noting its relationship (distance and orientation) to the robot, and identifying it is just the first step. This information can create a map of the surrounding area, enabling the robot to plan its movements or determine that certain goals were reached.
Maps used by robots may or may not be similar to the maps we use. They're all logically similar, but they may have different storage methods. If the environment is sparse, a robot simply may have a list of objects and their attributes (such as coordinates or landmark information). A grid-style map would be more useful in a dense environment. There's also the issue of 2D versus 3D maps, depending on the restrictions of the environment (e.g., limiting a robot to a flat surface). No single approach is valid for all applications. A constantly changing environment, among other issues, may determine how map-related information is stored and updated.
One difference between our maps and robot maps is related to uncertainty. If a robot hasn't seen or visited an area, then it may be uncertain of what will be found at a particular location on its map. It may not even be possible to get to a particular point, so the robot also must keep track of different types of map information.
A single map could be used in a more complex environment where a robot is moving or part of a group, but it's often more useful to build up a hierarchy of maps. This typically translates into a two-level mapping system, which can be effective for both individual robots as well as cooperating robot swarms.
The higher-level map normally has less detail and changes less often. It may be maintained by one robot within a group. But it's typically replicated to provide a more robust system, as many of these swarms are designed to work in hostile environments where losing a robot isn't unusual.
The robotic software frameworks often incorporate this type of hierarchical mapping. It tends to be a requirement if the framework also provides navigation support. This navigation support is essentially a very specific planning system that uses the mapping information to generate a movement plan to get from point A to B without running into an obstacle.
A high-level plan may indicate that the robot must go north down a hall and turn right (east). The robot may use its local mapping and navigation to go down the hall but move around obstacles that may be in the hall such as a chair or box.
Handling this split between high- and low-level planning and execution may sound simple, but it tends to be much more complex than most developers anticipate. Again, a framework can make the developer's job much easier. Unfortunately, the exercise isn't trivial, even with framework support. Still, developers no longer need a PhD, although it helps.
HARD PLATFORMS
Software robotics platforms are very important, but so are hardware platforms. In the past, most robots were custom-made from the ground up. New components like digital camera and compact processor modules have simplified the job. But the platforms that specifically target robotics have made the difference.
One example is the 914 PC-BOT from Whitebox Robotics (see the story's opening photo, p. 39). Designed to use off-the-shelf components, the 914 provides all the basics, including mounts for a Mini-ITX motherboard, multiple cameras, and drive bays. It includes wheeled locomotion, high-amperage batteries, and a steel frame. It's available with its own software framework and GUI control system that runs on Windows. Linux versions will be available in the future.
This type of platform is becoming more common, and a number of companies offer it. Software companies such as Evolution also have their own platform designed to get developers started quickly. It has even led to some interesting mobile platforms becoming more common.
MOVING ANYWHERE
Three- and four-wheeled vehicles are typical robot platforms. Although inherently stable, they tend to be more difficult to work with when the terrain gets rough.
Two-wheeled vehicles require dynamic stability support, but they offer a more flexible platform—especially in rough environments. The Segway RMP is one example of a two-wheeled system (Fig. 4). The RMP uses the same technology as the Segway HT (Human Transporter). The difference is that the RMP can handle a robotic package instead of a person. It appeals to college researchers because there is plenty of room for high-performance processors and sensors.
Using the RMP is no more difficult than using a platform with more wheels. In fact, it tends to be easier because the platform takes care of balance and movement, and it has a zero turning radius. It should never get stuck unless it falls in a rather large hole. The system is controlled via a pair of CANbus interfaces. It has a top speed of 8 mph and a range of eight to 10 miles.
CTGNet takes the same approach as the RMP, but it's a bit smaller (Fig. 5). Its Table Top Robot is designed for developers and hobbyists. It won't carry 100 pounds, but it will work with CTGNet's robot board stack. A control board handles balance and movement. Additional boards can be added for sensors and a control processor.
Airtrax might change the way robots work with more than a pair of wheels (Fig. 6). The Airtrax wheel looks odd, but a four-wheeled vehicle can move in any direction. It does so without rotating the platform, unlike the RMP and Table Top Robot, which must pivot to change direction. The rollers on the wheel are the key to its ability to move in any direction.
This will be critical for applications with a tight fit. It's also ideal for robot applications that can perform high-accuracy range detection and positioning and need the ability to move within a confined area.
The Airtrax system is currently being used on systems controlled by people, but some research is being done with robots. This is another example of technology that will make it easier to create and deploy complex robots.
Robotics continue to push the hardware and software envelope. They will become more common as the technology matures.