From Teleoperation to Autonomy: “Autonomizing” Non-Autonomous Robots

From Teleoperation to Autonomy: “Autonomizing” Non-Autonomous Robots B. Kievit-Kylar1, P. Schermerhorn1, and M. Scheutz3 1Cognitive Science Program, Indiana University, Bloomington, IN 47404, USA 2Department of Computer Science, Tufts University, Medford, MA 02155, USA Abstract— Many complex tasks (search and rescue, explo- close to the robotic platform may put the operator in danger, sive ordinance disposal, and more) that eventually will be eliminating the primary advantage of using a robot. Even in performed by autonomous robots are still performed by the absence of such obstacles, the need for constant human human operators via teleoperation. Since the requirements attention adds expense and limits the overall effectiveness of of teleoperation are different from those of autonomous oper- the robot. The ability to operate these robots autonomously ation, design decisions of teleoperation platforms can make would avoid many of these limitations, but researchers need it difficult to convert such platforms for autonomous use. access to the robots to continue to improve the performance In this paper, we discuss the differences and the potential of autonomous robot architectures to the point where the difficulties involved in this conversion, as well as strategies human operator is not needed. for overcoming them. And we demonstrate these strategies by The common response to the above issues has been “autonomizing” a fully teleoperated robot designed for tasks the design of “hybrid autonomous/teleoperated” systems such as bomb disposal, using an autonomous architecture that combine the strengths of both approaches. Mixed- that has the requisite capabilities. initiative architectures are suitable as extraplanetary rover control systems, where prohibitive communication delays Keywords: tele-operation, autonomy, conversion necessitate some degree of autonomy, while the higher- level decision-making remains in the hands of a team of 1. Introduction human experts [4]. Several groups have examined effective Teleoperated robots are becoming widely available for all mechanisms for adjustable autonomy, so that the balance kinds of activities, from defusing bombs (like the IRobot between teleoperation and autonomy can be dynamically Packbot in war zones)1 to remote presence robots (like the altered to fit the circumstances [5], [6], [7]. Vgo)2. These robots are able to go places and do things that While mixed-initiative systems touch on the autonomiza- would normally be too dangerous for humans, or simply tion problem, these systems are designed from the ground be too expensive to be practical. They include a range of up with partial autonomy in mind. Very little work has sophisticated equipment and low-level control algorithms, been done on converting systems that were designed to and would seem to be naturally suited, and are certainly be purely teleoperated into partially or fully autonomous highly desirable, for autonomous operation. Compared to systems. Not only is the literature on the transformation of autonomous robots, teleoperated robots are easier to build non-autonomous robots into autonomous ones far sparser, and easier to sell because no control system for autonomous but the existing papers also focus mostly on the integration operation has to be designed (all the intelligence and con- of one particular robotic platform. E.g., Barreto [8] describes trol lies with the human operator instead) and sometimes the autonomization of the ANDROS platform using the idea poorer quality or fewer sensors can be used (as humans of interchangeable “brick” components to add new sensory can generally make better use of available sensors than capabilities. Similarly, Stewart and Khosla[9] describe a current autonomous techniques). Hence, it is unsurprising modular control mechanism for a Puma 560 in which a that increasing the efficacy of teleoperation interfaces is a teleoperation module is replaced with an autonomous one. continued research focus (e.g., [1], [2], [3]). We believe that a greater understanding of how a con- One obvious drawback of teleoperation is the need to version can be done would be greatly beneficial to the have a live control stream of data for sensors and effectors. field. In this paper, we describe our efforts for developing However, given the constraints that make robots appealing systematic principles for converting non-autonomous tele- tools, it may be difficult or impossible to establish the operated robots into fully autonomous platforms. We start data connection (e.g., because of the distances involved or with a brief background on teleoperated and autonomous environmental interference), and requiring a controller to be robots. We then discuss some of the design philosophies that affect “autonomizing” teleoperated systems. Next we 1http://www.irobot.com/gi/ground/510_PackBot describe our transformation of the Multi-Mission Payload 2http://www.vgocom.com/what-vgo Platform (M2P2) into a general purpose autonomous system. After presenting an evaluation of the new system in a The remainder of this section examines in more detail “bomb disposal” task, we finish with some discussion about specific challenges that may need to be addressed when im- limitations of this technique as well as how generalizable it plementing an autonomous architecture on a robot designed is to other robotic platforms.3 for teleoperation. a) Physical connection: Sensors and effectors need to be 2. “Autonomizing” Teleoperated Robots exposed to the control architecture. In some cases it may be Successfully implementing an autonomous architecture on possible to make use of the existing teleoperation channel, a robot that has been designed for teleoperation requires but (as noted above), this will sometimes not be feasible. overcoming a variety of challenges. All of these challenges In that case, it will be necessary to create alternative inter- are traceable in some way to how different constraints factor faces (e.g., RS-232 or USB-based serial or wired Ethernet into the design of purely teleoperated robots. connections). Moreover, if device drivers and libraries do While there are some obvious mechanical differences not provide access at the right level of abstraction, it may existing in the hardware needed to perform communication be necessary for the control architecture to implement a with an operator verses an autonomous system, many more software interface, as well. subtle assumptions go into the construction of these two b) General control algorithms for effectors: Similarly, types of robotic platforms. Autonomous and teleoperated depending on the nature of the particular sensors and effec- robots will often require different levels of sophistication tors, it might be possible to use existing control algorithms in the sensors needed to perform their tasks. For example, (e.g., for a mobile robot base or for an n-degree of freedom while the output of wheel encoders and range-finders may be manipulator) or to use them after only minor adaptations. In very useful in allowing a program to determine its position, the worst case (typically because a given piece of hardware often humans rely on more expensive sensors such as video is used differently under teleoperation than under autonomy), cameras to quickly expose them to a high volume of noisy new algorithms need to be developed for particular sensors data. As well as sophistication in sensors, complex robots and effectors. For example, feedback from sensors such as with many moving parts require complex control systems. wheel encoders can be used to generate a simple, immediate, While a human operator may only be able to focus on a computational understanding of an autonomous robot’s pose. subset of controls at any given time, microchips are able However, the human operator is unlikely to find encoder to compartmentalize the various effectors allowing simulta- counts useful, so they may not be exposed via a software neous meaningful control of all. While more user friendly interface, and in the worst case, may not even be present interfaces or multiple operators may alleviate the control at all. Other sensors, such as cameras, are often easier to problem to some degree, it can not match the orchestration access, but may still require additional processing steps (e.g., of a single programmatic control architecture. Similarly, the to extract individual frames for visual processing from a computational requirements of a remotely-controlled robot video stream encoded for efficient transmission). can be very low. Hence, there may be no general-purpose onboard computer, or that computer may be underpowered c) Control architecture: Naturally, one of the biggest to handle the tasks (problem-solving, sensor processing, etc.) changes will be the inclusion of the autonomous control required for autonomous operation. architecture itself. A wide variety of configurations is pos- The same goes for effectors; for example, the design sible; depending on the task, the control architecture will of a gripper that will be actuated via a gamepad in the comprise different components, possibly including a planner, hands of a skilled user might look very different from an action execution component, components for user inter- what an autonomous robot architect might ideally envision faces including screen-based and possibly spoken natural (e.g., because it has fewer safeguards, relying instead on language dialog interfaces. The task approach can either be the operator’s skill and judgment). Even at the mundane pre-programmed

Load more