Autonomous behaviors for a remote vehicle

198104/2 1

AUTONOMOUS BEHAVIORS FOR A REMOTE VEHICLE

Field of the Invention [0002] The present invention relates to a method and device for simplifying control of aremote vehicle. The present invention more specifically relates to autonomous behaviors forremote vehicles, and more particularly to switching between tele-operation of a remote vehicleand autonomous remote vehicle behaviors.

Background of the Invention [0003] Remote vehicles are increasingly being used in military, law enforcement, andindustrial applications to provide a tool for a person to perform operations at a safe, remotedistance from sites of potential danger or hazard to human beings. Such remote vehicles arebeing deployed for some tasks by military and civilian forces, such as bomb and ordnancedisposal, in which the remote vehicle is remotely navigated to the proximity of the explosives orother potentially dangerous target by an operator located hundred of meters away, so thatinvestigation and disarmament can take place at a safe distance.

[0004] In typical remote vehicle operation, the operator controls the vehicle using a 2 198104/2 process known as tele-operation. Conventional remote vehicle tele-operation involves theuse of operator control consoles, most commonly having joysticks, trackballs, mouse-typeinput devices, or some arrangement of physical switches and/or potentiometers and similarmanual actuation input devices. Remote vehicles are typically configured with many axesof motion, including motion drive axes, steering axes (either physical or derived virtualsteering), manipulation axes, sensor pan-tilt-zoom axes, etc. The axes of the remotevehicle often involve complex mechanical coupling between the drive actuators and thephysical motion apparatus, such as wheels, tracks, rudders, heads, etc. Additionally,remote vehicle platforms typically contain many sensors, such as cameras, that canprovide multiple streams of video to the operator as visual feedback to aid the operator'scontrol. The electro-mechanical complexity of many remote vehicles has consequentlymade the manual control of such vehicles complex for human operators in a tele-operationprocess, requiring many function- specific knobs, joysticks and buttons to perform a task.A significant amount of operator training and experience can be required to developsufficient manual dexterity and skill to be able to accurately navigate and control a remotevehicle. US 2005/0192721 discloses a system of controlling a mobile device, whichincludes moving a surrogate under wireless control, and autonomously moving thesurrogate to regain wireless control when the wireless control is lost. US 2004/0216931 discloses an articulated tracked vehicle that has a main section,which includes a main frame, and a forward section, wherein the main frame includes apair of parallel main tracks wherein each main track includes a flexible continuous beltcoupled to a corresponding side of the main frame. The forward section includes anelongated arm wherein one end of the arm is pivotally coupled to the main frame near theforward end of the main frame about a transverse axis that is generally perpendicular tothe sides of the main frame. The main section is contained within the volume defined bythe main tracks and is symmetrical about a horizontal plane, thereby allowing invertedoperation of the robot. US 2006/0089800 discloses a system and method for multi-modal control of avehicle, wherein actuators (e.g., linkages) manipulate input devices (e.g., articulationcontrols and drive controls, such as a throttle, brake, accelerator, throttle lever, steeringgear, tie rods, or transmission shifter) to direct the operation of the vehicle. Behaviors thatcharacterize the operational mode of the vehicle are associated with the actuators. Afterreceipt of a mode select command that dictates the operational mode of the vehicle (e.g.,manned operation, remote unmanned tele-operation, assisted remote tele-operation, andautonomous unmanned operation), the actuators manipulate the operator input devices, inaccordance with the behaviors, to affect the desired operational mode.

None of the aforementioned publications disclose a system for allowing anoperator to switch between remote vehicle tele-operation and one or more remote vehicleautonomous behaviors, as provided herein.

[0005] In order for robots to be beneficial in such activities, a method and deviceare needed to allow remote vehicles to accomplish certain behaviors autonomously, eithercontinuously or upon user commands.

Summary of the Invention [0006] The present invention provides a system for allowing an operator to switchbetween remote vehicle tele-operation and one or more remote vehicle autonomousbehaviors, or for implementing remote vehicle autonomous behaviors. The systemcomprises an operator WO 2008/060689 PCT/US2007/068890 3 control system receiving input from the operator including instructions for the remote vehicle toexecute an autonomous behavior, and a control system on the remote vehicle for receiving theinstruction to execute an autonomous behavior from the operator control system. Upon receivingthe instruction to execute an autonomous behavior, the remote vehicle executes that autonomousbehavior.

[0007] The remote vehicle executes the autonomous behavior if permitted, and theautonomous behavior is not permitted if one or more of the remote vehicle’s position within itsenvironment, the current internal state of the remote vehicle, the current operational behavior ofthe remote vehicle, or the remote vehicle’s environment are incompatible with the autonomousbehavior.

[0008] The control system includes an arbiter, and the autonomous behavior sends a voteto the arbiter requesting control of one or more actuators on the remote vehicle necessary toperform the autonomous behavior. If the voting autonomous behavior has a higher priority than abehavior currently in control of the one or more actuators, the autonomous behavior executes.

[0009] The autonomous behaviors include one or more of ballistic, semi-ballistic, andpersistent behaviors. Ballistic behaviors include one or more of stair climbing, preset actions,click-to-drive, click-to-grip, preconfigured poses, retro traverse, self-righting, and autonomousflipper. Semi-ballistic behaviors include one or more of quick brake, speed boost, and cruisecontrol. Persistent behaviors include one or more of retro traverse, self righting, obstacleavoidance, and autonomous flippers.

[0010] The present invention also provides a method for allowing an operator to switchbetween remote vehicle tele-operation and one or more remote vehicle autonomous behaviors, orfor implementing remote vehicle autonomous behaviors. The method comprises inputting WO 2008/060689 PCT/US2007/068890 4 instructions for the remote vehicle to execute an autonomous behavior; evaluating one or more ofthe remote vehicle’s position within its environment, the current internal state of the remotevehicle, the current operational behavior of the remote vehicle, or the remote vehicle’senvironment are incompatible with the autonomous behavior; and allowing the autonomousbehavior to send a vote to an arbiter if the remote vehicle’s position within its environment, thecurrent internal state of the remote vehicle, the current operational behavior on the remotevehicle, or the remote vehicle’s environment are compatible with the autonomous behavior. Avote to the arbiter requests control of one or more actuators on the remote vehicle necessary toperform the autonomous behavior.

Brief Description of the Drawings FIG. 1 illustrates a embodiment of a control system of the present invention and a remotevehicle; FIG. 2 is a top view of an embodiment of a hand-held controller of the control system ofthe present invention; FIG. 3 is a rear view of the embodiment of FIG. 2; FIG. 4 is a side view of the embodiment of FIG. 2; FIG. 5 is a front sectional view of an embodiment of a roller wheel for use with the control system of the present invention; FIG. 6 is a side view of the roller wheel embodiment of FIG. 5; FIG. 7 is a top view of an embodiment of a rotary ring switch for use with the controlsystem of the present invention; FIG. 8 is another top view of the rotary ring switch embodiment of FIG. 7; WO 2008/060689 PCT/US2007/068890 5 FIG. 9 is a side view of the rotary ring switch embodiment of FIG. 7; FIG. 10 illustrates an embodiment of a quick-release pad of the control system of thepresent invention; FIG. 11 is an embodiment of a user interface of the control system of the presentinvention; FIG. 12 is another embodiment of a user interface of the control system of the presentinvention; FIG. 13 illustrates an exemplary use of the control system of the present invention with aremote vehicle; FIG. 13A illustrates an embodiment of the invention including a two-piece hand-heldcontroller; FIG. 13B illustrates another embodiment of the invention including a two-piece hand-held controller; FIG. 13C illustrates another embodiment of the invention including a two-piece hand-held controller; FIG. 14 is a block diagram illustrating an exemplary embodiment of autonomousbehaviors; FIG. 15 is a flow diagram illustrating an activation routine used to activate a ballisticbehavior and its associated routines; FIG. 16 is a flow chart illustrating a routine for activating a semi-ballistic behavior usedto tune a behavior; FIG. 17 is a flow chart illustrating a routine to activate or de-activate a persistentbehavior; WO 2008/060689 PCT/US2007/068890 6 FIG. 18 illustrates the execution of routines within a persistent behavior; FIGS. 19A and 19B illustrate an embodiment of a remote vehicle of the presentinvention; FIG. 20 illustrates a mobile robot for use with an embodiment of the present invention; FIG. 21 is a block diagram depicting an embodiment of a mobile robot control system; FIG. 22 illustrates an embodiment of a chassis assembly; FIG. 23 illustrates an embodiment of a neck module; FIG. 24 illustrates an embodiment of a head module; FIG. 25 illustrates an embodiment of a gripper module; FIG. 26 illustrates an embodiment of a network installed between a head, a neck, acontrol system, and a chassis; FIG. 27 illustrates an embodiment of an Ethernet endpoint block; FIG. 28 illustrates an embodiment of the invention using the Ethernet endpoint block inthe chassis, neck, head and EO/IR payload; FIGS. 29A and 29B illustrate an embodiment of a robotic arm; FIG. 30 illustrates an embodiment of a behavior system to be included within a remotevehicle; FIG. 31 illustrates a listing of behaviors within the behavior system in an exemplaryorder of priority; FIG. 32 illustrates an embodiment of a stair climbing behavior; FIGS. 33A and 33B illustrate positions of a remote vehicle relative to target stairs; FIG. 34 illustrates an embodiment of a method for performing a stair climbing behavior; FIG. 35 illustrates an embodiment of a preset action sequence behavior; WO 2008/060689 PCT/US2007/068890 7 FIG. 36 illustrates an embodiment of a control system display for a click-to-gripbehavior; FIG. 37 illustrates an embodiment of a click-to-grip routine; FIG. 38 illustrates an embodiment of a click-to-drive routine; FIG. 39 illustrates an embodiment of a technique for moving among preconfigured poses; FIG. 40 illustrates another embodiment of a technique for moving among preconfiguredposes; FIG. 41 illustrates an embodiment of a waypoint routine; FIG. 42 illustrates an embodiment of a retro traverse behavior; FIG. 43 illustrates an embodiment of remote control operation of a remote vehicle in anurban combat zone; FIGS. 44A and 44B illustrate a retro traverse behavior; FIGS. 45A - 45C illustrate a retro traverse behavior; FIGS. 46A - 46D illustrate a retro traverse behavior; FIG. 47 illustrates a retro traverse behavior; FIGS. 48 and 49 illustrate an embodiment of speed boost and quick brake behaviors; FIG. 50 illustrates an embodiment of a cruise control routine included within a cruisecontrol behavior; FIGS. 51A and 5IB illustrate an embodiment of a cruise control behavior; FIG. 52 illustrates an embodiment of a flow of information in a cruise control behavior; FIG. 53 illustrates an embodiment of a routine to generate cruise control commands; FIG. 54 illustrates an embodiment of an interaction between a cruise control behavior andother behaviors; WO 2008/060689 PCT/US2007/068890 8 FIGS. 55A - 55D illustrate an embodiment of an interaction between a cruise controlbehavior and an obstacle avoidance behavior; and FIG. 56 illustrates an embodiment of an obstacle avoidance routine for an obstacleavoidance behavior.

Detailed Description of Embodiments of the Invention

[0011] An embodiment of a control system (also called an “operator control system”herein) for use with the present invention includes an unobtrusive, highly mobile control systemthat provides the user with a remote vehicle operating experience that seamlessly integrates withthe user’s other tasks and duties. The control system allows the user to initiate autonomousbehaviors for the remote vehicle, and to switch between tele-operation and such autonomousbehaviors. Situational awareness is minimally compromised when operating the system, as it iscritical for the user to be aware of his surroundings. Basic components of the control system,which are illustrated in FIG. 1, include a display, an input device, a processor, an antenna/radio(for wireless communication), and software. In an embodiment of the invention, a head-mounteddisplay provides video display from one or more remote vehicle cameras. A hand-heldcontroller, preferably having a twin-grip design, includes controls to drive, manipulate, andmonitor the robot and its payloads. Audio may additionally be provided via the hand-heldcontroller, the display, or dedicated listening devices such as, for example, Bluetooth headsetscommonly used with mobile phones. In an embodiment of the invention, a microphone isprovided on the hand-held controller, the processor, the display, or separately from thesecomponents, and can be used with a speaker on the remote vehicle to broadcast messages. A button on the hand-held controller or a soft button within the GUI can be used to activate the WO 2008/060689 PCT/US2007/068890 9 speaker and microphone for broadcasting a message.

[0012] The system is preferably compatible with MOLLE packs, ALICE packs, ILBEs,or OTVs commonly worn by users. The system preferably has the following additionalcharacteristics: lightweight (e.g., no more than 7 pounds total, and no more than 2 pounds for thehand-held controller); mobile; small form factor (e.g., able to integrate with existing user gear);wearable or capable of being carried in a backpack; easy to put on/take off; adequate computerprocessing power; minimal or no external cables; meets mission time thresholds (e.g., 5 hours);rugged to intended environment (e.g., temperature, shock, vibration, water, etc.); able towithstand being dropped (e.g., 3 feet).

[0013] The platform should have standard interfaces for networking, display, wirelesscommunication, etc.

[0014] The control system, as illustrated in FIG. 1, includes a processor such as a ruggedlaptop computer. The processor could alternatively be any suitably powerful processorincluding, for example, a tablet PC. The processor communicates with the remote vehiclewirelessly or via a tether (e.g., a fiber optic cable). Although wireless communication may bepreferable in some situations of remote vehicle use, potential for jamming and blocking wirelesscommunications makes it preferable that the control system be adaptable to differentcommunications solutions, in some cases determined by the end user at the time of use. Avariety of radio frequencies (e.g., 802.11), optical fiber, and other types of tether may be used toprovide communication between the processor and the remote vehicle.

[0015] The processor must additionally communicate with the hand-held controller andthe display. In a preferred embodiment of the invention, the processor is capable ofcommunicating with the hand-held controller and the display, illustrated in the present WO 2008/060689 PCT/US2007/068890 10 embodiment to be a head-mounted display, either wirelessly or using a tether. To facilitatewireless communication among the various elements of the system, the processor includes aradio and an antenna.

[0016] It addition, the processor includes software capable of facilitating communicationamong the system elements, and controlling the remote vehicle. In an embodiment of theinvention, the software is a proprietary software and architecture, including a behavioral systemand common OCU software, which provide a collection of software frameworks that areintegrated to form a basis for robotics development. According to an embodiment of theinvention, this software is built on a collection of base tools and the component framework,which provide a common foundation of domain-independent APIs and methods for creatinginterfaces, building encapsulated, reusable software components, process/modulecommunications, execution monitoring, debugging, dynamic configuration and reconfigurationas well as operating system insulation and other low-level software foundations like instrumentmodels, widget libraries, and networking code. In an embodiment of the invention, the processorperforms all of the data processing for the control system.

[0017] Referring to FIG. 2, an exemplary embodiment of a twin-grip hand-heldcontroller is illustrated. The hand-held controller includes left and right grips shaped to be heldbetween a little finger, a ring finger, and the ball of a thumb of a respective hand, leaving theindex finger, middle finger, and thumb of the respective hand free to manipulate controls. Twojoysticks (analog, having 4 degrees of freedom) are provided on the left and right sides of thehand-held controller. The joysticks may be 2-axis analog. In an embodiment of the invention,analog-to-digital resolution of the joysticks is at least 12-bit per axis with the joystick center“dead band” (maximum offset from center on spring return) being less than about 3% of total WO 2008/060689 PCT/US2007/068890 11 resolution. If pressed, the joysticks can function as digital buttons. The present invention alsocontemplates using pucks (6 degrees of freedom) instead of joysticks.

[0018] In an embodiment of the invention, the left joystick is commonly used to drive theremote vehicle (forward, backward, left, and right). The right joystick controls one or moreother functions of the robot depending on a selected button function mode, including a camera(e.g., the attack camera), a weapon, or flipper control.

[0019] A directional pad is located on a left side of the hand-held controller and includesan array of four or five discrete digital buttons for manipulation by the user’s left thumb. Thebuttons are arranged in a diamond shape with an optional button in the center. The four buttonsnot in the center preferably come to a rounded point at one end to indicate direction. One buttonpoints up, one points down, one points right, one points left. In an embodiment, the four buttonsnot in the center have a generally flat exposed surface and the center button has a generallyhemispherical exposed surface and is raised above the surrounding buttons. In an embodimentof the invention, the directional pad is used to navigate among the soft buttons of a GUIdisplayed by the head-mounted display. The center button of the array, when present, may beused to select a soft button of the GUI.

[0020] A right button array includes an array of four discrete digital buttons formanipulation by the user’s right thumb. The buttons are arranged in a diamond shape and arecircular with exposed surfaces that may be at least slightly curved. The right button array can beused to control a variety of functions such as camera selection, robot light setting, and robotspeed. When no center button is provided on the directional pad, one of the buttons of the rightbutton array may be used to select a soft button of the GUI.

[0021] A center button array is shown to include five discrete digital buttons for WO 2008/060689 PCT/US2007/068890 12 manipulation by the user’s thumbs. A first button is generally located in an upper left region ofthe center area, a second button is generally located in an upper right region of the center area, athird button is generally located in a lower left region of the center area, a fourth button isgenerally located in a lower right region of the center area, and a fifth button is generally locatedin the center of the other buttons. The first four buttons are elongated (generally rectangular) andthe fifth button is generally hemispherical. In an embodiment of the invention, the center buttonis larger than the other buttons in the center array.

[0022] In an embodiment of the invention, the upper right button (second) button is themenu button, which brings up a menu within the GUI displayed by the head-mounted display.The menu is preferably a hierarchical menu, such as a drop-down menu, that allows the user toselect a screen layout, a robot to control, select a safe mode for the robot (such as observe mode),manage and play video, audio and snap shot recordings, select among other settings such asbrightness, and time/date, or review documentation regarding the controller or the robot. In thisembodiment, the upper left (first) button acts as a pause or brake button for the robot, ceasingmovement of the robot until released. To prevent accidental activation, the pause/brake buttonmay be recessed and/or may require a minimum force for activation.

[0023] A button on the hand-held controller or a soft button within the GUI can be usedto switch controllers, so that another hand-held controller or alternative control device can takeover control of the remote vehicle. This can allow multiple operators to control the same remotevehicle.

[0024] The pause or brake button may alternatively be designed as a dead man’s switchto ensure safe operation of the robot - if the user’s finger is released from the switch, the robotceases to operate. In an embodiment of the invention, the dead man’s switch is located under the WO 2008/060689 PCT/US2007/068890 13 user’s left index finger, right index finger, left middle finger, or right middle finger.

[0025] Bumper or rocker buttons are located on the shoulders of the hand-held controller,the buttons making up a rocker control. Two rocker buttons make up a first rocker control on theleft shoulder and are oriented vertically, and two more rocker buttons make up a second rockercontrol on the right shoulder and are also oriented vertically. As an alternative to rocker buttons,one-axis switches may be provided on the left and right shoulders (not shown). The rockerbuttons, being aligned vertically along the shoulder of the hand-held controller, are therebylocated in a pitch plane parallel to the articulated flipper drive. In an embodiment of theinventions, the rocker control on the right shoulder is used for flipper control.

[0026] The directional pad, left joystick, and left shoulder rocker control make up a leftcontrol zone. The right button array, right joystick, and right shoulder rocker control make up aright control zone.

[0027] A power button is located between the left and right shoulder areas of the hand-held controller. In the illustrated embodiment, the button is circular with a flat protrudingsurface. The button may optionally be recessed (to prevent inadvertent actuation) and/or backlitwith an LED that indicates the state of the hand-held controller (i.e., on or off). In anembodiment of the invention, the area of the hand-held controller immediately surrounding thepower button is smooth to facilitate using electrical tape to cover the power button and its LEDas needed. Covering the power button can avoid detection of the hand-held controller. Thepower button on the hand-held controller may control the state of just the hand-held controller, orof a number of other system components, such as the processor and one or more displays (e.g.,the head-mounted display).

[0028] An embodiment of the invention includes a tether zone (see FIG. 3) located WO 2008/060689 PCT/US2007/068890 14 between the left control zone and the right control zone, which includes a tether anchorconfigured to tether the hand-held controller between the left grip and right grip and permit thehand-held controller to hang in use (see FIG. 13) with the left grip and right grip pointingupward. A tether, or cord, extends from the tether anchor, preferably to the right shoulder of adismounted operator.

[0029] In an embodiment of the invention, the tether is detachable from the hand-heldcontroller, and connects the hand-held controller to the processor for non-wirelesscommunication between the two. In an embodiment of the invention, the hand-held controllercan operate on battery power and communicates wirelessly with the processor, but has the abilityto accept a tether when non-wireless connection is preferred.

[0030] In an embodiment of the invention, the tether has a strain relief allowing it to beflexible but also physically support the weight of the hand-held controller and withstand beingdropped the a distance equal to the tether’s length (e.g., 3 feet) without damage or disconnection.

[0031] In an embodiment of the invention, the tether attaches to the hand-held controllervia an environmentally sealed connector, such as push-pull, screw latching, etc. The sameenvironmentally sealed connection may be used where the tether connects to the processor. Thetether connectors may be keyed to prevent pin misalignment during connection.

[0032] FIGS. 5 and 6 illustrate an optional roller wheel that may be provided on thehand-held controller. In an exemplary embodiment, the roller wheel is surrounded by a texturedtire and sits in a cavity of the hand-held controller. The cavity is formed in the exterior surfaceof the hand-held controller and includes an interior shell to encase the roller wheel. An axleextends between two sides of the interior shell and allows the roller wheel to rotate within thecavity. Bushings may additionally be provided to reduce friction and wear. The axle extends WO 2008/060689 PCT/US2007/068890 15 into a rotary transducer located on at least one side of the cavity, the rotary transducer measuringrotation of the roller wheel and converting it to a digital output. The location of the roller wheelon the hand-held controller, if provided, may vary, although the wheel is preferable located sothat it can be actuated by the user’s thumb or forefinger (either left or right). The roller wheelmay be used, for example, for camera zoom or to scroll among soft buttons in the GUI.

[0033] FIGS. 7, 8, and 9 illustrate an optional rotary ring switch. In the illustratedexemplary embodiment, the rotary ring switch is located around a joystick and includes threepositions on the ring that may be selected by sliding a selector along the ring to one of thepositions. In an embodiment of the invention, the rotary ring switch surrounds the left joystickso that selection is made with the user’s left thumb. The rotary ring switch may be used to selectamong button functions modes.

[0034] The present invention contemplates a variety of locations for the ring switch ifone is provided, as well as a varying number of positions for selection. For example, the ringswitch could surround the right joystick, the directional pad, the right button array, or the centerbutton array.

[0035] The present invention contemplates using labels (not shown) on or near thebuttons of the hand-held controller to indicate the functionality of one or more of the buttons.

[0036] It will be appreciated by those skilled in the art that location and shape of thebuttons may vary among embodiments of the invention. The present invention contemplates avariety of button shapes and locations. Additional buttons may be added, or buttons may beremoved within the scope and spirit of the invention.

[0037] The present invention contemplates additional or alternative functionality for thehand-held controller. For example, the hand-held controller may be able to detect aspects of its WO 2008/060689 PCT/US2007/068890 16 own movement via accelerometers and gyroscopes and translate that movement into remotevehicle control functions such as, for example, scrolling through a GUI menu. While the hand-held controller’s movement could be translated into corresponding movement of the remotevehicle, such control may not be advisable in certain situations where precise control of theremote vehicle is critical and/or the controller may be subject to unforeseen jostling withpotentially hazardous results in terms of corresponding movement of the remote vehicle.

[0038] An embodiment of the invention provides mode changing software for changingbutton mapping of the hand-held controller between, for example, driving a robot, manipulatingan arm, controlling a camera, etc.

[0039] In an embodiment of the invention, switching among button function modes ofthe hand-held controller is accomplished by actuating a button or toggle-type switch, preferablyusing the operator’s index finger(s). This can be accomplished using an above-described rotaryring switch, another button on the hand-held controller, or even the optional roller wheeldescribed above. The present invention also contemplates switching button function modes onthe left side of the controller which one switch or button, preferably located on the left side, andswitching button function modes on the right side of the controller which another switch orbutton, preferably located on the right side.

[0040] According to an embodiment of the invention, button function modes include: [0041] Drive Mode - the left joystick is used to steer the robot forward, back, left, andright, the left button array is used to control the attack camera (for a robot having, for example, adrive camera and an attack camera), the right joystick controls a spooler (for example containingfiber optic cable), the right button array controls a variety of functions such as the camera zoom,robot lights, robot speed, an camera choice (allows user to choose one or more cameras as, for WO 2008/060689 PCT/US2007/068890 17 example, primary and secondary), and the right shoulder is for flipper control.

[0042] Manipulate (Gripper) Mode - the left joystick is used to move the gripperforward, back, left, and right, the right joystick is used to move the gripper up and down and tofold or unfold the elbow, and the right shoulder buttons are used to rotate the gripper clockwiseand counterclockwise.

[0043] Target (Attack Camera) Mode - The left joystick is used to move the attackcamera forward, back, left, and right, and the right joystick is used to move the attack camera upand down.

[0044] Joint Mode - The left joystick folds and unfolds the gripper shoulder (e.g., usingthe top and bottom buttons), and rotates the turret clockwise and counterclockwise (e.g., usingthe right and left buttons). The right joystick folds and unfolds two gripper elbows. The leftbutton array controls the attack camera, and the right button array controls a variety of functionssuch as the camera zoom, robot lights, robot speed, and camera choice. The right shoulderbuttons are used to rotate the gripper clockwise and counterclockwise.

[0045] Menu (GUI Navigation) Mode - The left joystick navigates a cursor up, down,right, and left, the left button array moves the menu itself up, down, left, and right, and the rightbutton array includes cancel and select functions.

[0046] Among the above exemplary button function modes, certain buttons may maintainthe same functions, such as the top left button of the center button array being a pause/brakebutton, and the top right button of the center button array being a menu button. In addition, thebutton to change among the above functional modes may remain the same. In an embodiment ofthe invention, the left joystick is always used to drive the remote vehicle and the directional padis always used to navigate soft buttons of the GUI. It is the other buttons that change WO 2008/060689 PCT/US2007/068890 18 functionality among modes.

[0047] It should be understood that the present invention contemplates a variety of buttonmapping scenarios, and a variety of single and combined function modes that allow the operatorto control one, two, or more payloads of the remote vehicle with the same hand-held device bymanipulating the buttons on the hand-held controller.

[0048] In an embodiment of the invention, the weight of the hand-held controller,including the cord, is less than or equal to two pounds. In a preferred embodiment, the weight ofthe hand-held controller itself is less than one pound, and the dimensions are no larger than 4.5”x 2.5” x 6.5”.

[0049] According to an embodiment of the invention, the hand-held controller isruggedized. For example, the casing and switch plate may comprise aluminum, and the unit orparts thereof may be coated in plastisol or another suitable coating. In addition, the tetherconnection may be environmentally sealed, and the buttons may additionally be made waterproofas is know to those skilled in the art, particularly in the area of waterproof cameras.

[0050] For adhering the hand-held controller to the user’s gear, an embodiment of theinvention includes a quick-release system. An embodiment of the quick-release system includesa quick release pad, an embodiment of which is illustrated in FIG. 10. The quick-release padpreferably comprises Velcro® on an outer-facing side thereof, and has a size suitable to allowreleasable but stable attachment of the hand-held controller to the pad. The pad is attached to aloop on the user’s gear. In the embodiment of FIG. 10, the loop is a horizontal loop such asthose provided on an OTV. A strap connected to the quick-release pad circles through the OTVloop to attach the quick-release pad to the OTV. An additional quick-release mechanism (notshown) may be used to releasably fasten the tether (which connects the hand-held controller to WO 2008/060689 PCT/US2007/068890 19 the processor) to the user’s gear. Complementary material is located on an underside the hand-held controller to mate with the quick-release pad. In an embodiment of the hand-held controllerincluding protrusions extending from a bottom thereof (see FIGS. 3 and 4), the complementarymaterial is located on the protrusions. In an alternate embodiment with, for example, a flatbottom, at least a portion of the bottom would include complementary material. BecauseVelcro® can wear out and become less effective, the present invention contemplates the Velcroin the quick-release system being easily replaceable.

[0051] The head-mounted display illustrated in FIG. 1 generally indicates a displaydevice worn on a user’s head or as part of a helmet, which has a display optic in front of one orboth eyes. A typical head-mounted display has one or two displays with lenses and semi-transparent mirrors embedded in a helmet, eye-glasses, or a visor. The display units areminiaturized and may include cathode-ray tubes (CRTs), liquid crystal display (LCD), LiquidCrystal on Silicon (LCos), or an organic light-emitting diode (OLED).

[0052] The head-mounted display allows the remote vehicle operator to see what theremote vehicle sees through one or more cameras, so that the remote vehicle can be controlledwhen it is not within the operator’s line of sight, and also allows the operator to maintainsituational awareness. In an embodiment of the invention, the head-mounted display is an Icuititactical display.

[0053] The head-mounted display displays a GUI with views from the robot’s camera(s)and information about the robot such as battery life, payloads, communication status, etc., andalso displays soft buttons that are mapped to the hand-held controller buttons and allow the userto more intuitively control the robot using the hand-held controller.

[0054] The present invention contemplates using one or more head-mounted displays WO 2008/060689 PCT/US2007/068890 20 with a single control system. In addition, the video stream from the robot camera(s) can bemulti-casted for use by multiple clients. Indeed, the multiple clients need not only be multiplehead-mounted displays, but may alternatively or additionally include a variety of displays and/orrecoding devices in a variety of locations.

[0055] The head-mounted display is preferably capable of either wireless or tetheredcommunication with the hand-held controller through the processor.

[0056] As stated above, a menu mode of the hand-held controller allows the user tonavigate among soft buttons or icons displayed by the head-mounted display. Exemplaryembodiments of the GUI display are illustrated in FIGS. 11 and 12.

[0057] As illustrated in the embodiment FIG. 11, the head-mounted display provides theuser with a variety of information in what is indicated as a “max camera” layout. In thisillustrated embodiment, the main image is a video stream from the robot’s attack camera and thesmaller image in the lower right corner is video stream from the robot’s drive camera. As analterative to video streams, a series of snapshots can be displayed at predetermined timeintervals. The status of the attack camera (e.g., front zoom) is displayed in the upper left comer,and certain camera control icons or soft buttons are presented under the camera status. In thisembodiment, the icons include zoom in, zoom out, IR filter on/off, IR lightoff/low/medium/high, camera default position (designated in this embodiment as a V in a sunshape), camera setting choices, audio choices, snap shot, and video record on/off. In thisembodiment, upon choosing (by pressing the soft button or icon by manipulating the hand-heldcontroller in the menu mode) camera settings and audio, the GUI pops up a screen to selectamong a variety of setting options. In an embodiment of the invention, the icons can beminimized. Above the status of the camera, the robot’s name can be displayed (illustrated herein WO 2008/060689 PCT/US2007/068890 21 as “Name567890123456”).

[0058] The camera may be returned to its default position, or otherwise controlled, viathe soft button mentioned above, or a button on the hand-held controller.

[0059] Additional icons or soft buttons may be displayed, for example on the right sideof the head-mounted display view. In this embodiment, the icons or soft buttons include, fromtop to bottom, status of communication link (with robot), battery charge level (of the robot andthe OCU), speed toggle (wherein the snail icon indicates that the robot is in a slow range ofspeed within the available scalable range of speed), robot heading, two icons indicating therobot’s position and heading, and a variety of autonomous assist options such as predefinedposes (described in detail below).

[0060] Another embodiment of the system’s GUI, indicated as a “quad” layout, isillustrated in FIG. 12. The larger, upper left image is a video stream from the robot’s attackcamera and the smaller image in the center of the display is video stream from the robot’s drivecamera. As an alterative to video streams, a series of snapshots can be displayed atpredetermined time intervals. The status of the attack camera (e.g., front zoom) is displayed inthe upper left comer, and certain camera control icons or soft buttons are presented under thecamera status, as set forth for the prior embodiment. In an embodiment of the invention, theicons can be minimized. Above the status of the camera, the robot’s name can be displayed(illustrated herein as “Name567890123456.” Under the camera controls is a map icon allowingthe user to select additional information from the system’s mapping function. To the right of themap icon and under the video stream from the attack camera, mapping information regarding oneor more of the robot’s prior mission movements can be displayed. Alternatively, the missions ofa number of nearby robots are displayed. WO 2008/060689 PCT/US2007/068890 22 [0061] Additional icons or soft buttons may be displayed, for example on the right sideof the head-mounted display layout. Similar to the previous embodiment, the icons or softbuttons include, from top to bottom, status of the communication link (with robot), batterycharge level (of OCU), speed toggle wherein the snail icon indicates that the robot is in a slowrange of speed (within the available scalable range of speed), and a variety of autonomous assistoptions such as predefined poses. In this embodiment, the poses are indicated by name ratherthat a graphical representation of the pose itself. Payload icons under the pose icons allow theuser to activate a payload or bring up a control menu for that payload. They can also displayinformation regarding selected payloads. Possible payloads include cameras, chemical detectiondevices, sniper detection devices, cable spools, batteries, etc. In the illustrated embodiment,payload 3 is an Explorer extension added to the chassis of the robot, and payloads 4 and 5 arebatteries.

[0062] To the right of the video stream from the robot’s attack camera is a representationof the robot’s position and heading, including any tilt. Under the positional representation is anidentification of the payloads and information regarding the payloads, such as an indication ofremaining battery life.

[0063] In accordance with the present invention, the user may choose among a variety ofGUI layouts, such as the “max camera” and “quad” layouts described above.

[0064] In the above illustrative embodiments of the GUI, the icons or soft buttons may bedisplayed continuously for the user, who navigates among them using a dedicated set of buttonson the hand-held controller (e.g., the directional pad), or may be displayed only when the hand-held controller is in a menu mode. Additional soft icons or buttons may be displayed asdesirable. In an embodiment of the invention, the illustrated icons are displayed continuously for WO 2008/060689 PCT/US2007/068890 23 the user, and selection of a menu mode on the hand-held controller brings up an additionalhierarchical menu of functions through which the user can navigate, for example, using thedirectional pad.

[0065] In an embodiment of the control system of the present invention, audio isprovided on one or more of the processor, the hand-held controller, the head-mounted display, ora separate headset.

[0066] The control system of the present invention preferably has two states (on and off)and three modes: (1) training mode; (2) operation mode; and (3) maintenance mode. The modesof the control system are distinct from the button function modes of the hand-held controller.After being powered on, the system may default into an operation mode, default to the last modeselected, or may initially prompt the user to choose among the three modes. Most systemfunctions, including the exemplary functions listed in the table below, are preferably performedin all three modes.

Power

On/off

Status

Communicate communicate with robot status of communications tethered and wireless communication WO 2008/060689 PCT/US2007/068890 24

Control drive/stop brake engage/release speed control flipper control head/neck control pose selection camera selection camera zoom camera control options includingaperture/exposure/resolution/black and white/color/etc.microphone control on/off/speakspeaker control on/off/volume request information/status/data illumination on/off/other select options select robot payload control map controls (autonomous robots or assistance)autonomy controls

Display display video WO 2008/060689 PCT/US2007/068890 25 display health and status (system) display options GPS location/navigational information

Audio

Emit

Send adjustment options

Process process data/audio/video [0067] The system is intended for use by a dismounted operator, dismounted means thatthe operator is freely moving about outside of the remote vehicle(s). However, the system mayadditionally be used by an operator that is not dismounted. The system of the present inventionmay be useful to an operator that is not dismounted in an instance where the operator hasdifficulty reaching all of the controls needed to operate the vehicle and its payloads, or thevehicle and other remote vehicles.

[0068] The system of the present invention should be capable of controlling remotevehicle mobility, executing operator tasks with one or more remote vehicles, and supportingmaintenance functions.

[0069] FIG. 13 illustrates a soldier using the control system of the present invention tocontrol a robot. Although the robot is illustrated to be in the soldier’s line of sight, the present WO 2008/060689 PCT/US2007/068890 26 invention is directed to non-line-of-sight operation as well, with the solder using the head-mounted display to see what the robot sees and thereby effectively control the robot.

[0070] FIG. 13A illustrates an embodiment of the invention including a two-piece hand-held controller that functions substantially similar to the one-piece hand-held controllerdescribed above. This embodiment of the invention allows the left portion of the controller to beattached to the user’s gun, so that one hand can remain on the gun while controlling the remotevehicle.

[0071] FIGS. 13B and 13C illustrate another embodiment of the invention including atwo-piece hand-held controller. In this embodiment, the right hand controller is mounted to thegun and the left hand controller can be secured to a quick-release pad. The left hand controllerwould preferably hang from the user’s left shoulder. This embodiment would be preferablywhere a user is trained to or tends to keep his firing hand on the gun.

[0072] The controller may have a variety of shapes and sizes to facilitate ease of grippingand actuation by a user. For example, the one or both pieces of the controller may include a gripportion shaped to be held between a little finger, a ring finger, and the ball of a thumb of arespective hand, leaving the index finger, middle finger, and thumb of the respective hand free tomanipulate controls. One or both pieces of the controller may include a joystick t bemanipulated by the user’s thumb. The two-piece hand-held controller may include the samenumber of buttons as the one-piece controller above, or may include a more limited number ofbuttons.

[0073] In an embodiment of the two-piece hand-held controller, the two pieces may bemated to form a one-piece hand-held controller for use as described above. In this embodiment,the two pieces may look more like halves of the one-piece hand-held controller illustrated in WO 2008/060689 PCT/US2007/068890 27 FIG. 2.

[0074] As in the prior disclosed embodiments, the hand-held controller communicateswith the display via a processor (not shown).

[0075] Remote vehicles can utilize a number of autonomous behaviors that can beimplemented automatically or via the control system, such as via the GUI icons described above.Such behaviors, illustrated in FIG. 14, can be categorized as: (1) ballistic behaviors thatautonomously execute once within a defined operating period; (2) semi-ballistic behaviors thatexecute once within a defined operating period and that operate autonomously while allowing formanual control during execution; or (3) persistent behaviors that execute continuously andautonomously while allowing the operator to manually control other behavior(s) of the remotevehicle. In an embodiment of the present invention, the autonomous behavior(s) may begin byeither responding to sensor output and autonomously starting the behavior, responding tooperator input via the depression of a key, soft key, or other actuator included the control systemdescribed above, or by responding to other behavior output.

[0076] An embodiment of the present invention provides the operator with varying levelsof autonomy so that the operator may control the remote vehicle at times and choose to allow theremote vehicle to operate autonomously at times or concurrently. Autonomous behaviors thatexecute one-time operations simplify operator manipulation of the remote vehicle when suchoperation includes monotonous or difficult tasks.

[0077] FIG. 14 is a block diagram illustrating an exemplary embodiment of autonomousbehaviors available to an operator and included within the remote vehicle’s control system.Included within the control system manipulated by the operator is a software array of behaviorsorganized under a main autonomous behavior 7050 and fanning out into the various subtypes of WO 2008/060689 PCT/US2007/068890 28 autonomous behavior. In particular the main autonomous behavior 7050 identifies in memorythree main subtypes of behaviors: ballistic behaviors 7065, semi-ballistic behaviors 7092 andpersistent behaviors 7053. An embodiment of the present invention includes the capability toprovide all three types of behaviors, but the present invention also contemplates providing onlyone or two types of behaviors. Ballistic behaviors 7065 comprise a particular behavior routinethat executes for a finite period of time when the behavior is activated. Activation of a ballisticbehavior 7065 causes that particular behavior’s status to indicate that the behavior is active, andfurther causes that behavior to put in a vote to the actuator to gain control of its associatedactuators. Exemplary ballistic behaviors 7065 include: stair climbing 7068, preset actionsequence 7071, click-to-drive or click-to-grip 7074, custom pose presets 7077, autonomousflipper routine 7078, retro traverse 7080, and self-righting 7083.

[0078] FIG. 15 is a flow diagram illustrating an activation routine used to activate aballistic behavior and its associated routines. To activate the behavior, the operator must actuatea control system button, switch, etc. to generate an associated signal, and the signal is transmitted802 to the control system. The control system then calculates a command 804 representative ofthe actuated button, switch, etc. and sends the command to the remote vehicle via acommunication connection. Once the command is received by the remote vehicle, the remotevehicle’s control system 1155 (see FIG. 21) executes a routine to determine if the behavior iscompatible 806 with the remote vehicle’s current state. This means that the executed routine willevaluate all sensor output to determine whether or not the remote vehicle’s position within itsenvironment, the current internal state of the remote vehicle, the current operational behavior onthe remote vehicle, or the remote vehicle’s environment are incompatible with the chosenbehavior. If the behavior is not okay to run (not permitted), the remote vehicle generates WO 2008/060689 PCT/US2007/068890 29 feedback information 808 that is sent to the user, alerting the user to the behavior’sincompatibility. The ballistic behavior activation routine is then exited 824.

[0079] If the behavior is compatible (permitted), the remote vehicle changes the startcondition of the chosen behavior to a positive value 810, causing the behavior to turn on. Onceturned on, the behavior sends a vote to the arbiter 812 requesting control of its associatedactuators. If the behavior has a higher priority than the behavior currently in control of theactuators 814, the remote vehicle will gain control of the actuators and wait for a second startcondition (explained further below). If the behavior doesn’t have a higher priority than thebehavior currently in control of the actuators 814, the behavior will wait 816, and send anothervote 812 to the arbiter. The behavior will continue to do this until it gains control of the actuator.Should the behavior have control of the actuator, and its second start condition is true 818, thenthe software routines included within the behavior will execute 822. When finished executing,the routines will alter the behavior’s start conditions to a false or stop status effectively haltingthe behavior 824.

[0080] If the remote vehicle’s second start condition 818 is not true, the behavior willwait 820 until such a condition is true. A second start condition check 818 is included toaccommodate those behaviors that may be in a perpetual start mode, but that are not activateduntil they receive particular sensor information. Alternatively, the second start condition check818 could be used to activate routines within behaviors that are currently in an “on” state. Anexample of the above routine includes starting the stair climbing behavior which can beaccomplished by, for example, depressing a soft button included on the screen, which in turncreates 800 and sends 802 a signal to the control system. The control system interprets the signalas indicating the start of stair climbing, and creates and sends a command 804 to the remote WO 2008/060689 PCT/US2007/068890 30 vehicle indicating that the stair climbing behavior should be activated. A routine within theremote vehicle’s control system 1155 then determines whether or not the remote vehicle is ableto execute stair climbing 806.

[0081] In response to an allowance of execution of stair climbing, the routine will thenalter the stair climbing behavior’s first start condition 810 to a positive or true value and the stairclimbing behavior will begin to send votes to the arbiter requesting control over the drive motors,tilt sensor, and other actuators and circuits involved in stair climbing. When the arbiterdetermines that stair climbing has the highest priority 814, stair climbing will then check to see ifits second start condition is true. Such a start condition could include such input as thepositioning of a target location over the stair case using a selection graphic included on thedisplay screen. Once the target location is input, a message could be sent to the remote vehicleindicating that the second start condition is true 818 and further causing the routines within thestair climbing routine to execute 822. During the time period between gaining actuator controland realizing a second start condition, the stair climbing behavior will wait 820. Once the robothas reached the top of the stairs, as indicated by the tilt sensor, an end condition is reached andthe stair climbing behavior resets its flags to a stop or negative start condition which effectivelyhalts and stops 824 the stair climbing behavior.

[0082] Activation of a semi-ballistic or interactive behavior 7092, on the other hand, cancause one of either an alternative version of a pre-existing behavior to execute, or a one-timetuning behavior to execute. For example, a behavior or routine that starts a fire-and-forgetprocess for a limited time (or stopped by a particular detection) but that permits user interactionor partial tele-operation during its course (in contrast to what is referred to herein as a “ballistic”behavior, which generally proceeds for a specific time period or until finished but would be WO 2008/060689 PCT/US2007/068890 31 interrupted and terminated by tele-operation intervention. Similar to ballistic behaviors 7065,alternative embodiments of the invention can include more or less semi-ballistic behaviors in thesemi-ballistic set, or can not include a semi-ballistic behavior set 7092 within the autonomousbehaviors 7050. Semi-ballistic behaviors 7092 may include, for example, quick brake 7089 andspeed boost 7086. In an embodiment where the semi-ballistic behavior 7065 is used to fine tuneanother behavior, the behavior chosen to be fine tuned can either be selected by the operator viapressing a button, selecting a behavior on the display via soft keys, a mouse, or controller, orthere could be a behavior pre-associated with a particular semi-ballistic behavior. Fine tuning abehavior preferably includes altering calculations within a routine included within a behavior, oraltering variables included within the behavior.

[0083] FIG. 16 is a flow chart illustrating a routine for activating a semi-ballisticbehavior used to tune a behavior. To activate the behavior, the operator actuates a controlsystem button or switch, which generates a signal associated with that particular button or switch830. The signal is transmitted 832 to the control system, which calculates a command 834representative of the actuated button or switch and sends the command to the remote vehicle viaa communication connection. This command includes information indicating that the semi-ballistic behavior should be activated, along with information indicating which behavior thesemi-ballistic behavior should be applied to. Once the command is received by the remotevehicle, its control system 1155 executes a routine to determine if the behavior is compatible 836with the remote vehicle’s current state. This means that the executed routine will evaluate allsensor output to determine whether the remote vehicle’s position within its environment, itscurrent internal state, its current operational behavior, or its environment are incompatible with the chosen behavior. WO 2008/060689 PCT/US2007/068890 32 [0084] If the behavior is not okay to run (not permitted), the remote vehicle generatesfeedback information 838 that is sent to the user, alerting the user to the behavior’sincompatibility, and the ballistic behavior activation routine is exited 850. Should the behaviorbe compatible (permitted), the remote vehicle changes the start condition of the chosen behaviorto a positive value 840, effectually causing the behavior to turn on. Once turned on, the behaviorsends a vote to the arbiter 842 requesting control of its associated actuators. If the behavior has ahigher priority than the behavior currently in control of the actuators 844, then the remote vehiclewill gain control of the actuators. If the behavior doesn’t have a higher priority than the behaviorcurrently in control of the actuators 844, then the behavior will wait 846, and send another vote842 to the arbiter. The behavior will continue to do this until it gains control of the actuators.Once the behavior has control of the actuator, the routine within the behavior 848 will execute.

[0085] The routine selects the chosen behavior to be altered and tune variables orroutines included within the behavior according to the routine within the semi-ballistic behavior.Once the routine within the semi-ballistic behavior finishes altering the chosen behavior, theroutine alters the semi-ballistic behavior’s start conditions to a false or stop status, effectivelyhalting the semi-ballistic behavior 824. An example of a semi-ballistic behavior is the speedboost behavior 7086 which has a chosen behavior already associated with it, the drive behavior.When an operator actuates the button or switch associated with speed boost, a signal is created830 and sent 832 to the control system, where the signal is converted into a command that is sentto the remote vehicle via a communication link 834. Once the remote vehicle’s control system1155 receives the command, a routine included in the remote vehicle’s control systemdetermines whether or not speed boost is compatible with the remote vehicle’s current state. Forexample, should the remote vehicle currently be climbing stairs, the routine may alert the user WO 2008/060689 PCT/US2007/068890 33 that speed boost cannot be activated. When speed boost is okay to activate 836, the startcondition in the speed boost behavior is set to a positive start value 840, and speed boost beginssending in votes 842 to an arbiter (see FIG. 31) to gain control of the actuators associated withthe drive behavior. Once speed boost is determined to be the highest priority behavior, theroutine within speed boost will then alter 848 any one of a speed range or velocity value withinthe drive behavior. Upon completing the change, the routine within speed boost alters speedboost’s start condition to a negative value and the speed boost behavior halts and turns off speedboost 850.

[0086] Also included within the autonomous behaviors 7050 are persistent behaviors7053, which include behaviors that can be turned on and kept on via an always true fist startcondition. A persistent behavior is activated via a proper second start condition. Persistentbehaviors 7053 start when the remote vehicle is powered up and can be stopped by actuating acontrol system button, switch, etc. An embodiment of the invention includes a persistentbehavior set 7053 including an obstacle avoidance 7059 behavior. While shown as a semi-ballistic behavior in FIG. 14, cruise control can alternatively be a persistent behavior.

[0087] FIG. 17 is a flow chart illustrating a routine to activate or de-activate a persistentbehavior. To de-activate a currently activated persistent behavior, the operator actuates a controlsystem button, switch, etc. generating a signal that is transmitted 857 to the control system. Thecontrol system then calculates a command 859 representative of the actuated button, switch, etc.and sends the command to the remote vehicle via a communication connection. According to anembodiment of the invention, the command either includes a start or stop command that causesthe persistent behavior to have an on or off state. When on, the behavior will execute in responseto sensor and system input. When off, the behavior will not execute. WO 2008/060689 PCT/US2007/068890 34 [0088] Once the command is received by the remote vehicle, the remote vehicle’s controlsystem 1155 relays the command to the proper behavior, which causes the behavior’s first startcondition to be altered. When the command indicates that the persistent behavior should beturned on, the start condition will be changed to a positive or on condition. When the commandindicates that the persistent behavior should be turned off, the start condition will be changed to anegative or off condition. Depending on whether the condition was made positive or negative,the persistent behavior will either start or stop 865. In an embodiment where persistentbehaviors have an initial positive start condition, an operator will need to turn off the behaviorsafter the remote vehicle is powered up to keep the persistent behaviors from executing inresponse to system and sensor output.

[0089] FIG. 18 illustrates the execution of routines within a persistent behavior when theroutines’ second start condition is activated by system or sensor output. The flowchart in FIG. 18 assumes that the persistent behavior’s first start condition is true, and has been true as afunction of its “always on” characteristic. To initiate the execution of the persistent behavior,sensor or system output must be sent 867 to the persistent behavior by the remote vehicle’scontrol system 1155. If such output is of the type that will cause the remote vehicle’s secondstart condition to become positive, the persistent behavior’s second start condition flag will bechanged 871 to a positive or start value and the persistent behavior will begin to send votes 873to the arbiter to gain control of the behavior’s associated actuators and manipulators. If thebehavior has a higher priority than the behavior currently in control of the actuators 873, then thebehavior will gain control of the actuators. If the behavior doesn’t have a higher priority than thebehavior currently in control of the actuators 875, then the behavior will wait 878, and sendanother vote 873 to the arbiter. The behavior will continue to do this until it gains control of the WO 2008/060689 PCT/US2007/068890 35 actuators or manipulators. Should the behavior have control of the actuator, the routine withinthe behavior will execute 879. The routine will continue to execute until it loses control over theactuators 885, in which case one of the first or second start condition flag is changed to anegative or stop value 887 which causes the behavior to stop 883. If the first start condition flagchanges to a negative or stop value, the behavior is disabled. In an embodiment of the invention,the behavior can thereafter be restarted using the routine displayed in FIG. 17. If the second startcondition flag is changed to a negative or stop value, the behavior will stop until it detects sensoror system output that causes the behavior to start again.

[0090] An example of a persistent behavior is obstacle detection (avoidance) 7059, whichis always on unless an operator actuates a control system button, switch, etc. for altering the firststart condition of the obstacle detection behavior. When actuated, a signal is generated and sent857 to the control system, where a representative command is sent 859 to the remote vehicle.Once received by the remote vehicle, the command is relayed to the obstacle detection behaviorwhere it changes the first start condition flag 861 to a negative value. This change of valuecauses the obstacle avoidance behavior to be disabled. If the obstacle detection behavior remainson, and a sensor detects an obstacle, the sensor output is sent to the obstacle detection behavior867, where it causes the obstacle detection behavior’s second start condition flag to change to apositive or on state 871. Upon the second start flag’s change in state, the obstacle detectionbehavior sends votes 873 to the arbiter to gain control of the drive assembly, actuators, andassemblies needed to avoid obstacles. When the arbiter determines that obstacle detection hasthe highest priority 875, obstacle detect then executes it routines 879. While executing, thebehavior checks to make sure that it has control of the actuators 885, and halts the routines and behavior 883 when it loses control. The behavior also checks to see if the second or first start WO 2008/060689 PCT/US2007/068890 36 conditions have changed, and if they change from positive to negative, then the routines andbehavior halt 883.

[0091] The above description of ballistic, semi-ballistic and persistent behaviors isexemplary. The present invention contemplates implementing other versions of the behaviors.For example, steps 879 through 887 of FIG. 18 may be substituted into the ballistic and semi-ballistic routines for steps 848 and/or 822.

Tutorial Routines [0092] In an embodiment of the invention, the software included in the control systemalso includes tutorial routines able to perform the characteristics of a training system. Thetutorial routines could include a storage bank for providing cells of storage to each mission forwhich the operator indicates that training information should be recorded. The traininginformation can more aptly be called macros in that it records, according to a timeline, anenvironmental set of variables, a command set, and a set of system variables. Preferably, thecommand sets include both commands sent by the operator and commands generated and sent byroutines within the remote vehicle’s control system 1155. The command sets and variables arerecorded as use routines able to recreate the recorded action according to a proper timeline.When a recorded mission is replayed, the use routines included in the macro are executed, whichcauses the control system to display information to the user as though it were sensing therecorded environmental and system sensor information, and further causes the remote vehicle tomobilize according to the recorded commands. The result is a replaying of the events of themission. The routines can be stored and used later as a pre-defined action sequence, and theymay further be used to train operators on the proper use of the control system and remote vehicle.When routines are used as a pre-defined action sequence, the replay routines call additional use WO 2008/060689 PCT/US2007/068890 37 routines that suppress environmental and system variable information and execute only thestored commands.

Robot Structure [0093] FIGS. 19A and 19B illustrate an embodiment of a remote vehicle of the presentinvention. A mobile robot 10 has a head 122 that includes a drive camera 127 mounted thereonto provide visual information regarding the environment of the mobile robot 10, an electro-opticinfrared (EO/IR) module 4165 which uses EID AR to map the environment and detect possibleobstacles, main drive treads 110 for propelling and steering the mobile robot 10, and robot-mounted antennae 131 for communicating with an operator via the control system. The mobilerobot 10 also includes rotatably extensible, treaded flippers 115 that can be deployed to augmenttraction and to overcome obstacles, and a robotic gripper 150 for grasping or manipulatingobjects in the mobile robot's environment. The mobile robot 10 further includes an attackcamera 151 to aid in navigation of the mobile robot and the robotic gripper 150.

[0094] FIG. 20 illustrates a mobile robot with both its robotic gripper 113 and attachedupper arm 112 and lower arm 111 extended. Further shown is the extension of an arm 118connected to the head 117, and the extension of the head 117 from the arm 118. Also shown isthe advantage of having an attack camera 114 attached to the gripper's upper arm 112. Theattack camera 114 is able to display the gripper's position within its environment in relation tothe position of the gripper's upper arm 112. Using this information, the user can adjust the upperarm 112 to reposition the gripper 113 in its environment. Further shown is an extended flipper116 which shifts the mobile robot's center of gravity.

[0095] FIG. 21 is a block diagram depicting an embodiment of a mobile robot controlsystem. Included in the control system 1155 is a single board computer (SBC) 1110 such as, for WO 2008/060689 PCT/US2007/068890 38 example, a Freescale MPC5200. A microprocessor can be used in lieu of the single boardcomputer 1110. Connected to the single board computer 1110 is a global positioning system(GPS) module 1135, a radio module 1150, and a wireless Ethernet transmitter and receiver 1140.A radio module 1150 is connected to the single board computer 1110 via an Ethernet switch1190, and is further connected to a radio antenna 1145. The user can control the control system1155 using a radio communicating over a secure connection created by the radio module 1150and the radio antenna 1145.

[0096] Further included in the control system 1155 in the illustrated embodiment is apower supply 1115 and memory 1125 including any combination of ROM, volatile, and non-volatile memory. Also connected to the single board computer are network 1 transmitter andreceivers 1120, 1121, 1122 and a network 2 switch 1130. The network 1 transmitter andreceivers 1120, 1121, 1122 provide communication between the control system 1155 and anactuator assembly 1165 via a first connection wire 1187 installed between the first network 1transmitter and receiver 1122 and second neck 1191 and a second connection wire 1186 installedbetween the second network 1 transmitter and receiver 1120 and first neck 1194. The network 1transmitter and receivers 1120, 1121, 1122 also provide communication between the controlsystem 1155 and the chassis 1160 via a third connection wire 1181 installed between the thirdnetwork 1 transmitter and receiver 1121 and the chassis 1160. The network 2 switch 1130, onthe other hand, provides communication between the network 2 switch 1130 and each of thechassis 1160, the first neck 1194, and the second neck 1191 via a first connection link 1180, asecond connection link 1188, and a third connection link 1180, between the chassis 1160, firstneck 1194, and second neck 1191, and the network 2 switch 1130.

[0097] In an embodiment of the invention, the network 1 transmitter and receivers 1120, WO 2008/060689 PCT/US2007/068890 39 1121, 1122 include an RS485 transmitter for transmitting data over an RS485 network using apoint-to-point configuration between each N1 (network 1) transmitter and receiver and acorresponding N1 transmitter and receiver. For example, the communication between thecontrol system 1115 and the head 1195 is achieved by establishing a communication linkbetween an Nla transmitter and receiver 1122 connected to the control system 1115 and an N1transmitter and receiver 4315 connected to the neck’s field programmable gate array (FPGA)4330. A connection is then made between the N1 transmitter and receiver 4360 connected to theneck’s FPGA 4330, and the N1 transmitter and receiver 4120 connected to the head’s FPGA4125. Thus, a network is created between the SBC 1110 and the head’s FPGA 4125 via thenodes created by the N1 transmitter and receivers included in the control system 1155, the firstneck 1194, and the head 1195. In an embodiment of the invention, the network has a two-wireconfiguration providing half duplex communication.

[0098] On the other hand, the network 2 (N2) transmitter and receiver 1130 of theillustrated embodiment includes an Ethernet switch for receiving and routing data over anEthernet network. An example of this includes communication between the SBC 1110 and thehead 1195, created by the N2 switch 1130 being connected to the SBC 1110 to establish aconnection with the N2 switch 4320 connected to the neck’s FPGA 4330 via a communicationlink 1188. A connection is then made between the N2 switch 4320 connected to the neck’sFPGA 4330 and the N2 switch 4130 connected to the head’s FPGA 4125. The connectionsmade create a network between the SBC 1110 and the head’s FPGA 4125. In an embodiment ofthe invention, the network is a full duplex communication implemented via Ethernet cable.

[0099] Connected to the control system 1155 is a chassis assembly 1160 as well as anactuator assembly 1165. In an embodiment of the invention, the actuators included in the WO 2008/060689 PCT/US2007/068890 40 actuator assembly 1165 are a first neck 1194 connected to a head module 1195, and a secondneck 1191 connected to a third neck 1192 which is further connected to a gripper module 1193.Also preferred is that each of the necks 1194, 1191, 1192, include a substantially similarhardware circuit and software routine architecture 4301. In an embodiment of the invention,both of the actuator modules within the actuator assembly 1165 are connected to the controlsystem 1155 via connection wires 1187, 1186, and connection links 1189, 1188. The chassis1160 is connected to the control system 1155 via a connection wire 1181, and a connection link1180. The present invention contemplates allowing the control system 1155 to communicatewith the actuator assembly 1165 and the chassis 1160 via connection links only, whereinconnection links include Ethernet, wire, wireless, radio, or any other link that providescommunication between circuits. The present invention also contemplates allowing the controlsystem 1155 to communicate with the actuator assembly 1165 and the chassis 1160 viaconnection wires only.

[00100] An embodiment of a chassis assembly 1160 is further described in theblock diagram shown in FIG. 22. Included within the chassis 4001 base circuit 4055 is an FPGA4035 connected to a network 1 transmitter and receiver 4050, and a network 2 switch 4045. Inan embodiment of the invention, the FPGA 4035 is a Xilinx XC3S1000. Further included withinthe base circuit 4055 are power regulators 4015 including circuits configured to manage powerwithin the chassis 4001. Additionally, included in the base circuit 4055 for motion control aremotor drivers 4030, motor encoders 4025, and a motor battery charger 4020. The chassis 4001also includes a number of motion control components connected to the base circuit 4055,including incremental encoders 4060, drive motors 4065, a brake 4070, thermistors 4075, and hall sensors 4080. WO 2008/060689 PCT/US2007/068890 41 [00101] A block diagram of an embodiment of a neck module 4301 is shown inFIG. 23. The neck module 4301 includes a base circuit 4305 having an FPGA 4330 connected toa first network 1 transmitter and receiver 4315, a second network 1 transmitter and receiver4360, and a network 2 switch 4320. Included within the base circuit 4305 are power regulators4340 that are circuits configured to regulate power within the neck module. The first and secondnetwork 1 transmitter and receivers 4315, 4360 are connected to a payload connector 4310,4355. The payload connectors 4310, 4355 are plugs configured to mate with a correspondingplug on a payload such as an additional neck module 1191, 1192, a head module 1195, or agripper module 1193. Further included within the base circuit 4305, to aid in motion control, area clavical encoder 4345, a tilt 1 encoder 4350, half-bridge drivers 4365, and h-bridge drivers4370. Additional motion control components included within the neck module 4301 andconnected to the base circuit 4305 are brushless motors 4385, hall sensors 4380, and a thermistor4375.

[00102] The neck module 4301 is also connected to a pan module 4390 and a tiltmodule 4395. The pan module 4390 allows the user to pan the distal portion of the neck aboutthe neck's pivot point, while the tilt module 4395 allows the user to tilt the distal portion of theneck about the neck's pivot point. A slip ring and magnet assembly for the connections betweenthe pan module 4390 and the neck module 4301, between the pan module 4390 and the tiltmodule 4395, and between the tilt module 4395 and a further connection.

[00103] A block diagram of an embodiment of a head module 4100 is shown inFIG. 24, and includes a base circuit 4105 with a centrally located FPGA 4125. Connected to theFPGA 4125 are a network 2 switch 4130, and a network 1 transmitter and receiver 4120 which isfurther connected to a payload connector 4190. In an embodiment of the invention, the payload WO 2008/060689 PCT/US2007/068890 42 connector 4190 is a plug configured to mate with a corresponding plug on a neck module 4301such as neck module 1 1194. Additionally, included in the base circuit 4105 are powerregulators 4110 that are circuits configured to manage power within the head module 4100. Thebase circuit 4105 is connected to a set of video decoders 4150 via a CCIR-656 videocommunication bus 4145 and a serial bus 4140. Input to the video decoders 4150 includes: (1)the output from a drive camera 4160; (2) the output from a differential NTSC receiver 4155which is further connected to the head module connector 4156; and (3) the output from theelectro-optic infrared (EOIR) module 4165. Output from the EOIR module 4165 includes a nearinfrared (NIR) 4170 camera, a long wave infrared (LWIR) 4175 camera, and a laser range finder4180.

[00104] An embodiment of a gripper module 1193 is shown in the block diagramof FIG. 25. Located within the base circuit 4210 of the gripper module 4201 is a FPGA 4240connected to a network 2 switch 4245, and network 1 transmitter and receiver 4235 that isfurther connected to a payload connector 4230. The payload connector 4230 is preferably a plugconfigured to mate with a corresponding plug on neck module 3 1192. Also included within thebase circuit are power regulators 4220 including circuits for regulating power within the grippermodule 4201, and the following components for motion control: gripper encoders 4215; half-bridge drivers 4255; and h-bridge drivers 4260. Additional motion control componentsconnected to the base circuit 4210 and included within the gripper module 4201 are brushlessmotors 4285, hall sensors 4280, and a thermistor 4275. A video decoder 4265 is also connectedto the base circuit 4210. An attack camera 4270 located proximate to the gripper 4201 createsinput to the video decoder 4265 so that the user can view the gripper 4201 actions. WO 2008/060689 PCT/US2007/068890 43

Network Configuration [00105] FIG. 26 illustrates an embodiment of a network installed between the head4401 and the control system 4409 and the chassis 4406. There are two sub-networks includedwithin the network: (1) the Ethernet network created by the Ethernet switches 4427 includedwithin each module and the communication link 4415 that connects each Ethernet switch to acorresponding switch; and (2) the RS485 network created by the RS485 transmitter and receivers4430 and the connection wires 4412 that connect each RS485 transmitter and receiver to acorresponding transmitter and receiver. An alternative network may include RS422 transmitterand receivers in lieu of RS485 transmitter and receivers. Such an embodiment would providefull duplex communication, meaning each transmitter and receiver could simultaneously receiveand transmit data packets.

[00106] The RS485 network embodiment illustrated in FIG. 26 includes masternodes and slave nodes. A master node includes the node created by the single board computer4436, the node created by the head 4401 and the node created by the chassis 4406. Such nodesare master nodes because they provide a central point to which other nodes, slave nodes,communicate. An example of such communication includes the communication between thesingle board computer 4436, the chassis 4406, and the head 4401. The single board computercan receive information from the head 4401 representative of a drive command and pass suchinformation onto the chassis 4406. This configuration would consider the single board computer4436 a master node, and the chassis 4406 and the head 4401 slave nodes.

[00107] The network includes a control system 4409 with a single board computer4436 for processing information transmitted to the computer 4436 by each network. To gathersuch information, the single board computer 4436 is connected to a single Ethernet switch 4427 WO 2008/060689 PCT/US2007/068890 44 which in turn is linked to an Ethernet switch 4427 within the neck 4403 via a communicationlink 4415 and an Ethernet switch 4427 within the chassis 4406 via a communication link 4415.The single board computer 4436 connects to two RS485 transmitter and receivers 4430, onetransmitter and receiver 4430 is connected to a RS485 transmitter and receiver 4430 in the neck4403 via a connection wire 4412, and a second transmitter and receiver 4430 is connected to aRS485 transmitter and receiver 4430 in the chassis 4406 via a connection wire 4412. While anembodiment of the invention includes both an Ethernet network and a RS485 network, analternative embodiment can include only an Ethernet network. Such a network would provide afull duplex communication network requiring less infrastructure than a RS485 network. Theinclusion of both an RS485 network and an Ethernet network is advantageous because itprovides two networks, including an Ethernet network capable of communicating from one farnode to another, thus bypassing the token ring configuration of the RS485 network whichrequires passage of data through intermediate nodes.

[00108] Each actuator assembly includes a core circuit capable of implementing an alternative network that includes only an Ethernet network. The core circuit includes a fieldprogrammable gate array 4418 with a media access controller 4433, where the FPGA is capableof managing multiple digital input 4421 and is further programmed to interface with the mediaaccess controller (MAC), which includes information or commands generated either by theFPGA or the digital VO 4421 to generate frames of data to be sent to other modules within therobot via packets sent by the Ethernet switch 4427. Furthermore, the MAC is able to parseframes of data included within packets it receives from the Ethernet switch and extractinformation or commands that are either processed by routines included within the FPGA orrelayed to the digital VO 4421. Due to the full duplex communication network created by the WO 2008/060689 PCT/US2007/068890 45

Ethernet switch 4427, the MAC is able to simultaneously transmit and receive packets of data.The RS485 transmitter and receiver 4430, on the other hand, is half duplex communicationmeaning that the transmitter and receiver 4430 cannot transmit data and receive datasimultaneously. “Actuator assembly” refers to the head 4401, the neck 4403 or the chassis 4406.“Module” refers to a component within the head 4401, the neck 4403, the control system 4409,or the chassis 4406.

[00109] Each Ethernet switch 4427 is also connected to a payload 4424, whereinpayload can include a drive assembly, an EO/IR, or other assembly. Use of an Ethernet switch4427 allows for simultaneous communication between the payload 4424 and other moduleswithin the network including the head 4401, neck 4403, and chassis 4406. An example of thiswould include video information transmitted from a payload 4424 such as the video decoders4150. The form of such information is a constant stream of video feedback from the drivecamera 4160. The example network created using the Ethernet switch 4427 allows forsimultaneous receiving of video information from the drive camera 4160 and transmitting andreceiving of information from the single board computer 4436.

[00110] FIG. 27 illustrates an embodiment of an Ethernet endpoint block 4439including an FPGA 4418 configured to include a MAC and connected to an Ethernet switch4427. The Ethernet switch 4427 is connected to the MAC included on the FPGA 4418 via amedium independent interface bus that provides a logical interface with a communicationprotocol selecting the line speed and whether the connection is in a half or full duplex mode.The MAC parses the I/O ports 4445 included on the FPGA and generates frames of data to beincluded in packets. The packets are transmitted out through the Ethernet switch 4427 to the restof the modules in the network. Included on the Ethernet switch 4427 are physical devices or line WO 2008/060689 PCT/US2007/068890 46 interfaces that handle the transfer of data from the Ethernet cable to the Ethernet switch 4427.An oscillator 4442 is included to facilitate the exchange of information between the Mil buses.

[00111] FIG. 28 illustrates an embodiment of the invention using the Ethernetendpoint block in the chassis, neck, head and EO/IR payload. Further shown is the connection ofvarious payloads to the Ethernet endpoint block as well as the running of Ethernet to othermodules. Advantages of an Ethernet endpoint block include: low EMC footprint, noise/bouncetolerant, modularity, can uniformly read/control each endpoint. In addition, an Ethernet networkcan handle far node-to-far node communication.

[00112] Referring to FIG. 26, both the RS485 network and the Ethernet networkcan be used for communication. As an example, the Ethernet network can be used for quick datatransmission of video output from the EO/IR module to the single board computer 4436, whilethe RS485 network is used to transmit drive commands from the computer 4436 to the head 4401via the neck. Such a transmission would include the creation of video output by the EO/IRmodule 4424, the video output would then be relayed to the Ethernet switch 4427 where it wouldbe transmitted directly to the single board computer 4436 in the central control system 4409.The video data would be transmitted via a cable 4415 connected at one end to the Ethernetswitch 4427 and at the other end to an Ethernet switch in the neck 4403, and via a cable 4415connected at one end to the Ethernet switch 4427 in the neck 4403 and at the other end to anEthernet switch 4427 in the control system 4409. The Ethernet switch 4427 in the controlsystem 4409 is connected to the single board computer 4436 included in the central controlsystem 4409. Although the video information must pass through two additional Ethernetswitches, such information can pass through each switch without the need for additional signalprocessing by the intermediary Ethernet switches. WO 2008/060689 PCT/US2007/068890 47 [00113] If the RS485 network is used to send a drive command from the singleboard computer 4436 to the head 4401, the data must first be sent to an RS 485 transmitter andreceiver included in the control system 4409, which then transmits the data over a wire 4412connected at the other end to an RS485 transmitter and receiver located in the neck 4421. Thedata must then be processed by the FPGA 4418 included in the neck 4403 and then passed on toa second RS485 transmitter and receiver 4430 included in the neck 4403. The second RS485transmitter and receiver 4430 then transmits the data over a wire 4412 to an RS485 transmitterand receiver 4430 included in the head 4401 which is further connected to an FPGA 4418included in the head 4401. The RS485 network processes the data at the intermediary node (inthe neck 4403) between the head 4401 and the control system 4409. The Ethernet network, onthe other hand, is able to send the data through the neck 4403, or intermediary node, withoutrequiring additional signal processing. Including both and RS485 and Ethernet network canprevent bottlenecks created by the passage of large amounts of data over a single network, andfurther allows for faster transmission time due to the inclusion of multiple networks. Alternativeembodiments of the system can include one or more Ethernet networks, or one or more RS485networks. Further embodiments include a full duplex RS485 network implemented using RS422transceivers and receivers.

Gripper Manipulator [00114] FIGS. 29A and 29B illustrate an embodiment of robotic arm 900 forfunctioning as a gripper affixed to the mobile robot 10. The robotic arm 900 preferably includesa base 925 with circuitry required to control the arm. Additionally, the arm 900 includes a pairof actuators 920 installed toward the end of the arm and able to grip and manipulate objects.Further included near the actuators 920 are joints 915,910 which may be mobilized to alter the WO 2008/060689 PCT/US2007/068890 48 position of the actuators 920 in space, and a camera 905 installed proximate the actuators 920 sothat the operator may control actuator 920 movement based on video feedback. The actuatorsare connected to a secondary arm 930 which pivots at a joint 901, and which is connected to amain arm that pivots at a joint 940.

[00115] The joint 940 connected to the arm base 925 and the primary arm 935 canbe controlled by the operator via the control system outlined above. When drive commands aresent to the mobile robot 10 indicating that the joint 940 should be actuated, a drive command issent to the drive assembly located proximate the joint 940 which in turn causes a motor locatedin the drive assembly to mobilize actuators connected to the joint 940 via gears and subsequentlymobilize the primary arm 935. Similarly, drive commands sent to the drive assembly locatedproximate the joint 901 connecting the primary arm 935 to the secondary arm 930 can cause amotor located in the drive assembly to mobilize actuators connected to the joint 901 via gearsand subsequently mobilize the secondary arm 930. Joints 915, 910, capable of mobilizing themanipulators 920 located on the gripper, can also be actuated via drive commands sent to a driveassembly proximate the joint 915 and including a motor. Additionally, the camera 905 installednear the gripper actuators 920 can input video data regarding the gripper’s environment andfurther transmit such data to the control system 1155 where it is further transmitted to the controlsystem to be displayed on a screen so that the operator may view the gripper’s environment.

Software Architecture

Behavior System Overview [00116] In accordance with the present invention, a remote vehicle (such as the mobile robot 10 described above) has included within its control system 1155 a behavior systemcomprising software routines and circuits. FIG. 30 illustrates an embodiment of a behavior WO 2008/060689 PCT/US2007/068890 49 system to be included within a remote vehicle. At the heart of the system are behaviors 715including different behavior software routines that further include behavior software subroutines.The behavior software routines are the main routines and are referred to as the individualbehaviors, for example the stair climbing behavior software routine is referred to as the stairclimbing behavior. The individual behaviors 715 include within them sub-routines, which areroutines that implement the actions associated with each behavior. An example would includethe stair climbing behavior which includes within it a stair climbing routine, a maintainalignment routine, as well as other routines necessary to fully implement the stair climbingbehavior.

[00117] In an embodiment of the invention, each behavior includes a status check routine that constantly checks sensor input to determine a change in start condition. When thestart condition is a positive value, the behavior initiates a routine, included within the behaviorthat begins sending software commands to an arbiter (coordinator) 710 included within thebehavior system. The commands sent to the arbiter 710 are votes that tell the arbiter 710 that thebehavior would like control of the actuators used by the routines included within the behavior.An example of this would include the stair climbing behavior, that responds to a positive changein its start condition by sending votes to the arbiter 710 indicating that stair climbing would likecontrol over the tilt sensor, the drive assembly, the drive and attack cameras, and all otheractuators and manipulators needed to implement the stair climbing behavior. Each behaviorcould have its own specific set of routines, or some or all behaviors 715 may be able to share acommon set of routines included within the behavior system.

[00118] Also included within each behavior is a priority. FIG. 31 illustrates alisting of behaviors within the behavior system in an exemplary order of priority. As shown, a WO 2008/060689 PCT/US2007/068890 50 behavior such as the obstacle avoidance behavior 7059 has a higher priority than the stairclimbing behavior 7068 as it is more important that the remote vehicle avoid an obstacle thanclimb a stair. This practicality can be displayed in a situation where there is a bomb located on aset of stairs, and the behavior system stops the stair climbing behavior 7068 on detection of anobstacle by a sensor, so that the higher priority obstacle avoidance behavior 7059 may controlthe remote vehicle’s drive assembly to drive away from the obstacle which in this case is abomb. Were the obstacle avoidance behavior 7059 is not a higher priority than the stair climbingbehavior 7068, the remote vehicle would have continued to drive toward the bomb, likely hittingit and causing injury to the remote vehicle and those humans present in the surroundingenvironment.

[00119] The arbiter 710 included within the system is a software routine that manages the votes and priorities of the individual behaviors 715 in conjunction with thescheduler 730, to determine when and in what order the behaviors 715 will gain control over theactuators and manipulators within the remote vehicle. To accomplish this, the arbiter 710, at anypoint in time, reviews all the behaviors 715 currently voting for control. To determine whichbehavior 715 will gain control, the arbiter 710 reviews each voting behavior’s priority level, andthe scheduler’s 730 indication of which behavior should gain control based on the length of timethat the current behavior or a past recorded behavior, has or had control of the actuators andmanipulators. An embodiment of the invention includes a scheduler 730, but alternativeembodiments may include a system with a single arbiter 710 that determines the controllingbehavior based on priority level and votes.

[00120] To input sensor output to the behaviors 715 and their correspondingroutines, the system has a set of virtual sensors 720 in communicative connection with a set of WO 2008/060689 PCT/US2007/068890 51 sensors 725. The sensors 725 can include sensor components and related circuitry and softwareroutines that provide feedback representative of the remote vehicle’s current external and internalenvironment. An example includes a wireless receiver providing feedback regarding detectablewireless signals within the remote vehicle’s external environment, and a brake that uses anelectrical switch to provide feedback about the state of the brake within the remote vehicle’sinternal environment via an electrical signal generated when the electrical switch is closed.Output from the sensors 725 is further conditioned by virtual sensors 720 which include circuitsand software able to input sensor 725 signals and process the signals to provide outputsrepresentative of each signal, but in a form able to be processed by the routines within thebehaviors 715.

[00121] In an embodiment of the invention, each of the sensors 725 has acorresponding virtual sensor 720 configured to the requirements of that sensor. An example isthe brake sensor which outputs an electrical signal in response to the actuation of the brake. Thevirtual sensor 720 associated with the brake sensor may be configured to input the raw analogsignal into a signal processing circuit that further conditions the analog input and outputs adigital signal which is further processed by a software routine that outputs a logic valuerepresentative of the brake’s status. Output from the virtual sensors 720 is inputted to thebehaviors 715 where it is used in behavior routines to mobilize the remote vehicle and furtherrespond to raw sensor output.

[00122] Included within the behavior system are actuators 705 able to responds tooutput from virtual actuators 701 by mobilizing and performing actions. To control the actuators705 within the robot 10, the behaviors 715 output control commands which can include drivecommands, communication commands, and other commands able to control actuators included WO 2008/060689 PCT/US2007/068890 52 on the robot 10. Each actuator is able to receive drive commands in a particular format. Thevirtual actuators 701 include software routines and circuits able to input the software controlcommands from the behaviors 715, and convert them into control commands able to be receivedby the actuators 705. In particular, the motors included within the chassis can take drivecommands in a format that preferably includes an electrical signal. The virtual actuator 701associated with the motors within the chassis are able to take the software command generatedby the behaviors 715 and convert the command into a signal that is then transmitted to themotors within the chassis.

Autonomous Remote Vehicle Behaviors [00123] In an embodiment of the invention, these behaviors are included on theremote vehicle in memory, and are executed by the single board computer. There are three typesof behaviors: Ballistic, Semi-Ballistic, and Persistent. The descriptions below refer to mobilerobot 10 described above. The present invention contemplates employing autonomous behaviorson a variety of remote vehicle types as would be appreciated by one of ordinary skill in the art.Ballistic Behaviors

Stair Climbing [00124] The stair climbing behavior drives the mobile robot 10 to traverse a set ofstairs in an autonomous manner, after receiving a command to initiate the behavior andinformation indicating the location of the stairs from the operator. The mobile robot 10 mayinclude a pitch/roll sensor that indicates whether the mobile robot 10 is tilted relative to theground, which is used by the stair climbing behavior to decide whether the mobile robot 10should continue climbing the stairs.

[00125] The mobile robot 10 can be positioned in the vicinity of a staircase 920, WO 2008/060689 PCT/US2007/068890 53 and the user may initiate the autonomous stair climbing behavior by simply identifying thelocation of the stairs 920 and inputting a command to activate the stair climbing behavior. Themobile robot 10 can then ascend or descend the stairs 920 without requiring further input fromthe operator.

[00126] Referring to a control system console illustrated FIG. 32, an embodimentof a stair climbing behavior is initiated when the operator navigates the mobile robot 10 to withina threshold distance of the stairs, such that the stairs are visible in the image data displayed bothin a drive camera window 261 and an attack camera window 262. The operator positions a firstselector 267 to enclose or abut a region of the window 261 corresponding to the stairs, andsimilarly positions a second selector 268 to enclose or abut a region of the window 262 that alsocorresponds to the stairs.

[00127] With the target stairs 920 identified by the first and second selectors 267,268, the operator can then trigger the stair climbing behavior by clicking an on-screen button orotherwise inputting a command that causes transmission of a control signal that activates the stairclimbing behavior. In accordance with an embodiment of the invention, the operator furtherinputs whether the mobile robot 10 should climb up the stairs or descend the stairs. In anotherembodiment, the mobile robot 10 includes a routine for autonomously determining whether thetarget stairs 920 are ascending or descending relative to the mobile robot 10, and informs thestair climbing behavior accordingly.

[00128] FIGS. 33A and 33B illustrate positions of the mobile robot 10 relative tothe target stairs 920 as the mobile robot ascends or descends the stairs 920 in accordance with thestair climbing behavior. The mobile robot 10 may initially extend the flippers 115 to apredetermined angle to facilitate the stair climbing operation. FIG. 33A illustrates an WO 2008/060689 PCT/US2007/068890 54 embodiment of the invention wherein the flippers 115 may rotate out to a 180° angle relative tothe main treads 110 to ensure contact with the stairs 920 and to raise the front end of the mobilerobot 10 up onto the stairs 920. When descending, the mobile robot 10 may instead extend theflippers to an angle 77 that is approximately 45° relative to the main treads 110 (see theembodiment of FIG. 33B).

[00129] When the tilt sensor of the mobile robot 10 indicates that the angle of tiltof the mobile robot 10 is zero relative to the horizon, the stair climbing behavior may stop andnavigation authority may be resumed by another routine.

[00130] FIG. 34 illustrates an embodiment of a method for performing the stairclimbing behavior. At step 2901, the behavior initializes internal variables (by setting the initialturn rate and roll rate to zero, for example), and then determines at step 2902 whether the mobilerobot 10 should ascend the stairs. If so, the mobile robot positions the flippers 115 to theappropriate angle for ascending the stairs at step 2903, outputs a speed value for ascending thestairs at step 2904, and proceeds to traverse the stairs at step 2907. The mobile robot 10 mayascend the stairs at a predetermined speed while under control of the stair climbing behavior.The predetermined speed may be, for example 0.2 meters per second.

[00131] If the mobile robot 10 is determined at step 2902 not to be intended toascend the stairs, then the behavior positions the flippers 115 to an angle appropriate fordescending the stairs, sets a speed appropriate for descending stairs, and proceeds to navigate thestairs at step 2907. Thereafter, the behavior may optionally perform steps to maintain the mobilerobot's alignment with the stairs at step 2908 (for example, to prevent the robot falling off theside of unprotected stairs), and then determines at step 2909 whether the tilt sensor indicates the existence of tilt. WO 2008/060689 PCT/US2007/068890 55 [00132] If tilt exists, the behavior continues to ascend the stairs 920 autonomouslyby returning to step 2907. Otherwise, step 2910 stops the mobile robot 10 from proceedingfurther, and returns the flippers 115 from the ascending or descending position back to theneutral, undeployed position at step 2911.

[00133] To ascertain whether there are more stairs to traverse, the stair climbingbehavior may use a median pitch filter routine to integrate tilt sensing information from multiplesources, and to reduce false positive determinations of being level. In one embodiment, themedian pitch filter routine tracks pitch information from the tilt sensor and uses only thosevalues that fall within the median of all previously recorded values. Accordingly, the routine canreduce the detrimental impact of transient values on the determination of whether the stairtraversal is complete.

[00134] According to an embodiment of the invention, the median pitch filterroutine stores native pitch/roll sensor output in memory. An on-board timer then increments andthe routine periodically checks whether it has been incremented by a full half second. If so, thenthe routine moves on to the next step. Otherwise, the routine stores the tilt sensor output, andincrements the timer. The median pitch filter routine then examines the pitch/roll sensor nativeoutput over the full half second and determines the respective highest and lowest frequencies ofthe signal. Using this information, the median pitch filter routine then calculates the medianfrequency. The median pitch filter routine outputs this calculated median frequency as thepitch/roll sensor output to the robot’s control assembly.

[00135] The maintain alignment routine may be used by the stair climbingbehavior to keep the mobile robot 10 moving in a consistent direction with respect to the verticalaxis of movement, and allows the mobile robot 10 to ascend or descend stairs with a turn rate WO 2008/060689 PCT/US2007/068890 56 magnitude of zero. While moving forward with a zero turn rate, for example, the routinesimultaneously samples the roll angle as determined by the pitch/roll sensor output andsubsequently calculates a turn rate magnitude from the output. In an embodiment of theinvention, the equation by which the turn rate magnitude is calculated may be approximatelyk*X degrees per second, in which k is a constant having a value within the range of 1/10 to 3 andX represents the roll angle. Other embodiments may use differing formulas. At one step, theroutine checks the roll angle to determine whether it has a value other than zero. If so, theroutine returns to the first step and moves forward with a roll angle of zero. Otherwise, theroutine re-aligns the mobile robot 10 by turning the mobile robot 10 by the calculated turn ratemagnitude. Once the mobile robot 10 is re-aligned, the process goes back to the first step andcontinues to climb forward with a roll angle of zero.

[00136] This embodiment of the stair climbing behavior utilizes a tilt sensorallowing the robot 10 to position itself without the need for walls. Alternative embodiments mayinclude the use of a SICK LIDAR sensor to detect walls to position the robot as the robot movesup the stairs, or the use of SONAR to detect walls and position the robot as it moves up thestairs. Other alternative embodiments include a fully autonomous version of stair climbing thatis implemented upon the detection of stairs. Such a version may include a sensor placed towardthe outer rim of the robot’s lower chassis to detect negative obstacles such as downward stairs, ormay require multiple sensors to indicate that there is an obstacle within the allowed height,meaning that software routines within the robot would associate certain dimensions with stairs.Still other alternative embodiments include a routine that commands the robot to re-position itsarms to 180° when it reaches the top of the stairs, or a robot that utilizes a magnetic compass or IMU in addition to or in lieu of a tilt sensor. WO 2008/060689 PCT/US2007/068890 57

Preset Action Sequence [00137] FIG. 35 illustrates an embodiment of a preset action sequence behavior bywhich an operator can create a custom action sequence routine that is an aggregation of user-chosen routines and behaviors. An action sequence routine may consist of a combination ofavailable robot behavior routines and events. Alternatively, the operator can include actions andmovements available to the mobile robot 10 but not defined by a pre-existing behavior orroutine. An exemplary method for constructing the preset action sequence behavior using aconsole as illustrated in FIG. 35 includes depressing soft keys 253 either by moving a mouseover the button image on the screen 261 and then depressing a mouse button, or by contactingand applying a force to the area on the screen 261 that corresponds to the button image 253.Once the button is actuated a command is sent to the control system 1155 to include the action orbehavior routine in the preset action sequence behavior. Further methods of input includeactuating buttons or switches of the control system described above, or by any other suitablemethod. Alternatively, a software routine of the preset action sequence behavior can be loadeddirectly into the mobile robot memory 1125, for example via an external memory device insertedinto the mobile robot 10. Furthermore, the preset action sequence behavior can be created byrecording a macro of the actions of the robot while the user is driving the robot and actuatingvarious autonomous behaviors. Additionally, the present action sequence can be created usingany combination of the methods described above.

[00138] Once the preset action sequence behavior is initiated by the operator, theoperator can then input the desired sequence of behaviors, actions, and events in step 3901. Sucha sequence can be any combination of autonomous behaviors, actions, and events available onthe robot, and manual behaviors, actions, and events available on the mobile robot 10. Upon WO 2008/060689 PCT/US2007/068890 58 entering step 3901, a routine included within the preset action sequence behavior routinedetermines if the combination of behaviors, actions, and events chosen by the user is allowed instep 3902. Such a determination is made by evaluating the requirements for each behavior,action, and event and then inputting the determined results against a series of error checkingroutines that evaluate whether the selected combination is allowed per requirement vectors storedin memory. Should a combination not be allowed, the routine included in step 3902 will eitheralert the user of the error and perhaps require them to chose an alternative sequence, or exit thepreset action sequence behavior routine step 3907.

[00139] An example of a combination action sequence that might be precludedwould be the use of Speed Boost in addition to the Stair Climbing behavior. A Boolean valuerepresentative of whether the chosen action sequence is allowed is outputted. Should the valuenot be allowed, then the behavior routine either re-displays the initial action entry screen andperhaps instructs the user to enter a different action sequence step 3901, or exits the preset actionsequence behavior. Alternatively, if a speed value is selected in the Speed Boost behavior that isincompatible with the Stair Climbing behavior, then the behavior routine may re-display theinitial action entry screen and instruct the user to enter a different value for the speed. Otherembodiments may make substitutions for the forbidden actions and proceed with the behavior’ssubsequent steps. In an embodiment of the invention, the screen also relays to the operator theconflicts present in the previous list of chosen actions. Alternatively, the screen may request thatthe operator change only the actions that are not allowed.

[00140] Further referring to FIG. 35, upon identification of an allowed actionsequence, the behavior routine stores the selected sequence step 3903 in memory 1125. Once anallowed sequence is stored, the control system 1155 executes the preset action sequence starting WO 2008/060689 PCT/US2007/068890 59 in order from the first action chosen by the operator in step 3904. The step of initiating an actionstep 3904 is followed by a check to see if operator input is needed for the action to performproperly in step 3905. In an embodiment of the invention, a need for operator input is onlyindicated in absolute cases so that efficiency and autonomy is preserved. In an embodiment ofthe invention, autonomy is enhanced by allowing the mobile robot 10 to determine the value ofoperator input based on prior operator data and environmental data. In other embodiments, themobile robot 10 may refrain from inputting data for operator inputs and should indicate whenoperator input is needed. If the mobile robot 10 determines that operator input is needed, itshould prompt the operator to input the required data and then perform the action in step 3909.Example user input may include any one of a speed value, time duration of an autonomousbehavior, a direction heading, or other value needed to execute any one of the includedbehaviors, actions, or events. Should the initiated action need no further user input, the behaviorroutine will then continue to execute autonomously and perform the action in step 3909.

[00141] Once the action has been performed in step 3909, the mobile robot 10checks to see if there are further actions listed in the sequence step 3906. In the event thatadditional actions remain, the next action in the sequence is initiated and the operator input checkis done before the action is performed. Otherwise, if no additional actions remain, the mobilerobot 10 exits the preset action sequence behavior in step 3907. An embodiment of the inventionallows the mobile robot 10 to enter another behavior or event when no additional actions remain.

[00142] An alternative routine may substitute the portion of the behavior routineassociated with the execution of an action 3910, with a single step of executing the behaviorroutine as recorded. Such a step would not allow the user to input additional data, but wouldrather execute the actions in the order in which they were chosen. WO 2008/060689 PCT/US2007/068890 60

Click-to-Drive and Click-to-Grip [00143] In an embodiment of the invention, the robot includes two “fire andforget” behaviors allowing an operator to chose a destination pixel displayed to the operator viathe above-described control system and either drive toward the destination or move toward thedestination and grip an item. Both of these behaviors are intended for one-time use and allow theoperator to accomplish complex actuation and driving with less intervention. The click-to-gripbehavior also utilizes image data from first and second cameras displayed in respective first andsecond windows 261, 262 to identify a target object for the behavior. The embodiment of FIG.36 illustrates that the robot’s gripper can be manipulated to move toward an object and grip theobject in response to a user clicking on the object within an image of the environment. Toaccomplish gripping, the operator positions the first and second selectors 267, 268 to identify thetarget object 3010 in both the drive camera display 261 and the attack camera display 262. In anembodiment of the invention, the operator has already actuated a button or switch to actuate theclick-to-grip behavior. Alternatively, the operator may additionally actuate a “begin behavior”button or switch, which transmits a control signal to the mobile robot 10 that activates the click-to-grip behavior.

[00144] Once the object is chosen in both displays 261, 262, the position of theobject within those displays is used to calculate its coordinates. FIG. 37 illustrates anembodiment of a click-to-grip routine executed during the click-to-grip behavior. Uponselection of the object by the operator, the routine stores the image coordinates from the attackcamera video display 8103 and the drive camera video display 8106. Using these imagecoordinates and stored values corresponding to the resolution of the attack camera and the drivecamera, the routine calculates the destination point 8109. The coordinates are projected into the WO 2008/060689 PCT/US2007/068890 61 robot’s current environment 8112 and from the projected coordinates, a set of rays are calculated8115 that are representative of travel vectors from the robot’s current position to the destinationposition. The rays are then corrected 8118 and a check is done to ensure that the gripper is onthe correct side of the turret 8121. If the gripper is not on the correct side of the turret, the robotmoves the gripper 8124. Once the gripper is correctly positioned, a check is done to ensure thatthe drive camera is synched up with the object to be gripped 8130. If the camera is not synchedup, then the robot can move the camera 8127 which may include moving the camera to a positionincluded within the newly calculated travel vector. Once the drive camera is synched up with thedestination object, the robot moves the gripper toward the destination point 8133 grips the object8136 after arriving at the destination point.

[00145] Similarly, click-to-drive uses video feed from the attack and drive camerasto determine a destination point. FIG. 38 illustrates an embodiment of a routine included on therobot for implementing click-to-drive. The routine responds to activation of the click-to-drivebehavior and selection of a destination pixel by storing the selected coordinates from the attackand drive camera video displays 8153. Once the coordinates are stored, the routine calculates adestination point 8156 and projects the destination point onto the robot’s current ground plane8159 so that directional rays can be calculated 8162. Once calculated, the rays are corrected8165 and used by the robot to drive toward the destination point 8168. Like click-to-grip, click-to-drive is a fire-and-forget behavior and therefore will terminate once the robot reaches thedestination point. In an embodiment of the invention, the click-to-drive and click-to-gripbehavior include fail safe routines where the behavior will terminate and reset when the robot ispowered down, loses communication with the control system, or is interrupted by a behaviorwith a higher priority. WO 2008/060689 PCT/US2007/068890 62 [00146] The present invention also contemplates an embodiment where the click-to-grip and/or the click-to-drive behavior are operable in two modes: (1) a high degree ofprecision mode and (2) a low degree of precision mode. The high degree of precision modeallows the operator to choose the object’s corresponding pixel image on the display screen andresponds to the actuation of a button triggering a gripping sequence that takes the precise pixellocation and converts it to a destination point. The low degree of precision mode, on the otherhand, allows the operator to choose a heading direction and responds to actuation of buttontriggering a sequence that flies the gripper in the general direction of the objects included withinthe heading. An embodiment of the invention includes a robot with the ability to choose a pathwithin an approved heading that provides the most direct route and avoids obstacles. In bothmodes, the gripper moves using a “fly in motion,” which actuates all joints in a fluid motion.Fly-in motion moves the claw forward in a single fluid motion actuating all necessary joints tokeep the direction of movement uniform. The gripper will stop if it encounters unexpectedobstacles, and will move forward 50% of the estimated distance to reduce the risk of over-travel.An alternative embodiment of the invention moves forward 100% of the estimated distance.After moving 50% of the estimated distance, the operator may reposition the gripper and thentrigger the click-to-grip behavior again. Both modes can also move away from the object usingthe same path that was used to move the gripper forward. Further alternatives include a robotthat: o uses sensors to identify the basic shape of the object and orient the wrist joint ofthe manipulator arm accordingly; o has motors that can fine tune the manipulator arm; o has a pre-programmed manipulator arm motion routine; WO 2008/060689 PCT/US2007/068890 63 o uses analysis of the object’s dimensions to close the gripper’s fingers until theaperture is the required size or until torque sensors in the gripper indicate that the fingers have arequired amount of resistance; o has a gripper that grips the object until the grip routine exits; o has an emergency halt routine that halts the gripper and awaits instructions if anunexpected obstruction is encountered; o uses camera triangulation, camera depth-of-field, and object size estimation toestimate the range to the target; and/or o has a distance sensor to provide distance feedback used by the routine to adjustmovement toward the object to be gripped.

Custom (Preconfigured) Poses [00147] As shown in FIGS. 39 and 40, once a preconfigured pose available via aGUI, soft button, dedicated button, switch, toggle, or other selection device has been selected,the robot must move some or all of the flippers, neck, and head with respect to the robot mainbody and main drive in order to move from the present pose to the preconfigured pose (e.g.,prairie dog P16, stowed P10, driving on a flat surface P14, driving on a bumpy or angled surfaceP20, stair climbing). Some robot configurations may use symmetric flipper arm and body (eachthe same size), providing alternative poses (e.g., inverted Y in which the body and/or head ispositioned directly above a steepled symmetric flipper and body, inverted arrow in which bodyand/or head are positioned above V-oriented symmetric flipper and body - which may furtherrequire inverted pendulum gyroscopic AKA "Segway" balancing). Only a few exemplary posesare shown in FIGS. 39 and 40. Actions by the robot or in which "the robot moves" mean that theactuators of the robot are driven under motor control and amplification as directed by the WO 2008/060689 PCT/US2007/068890 64 controller circuit on the robot itself.

[00148] Changing or returning to a preconfigured pose from any arbitrary posemay require determining the current position and orientation of the robot's body, drive or flipperarms, neck, and/or head. In an embodiment of the invention, the robot's movement is determinedthrough the use of motor encoders (relative or absolute) and the robot's camera (with cameralens) is mounted at a controllable height above the robot's body, as controlled by the movementof the neck. A pan/tilt head with a camera is mounted at the top of the neck. The neck maycontain a physical neck index switch allowing the system to reset the neck location in an absolutesense as the neck's movement passes through a specified location. By using the starting angle ofthe neck and motor encoders, the angular location of the neck at any given time can becalculated. Likewise, the pan and tilt position of the head camera can be calculated using thestart locations. Alternatively, some or any of the flipper arm angle, neck angle, head angle (tilt),and head turn (pan) may use absolute encoders.

[00149] By using the current locations of each of the robot elements (body, flipperarm, neck, head pan & tilt) via motor encoders or other proprioceptive sensing, the staticgeometry of the robot itself (for example, the length of the neck and its arc of travel, the distancefrom the center of rotation to the base of the neck, known x, y, z locations of the center of massof each of the body, flipper arms, neck, head) and on-board orientation sensors in any robotelement (accelerometers, tilt sensors, gyroscopes, and/or horizon detection), it is possible toproduce a frame of reference for each robot element. Each frame of reference is represented by amatrix giving the x, y, z location of the robot element and the rotation vectors for forward, leftand up.

[00150] A similar frame of reference can alternatively be created for each element WO 2008/060689 PCT/US2007/068890 65 in turn using well-known Denavit-Hartenberg Parameter computations, e.g., going from therobot base toward the head and camera location. For example, the frame of reference for theneck can be computed using the body frame of reference, Denavit-Hartenberg Parametersdescribing the neck geometry, and the current neck angle of rotation. Using these three inputs, anew frame of reference can be computed for the neck. Similarly, the pan frame of reference iscalculated, followed by the tilt frame of reference. In an embodiment where the camera isattached to the head, the frame of reference for the head is the frame of reference for the cameraitself.

Such calculations from sensor data, performed on the robot itself, permit the robot's starting stateto be determined, e.g., including the robot's location and vector (frame of reference) and thecamera's location and vector (frame of reference). Embodiments of the invention may notrequire all of the calculations. For a particularly robust robot, merely the element configurationsas expressed by the relative position of the body, flipper arms, neck, and head may be sufficient.

[00151] FIG. 39 illustrates an embodiment of a technique for moving betweenpositions - by mapping necessary states between preconfigured poses and current states,including necessary states P24. This state diagram shows that for some robot configurations, aloop among the states is not necessarily formed, and the path between intervening states may belimited to passing through particular sequences of intervening states. For example, a robot instowed pose P10 (solid lines indicating a preconfigured pose), with head and neck retracted andflippers aligned along the main tracks, may be placed in any of three exemplary preconfiguredposes (prairie dog P16, bumpy travel P20, and flat travel P14).

[00152] In order to move to prairie dog pose P16, in which the robot is stablyelevated on the flipper tracks with the neck elevated to a substantially maximum height, the robot WO 2008/060689 PCT/US2007/068890 66 must begin by lifting the body, by turning the flipper tracks counterclockwise F-CCW (from theside shown in FIG. 39). As the robot moves through intervening poses P12, the center ofmass/gravity of each of the body, neck, and head are maintained above the midpoint of theflipper arms. As shown in FIG. 39, this may be accomplished by specifying predeterminedintervening states and actuations for the robot to pass through (e.g., where "CW" is clockwisefrom the side shown in FIG. 39 and "CCW" is counter clockwise, first arranging the body andhead above the arms by moving the body only via the flippers F-CCW, then by elevating theneck N-CCW and head H-CW, then by unfolding all at once vertically flipper F-CCW, neck N-CCW, and head H-CW).

[00153] To return to the stowed position P10, or as shown in FIG. 39 to move toeither of the driving positions P20 or P14, the robot moves back through the necessary states inthe opposite order and with the opposite CW or CCW motions.

[00154] In order to move to, e.g., bumpy driving pose P20, in which the robot isstably positioned to be driven at slower speeds on the main tracks with the flipper tracks up tohandle small obstacles, the neck and head being positioned behind the main body to provide adriving view but maximum static stability, the robot must begin by turning the flipper tracksclockwise F-CW (from the side shown in FIG. 39). As the robot moves through interveningposes P22, the flipper arms move to a ready-for-driving (or potentially climbing) position. Asshown in FIG. 39, this may be by specifying predetermined intervening states and actuations forthe robot to pass through (e.g., first arranging the flipper by moving only the flippers F-CW, thenby elevating the neck N-CCW and head H-CW).

[00155] In order to move to, e.g., flat driving pose P14, in which the robot is stablypositioned to be driven at higher speeds on the main tracks with the flipper tracks also in contact WO 2008/060689 PCT/US2007/068890 67 with the ground, the neck and head being positioned behind the main body to provide a drivingview but maximum moment about the leading end to resist flipping forward upon sudden stopsor braking, the robot continues from the bumpy driving pose P20 by moving the flippers F-CW,elevating the neck N-CCW and tilting the head H-CW (from the side shown in FIG. 39). Inorder to "return" to any of the previous preconfigured poses, the robot must pass through theintervening preconfigured poses and intermediate poses.

[00156] As discussed, FIG. 39 demonstrates a model in which intervening andintermediate poses are predefined states on a closed, not necessarily looping, state map, in orderto ensure that the robot does not tip over, self collide, or inappropriately lose balance or pose intransitioning from a present pose to a preconfigured pose. This is a methodical, but less flexibleapproach than having the robot actively maintain balance using proprioception , tilt, acceleration,and rotation (gyro) sensors.

[00157] FIG. 40 shows an embodiment in which the robot, although passingthrough similar states, constantly monitors balancing proprioception (position encoders), tilt,acceleration, and/or rotation (gyro) sensors. This system may deal more successfully with unevenground (shown in FIG. 40) than a system using predefined positions. As shown in FIG. 40, arobot on level, tilted, or uneven ground in the stowed position P30 may be moved into, e.g.,prairie dog pose (on uneven ground P32), flat driving pose (on uneven ground P34), and bumpydriving pose P36 by monitoring position encoding, calculating the overall center of gravity of therobot over that portion of the robot in contact with the ground (either the main body, the mainbody and flipper tracks, or just the flipper tracks), maintaining the individual centers of gravityof the body, flipper arms, neck, and head in positions over a stable center of ground contact, andmonitoring and/or controlling acceleration and movement of the elements to obtain relative tilt, WO 2008/060689 PCT/US2007/068890 68 orientation to terrestrial gravity, and/or static and/or dynamic stability. As shown in FIG. 40,because the preconfigured poses are reached by active monitoring and control of balance, therobot need not pass through all preconfigured intermediate pose states, but will pass througharbitrary, yet stable and balanced poses P40, on its way from one pose to another (e.g., frombumpy driving P36 to prairie dog P32 without passing through the stowed configuration P30).As such, the state map P38 will permit direct transition from one preconfigured pose state toanother through a continuously changing, but continuously balanced pose transition, and fromarbitrary current poses P42 directly to preconfigured poses P30 via a continuously changing, butcontinuously balanced pose transition (or a succession of continuously balanced posetransitions). The robot may also seek preconfigured poses by moving only from a presentposition into a confined solution space of next positions that includes only balanced poses.

[00158] In an embodiment of the invention, the robot may display to the user arepresentation of itself within its environment (see FIGS. 11 and 12) based on currentinformation from the robot to the control system. Upon the user selecting a pose, the robotflippers and body move to angle themselves using accelerometers that input a direction of gravityreference. To achieve, for example, a prairie do position, accelerometer input is used by therobot to position its body at about 55° plus or minus about 2° from the horizontal (with respect togravity). The robot tries to position its body at this orientation even on non-level ground. Therobot is kept balanced during pose transitions by monitoring its body position relative to thehorizontal. As can be seen from the illustrated prairie dog position, the neck may be set at about130° relative to the body.

[00159] In an embodiment of the invention, the prairie dog pose may need to bedeactivated to tilt the robot head, but no to pan it. WO 2008/060689 PCT/US2007/068890 69 [00160] In an embodiment of the invention, the robot returns from the prairie dog pose to a driving position quickly, if not gracefully, to facilitate expedient withdrawal or othermovement.

[00161] In an embodiment of the invention, the robot can be controlled to activelyreturn to a preconfigured pose set when disturbed via the continuously balanced pose transition,including a self-righting routine intervening before the robot seeks the last set preconfiguredpose. For example, if the robot is temporarily forced into a different pose, or is tipped over orotherwise disturbed, using tilt sensors, proprioceptive encoders, accelerometers, and/or gyrosensors, it may detect this and initiate seeking of the predetermined pose. In moving to ad frompreselected poses, a embodiment of the invention further includes an inherent collisionavoidance behavior or system that uses a geometric model of the robot in its environment toensure that the robot parts will not collide with each other when moving to and among poses.Autonomous Flipper Behavior [00162] Autonomous flipper behavior allows an operator to operate the robot manually while the flippers are in an autonomous mode. The behavior autonomously identifiessurface conditions and can use this data to trigger the autonomous flipper behaviors. Whenconstantly running in the background, autonomous flipper behavior is considered a persistentbehavior. Possible terrains to identify include: (1) soft terrains which may include snow andsand; (2) hard smooth terrains such as building interiors or roadways; and (3) firm broken terrainsuch as fields or dirt roads. For each terrain, there is a corresponding flipper position that worksbest. For example, flippers rotated into the retracted position work best on soft terrains, andflippers extended upwards works best on hard smooth terrains. Other inputs that could triggerautonomous flipper behavior include the robot being lifted high off the ground by an object WO 2008/060689 PCT/US2007/068890 70 which the robot traversed. In an embodiment of the invention, autonomous flipper behaviordraws upon data flows already present - operator drive commands, accelerometer spectraldensity, and load on the drive motors. More experienced users may disable the automatedbehaviors and manually control the flippers as needed.

[00163] An embodiment of the invention determines terrain type using spectraldensity of the vehicle’s onboard accelerometer readings to identify the amount and type ofvibration the robot is encountering. This data is correlated with other inputs to identifyconditions requiring flipper position modification. For example, high centering shows negligibleaccelerometer vibration and rough terrain shows large jolts. Alternative or addition sensor inputto consider includes video jitter and flow, comparing odometry to an external reference such asGPS, and tracking the fiber optic control line’s feed-out speed. High centering a situation wherethe treads do not make solid contact, resulting from an encounter with an obstacle high enough tolift the robot’s chassis. The ideal configuration for driving over unknown terrain for instance iswith the flippers in front and raised at 30 to 45 degrees relative to the surface.

[00164] In an embodiment of the invention, operation in soft terrain causes theautonomous flipper behavior to maximize the amount of driven surface contacting the ground.To accomplish this, the flippers are lowered in front of the vehicle or tucked along the side of thevehicle. When the flippers are extended, there is a possibility that a flipper will dig into the softground.

[00165] In high center events, an embodiment of the invention directs the vehicleto mobilize the tracks in a swimming motion, continuously rotating the flippers overhand anddriving the tracks only when the flipper is in contact with the surface. When engaged, tracks arepropelled at the same rate that the flipper is expected to pull the vehicle forward. In swimming, WO 2008/060689 PCT/US2007/068890 71 the optimal speed of flipper rotation is based not on the absolute length of the flippers but ontheir effective length (the area in effective contact with the ground), which changes as the surfacedensity changes. By measuring the changes in angle of the vehicle as the flippers rotate, it ispossible to calculate optimal speeds.

Retro Traverse [00166] In an embodiment of the invention, a retro traverse behavior autonomously navigates the mobile robot 10 back along a return path interconnecting variouspreviously traversed coordinates. The retro traverse behavior may be activated by user requestor automatically when trigger conditions are detected by the mobile robot 10, such as when nocontrol signal has been received after a threshold period of time; or may be activated explicitlyby the operator inputting an activation command. If automatically triggered, retro traverse actsas a persistent behavior.

[00167] To perform retro traverse according to an embodiment of the invention,the mobile robot 10 records waypoints at intermittent times when the mobile robot 10 is moving.FIG. 41 illustrates an embodiment of a waypoint routine. At step 2101, the routine receives thevalues for variables min_dist (the minimum distance by which successive waypoints should beseparated), wait_interval (the period of time the routine should wait before recording a nextwaypoint) and pres_coord (the present coordinates of the mobile robot 10, as provided by aposition reckoning system), and step 2102 initializes several variables, setting init_time (theinitial timestamp) and pres_time (the current time of the present execution cycle) to zero, andprev_coord (the coordinates ascertained for the previous execution cycle) and pres_coord (thecurrently ascertained coordinates of the mobile robot 10) to zero, as well.

[00168] It is determined at step 2103 whether the robot is moving and, if not, the WO 2008/060689 PCT/US2007/068890 72 process loops back to step 2103. Otherwise, step 2104 gets the current time (such as from aclock or cycle counter) and stores it to the variable pres_time. It is then determined at step 2105whether sufficient time has passed since the initial time and, if not, the process returns to step2103. If sufficient time has passed, then step 2106 assigns the value of pres_time to the variableinit_time; step 2107 ascertains the present coordinates of the mobile robot 10 and stores them tothe variable pres_coord; and step 2108 calculates the distance between the mobile robot's currentposition and the position of the mobile robot 10 ascertained at the immediately previous cycle.

[00169] If step 2109 determines that not enough distance has been traversed sincethe previous cycle, then the process returns to step 2103. Otherwise, step 2110 appends thevalues of pres_coord (as a positional record) and pres_time (as the corresponding timestamp) tothe list of recorded waypoints; step 2111 sets the value of prev_coord to the same value aspres_coord; and step 2112 updates the variable wait_interval, if necessary or appropriate, beforereturning to step 2103.

[00170] Accordingly, the waypoint routine maintains a list of recorded waypointsseparated by at least minimum permitted differences in time and distance. The retro traversebehavior can then utilize the list of recorded waypoints to generate a return path interconnectingthe waypoints, in reverse order of timestamps.

[00171] FIG. 42 illustrates an embodiment of a method for performing a retrotraverse behavior. At step 2201, it is checked whether the behavior is active and, if so, thebehavior proceeds to step 2202 (otherwise looping back to step 2201). Step 2202 sets the valuesof retro_start and prev_retro_start to zero; step 2203 erases any previously used waypoints; andstep 2204 ascertains the current position of the mobile robot 10 and the current time, which are prepended to the list of recorded waypoints. WO 2008/060689 PCT/US2007/068890 73 [00172] At step 2205 it is determined whether a control signal has been properlyreceived. If so, then step 2212 proceeds to navigate the robot based on the instructions receivedfrom the operator. Otherwise, step 2206 sets the value of prev_retro_start to retro_start, andprev_retro_end to retro_end; step 2207 sets the value of retro_start_time to the current time; andstep 2208 navigates the mobile robot 10 toward the next previous waypoint retrieved from thelist of recorded waypoints for one execution cycle. If step 2209 determines that communicationhas not been restored, the behavior returns to step 2208 and continues navigating toward thewaypoint; otherwise, step 2210 sets retro_end_time to the current time and step 2211 inserts anew entry (comprising the values of retro_start_time and retro_end_time) into a list of retrotraverse intervals before proceeding to step 2212.

[00173] By maintaining a list of previously-performed retro traverses (for example,by recording a list of start/end time pairs for each period of time the retro traverse behavior isactivated and deactivated), the retro traverse behavior can ignore any waypoints that are recordedduring retro traverse operation, as these are spurious for future retro traverse purposes. That is,after the mobile robot 10 has finished a retro traverse, it records the range of timestamps on thepoints it retraced and that it created on its path back. On its next retro traverse, it may ignorethose points.

[00174] An embodiment of remote control operation of the mobile robot 10 in an urban combat zone is shown in FIG. 43. An operator 5 is positioned within a sandbag-enclosedbunker 9012 adjacent a roadway. The mobile robot 10 proceeds out from the bunker 9012, undercontrol of the navigation commands transmitted, preferably wirelessly, by the operator. Asshown by the curved dotted line, the mobile robot 10 then traverses a path between variousbuildings 9011. WO 2008/060689 PCT/US2007/068890 74 [00175] At various times during navigation of the mobile robot 10, waypoints Athrough J are recorded. Each recorded waypoint includes information regarding the position ofthe mobile robot and a timestamp indicating when the position was sampled. The waypointsmay be recorded in the electronic memory of the mobile robot 10 in a suitable data structure(e.g., as a doubly-linked, indexed list, sorted chronologically by timestamp) to permit forwardand reverse list traversal as well as indexed access to the waypoints, for example.

[00176] As the mobile robot 10 proceeds further away from the operator, or whenan obstacle such as the buildings 9011 sufficiently impede wireless communication, the mobilerobot 10 may fail to receive the control signal transmitted by the operator. Therefore, as anexample of a persistent autonomous behavior, the retro traverse behavior may be activated by therobot 10 when it determines that communication is lost.

[00177] Another embodiment of a retro traverse behavior is illustrated in FIG.44A, in which the robot traverses either forward or backward along a single line 2300. First themobile robot 10 proceeds out along the line 2300 during a first outbound leg 2301. In this case,the waypoint routine records waypoints A and C at positions x = 3 and 7. When the mobilerobot 10 starts retro traversing, it uses these waypoints because no previous retro traverse has yetbeen performed.

[00178] In the embodiment of FIG. 44A, the first outward leg 2301 stops just aftert = 8 (at which time the mobile robot 10 may have lost radio contact with the operator orreceived instructions to stop, inter alia). The first retro traverse leg 2302 then begins at t = 8.1and continues until t = 12, at which time the mobile robot 10 stops retro traversing and resumesoutbound traversal along the second outbound leg 2303 (e.g., after regaining communicationswith the operator). During the first retro traverse leg 2302, the mobile robot 10 again travels WO 2008/060689 PCT/US2007/068890 75 over points B and A, but does not proceed all the way back to t = 0. Also during the first retrotraverse leg 2302, the waypoint routine generated waypoints at t = 9 and t = 11.

[00179] So the retro traverse interval t = 8.1 to 12, representing the start time (t =8.1) and end time (t = 12) of the retro traverse leg 2302 is added to the list of retro traverseintervals, and any waypoints having a timestamp within this range (in this case, the waypoints att = 9, 11) are excluded on any subsequent retro traverse.

[00180] FIG. 44B illustrates an embodiment of the invention that continues fromthe example shown in FIG. 44A. The mobile robot 10 proceeds along the second outbound leg 2303 until t = 18, when retro traverse is activated again. When this second retro traverse leg 2304 starts, the retro traverse behavior retrieves the list of waypoints having timestamps t = 17,11,9,7,3,0.

[00181] From the list of waypoints, the behavior removes from consideration all recorded waypoints having a timestamp within the interval t = 8.1 to 12, resulting in a pruned listt = 17 (corresponding to C), t = 7 (corresponding to B), t = 3 (corresponding to A) and t = 0 (animplicit, unnamed timestamp corresponding to the beginning of the robot's movement). Thispruned list corresponds to the desired straight path back to the beginning of the journey.Following the second retro traverse leg 2304 ending at t = 26, a second retro traverse interval t =18 to 26 is appended to the list of recorded retro traverse intervals (resulting in a list of intervalscomprising the two entries [8.1, 12] and [18, 26]) and the third outbound leg 2305 then starts(resulting in a third waypoint D recorded at t = 36).

[00182] If a third retro traverse leg (not shown) were to start, it would accordingly ignore all waypoints with timestamps within the intervals 8.1 to 12 and 18 to 26.

[00183] To ensure smooth navigation and avoid abrupt veering or swerving in the WO 2008/060689 PCT/US2007/068890 76 vicinity of corner points along an intended path of travel, the mobile robot 10 may base itsnavigation on a lookahead vector. A lookahead vector can be defined in the following way: astarting point lies at the closest point on the path to the mobile robot 10, and an ending point is apoint farther along the path that is either at a maximum distance away, or at a shorter distance asdetermined by the curvature of the path and/or other factors. For example, the mobile robot 10may continuously drive toward a virtual point approximately 1 meter in front of it along theintended path. In some implementations, the distance that the mobile robot 10 looks ahead maybe variable, depending upon the geometry of the lookahead vector.

[00184] In addition, rather than always manipulating the x-y coordinates of points directly, navigation of the mobile robot 10 may utilize a line-segment abstraction of the intendedpath. First, when retro traversing, the return path can be represented as a set of piecewisecontinuous, conjoining line segments rather than a set of points. The mobile robot 10 mayperform most of its calculations in terms of the tangent and perpendicular to the line segment themobile robot 10 is traversing instead of based on the vector difference to the next waypoint.Accordingly, the mobile robot 10 may reduce or eliminate sharp turning when it approacheswaypoints conjoining two path line segments at acute angles.

[00185] Secondly, once the robot has pre-computed the tangents and lengths of the line segments, a point can be expressed as a distance along the path. For example, letting λrepresent the tangent unit vector to the ith line segment, then a point r with path length I has aposition n

<img img-format="tif" img-content="drawing" file="IL198104AD00021.tif" id="idf0001" />

WO 2008/060689 PCT/US2007/068890 77

where ai represents the length of the zth segment for i = 0 to n-1 and a»~ I η— 1

<img img-format="tif" img-content="drawing" file="IL198104AD00022.tif" id="idf0002" />

i = 0 [00186] Further, the retro traverse behavior may implement a predetermined cycle of calculations to follow a return path: • Determine on which line segment the robot is currently traversing; • Calculate the end of the lookahead vector; and • Calculate motion commands.

The calculations may be done in the listed order during a cycle of the behavior systembecause the mobile robot 10 moves after all of the calculations have been completed.

[00187] The retro traverse behavior may use a radius of interception to determine whether the mobile robot 10 has reached a waypoint, or a perpendicular plane to determine whenthe mobile robot 10 has passed a waypoint. Preferably, however, the mobile robot 10 keepstrack of which line segment of the return path it is traversing. Since the lookahead vector keepstrack of the local area that the robot’s motion is based on, the only line segments of the retrotraverse path that the robot needs to consider are those spanned by the lookahead vector. Theretro traverse behavior then determines the closest of these line segments and sets that as itsreference.

[00188] FIG. 45A illustrates an embodiment of the invention where the lookaheadvector 2410 extends from the mobile robot 10 along a linear return path including a first linesegment 2401 and second line segment 2402 interconnecting waypoints A, B and C. The mobilerobot 10 computes its distance to all the line segments between the beginning and the end of thelookahead vector 2410. The line segment closest to the mobile robot 10 is the one it associateswith. In the embodiment of FIG. 45A, the robot associates to the first line segment 2401 via theperpendicular line 2411. WO 2008/060689 PCT/US2007/068890 78 [00189] In an embodiment illustrated in FIG. 45B, third and fourth line segments2403, 2404 interconnecting waypoints D, E and F, form an angle with waypoint E as the corner.Here, on the previous iteration, the mobile robot 10 determined it was closest to the third linesegment 2403, and thus the lookahead vector 2410 starts there for the present cycle. Howeverthis time it finds that it is closest to the fourth line segment 2404, meaning it has passed waypointE.

[00190] FIG. 45C illustrates a situation similar to the arrangement of FIG. 45B;however, in FIG. 45C, the lookahead vector—which is rooted in the fifth line segment 2405—does not extend all the way out to the closest point on the sixth line segment 2406. In this case,the mobile robot 10 should not associate with the sixth line segment 2406 because then themobile robot 10 would short cut the desired path. Accordingly, the lookahead vector preferablygets shortened in order to avoid taking short cuts that bypass waypoints. To achieve proper pathswithout shortcutting, the retro traverse behavior does not accept any line segments for which theclosest point to the mobile robot 10 is beyond the end of the lookahead vector.

[00191] In the embodiment of FIG. 45C, the mobile robot 10 stays on the fifth linesegment 2405 despite it being farther away than the sixth line segment 2406. Once the mobilerobot 10 has determined which line segment it is on, it calculates the closest point to the mobilerobot 10 on that line segment. This point is then used as the origin of the lookahead vector forthe subsequent iteration.

[00192] After determining the beginning of the lookahead vector, the retro traverse behavior next determines where the end of the lookahead vector is. Referring to an embodimentof the invention illustrated FIGS. 46A through 46D, the lookahead vector 2510 may have alength established by default to a predetermined value (e.g., one meter long). However, the retro WO 2008/060689 PCT/US2007/068890 79 traverse behavior may be implemented so as to ensure that the mobile robot 10 drives at leastwithin a maximum permitted distance of each waypoint. If the lookahead vector 2510 were toalways stay at its full default length, the mobile robot 10 might traverse a route with all thecurves excessively smoothed out in some circumstances.

[00193] In view of this, the embodiment of FIGS. 46A through 46D demonstrate asystem for determining when and how to shorten the lookahead vector 2510 to keep the mobilerobot 10 aligned with the intended path. FIG. 46A shows a straight-line path comprising firstand second line segments 2501, 2502. In this case, the path of mobile robot 10 passes wellwithin the permitted distance from waypoint A and accordingly, the lookahead vector 2510 mayremain at its full default length.

[00194] In FIG. 46B, the mobile robot 10 has moved farther along the path to asection where it angles slightly at waypoint E between the third line segment 2503 and fourthline segment 2504. Because the mobile robot 10 will attempt to drive toward the end of thelookahead vector 2510, the appropriate approximation of the mobile robot's path is the vectorextending from the mobile robot 10 to the end of the lookahead vector 2510.

[00195] To ascertain whether the mobile robot’s route will lie within the permitteddistance from a waypoint, the retro traverse behavior checks whether the perpendicular distancefrom a waypoint to is less than the maximum permitted distance (which may be a predetermined,constant value—such as one meter, for example). The mobile robot 10 repeats this check forevery waypoint disposed orthogonally to the lookahead vector (i.e., waypoints for which thereexists an orthogonal projection onto the lookahead vector). Alternatively, the mobile robot 10may repeat the distance check for every waypoint that is associated with any of the retro traversalpath line segments intersected by the lookahead vector 2510, to simplify the calculation of WO 2008/060689 PCT/US2007/068890 80 whether a waypoint “lies along” the lookahead vector 2510. In the example shown in FIG. 46B,the distance is within the permitted range; therefore, the lookahead vector 2510 extends to its fulllength.

[00196] FIG. 46C shows a similar situation; however, the full-length lookaheadvector 2510 does not lead to a path that is within the permitted distance of one of the waypoints(waypoint I) that projects orthogonally onto the lookahead vector 2510. The mobile robot 10therefore sets the end of the lookahead vector 2510 (which will be used in the subsequent cycle)to be the mean of the current end point and the end point of the previous lookahead vector 2511used in the preceding cycle of the behavior. The retro traverse behavior running on the mobilerobot 10 will continue to decrement the length of the lookahead vector 2510 for several iterationsin a similar manner until it either finds an acceptable end point or performs a maximum thresholdnumber of iterations without success. Because the end point of the lookahead vector 2510should always be on a line segment in the intended path, the mean of the old and new end pointsare preferably calculated in terms of the respective path lengths of the two and then transformedinto x-y coordinates, rather than averaging the x-y coordinates of the two points.

[00197] FIG. 46D illustrates a situation with a sharp angle between the seventh andeighth line segments 2507, 2508. The waypoint K does not project orthogonally onto thelookahead vector 2510 shown in FIG. 46D. Accordingly, the retro traverse behavior preferablyensures that the closest point is actually within, to obviate this situation.

[00198] FIG. 47 illustrates an embodiment of a relationship between two outputvalues, v_rotate and v_translate, that may be issued by the retro traverse behavior. Thetranslational (v_translate) and rotational speeds (v_rotate) are calculated based on the angle bywhich the mobile robot 10 needs to turn to be heading toward at the end of the lookahead vector. WO 2008/060689 PCT/US2007/068890 81

The rotational speed may be determined as a PID loop on the function v_rotate shown in FIG. 47, for example. The function characteristics may be adjusted to ensure the mobile robot 10 doesnot overshoot waypoints.

[00199] Also, in another embodiment, there are three different modes in which themobile robot 10 can operate: “always drive forward;” “always drive backward;” or “drive in which ever direction requires the least rotation.” [00200] For “always drive forward,” the speeds are calculated based on the anglebetween the mobile robot’s heading and the direction to the end of the lookahead vector. For“always drive backward,” they are based on 02, and the translational speed is multiplied by -1.For “driving the direction of least rotation,” when Θ in between θι and θ2 then the mobile robot10 drives forward; otherwise, it drives backwards.

[00201] Retro traverse can be implemented in the following exemplary manners: • the robot will either track odometry and determine position based on that; • will maintain a global map and place the coordinates within a global map; • will maintain a far off destination point within a global map and adjust its headingto move towards that point; • will use some sort of navigation point (i.e. GPS, or other satellite or landmarkeasily detected from most points within the environment); or • will communicate with navigation beacon points (signal repeaters, etc.) and usethose to determine position within the environment.

[00202] Alternative methods of implementing retro traverse include: (1) following WO 2008/060689 PCT/US2007/068890 82 a reduction in chemical scent, or following a chemical scent; or (2) following a trail left by therobot - i.e. a fiber optic cable, a line of spray paint, setting a destination point in a global mapand traveling towards that destination point.

[00203] Two alternative methods of implementing retro traverse include: • Collecting odometric data and using it to calculate the return path; 1. Example Data - heading and approximate distance of travel foreach stage of retro traverse. • GPS waypoint collection 1. GPS approximations can be collected. 2. Tie these approximations to the odometry data. 3. Use Kalman Filter based algorithms to provide confidence in thereturn path.

Self-Righting [00204] Self-righting behaviors can also be persistent, in a sense that it mayconstantly be running in the background to right the robot if it is up-ended. Robots travelingover very rough terrain or through opposing fire can end up flipped on their sides or even upsidedown. Self righting behavior allows the remote vehicle to turn itself back over and onto itstracks so it can continue with its mission objective or return back to the operator, as desired.When self righting, the robot senses its orientation and determines a strategy for turning itselfupright. The robot will perform a progression of increasingly complex arm and flipper motionsuntil it has levered itself back onto its tracks.

[00205] Self righting has two modes. In the first mode, it will be autonomouslyinitiated when the robot detects that it has flipped upside down. In the second mode, the operator WO 2008/060689 PCT/US2007/068890 83 explicitly commands the robot to start or stop self righting. The advantage of enabling persisentautonomous self righting is that should communications be degraded because the antennae arebeneath the unit to the point where the operator cannot directly command it, the robot can rescueitself without explicit direction, and without the need for hands-on human intervention.

Semi-Ballistic Behaviors [00206] Semi-ballistic behaviors allow the operator to manually operate the remotevehicle. Semi-ballistic behaviors can quit when certain actuators are actuated such as stop aspeed boost behavior when the operator actuates a stop button or switch, the drive control, or aquick brake.

Speed Boost and Quick Brake [00207] In an embodiment of the invention, activating speed boost or quick brakebehavior allows the operator to quickly increase or decrease the current drive speed of the mobilerobot 10. Once activated, the mobile robot 10 will continue to drive with the new drive speeduntil a new behavior, action, or event occurs. An example of this is the execution of the speedboost behavior while the mobile robot 10 is driving forward at a current drive speed. Uponexecution, the mobile robot 10 then drives forward at a speed equivalent to the current drivespeed increased by a preset speed value stored in memory.

[00208] FIGS. 48 and 49 illustrate an embodiment of speed boost and quick brakebehaviors. These behaviors are initiated by activating a switch or button of the control systemdescribed above. Activating the button or switch multiple times in a row will result in multipleand successive executions of the chosen behavior. The end result is a new drive speedequivalent to the current drive speed increased or decreased by a factor of the preset speed valuemultiplied by the number of times the button or switch was activated. WO 2008/060689 PCT/US2007/068890 84 [00209] The speed boost behavior stores the current drive speed 8001 and thecurrent drive heading 8002. The behavior then calculates a new drive speed value by increasingthe current drive speed value by a factor equivalent to a preset speed value 8004 stored inmemory 1125. A speed check 8006 is done to ensure that the new drive speed is compatiblewith behaviors or routines that may be active on the mobile robot 10. If the speed check 8006allows for the new drive speed, the mobile robot 10 drives forward at the new drive speed 8010and the speed boost behavior ends 8012. Otherwise, if the speed check 8006 does not allow forthe new drive speed, then the mobile robot 10 drives forward at the current drive speed 8008 andthe speed boost behavior ends 8012.

[00210] The quick brake behavior embodiment shown in FIG. 49 is similar to thespeed boost behavior embodiment in that it stores the current drive speed 8014 and the currentdrive heading 8016 and performs a speed check 8020 once the new drive speed is calculated.The quick brake behavior differs in that the new drive speed is calculated by decreasing thecurrent drive speed by a factor equivalent to the preset speed value 8020. Like the speed boostbehavior, if the new drive speed is allowed, then the mobile robot 10 drives forward at the newdrive speed 8024 and the quick brake behavior ends 8026. Alternatively, if the new drive speedis not allowed, then the mobile robot 10 drives forward at the current drive speed 8020 and thequick brake behavior ends 8026.

[00211] Alternate embodiments of speed boost and quick brake may include: • A speed boost behavior that sets a zone of acceptable speeds that is greater thanthe normal zone (e.g., typically the robot can drive at a speed between 2 and 20 MPH, but withspeed boost it can drive between 15 and 50 MPH); • A speed boost behavior that provides a quick boost of speed for a period of time - WO 2008/060689 PCT/US2007/068890 85 then returns to the previous drive speed; • A quick brake that lowers the zone of acceptable speeds (e.g., zone is now 0 to 5MPH from 2 to 20 MPH); and/or • A quick brake that for a period of time quickly reduces the speed of the robot,then returns to the previous drive speed after the period of time.

Cruise Control [00212] A cruise control behavior receives information from the control systemregarding an intended constant speed and heading for the mobile robot 10. In an embodiment ofthe invention, the information sent from the control system includes an acceleration value and arotational velocity, both of which are used by the mobile robot 10 to determine a drive velocityand heading. The cruise control behavior allows the operator to drive the robot 10 for a distancewithout necessary intervention by the operator. In an embodiment of the invention, the operatoruses a left and right joystick or puck of the control system to control the robot’s movement. Inthis embodiment, the left joystick or puck can be dedicated to the cruise control behavior suchthat when the left joystick or puck is actuated, the cruise control behavior commences, and whenthe right joystick or puck is actuated, the cruise control behavior halts. Alternatively, the cruisecontrol behavior could commence following the actuation of a button or other actuator of thecontrol system. Alternatively, a third joystick or puck may be included in the control system thatis dedicated to cruise control.

[00213] In an embodiment of the invention utilizing pucks, each puck has the ability to rotate about a vertical axis, translate forward and backward about a horizontal axis, andtilt away from the vertical axis. Furthermore, when the puck is translated, rotated or tilted, it isthe movements correspond to different movements of the robot. In particular, driving the robot WO 2008/060689 PCT/US2007/068890 86 in a forward or backward direction is preferably controlled by the translation of the puck about ahorizontal axis, alteration of the robot’s heading is controlled by the rotation of the puck about avertical axis, and actuation of the flippers included on the robot are controlled by tilting thepucks. An example of the movement of a robot in response to puck movement is one in whichthe puck is rotated about the vertical axis 30° in a clockwise direction, and the puck is movedforward a distance of a half inch. In response, a robot at rest will adjust its heading by turning30° in a clockwise direction, and driving forward at a velocity equivalent to a pre-determinedvalue associated with movement of the puck a half inch. Should the puck be tilted to the right15° from the normal, the robot’s flippers would respond by rotating towards the ground an angleequivalent to 15°.

[00214] FIG. 50 illustrates an embodiment of a cruise control routine 3200included within a cruise control behavior. When in control of its corresponding actuators, thecruise control behavior executes the cruise control routine 3200, which commences by scanningfor a new set of cruise commands 3212 from the operator. Should the routine sense a new set ofcruise commands, the routine inputs the commands as an absolute heading 3215. There may be atime lag between when the robot’s cameras record video information and the time that suchinformation is displayed to the operator. If the robot 10 is moving at a particular speed andparticular heading, and a new heading and/or speed is chosen by the operator and sent to therobot, the robot will have moved a certain distance during the time between when the robot’scamera detected the image and when image was displayed to the operator. The latency of thesystem can cause discrepancies when sending the robot cruise commands.

[00215] In an embodiment of the invention, to eliminate the possibility of thesediscrepancies, the operator sends the robot 10 an absolute heading and velocity. When the robot WO 2008/060689 PCT/US2007/068890 87 10 receives the absolute heading and velocity, the robot then calculates its new heading andvelocity using the absolute heading and velocity and the positional and velocity values at thetime the robot’s camera detected the image, rather than the current real-time positional andvelocity values. Upon calculating the new travel velocity and heading, the robot 10 uses real-time positional and velocity values to calculate a new travel vector 3218.

[00216] Once a travel vector is calculated 3218, the robot will then drive at thespecified velocity using the specified heading 3201. While driving, the cruise routine gathersreal-time positional and velocity values from the sensors 3203 and compares these values to thechosen travel vector 3206. Should there be a significant difference between the current travelvector and the chosen travel vector, the routine will instruct the robot 10 to adjust its heading andvelocity 3221 using past odometry values. Otherwise, if there is little difference between thecurrent travel vector and the chosen travel vector, the routine will instruct the robot 10 tocontinue driving 3201.

[00217] Further illustrative of an embodiment of cruise control, FIGS. 51A and5IB display a robot 3444 that responds to new heading commands to change direction. Therobot 3444 moves forward in a particular direction 3440. Once the operator retrieves videofeedback of the robot’s position, the robot’s position has changed from its position at the time thevideo information was captured 3446 to its current position 3444. Thus, the robot has continuedalong its current path 3440 during the time between when the robot collects video information ofits position at that time 3446 and the time when the robot receives new heading commands fromthe operator. When the operator sends the heading information to the robot 10, the headinginformation 3442 is relative to the robot’s previous position 3446. FIG. 5IB shows how therobot uses the heading 3442 generated in relation to the robot’s previous position 3446 to WO 2008/060689 PCT/US2007/068890 88 determine a new heading 3452 calculated in relation to the robot’s current position 3444.

[00218] FIG. 52 illustrates an embodiment of a flow of information in the cruisecontrol behavior. Input from the control system is received and processed to produce an updatedcurrent intended heading and speed 0n, U . In the equations displayed, θη_ι is the intendedheading of the preceding cycle, is the time of the current cycle, tn~1 is the time of thepreceding cycle, Θ (- tn~1) is the angular difference between the heading of the current cycleand the heading of the preceding cycle, v«-1 is the intended speed of the preceding cycle, and( vn - v»-i ) is the difference between the speed of the current cycle and the speed of thepreceding cycle.

[00219] Simultaneously, input from position reckoning systems (such as acompass, IMU, or GPS) are fed to a motion tracking system, which updates the reckoned actualheading and speed. The reckoned actual heading and speed of the mobile robot 10, as well as theupdated intended heading and speed, are passed to a comparator, which generates an appropriateoutput (such as turn rate and drive motor current) to control the drive system.

[00220] Activation of the cruise control behavior includes first actuating anactuator of the control system. As discussed above, the actuator may be a puck, button, lever,soft button, or any other actuator that initiates the cruise control behavior. FIG. 53 illustrates anembodiment of a routine carried out by the control system (using a puck for cruise controlactivation) to generate cruise control commands. The routine scans a puck designated foractivating and controlling the cruise control behavior 3251. Upon detecting a change in theposition of the puck 3253, the routine determines whether the change included a rotation of thepuck about a vertical axis 3256. If not, the routine will continue to scan the puck’s position. Ifthe change included a rotation of the puck about a vertical axis 3256, the routine calculates a WO 2008/060689 PCT/US2007/068890 89 rotational velocity proportional to the rotation of the puck and indicative of the direction thepuck was rotated 3259, and the control system sends the new drive heading to the robot 10,where the heading is relayed to the cruise control behavior.

[00221] The routine then determines whether or not the puck was translated abouta horizontal axis 3265. If this has occurred, the routine calculates an acceleration/decelerationcommand 3268 representative of the puck’s movement, and the control system sends theacceleration/deceleration command 3271 to the robot 10 where the acceleration/decelerationcommand is relayed to the cruise control behavior. In the illustrated embodiment, if the routinedetects a tilting of the puck 3274, the routine exits 3277 because such a movement of the puckindicates flipper movement which is controlled by a behavior other than the cruise control -activation of another behavior causes cruise control to halt. If the routine does not detect a tiltingof the puck 3274, the routine continues to scan the puck’s position 3251.

[00222] FIG. 54 illustrates an embodiment of the interaction between the cruisecontrol behavior and other behaviors installed on the robot’s single board computer. When thecruise control behavior has control of the robot’s actuators, it executes its cruise routine 3301.However, when the coordinator indicates that another behavior has been activated 3303 and thatbehavior has a higher priority 3306 than the cruise control behavior, the cruise control behavioris halted and the cruise routine exited 3318. Otherwise, if the coordinator does not indicate thatanother behavior has been activated 3303, or if a behavior has been activated but that behaviordoes not have a priority 3306 greater than the cruise control behavior, the cruise control routinewill continue to execute 3301. In an embodiment of the invention, when a behavior with ahigher priority than cruise control is activated, the coordinator checks whether this behavior isthe obstacle avoidance behavior 3309, and if true, allows the obstacle avoidance behavior to have WO 2008/060689 PCT/US2007/068890 90 control of the actuators without halting the cruise control behavior. Otherwise, if the obstacleavoidance behavior is not identified and the behavior has a higher priority than the cruise controlbehavior, the cruise control behavior will exit the cruise routine and halt 3318.

[00223] Should the obstacle avoidance behavior gain control of the actuators, anobstacle avoidable routine is executed 3312 by the obstacle avoidance behavior. Once theobstacle avoidance behavior is executed and exited, cruise control may regain control of theactuators 3321. Once in control of the actuators, the cruise control will pick up where it left offand begin executing the cruise control routine 3301. Within the cruise routine 3200 (see FIG.50), a check is made of the robot’s real-time travel vector 3203. Since the obstacle avoidanceroutine caused the robot to veer away from the chosen travel vector, the cruise control routinewill detect the change in travel vector and correct the robot’s heading and velocity 3221 usingpast odometry values so that the robot returns to the chosen travel vector.

[00224] An embodiment of the interaction between the cruise control behavior andthe obstacle avoidance behavior is illustrated in FIGS. 55A - 55D. Obstacle avoidance can be apersistent behavior, but is discussed here based on its interactions with cruise control. FIG. 55Ashows the robot’s 3458 movement along the chosen travel vector 3456 dictated by the cruisecontrol behavior, where the vector 3456 points the robot toward an obstacle 3454. FIG. 55Billustrates the robot’s response to the obstacle 3454 by commanding the robot to drive to aposition 3460 not included within the chosen travel vector, which is the result of an avoidancetravel vector 3462 instituted by the obstacle avoidance behavior to cause the robot 10 to avoidthe obstacle 3454.

[00225] Once the obstacle 3454 is avoided, the cruise control behavior re-assumescontrol of the actuators and, as shown in FIG. 55C, begins to adjust the robot’s direction of travel WO 2008/060689 PCT/US2007/068890 91 so that the robot returns to a path included within the chosen travel vector 3456. To do this, thecruise control behavior alters the robot’s heading so that the robot drives along a path includedwithin a translational vector 3462 calculated to cause the robot 3460 to return to the chosentravel vector 3456. FIG. 55D displays the final effect of the translational vector 3462. Therobot 3458 moves from a path included within the avoidance travel vector 3462 to a path withinthe chosen travel vector 3456.

[00226] The obstacle avoidance behavior can include an embodiment of anobstacle avoidance routine as illustrated in FIG. 56. Once an obstacle is detected 3520 and theobstacle avoidance behavior has retained control of the actuators, the obstacle avoidance routinebegins to execute. The routine first inputs camera video output of the obstacle detected 3522 anduses the camera’s resolution to determine the dimensions of the obstacle. To ensure properclearance, the routine bloats the obstacle by a pre-determined value so that an avoidance vectorcan be calculated 3518. The avoidance vector allows the robot 10 to drive along a path thatavoids the obstacle 3528. As the robot 10 drives forward 3528, the routine continually checksfor obstacles 3530. If an obstacle is detected, the robot 10 then inputs the video image of theobstacle 3522, determines its dimensions 3524, bloats the obstacle 3526 and calculates a newavoidance vector 3518. These steps occur until no obstacle is detected, at which point theobstacle avoidance routine is exited 3532 and the cruise control behavior regains control of theactuators.

[00227] In an embodiment of the invention, the cruise control behavior assumesthat the robot is moving at a velocity of 0 m/s, and considers the robot’s position to be the normalposition. Subsequent rotational velocities and accelerations/decelerations are an alteration of therobot’s 0 m/s velocity and normal position. Alternatively, the cruise control behavior could WO 2008/060689 PCT/US2007/068890 92 include cruise routines that allow for acceleration and/or deceleration of a robot with a velocityother than 0 m/s. In such an embodiment, an additional actuator may be included in the controlsystem so that the user can control activation of cruise control with an actuator separate from thepuck.

[00228] Other possible features of the cruise control behavior include fail safeconditions that cause the cruise control behavior to halt. These conditions include: (1) actuatingbrakes included within the drive system; (2) actuating a button, switch, puck, or other inputdevice not designated to control the cruise control behavior; (3) depressing a stop actuatorincluded of the control system; (4) changing the drive mode; or (5) dropping communicationbetween the control system and the robot 10. Additionally, there is a maximum speed at whichthe robot can go and the robot is configured not to drive at a speed higher than the maximumspeed.

[00229] Alternative embodiments of the implementation include: • Setting a point far in the distance and driving toward that point so thatwhen a behavior like obstacle detection interrupts, the cruise control behavior can do one ofcalculating a path from the robot’s current position back to the original cruise path andcalculating a new path from the robot’s current position to the destination point o Tracking odometry and adjusting the robot’s current path using a translationalvector calculated from the odometry values so that when obstacle detect interrupts, the cruisecontrol behavior calculates a translational vector from the past odometry values and applies thevector to the robot’s current path - so that the robot will return to the cruise path. • Set a start waypoint and end waypoint when a behavior like odometryinterrupts cruise, meaning that two waypoints are stored while the robot is still on the cruise WO 2008/060689 PCT/US2007/068890 93 control path and at the point in time when obstacle detection is initiated, the first waypoint beingrepresentative of the robot’s position when obstacle detect interrupts an the second waypointbeing representative of a point much farther down the path from the first waypoint (far enoughthat the point will exist at a position beyond the obstacle). After obstacle detection finishes, thecruise control behavior uses the two waypoints to calculate a path back to the original cruisecontrol path.

[00230] In an embodiment of the invention, the cruise control behavior sends an “operator attention required” alert to the operator. Alert conditions may include: • Hard bump to the manipulator arm, indicating contact with a solid object. • Repeated drifting off course, indicating uneven ground. • Tilt or roll approaching tip-over limits. • Increased motor torque indicating the presence of an obstruction. • Time-out situations to prevent over-travel.

[00231] Other embodiments of the cruise control behavior include a cruise behavior that can be used while drive is in control, the user actuating a cruise control button ofthe control system. The cruise control behavior can also be activated such that the robot willcruise for a predetermined period of time, or a predetermined distance. Alternatively, the cruisecontrol behavior could include a hybrid where such an action would happen unless the userinstructs the normal cruise to take over indefinitely.

Obstacle Avoidance [00232] An embodiment of an obstacle avoidance behavior is described above.

Ways of implementing the obstacle avoidance behavior include: o Path Planning - the robot detects obstacles &amp;amp; bloats them, then calculates a patharound the obstacle. Path planning may be carried out while the robot is traversing the path to WO 2008/060689 PCT/US2007/068890 94 ensure that the robot remains on the path. o Continuous obstacle detection where there are obstacle detection sensors installedalong the sides of the robot. The robot turns a predetermined angle and moves a predetermineddistance in response to a forward obstacle detection. Once the forward sensor no longer detectsthe obstacle and if the side sensors detect the obstacle, obstacle detect moves forward until theside sensors no longer detect the obstacle.