Designing Autonomous Mobile Robots phần 8 pot

236 Chapter 15 Notice that the control panel inherits the name of the door (dock), and all of the necessary interface information required to control and monitor the door. All of this functionality was provided by the graphical programming system when the door sym- bol was dropped onto the map. The runtime control software (i-Con) automatically inherited the necessary information to provide the functionality. In fact, every animated object that appears on the runtime map can be clicked by the operator to obtain its status and/or to control it. In the case of the SR-3 security robot, these objects include the robots, elevators, alarms, tagged assets, intruders, flames, and so forth. Expert assistance I have never been fond of the term AI (artificial intelligence). My personal disdain for the title is philosophical, and has its roots in the fact that it seems to imply aware- ness or sentience. Society has generally concluded that we as humans are sentient, and that we all tend to experience what we call “reality” in much the same way, while the creatures we choose to ruthlessly exploit are deemed to be fair game because they are not capable of such perception. In fact, we do not really know anything except what we personally perceive to be reality. We can never truly know if others share this perception. Because of this, and Turing 6 tests aside, I cannot imagine how we would ever know if we had created “artificial intelligence.” 6 Alan Turing’s 1950 paper, Computing Machinery and Intelligence, published in the journal, Mind, held that computers would eventually be capable of truly thinking. Turing went on to propose a test whose basis was that if a blind observer could not tell the typed responses of a computer from those of a fellow human, then the machine was “thinking.” The fallacy of this proposal is in presupposing that the human respondents would be thinking. The unlikelihood of this is easily demonstrated by visiting an online chat room or listening to a radio talk show. Figure 15.8. Door control panel 237 Programming Robots to Be Useful Having ranted against AI, I will say that I personally like the term expert system. This term simply implies that the expertise of someone who is skilled at a task can be made available through a software interface. Since robotic systems tend to be complex in nature, expert systems can be extremely useful in both their program- ming and operation. PathCAD has several expert systems built into it. These experts watch the program- ming sequence for situations where their expertise can help in the process. The most vocal of these is called “NavNanny.” NavNanny watches the programs being created to assure that they contain sufficient navigational feature references to assure proper operation. To accomplish this, NavNanny estimates the narrowness or tightness of a path from the features and settings it contains. It then estimates the distance that the robot could drive without a correction before risking becoming dangerously out of posi- tion. This distance is called the dead reckoning distance. Notice that in the example of Figure 15.6, PathCAD has attached a footer to the program which records these figures. The path assembler electronically reads this footer and uses it to calculate the path’s estimated time and risk cost. Conclusions In some jobs robots can be self-teaching; however, in more complex applications they must be preprogrammed. Programs may be implied by objects embedded in a map, or they may be discrete from the map. Discrete programming can be done traditionally or graphically, or with a combination of the two. The application will dictate the most effective programming approach. Command, Control, and Monitoring 16 CHAPTER 239 Many robot designers have an innate longing to create truly autonomous robots that figure out the world and “do their own thing.” This is fine as long as the robot is not expected to provide a return on investment to anyone. Like most of us, however, most robots will be required to do useful work. For these robots, all but the simplest tasks will require management and coordination. Once we have developed a control language and a P-code router or a map router, we have the means to specify jobs for a robot. A job is specified by its ending node. For a P-code driven robot, this will cause the router to create the job program by concat- enating the lowest cost combination of action programs that will take the robot to the destination. If the robot is to perform some task at the destination, then the task action will be specified implicitly in the action program ending at the destination node (as discussed in Chapter 15). For a map-driven system, the destination node is sent directly to the robot, whose onboard router plans the route to the destination. As discussed in the previous chap- ters, a map-driven system does not inherently know how to perform actions other than movement. Therefore, in order to support the robot doing useful things once it arrives at its destination, either the action must be implied in the properties of the destination node, or the map interpreter must have a scripting language. Once our robot has the ability to go somewhere and do a job, the obvious next ques- tion is: “Where will jobs come from and how should they be managed?” Like all of the previous choices in our architecture, this choice will depend heavily on the applica- tion for which we are designing the robot. The easiest way to place this subject in perspective is to start at the least complex end of the spectrum. 240 Chapter 16 Unmanaged and self-managed systems The two most common examples of unmanaged systems are area coverage systems and loop systems. The reason for the popularity of these systems has largely been that they stand alone and do not require a communications and control infrastructure. In the past, installing and maintaining a network of radio transceivers significantly impacted the overall cost of a system and made it more difficult to justify. With the popularity of 802.11 Ethernet radio networks and the proliferation of computer work- stations, it is now possible to ride on existing corporate or government customer systems with little or no additional hardware cost. For smaller business customers and high- end consumers, who do not have existing radio systems, the cost of a single 802.11 access point is low enough to be practical in many instances. With the cost barrier eliminated, unmanaged systems are already beginning to disappear for most high-end applications. Even so, it is still useful to discuss how unmanaged systems work, as certain concepts can be useful in managed systems. Area coverage systems Area coverage systems are most commonly seen in cleaning applications. As we have already discussed, these systems must be initialized and managed by a human worker on premises. For domestic cleaning this is no problem, but for commercial cleaning the need for an on site operator clouds any cost justification based on labor savings. In these commercial applications, the operator will be expected to provide menial work in parallel with the robot. Since this implies a minimal wage job, it is apparent that the robot’s operation must be very simple. It is equally important that the tasks for the robot and operator take roughly the same amount of time. If this is not the case, then either the robot or the operator will be idle while waiting for the other to finish a task. Trying to assure a potential customer of the savings of such a system may be a challenge. Loop systems Loop systems are most commonly seen in mail delivery and very light materials- han dling applications. In such applications, the vehicle is loaded with mail or consumable materi- als and is sent out to execute a service loop. Along this loop the vehicle will make programmed stops to allow the clients to retrieve or load items. In most cases, the system is not sophisticated enough to know if there is mail addressed to anyone at a specific stop, so the robot simply halts at each stop for a predetermined time and then continues on. 241 Command, Control, and Monitoring The obvious problems with loop systems are their low efficiency, lack of flexibility, and the lack of monitoring. For example, if the robot only has mail for one or two stops it will need to make the entire loop just the same. One of the methods used to overcome the efficiency problems is for the loop-dis patched v ehicle to carry or tow a payload carrier. The loaded carriers are dropped off at predet- ermined points such as mailrooms or logistics points. The vehicle may then pick up the carrier that it previously delivered, and return to the dispatching center. If the robot arrives to drop off a carrier, and the previous (empty) carrier has not been re- moved, then either two parking spaces will be needed or the robot must shuffle the empty carrier out of the way before dropping off the full one. A simple sketch of one such system is shown in Figure 16.2. In this case, the robot is equipped with a lifting device and once it is under the payload carrier it activates this lift so that the carrier is resting on it, and then drives away. While these schemes make loop dispatching more practical, they do so at the cost of system flexibility. Mail Room Stop 1 Stop 2 Stop 3 Stop 9 Stop 8 Stop 7 Stop 6 Stop 5 Stop 4 Figure 16.1. Simplified diagram of loop dispatching 242 Chapter 16 While the efficiency problem of loop dispatching is obvious, the lack of flexibility may be an even more significant problem. If a blockage occurs anywhere along the loop, the system is disabled completely. If the vehicle is disabled along the way, there is no inherent way of knowing about the problem until it fails to return to its starting point on schedule. Ping-pong job management One of the simplest techniques of job management is the ping-pong method. This tech- nique has been used for light materials handling robots and AGVs (automatic guided vehicles) in a number of applications. Under the ping-pong scheme, the robot is dispatched from an onboard interface. People at various workstations load the vehicle and then send it on its way using this interface. There are two problems with this method; the efficiency of the robot de- pends upon rapid servicing at each destination, and like loop systems there is no inherent central control from which its location and status can be monitored. The most obvious problem is that if a robot arrives at a destination and is not ser viced, it will be effectively out of service. If the robot is programmed to automatically return after a period without service, it may do so with its undelivered cargo. In this case, the sender must either unload the robot or send it back again. Additionally, people at the robot’s destination have no inherent way of knowing to expect it. If something goes wrong along the way, a significant time may lapse be- Robot Payload Carrier Lift Figure 16.2. Piggyback payload dispatching 243 Command, Control, and Monitoring tween when it is dispatched and it is missed. In such an event, it will then be neces- sary to send a rescue party along the robot’s route to locate it. Customers seldom show much enthusiasm for such expeditions. To overcome the monitoring deficiency, some ping-pong dispatched systems have been retrofitted with central monitoring. The problem with this approach is that it incurs most of the costs of central dispatching with only the single benefit of moni- toring. In many cases, the ping-pong method violates the simplicity maxim that states: “A system’s design should be as simple as possible and no simpler.” Automation does not loan itself well to halfway measures. Once the decision is made to automate a function it is a declaration of revolution. Either the revolution will spread to include the system’s control and to integration with adjacent systems, or it will ultimately stagnate and fail. This is because the pressure to increase productivity never ends. If new ways to improve efficiency are not found on an ongoing basis, the customer will begin to forget the initial gains and look for new solutions. Dispatched job management Most commercial applications will therefore continue moving toward centrally managed and dispatched systems. In such systems, the software that manages jobs is usually called the dis patcher. The dispatcher is normally at a fixed control point, but in some cases may be onboard the robot. The jobs that a robot will be requested to perform will normally come to the dispatcher from one of four sources: 1. Internal requests 2. External requests 3. Time-activated job lists 4. Operator requests Internal job requests Job requests generated within the robot or its immediate control can include re- quests to charge its batteries, and empty or load job-related materials. The specifics are again application dependent. A nuclear inspection robot may consume inert gas through its detectors, a scrubbing robot may need cleaning fluid, and a vacuuming robot may need to dispose of waste. None of these requirements is necessarily synchronous with other tasks, so efficient operation requires that they be performed on demand. 244 Chapter 16 External job requests External job requests also depend on the robot’s calling in life. For a security robot, these can include signals from panic buttons, fire alarms, motion detectors, door switches, card readers, and even elevators. External security jobs fall into two broad categories: alarm response and routine in- vestigation. Alarm response jobs usually direct the robot to move to the alarm site, start surveillance behaviors, notify the operator, and wait for the operator’s direc tion. This is often referred to as situation assessment. The purpose is usually to confirm that an alarm is valid and to aid in formulating an appropriate response. Investigation jobs may simply direct the robot to drive by the signal source to docu- ment the situation. For example, someone entering an area after hours may generate an investigation response even if the individual has all the proper clearances. These types of responses require no operator assistance and are simply a way of increasing the richness of the robot’s collected data. For a materials-handling robot, external jobs will normally be created automatically by other processes in the facility. These processes will normally involve either a request for pick-up or a request for drop-off. Since the various processes are usually asyn- chronous, these requests can occur randomly. Because the robot(s) cannot always perform tasks as quickly as they can come in, there will need to be a job buffer that holds the requests. Additionally, the processes from which the jobs are generated will usually be mechanically buffered so that the process can continue uninterrupted while waiting for the requested job to be performed. In factory materials handling, most processes are controlled by programmable con- trollers or dedicated microcomputers. In these smart systems, where the station must receive service quickly to avoid downtime, the controllers sometimes do not wait for the condition to occur. Such process controllers often calculate that service will be needed and make the requests before the event, thus minimizing the down time while waiting for service. These systems may even post a requested time for the robot to arrive so that the dispatcher can plan the job well ahead of time. To date, most cleaning robots have been semiautonomous. These systems have been moved from area to area by their operators and then turned loose to perform their jobs on an area basis. Since these systems do not fully free the operator, it may be more difficult to justify their payback. For this reason, high-end cleaning robots will migrate toward more automatic job control. 245 Command, Control, and Monitoring Time activated job lists A security guard often has a route that must be patrolled at certain intervals during a shift. Likewise, a cleaning crew will normally clean in a fixed sequence. In both cases, there will be times when this routine must be interrupted or modified to handle special situations. Robots that perform these tasks will likewise be expected to have lists of things to do at certain times and on certain days. For a security robot these lists are called patrol lists. While guard routes are usually constant, security robots may be programmed to randomize the patrol in such a way as to prevent anyone from planning mischief based on the robot’s schedule. It is not uncommon for job lists to vary by day of the week, or even time of day. For example, the first patrol of the evening by a security robot might need to be sequen- tial so that it can be synchronized with the cleaning staff (or robots) as they move through the facility. Subsequent patrols may be random. Likewise, cleaning robots may clean only one section of the building on one day and another section on the next day. Figure 16.3. Graphical control of the path disabling process [...]... obvious that it was disabled Paths can also be suspended for specified periods, in which case they will automatically be brought back into service at a later time Operator job requests Until such time as robots have taken over the entire planet1, it will be necessary for most of them to do the bidding of humans In many cases, this means that unscheduled jobs must be performed spontaneously at the request . by visiting an online chat room or listening to a radio talk show. Figure 15 .8. Door control panel 237 Programming Robots to Be Useful Having ranted against AI, I will say that I personally like. and Monitoring 16 CHAPTER 239 Many robot designers have an innate longing to create truly autonomous robots that figure out the world and “do their own thing.” This is fine as long as the robot. provide a return on investment to anyone. Like most of us, however, most robots will be required to do useful work. For these robots, all but the simplest tasks will require management and coordination. Once