Mutual detection of obstacle states for mobile robots

Abstract

The method includes the steps of: moving, in a mobile robot, along a current path; using sensors of the mobile robot; capturing sensor data representative of the vicinity of the mobile robot; detecting an obstacle obstructing the current path based on the sensor data; outputting a state change request corresponding to the obstacle in response to detecting the obstacle; receiving data at the mobile robot in response to the state change request defining an updated state of the obstacle; selecting a navigation action between (i) continuing to move along the current path and (ii) generating a new path that bypasses the obstacle based on the updated state data; and executing the selected navigation action.

Description

[Background technology]

[0001] Autonomous or semi-autonomous mobile robots may be deployed within facilities such as warehouses, manufacturing facilities, medical facilities, etc., to, for example, transport items within the facility. While navigating within the facility, the mobile robot may detect obstacles in its path. Replanning its path to avoid the obstacle, for example, by passing through a different part of the facility, can be computationally expensive and time consuming. Summary of the Invention

[0002] The accompanying drawings, together with the following detailed description, which are incorporated in and form a part of this specification, serve to further explain embodiments of the concepts comprising the claimed invention(s) and to explain various principles and advantages of those embodiments, in which like reference numbers indicate identical or functionally similar elements throughout the different views. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a schematic diagram of a mobile robot for transporting goods deployed within a facility.

[0004] [Figure 2] FIG. 2 is a schematic diagram of certain components of the mobile robot of FIG.

[0005] [Figure 3] FIG. 3 is a flow chart illustrating a method for interactive fault condition detection.

[0006] [Figure 4] FIG. 4 is a schematic diagram illustrating an exemplary implementation of blocks 305, 310 of the method of FIG.

[0007] [Figure 5] FIG. 5 is a schematic diagram illustrating an exemplary implementation of block 315 of the method of FIG.

[0008] [Figure 6] FIG. 6 illustrates an exemplary implementation of block 345 of the method of FIG.

[0009] [Figure 7] FIG. 7 illustrates another exemplary implementation of blocks 305-315 of the method of FIG.

[0010] [Figure 8] FIG. 8 illustrates yet another exemplary implementation of blocks 305-315 of the method of FIG.

[0011] [Figure 9] FIG. 9 is a schematic diagram showing unobservable obstacles adjacent to the mobile robot 120 of FIG. DETAILED DESCRIPTION OF THE INVENTION

[0012] Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0013] Components of the apparatus and methods are designated by conventional numerals in the drawings, where appropriate, and the drawings show only those specific details relevant to understanding the embodiments of the invention so as not to obscure the detailed disclosure, which disclosure will be readily apparent to those skilled in the art having the benefit of the descriptions herein.

[0014] Embodiments disclosed herein are directed to a method comprising: capturing sensor data representative of a vicinity of a mobile robot; detecting an obstacle obstructing a current path of the mobile robot based on the sensor data; outputting a state change request corresponding to the obstacle in response to detecting the obstacle; receiving data defining an updated state of the obstacle in response to the state change request; selecting a navigation action between (i) continuing to move along the current path and (ii) generating a new path that bypasses the obstacle based on the updated state data; and executing the selected navigation action.

[0015] An additional embodiment disclosed herein is directed to a mobile robot comprising: a mobile assembly; an output device; and a processor; wherein the processor is configured to: control the mobile assembly to move according to a current path; capture sensor data representative of a vicinity of the mobile robot; detect an obstacle that obstructs the current path based on the sensor data; in response to detecting the obstacle, control the output device to provide a state change request corresponding to the obstacle; in response to the state change request, receive data defining an updated state of the obstacle; and, based on the updated state data, select a navigation action between (i) continuing to move according to the current path and (ii) generating a new path that bypasses the obstacle; and perform the selected navigation action.

[0016] FIG. 1 illustrates the interior of a facility 100, such as a warehouse, manufacturing facility, medical facility, or the like. The facility 100 includes a plurality of support structures 104 that hold items 108. In the illustrated example, the support structures 104 include shelving modules arranged in sets to form, for example, aisles 112-1, 112-2 (collectively referred to as aisles 112 and generally as aisle 112; similar nomenclature is used for other components herein). As shown in FIG. 1 , the support structures 104 in the form of shelving modules include support surfaces 116 that support the items 108. In other examples, the support structures 104 may include pegboards, bins, or the like.

[0017] In other embodiments, facility 100 may include fewer aisles 112 than are shown in FIG. 1 , or may include more aisles 112 than are shown in FIG. 1 . In the illustrated embodiment, aisles 112 are formed by sets of eight support structures 104 (four on each side), although a facility may have a variety of other aisle layouts. As will be apparent, each aisle 112 is an open-ended space bounded on both sides by support structures 104. The aisles 112 may be traversed by people, vehicles, and the like. In yet other embodiments, facility 100 need not include aisles 112, but instead may include an assembly line, or the like.

[0018] The items 108 may be processed according to various processes, depending on the nature of the facility. In some examples, the facility is a shipping facility, a distribution facility, etc., and the items 108 may be placed on the support structure 104 for storage and then removed from the facility for shipping. The placement of the items 108 on the support structure and / or the removal of the items 108 from the support structure may be performed or assisted by a mobile robot, two exemplary robots 120-1, 120-2 of which are shown in FIG. 1 . For example, based on the size and / or layout of the facility 100, more than the two robots 120 shown in FIG. 1 may be deployed within the facility 100. The components of the robots 120 are described in more detail below. Generally, each robot 120 is configured to transport the items 108 within the facility 100.

[0019] Each robot 120 may be configured to track its pose (e.g., position and orientation) within the facility 100, for example, within a coordinate system 124 pre-established within the facility 100. The robot 120 may autonomously navigate (move) within the facility 100, for example, to locations assigned to the robot 120, where it may pick up and / or deposit items 108. The items 108 may be placed in or on the robot 120 or retrieved from the robot 120 by one or more human workers 126 and / or mechanized devices, such as a robotic arm, deployed within the facility 100. The locations to which each robot 120 travels may be assigned to the robot 120 by a central server 128. That is, the server 128 is configured to assign tasks to the robot 120. Each task may include one or more locations to travel to and / or one or more actions to perform at those locations. For example, server 128 may assign robot 120-1 the task of traveling to a location defined by coordinate system 124 and waiting to receive one or more items 108 at that location.

[0020] Tasks may be assigned to the robots 120 by exchanging messages between the server 128 and the robots 120 over a suitable combination of local area and wide area networks, including, for example, communication links 130-1, 130-2. The server 128 may be located at the facility 100 or may be remotely located away from the facility 100. In some embodiments, the server 128 is configured to assign tasks to the robots 120 at multiple facilities and need not be physically located at any of the individual facilities.

[0021] The mobile robot 120 is configured to generate a path through the facility 100 from the current position and orientation of the robot 120 to the target location, for example, in response to receiving the target location from the server 128. The generation of the path may be based on a map of the facility 100 (e.g., obtained from the server 128) that is stored on the mobile robot 120 or otherwise accessible to the mobile robot 120. The mobile robot 120 is configured to move along the generated path toward the target location.

[0022] Various objects within facility 100, such as boxes, pallets, items 108, other robots 120, and humans (e.g., workers 126), are generally not represented on the map because the locations of such objects within facility 100 are typically temporary. Accordingly, robot 120 is further configured to monitor its surroundings for obstacles while traveling along the generated path. Upon detecting an obstacle that obstructs its current path, robot 120 may generate a new path to the target location that avoids the obstacle, although the new path may involve significantly longer travel distances to the target location (e.g., exiting aisle 112 and passing through a different aisle 112). Robot 120 may be configured to pause its movement for a predetermined timeout period before generating a new path. This pause may be performed, for example, to determine whether the obstacle has been removed (gone) under its own power (e.g., if the obstacle is a worker 126 or another robot 120) or whether it has been removed by another entity (e.g., if an obstacle such as a box is removed from the path of the robot 120 by a worker 126).

[0023] However, such a timeout period may increase the time it takes to reach the goal location if the obstacle remains at the end of the timeout period and a new path is eventually generated to go around the obstacle, whereas in other scenarios, the robot 120 may generate a new path just before an obstacle is removed from the original path, in which case the extended travel distance of the new path unnecessarily increases the travel time to the goal location.

[0024] Accordingly, the robot 120 is configured to generate and output obstacle state change requests, as described below. The requests prompt nearby entities, such as a worker 126 and / or other mobile robots 120, to cause the mobile robot 120 to provide information about the current or anticipated presence of detected obstacles and, in some cases, physically manipulate the obstacles (e.g., remove the obstacles from the robot's 120's current path). By generating such requests and incorporating state data collected as a result of the requests into the selection of navigation actions, the mobile robot 120 may improve navigation efficiency. For example, it may bypass timeout periods in some cases or extend timeout periods in other cases to reduce the overall travel time to the target location.

[0025] Before describing the functions implemented by the robot 120 in more detail, certain components of the robot 120 will be described with reference to Figure 2. As shown in Figure 2, each robot 120 includes a chassis 200 that supports various other components of the robot 120. In particular, the chassis 200 supports a movement assembly 204, which may include one or more motors 210, such as electric motors (e.g., brushless DC electric motors), that may drive an effector 211, such as a set of wheels or tracks. The movement assembly 204 may include one or more sensors, such as wheel odometers, an inertial measurement unit (IMU), etc. The movement assembly 204 may further include one or more braking devices, for example, coupled to the effector 211.

[0026] The chassis 200 also supports receptacles, shelves, etc. for supporting the items 108 during transport. For example, the robot 120 may include a combination of selectable receptacles 212. In the illustrated example, the chassis 200 supports racks 208, which may include, for example, rails or other structural features configured to support receptacles 212 at various heights above the chassis 200. Thus, the receptacles 212 may be attached to and detached from the racks 208, allowing different combinations of receptacles 212 to be supported by the robot 120.

[0027] The robot 120 may also include an output device such as a display 214. In the illustrated example, the display 214 is mounted above the rack 208, although it will be apparent that in other embodiments the display 214 may be located elsewhere on the robot 120. The robot 120 may also include other output devices in addition to or instead of the display 214. For example, the robot 120 may include one or more speakers, lights such as a strip of light-emitting diodes (LEDs) along the rack 208, etc.

[0028] The robot 120 may further include an input device 216, such as a touchscreen integrated with the display 214. In other embodiments, the input device 216 may include other input devices, such as a microphone, a keypad, etc., in addition to or instead of the aforementioned touchscreen. The input device 216 is configured to accept input from an entity, such as the worker 126, and to provide data representing such input to the processor 220 of the mobile robot 120.

[0029] The chassis 200 of the robot 120 also supports various other components, including a processor 220 (e.g., one or more CPUs, GPUs, or dedicated hardware controllers such as ASICs). The processor 220 is communicatively coupled to a non-transitory computer-readable medium such as memory 224 (e.g., a suitable combination of volatile and non-volatile memory elements). The processor 220 is also coupled to a communication interface 228, such as a wireless transceiver, that allows the robot 120 to communicate with other computing devices, such as a server 128 or other robots 120.

[0030] Memory 224 stores various data used for autonomous or semi-autonomous navigation, including applications 232 executable by processor 220 to implement navigation functions and other task performance functions. In some embodiments, the aforementioned functions may be implemented via multiple different applications stored in memory 224.

[0031] Chassis 200 may also support sensors 240, such as one or more cameras and / or depth sensors (e.g., LiDAR, depth cameras, time-of-flight cameras) coupled to processor 220. The sensors 240 are configured to capture image and / or depth data indicative of at least a portion of the physical environment of robot 120. Data captured by sensors 240 may be used by processor 220 for navigation purposes, such as path planning and obstacle avoidance, and in some embodiments, for updating maps of the facility.

[0032] Each sensor 240 has a field of view (FOV). For example, a first FOV 242a corresponds to a laser scanner, such as a lidar sensor, disposed on the front of the chassis 200. The FOV 242a may be substantially two-dimensional, e.g., extending forward in a substantially horizontal plane. A second FOV 242b corresponds to a camera (e.g., a depth camera, a color camera, etc.) mounted on the front of the chassis 200. As will be apparent, various other optical sensors with their own FOVs 242 may be disposed on the chassis 200 and / or rack 208.

[0033] Components of the robot 120 that consume power may receive such power from a battery 244 (eg, implemented as one or more rechargeable batteries housed within the chassis 200).

[0034] 3, a method 300 for interactive detection of obstacle conditions is shown. The method 300 is described below with respect to an exemplary execution thereof by the mobile robot 120, e.g., via execution of the application 232 by the processor 220.

[0035] In block 305, the mobile robot 120 is configured to execute a current path through the facility 100. The current path may be previously generated, for example, in response to a command from the server 128 to move to a target location within the facility 100. In response to generating the current path, the mobile robot 120 may control the movement assembly 204 to move along the current path toward the target location.

[0036] While executing the current path, in block 310, the mobile robot 120 is configured to capture sensor data, for example, by activating one or more sensors 240. For example, the processor 220 may capture image data, depth data (e.g., point clouds), etc., representative of the robot 120's vicinity within one or more FOVs 242 at any suitable frequency (e.g., 30 Hz) while moving along the current path. The processor 220 is configured to detect one or more obstacles that obstruct the current path from the sensor data. It should be apparent that the mobile robot 120 may also detect obstacles in the sensor data that do not obstruct the current path, although processing of these obstacles is beyond the scope of this description.

[0037] An obstacle that blocks the current path may be, for example, an obstacle that intersects the current path, or an obstacle that is within a threshold distance of the current path and an obstacle that is within a threshold distance of the mobile robot 120. For example, a worker 126 at the opposite end of a hallway may intersect with the current path of the mobile robot 120, but may not be considered to be blocking the current path if he or she is far enough away from the current position and orientation of the mobile robot 120.

[0038] As will be apparent, if no obstacles interfering with the current path are detected, the mobile robot 120 may continue moving along the current path while periodically repeating sensor data capture. The obstacles detected in block 310 (i.e., obstacles interfering with the current path) may include a variety of obstacles, such as autonomous obstacles, such as a worker 126 or another mobile robot 120, and passive obstacles, such as boxes, items 108, and pallets. In some examples, the obstacles detected in block 310 may include previously observed obstacles whose observed positions intersected the current path but are no longer within the FOV 242 of the mobile robot 120. Examples of each of the aforementioned obstacle types are described further below.

[0039] 4, an exemplary performance of blocks 305, 310, and 315 is illustrated. In particular, mobile robot 120-1 is illustrated as moving from an initial position and attitude 400 toward a target position 408 within passageway 112-1 along a current path 404. As robot 120-1 enters passageway 112-1, processor 220 detects an obstacle within FOV 242b. In this example, the obstacle is worker 126, which not only intersects with the current path but is also close enough to mobile robot 120-1 that mobile robot 120-1 cannot continue along current path 404. In other words, worker 126 is obstructing current path 404.

[0040] Referring again to FIG. 3 , in block 315, in response to detecting an obstacle obstructing the current path 404, the processor 220 is configured to generate and output a request for a state change corresponding to the detected obstacle in block 310. The nature of the request generated in block 315 depends on the nature of the obstacle in block 310, various embodiments of which are further described below. Generally, the request initiates an interaction between the mobile robot 120 and the obstacle itself or a nearby entity to request a physical movement of the obstacle, e.g., an indication of the obstacle's expected movement in the near future, or confirmation of the obstacle's presence or absence. Thus, through the interaction initiated by the request, the mobile robot 120 can obtain updated state data from the obstacle or nearby entity that may not be obtainable from sensor data alone. A next (subsequent) navigation action can be selected based not only on the sensor data but also on such updated state data.

[0041] The processor 220 is configured to select from among multiple request types in block 315 based on either or both of the obstacle type and the current state of the obstacle. The obstacle type may indicate, for example, whether the obstacle is passive (e.g., unable to communicate with the robot 120) or self-propelled (e.g., able to communicate with the robot 120). In some embodiments, a more specific obstacle type may be detected in block 310, for example, to distinguish between a worker 126 and another mobile robot 120 (both self-propelled). The current state of the obstacle may include, for example, an indication of whether the obstacle is currently observed or unobservable. An unobservable obstacle is an obstacle previously observed at a location that is now outside the FOV 242. In other words, the mobile robot 120 may not be able to determine from current sensor data whether an unobservable obstacle still exists at a previously observed location.

[0042] Thus, processor 220 may select the type of request to generate in block 315 from, for example, a mapping between request types and obstacle types and / or obstacle conditions stored in memory 224. In this exemplary implementation of method 300, the obstacle detected in block 310 is worker 126 shown in FIG. 4 , and processor 220 may therefore select a request corresponding to a self-propelled obstacle. In some examples, processor 220 may select a request that specifically corresponds to a human rather than a self-propelled obstacle (e.g., a separate request type (e.g., electronic message exchange) may be employed for other self-propelled obstacles, such as other mobile robots configured for electronic communication with robot 120).

[0043] In this example, the request generated in block 315 is a request directed to the obstacle itself (e.g., the worker 126) to perform a state change. In this example, the request generated in block 315 may include requesting the worker 126 to indicate an expected state in the near future, such as whether the worker 126 intends to leave their current location within a certain time period. In other words, the request requests the worker 126 to clear the current path of the mobile robot 120 and allows the worker 126 to indicate whether they intend to perform the requested move.

[0044] 5 illustrates an exemplary request rendered on the display 214 in block 315. In other embodiments, the request may be presented via other output devices, such as through a speaker, in addition to or instead of the display 214. The request may include a message requesting that the worker 126 unblock the current path 404 and indicate a default timeout period 500 after which the robot 120 will generate a new path around the worker 126 (e.g., via an adjacent aisle 112) if no response to the request is received. The request may also include selectable responses 504, 508. Response 504 is selectable by the worker 126 to provide the robot 120 with updated status data indicating that the worker 126 intends to move off the current path 404. Response 508 is selectable by the worker 126 to provide the robot 120 with updated status data indicating that the worker 126 intends to continue blocking the current path for at least the timeout threshold.

[0045] The responses 504, 508 are shown as being selectable, for example, via a touchscreen integrated into the display 214. In other examples, the response data may also be received via a microphone (e.g., the operator 126 may provide a voice response) or other suitable input device.

[0046] In some embodiments, the request may indicate a threshold time to evaluate when determining which response the worker 126 selects. For example, the request may indicate that if the worker 126 plans to move within the next 30 seconds (e.g., twice the timeout period), then response 504 should be selected.

[0047] 3 , in block 320, processor 220 is configured to receive updated state data, for example, in response to the request generated in block 315. The data received in block 320 includes an updated state of the obstacle, such as an indication that the obstacle is expected to continue obstructing the current path or an indication that the obstacle is expected to clear (exit) the current path. Processor 220 is configured to select a navigation action based on the updated state data between continuing to travel along the current path and generating a new path that bypasses the obstacle.

[0048] In this example, when response 504 is selected by worker 126 indicating that worker 126 intends to depart from a current position that obstructs current path 404, processor 220 proceeds to block 325. In block 325, processor 220 may be configured to extend the aforementioned default timeout period (waiting period), for example, by a predetermined factor (e.g., doubling the default timeout period, although various other absolute or fractional adjustments may also be employed). In block 330, processor 220 may use additional sensor data captured via sensors 140 to determine whether worker 126 continues to obstruct current path 404. If the determination in block 330 is negative, processor 220 is configured to determine in block 340 whether the extended timeout period (waiting period) has elapsed. If the timeout has not yet elapsed, processor 220 is configured to continue monitoring sensor data in block 330. In some embodiments, before the extended timeout period has elapsed, while monitoring sensor data via block 330, the mobile robot 120 may continue to display the extended timeout period on the display 214 along with selectable elements 504, 508. Accordingly, the operator 126 may provide an updated indication to the mobile robot 120, for example, indicating that the operator 126 no longer plans to depart immediately. In that case, the mobile robot 120 may proceed to block 345, just as it would after determining in block 320 that the obstacle is expected to remain in place. In further embodiments, repeated selection of element 508 may further extend the timeout period.

[0049] When the determination at block 330 is affirmative, the processor 220 may be configured to control the movement assembly 204 to continue the current path 404. When the determination at block 340 is affirmative, indicating that the worker 126 has not cleared the current path 404, the processor 220 may be configured to generate a new path at block 345 to move to the target location 408 while avoiding the worker 126. As will be apparent, when the updated state data received at block 320 is adequate, the robot 120 may delay generating the new path, thereby arriving at the target location 408 sooner than generating the new path.

[0050] 4 (e.g., if response 508 is selected by the worker 126), the processor 220 proceeds from block 320 to block 345 to generate a new path that bypasses the timeout period. In other words, by bypassing the timeout period, the robot 120 may reduce the total travel time to the target location compared to a scenario in which the updated state data is not received. FIG. 6 illustrates an example execution of block 345 in which the processor 220 generates a new path 600 to the target location 408 that bypasses the worker 126, for example, by going through an adjacent aisle 112.

[0051] As is apparent from the foregoing, generating the request in block 315 and receiving updated state data in block 320 may also be performed for obstacles in the form of other mobile robots. In such instances, the request may be output via communication interface 228 rather than display 214, and the updated state data may be received via communication interface 228 rather than a touchscreen, microphone, etc.

[0052] As previously described, method 300 may be performed by robot 120, and navigation actions may be selected as various types of obstacles are encountered in various states. In a further example shown in FIG. 7 , mobile robot 120 detects, in block 310, an obstacle 700, such as a box or pallet, that blocks current path 404. In other words, obstacle 700 is not self-propelled, i.e., it cannot perform a state change on its own or respond to a request generated by mobile robot 120 in block 315. Thus, mobile robot 120 may select, in block 315, a rendering request (e.g., by rendering on display 214) requesting a state change for obstacle 700 from a support entity different from obstacle 700. For example, worker 126 in hallway 112-1 may view the request on display 214, provide updated state data to robot 120, and selectively manipulate obstacle 700.

[0053] As shown in FIG. 7 , the request presented on the display 214 includes a request to move the obstacle 700 and may include an indication of the current timeout period, as previously described. In this example, the request may also include a map 704 depicting a portion of the path to indicate the location of the obstacle (shown with hatching) relative to the robot 120 and the support structure 104. The request includes responses 708, 712 selectable by the operator 126, as described in connection with FIG. 5 . Selection of response 708 provides the robot 120 with updated status data indicating that the obstacle 700 is expected to continue obstructing the current path 404. Thus, the robot 120 may proceed to block 345 and generate a new path, bypassing the timeout period. The operator 126 may select response 708, for example, when the obstacle 700 is too heavy to move or when other tasks within the facility 100 require the presence of the obstacle 700.

[0054] Selection of response 712 provides the robot 120 with updated state data indicating that the obstacle 700 is expected to soon be removed from the current path 404. Accordingly, the robot 120 may proceed to block 325, extend the timeout period, and monitor the sensor data for the departure of the obstacle 700 from the current path, as described above in connection with FIG.

[0055] In a further example, the request generated in block 315 requests updated status data from a nearby assistance entity (e.g., a worker 126 or another mobile robot 120) indicating the current (actual) presence or absence of an obstacle, rather than the predicted presence or absence of an obstacle as described above. In cases such as those shown in Figures 5-7, the current (actual) presence or absence of an obstacle can be directly detected from the sensor data captured in block 310. However, in other cases, if a previously detected obstacle is outside the FOV 242 of the sensor 240, the current (actual) presence of the obstacle cannot be directly detected.

[0056] FIG. 8 illustrates a further example in which the robot 120 detects an obstacle 800 while traveling to its current position (i.e., the aforementioned target position 408). A new target position 804 is assigned and a current path 808 is generated, but the robot 120 can no longer observe the obstacle 800 because, for example, the obstacle 800 is a low obstacle below the lower limit of the sensor FOV 242b. Briefly reviewing FIG. 9, a side view of the robot 120 is shown with the obstacle 800, showing that the obstacle 800 is outside the FOV 242b. In other words, the obstacle 800 may remain within the obstacle map stored by the robot 120, but may not be directly observed by the robot 120. Thus, the robot 120 may be unable to proceed along the current path 808. In some cases, the robot 120 may be inhibited from executing a new path due to the obstacle 800's proximity to the chassis 200.

[0057] Accordingly, the robot 120 is configured to generate, in block 315, a further request type, e.g., on the display 214 (or wirelessly transmitted to another robot 120), requesting that an assisting entity provide updated status data indicating the current presence of the obstacle 800. In particular, the request may include a map 812 similar to the map 704 described in connection with FIG. 7 , a selectable option 816 for indicating that the obstacle 800 is still present, and a selectable option 820 for indicating that the obstacle 800 is absent. When option 820 is selected, the robot 120 may proceed directly to block 335, and blocks 325 and 330 are omitted. When option 816 is selected, the robot 120 may proceed to block 345, although in some cases the robot 120 may first proceed to block 350 and generate a request for assistance. The request for assistance may include a request to move an unobservable obstacle 800 and / or a request to push the robot 120 itself until the obstacle 800 is within the sensor FOV 242. In some examples, following the request for assistance in block 350, the mobile robot 120 may resume path execution from block 305, for example, if the requested assistance is to remove an obstacle or to reposition the mobile robot 120 to allow navigation to continue.

[0058] The foregoing specification describes particular embodiments. However, those skilled in the art will recognize that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be understood in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present teachings.

[0059] Benefits, advantages, solutions to problems, and any elements that may cause or make more noticeable any benefit, advantage, or solution should not be construed as critical, necessary, or essential features or elements of any or all of the claims. The present invention is defined solely by the appended claims, including any amendments made during the pendency of this application and all equivalents of those claims as issued.

[0060] Furthermore, in this document, related terms such as first and second, above and below, etc. may be used only to distinguish one entity or operation from another and may not necessarily require or imply an actual relationship or ordering between such entities or operations. The terms "comprises," "comprising," "has," "having," "include," "including," "contains," "containing," or any other variations thereof, are intended to cover a non-exclusive inclusion. A description of a process, method, article, or apparatus as comprising, having, including, or containing a list of elements does not include only those elements, but may include other elements not expressly listed and other elements inherent in such process, method, article, or apparatus. An element preceded by "comprises ... a," "has ...," "includes ... a," or "contains ... a" does not, without further constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, or contains the element. The terms "a" and "an" are defined as one or more, unless expressly stated otherwise. The terms "substantially," "essentially," "approximately," "about," and any other variations thereof are defined as close as understood by one of ordinary skill in the art, and in one non-limiting embodiment, such terms are defined as within 10%, in another embodiment within 5%, in another embodiment within 1%, and in another embodiment within 0.5%. The term "coupled," as used herein, is defined as connected, but not necessarily directly, and not necessarily mechanically. A device or structure "configured" in a certain way is configured in at least that way, but may also be configured in ways not listed.

[0061] Certain phrases may be used herein to enumerate (list) combinations of elements. Examples of such phrases include "at least one of A, B, and C," "one or more of A, B, and C," "at least one of A, B, or C," and "one or more of A, B, or C." Unless expressly stated otherwise, the foregoing phrases include any combination of A and / or B and / or C.

[0062] It will be understood that some embodiments may consist of one or more special-purpose processors (or "processing devices"), such as microprocessors, digital signal processors, customized processors, field programmable gate arrays (FPGAs), etc., in combination with specific non-processor circuitry and unique stored program instructions (including both software and firmware) that control the one or more processors to implement some, most, or all of the functionality of the methods and / or apparatus described herein. Alternatively, some or all of the functionality may be implemented by a state machine without stored program instructions, or by one or more application-specific integrated circuits (ASICs) in which each function or a particular combination of functions is implemented as custom logic. Of course, a combination of the two approaches may also be used.

[0063] Furthermore, embodiments may be implemented as a computer-readable storage medium having computer-readable code stored thereon for programming a computer (e.g., including a processor) to perform the methods described and claimed herein. Examples of such computer-readable storage media include, but are not limited to, hard disks, CD-ROMs, optical storage devices, magnetic storage devices, ROMs (read-only memories), PROMs (programmable read-only memories), EPROMs (erasable programmable read-only memories), EEPROMs (electrically erasable programmable read-only memories), flash memories, etc. Furthermore, it is expected that those skilled in the art will be readily able to generate such software instructions, programs, and ICs with minimal experimentation when guided by the concepts and principles disclosed herein, despite significant effort and numerous design choices, motivated by, for example, available time, current technology, and economic considerations.

[0064] This Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. It may also be noted that in the foregoing Detailed Description, various features are grouped together in various embodiments for the purpose of facilitating this disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. The following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

Claims

1. capturing sensor data representative of a vicinity of the mobile robot; detecting an obstacle that obstructs a current path of the mobile robot based on the sensor data; in response to detecting the obstacle, outputting a request for a state change corresponding to the obstacle; receiving data defining an updated state of the obstacle in response to the request for a state change; selecting a navigation action between (i) continuing to move along the current route and (ii) generating a new route that bypasses the obstacle based on the updated state data; performing the selected navigation action; A method comprising:

2. The data defining the updated status of the obstacle includes one of: (i) an indication that the obstacle is expected to continue obstructing the current path; and (ii) an indication that the obstacle is expected to clear the current path.

2. The method of claim 1 .

3. The step of selecting a navigation action includes: electing to continue traveling along the current path if the updated state data includes the indication that the obstacle is expected to clear the current path; electing to generate a new route that bypasses the obstacle if the updated state data includes the indication that the obstacle is expected to continue to obstruct the current route; Contains 3. The method of claim 2.

4. Continuing to move along the current path includes determining whether the obstacle clears the current path within a timeout period.

2. The method of claim 1 .

5. Continuing to move along the current route includes generating a timeout period by extending a default timeout period.

5. The method of claim 4.

6. The performing of generating a new path around the obstacle includes generating the new path bypassing a timeout period.

2. The method of claim 1 .

7. detecting the obstacle includes determining that a previously detected obstacle location is outside a field of view of a sensor; The request for a change of state includes a request for data indicating that the previously detected obstacle (i) is present at the location, or (ii) is not present at the location.

2. The method of claim 1 .

8. generating a second request to an assisting entity to push the mobile robot if the updated state data indicates that the detected obstacle is present at the location before generating the new path around the obstacle.

8. The method of claim 7, further comprising:

9. The request for a state change includes a request to an assisting entity to move the obstacle from the current path.

2. The method of claim 1 .

10. the step of detecting the obstacle includes the step of determining that the obstacle is self-propelled; The state change request includes a request directed to the obstacle to move from the current path.

2. The method of claim 1 .

11. Detecting the obstacle includes determining that the obstacle is one of: (i) a human; and (ii) another mobile robot.

11. The method of claim 10.

12. Outputting the request includes rendering the request on a display of the mobile robot.

2. The method of claim 1 .

13. The request includes a graphical representation of the location of the obstacle.

2. The method of claim 1 .

14. A mobile robot, a moving body assembly; an output device; a processor; Equipped with The processor: controlling the mover assembly to move according to a current path; capturing sensor data representative of a vicinity of the mobile robot; Detecting an obstacle that obstructs the current path based on the sensor data; controlling the output device to provide a state change request corresponding to the obstacle in response to detecting the obstacle; receiving data defining an updated state of the obstacle in response to the request for a state change; selecting a navigation action between (i) continuing to move along the current route and (ii) generating a new route that bypasses the obstacle based on the updated state data; Perform the selected navigation action It is configured as follows: A mobile robot characterized by:

15. The data defining the updated status of the obstacle includes one of: (i) an indication that the obstacle is expected to continue obstructing the current path; and (ii) an indication that the obstacle is expected to clear the current path.

15. The mobile robot according to claim 14.

16. The processor: by choosing to continue traveling along the current path if the updated state data includes the indication that the obstacle is expected to clear the current path; and by choosing to generate a new route that bypasses the obstacle if the updated state data includes the indication that the obstacle is expected to continue to obstruct the current route; configured to select the navigation action.

16. The mobile robot according to claim 15.

17. The processor: by determining whether the obstacle has cleared the current path within a timeout period; configured to continue moving along the current path.

15. The mobile robot according to claim 14.

18. The processor: By generating said timeout period by extending a default timeout period, configured to continue moving along the current path.

18. The mobile robot according to claim 17.

19. The processor: By bypassing the timeout period and generating a new route, generating a new path that bypasses the obstacle.

15. The mobile robot according to claim 14.

20. The processor: by determining that the location of a previously detected obstacle is outside the field of view of the sensor; configured to detect the obstacle; The request for a change of state includes a request for data indicating that the previously detected obstacle (i) is present at the location, or (ii) is not present at the location.

15. The mobile robot according to claim 14.

Images