Patent Application
20240227183
Autonomous or semi-autonomous mobile robots, e.g., deployed in facilities to transport items such as parcels and the like, can be assigned tasks from a central computing device such as a server. The server can, for example, distribute a set of tasks between a fleet of the mobile robots. Task assignments to the mobile robots, in other words, can be centralized. Centralized task assignment, however, can lead to suboptimal usage of the mobile robots, and/or increased computational burden on the server.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.
Skilled artisans 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 of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
Examples disclosed herein are directed to a method, comprising: storing, at a mobile robot, a local repository of self-assigned task definitions; determining, at a processor of the mobile robot, that a local activity metric associated with tasks assigned to the mobile robot by a central server meets an idle criterion; in response to determining that the local activity metric meets the idle criterion, selecting, by the processor, one of the self-assigned task definitions from the local repository; and initiating execution of a self-assigned task corresponding to the selected self-assigned task definition at the mobile robot.
Additional examples disclosed herein are directed to a mobile robot, comprising: a memory storing a local repository of self-assigned task definitions; a locomotive assembly; a communications interface communicatively connecting the mobile robot with a central server; and a processor configured to: determine that a local activity metric associated with tasks assigned to the mobile robot by the central server meets an idle criterion; in response to determining that the local activity metric meets the idle criterion, select, one of the self-assigned task definitions from the local repository; and initiate execution of a self-assigned task corresponding to the selected self-assigned task definition at the mobile robot.
In other examples, the facility 100 can include fewer aisles 112 than shown, or more aisles 112 than shown in
The items 108 may be handled according to a wide variety of processes, depending on the nature of the facility. In some examples, the facility is a shipping facility, distribution facility, or the like, and the items 108 can be placed on the support structures 104 for storage, and subsequently retrieved for shipping from the facility. Placement and/or retrieval of the items 108 to and/or from the support structures can be performed or assisted by mobile robots, of which two example robots 120-1 and 120-2 are shown in
Each robot 120 can be configured to track its pose (e.g., location and orientation) within the facility 100, e.g., within a coordinate system 124 previously established in the facility 100. The robots 120 can navigate autonomously within the facility 100, e.g., travelling to locations assigned to the robots 120 to receive and/or deposit items 108. The items 108 can be deposited into or onto the robots 120, and removed from the robots 120, by human workers and/or mechanized equipment such as robotic arms and the like deployed in the facility 100. The locations to which each robot 120 navigates can be assigned to the robots 120 by a central server 128. That is, the server 128 is configured to assign tasks to the robots 120. Each task can include either or both of one or more locations to travel to, and one or more actions to perform at those locations. For example, the server 128 can assign a task to the robot 120-1 to travel to a location defined in the coordinate system 124, and to await the receipt of one or more items 108 at that location.
Tasks can be assigned to the robots via the exchange of messages between the server 128 and the robots 120, e.g., over a suitable combination of local and wide-area networks. The server 128 can therefore be deployed at the facility 100, or remotely from the facility 100. In some examples, the server 128 is configured to assign tasks to robots 120 at multiple facilities, and need not be physically located in any of the individual facilities.
In addition to primary tasks such as item retrieval and transport, the robots 120 can perform a variety of supporting and/or maintenance tasks within the facility 100. Such tasks can include traveling to charging docks (not shown) within the facility 100 to charge batteries of the robots 120, or travelling to predetermined staging locations within the facility 100 to await charging or primary task assignment. Other examples of supporting and/or maintenance tasks can include inspection of various elements of the facility 100, e.g., to update a map of the facility 100 stored at the server 128 and deployed to the robots 120 for navigational purposes. Updating the map can include travelling a region of the facility 100, e.g., by a robot 120, and capturing sensor data to detect the positions of objects within the region (e.g., support structures 104 and the like). Periodically performing map updating tasks can update the map to reflect physical movements of objects in the facility 100, e.g., rearrangement of aisle 112 layouts.
Further examples of supporting and/or maintenance tasks performed by the robots 120 can include inspecting fiducial markers such as retroreflectors disposed as navigational aids on structures within the facility 100 (e.g., the support structures 104, conveyor belts, or other item-handling equipment with which the robots 120 may interact). Inspection of fiducial markers can include detecting the markers and comparing detected marker positions within the coordinate system 124 to expected positions of such markers. Still further examples of supporting and/or maintenance tasks include inventory checks, e.g., involving travelling an aisle 112 by a robot 120 and capturing images of the items 108 within the aisle 112, for later processing (e.g., by the robot 120 or by the server 128) to detect item identifiers and determine whether any items 108 are out of stock, misplaced, or the like. Supporting and/or maintenance tasks can also include a network mapping task, e.g., to travel a region of the facility 100 and record signal strength measurements (e.g., received signal strength indicators or RSSIs) and access point identifiers corresponding to wireless networking infrastructure within the facility 100. Such data can be employed to generate a heat-map of Wi-Fi reception throughout the facility 100, e.g., to determine whether to adjust the deployment of the network infrastructure to improve reception, throughput, or the like.
Some supporting and/or maintenance tasks are robot-specific, such as calibration tasks, e.g., to calibrate odometry sensors of a robot 120, perform battery conditioning at a robot 120, upload collected data (e.g., images of an aisle 112 as mentioned earlier) to the server 128, and the like.
The range of tasks performed by the robots 120 is such that controlling all task assignments at the server 128 may be computationally costly. Further, conducting all task assignments at the server 128 can lead to suboptimal usage of the robots 120. For example, when a robot 120 completes a task more quickly than expected, or aborts a task due to an obstruction, that robot 120 may remain idle for some period of time until the server 128 is able to assign a further task to the robot 120.
The robots 120 are therefore configured, as discussed in detail below, not only to execute tasks assigned by the server 128, but also to maintain a local repository of self-assigned task definitions, and to independently perform self-assigned tasks selected from the repository under certain conditions. In general, the robots 120 are configured to periodically assess one or more local activity metrics associated with tasks assigned to the robots 120 by the server 128. When the local activity metric(s) meet one or more idle criteria, the robots 120 can be configured to self-assign tasks, thereby increasing utilization time for the robots 120.
Before discussing the functionality implemented by the robots 120 in greater detail, certain components of the robots 120 are discussed with reference to
The chassis 200 also supports receptacles, shelves, or the like, to support items 108 during transport. For example, the robot 120 can include a selectable combination of receptacles 212. In the illustrated example, the chassis 200 supports a rack 208, e.g., including rails or other structural features configured to support receptacles 212 at variable heights above the chassis 200. The receptacles 120 can therefore be installed and removed to and from the rack 208, enabling distinct combinations of receptacles 212 to be supported by the robot 120.
The robot 120 can also include an output device, such as a display 216. In the illustrated example, the display 216 is mounted above the rack 208, but it will be apparent that the display 216 can be disposed elsewhere on the robot 120 in other examples. The display 216 can include an integrated touch screen or other input device, in some examples, The robot 120 can also include other output devices in addition to or instead of the display 216. For example, the robot 120 can include one or more speakers, light emitters such as strips of light-emitting diodes (LEDs) along the rack 208, and the like.
The chassis 200 of the robot 120 also supports various other components, including a processor 220, e.g., in the form of one or more central processing units (CPU), graphics processing units (GPU), or dedicated hardware controllers such as application-specific integrated circuits (ASICs). The processor 220 is communicatively coupled with a memory 224, e.g., a suitable combination of volatile and non-volatile memory elements. The processor 220 is also coupled with a communications interface 228, such as a wireless transceiver enabling the robot 120 to communicate with other computing devices, such as the server 128 and other robots 120.
The memory 224 stores various data used for autonomous or semi-autonomous navigation, including an application 232 executable by the processor 220 to implement navigational and other task execution functions. In some examples, the above functions can be implemented via multiple distinct applications stored in the memory 224. The memory 224 also stores a local repository 236 of self-assigned task definitions, as noted earlier.
The chassis 200 can also support a sensor 240, such as one or more cameras and/or depth sensors (e.g., lidars, depth cameras, time-of-flight cameras, or the like) coupled with the processor 220. The sensor(s) 240 are configured to capture image and/or depth data depicting at least a portion of the physical environment of the robot 120. Data captured by the sensor(s) 140 can by used by the processor 220 for navigational purposes, e.g., path planning, obstacle avoidance, and the like, as well as for updating a map of the facility in some examples.
The components of the robot 120 that consume electrical power can be supplied with such power by a power assembly 244, e.g., including one or more rechargeable batteries and associated hardware for recharging the batteries, such as a charging port on the chassis 200 or the like.
Turning to
At block 305, the robot 120 is configured to store a set of self-assigned task definitions, e.g., in the repository 236 mentioned above. Each self-assigned task definition contains various data that can be used by the processor 220 to perform the corresponding task, as well as evaluate when or whether to perform the corresponding task. Turning to
Each task definition 400 includes data that can be processed by the processor 220 to perform the corresponding task. Such data can include a series of navigational instructions, commands to enable various components of the robot 120, and the like. Each task definition 400 can also include, as shown in
Each task definition 400 can also include indications 408 of one or more subsystems of the robot 120 involved in the execution of the corresponding self-assigned task. In other examples, the subsystem indications 408 can be omitted. When present in the repository 236, the subsystem indications can be used by the robot 120 to assess idle criteria on a per-subsystem basis, such that a self-assigned task may be initiated simultaneously with a server-assigned task, so long as the self-assigned task does not interfere with the server-assigned task. For example, the robot 120 may initiate a self-assigned data post-processing task while performing a charging task assigned by the server 128.
As shown in
That is, the robot 120 may not initiate the calibration or mapping tasks if either of the navigational subsystem and the charging subsystem are in use to execute a task assigned to the robot 120 by the server 128. As will be apparent, if the charging subsystem is occupied, navigating away from a charging dock to perform odometry calibration or mapping would interrupt the charging task. The task definition 400-2, in contrast, indicates that the charging subsystem is expected to be in use as a result of a server-assigned charging task, or that a battery charge level of the robot 120 is expected to be above a threshold (e.g., 70%) before beginning the post-processing task. The post-processing task, in other words, illustrates that the robot 120 need not be entirely idle to begin a self-assigned task. In other examples, the subsystem indicators 408 can be omitted.
Each task definition 400 can further include prioritization criteria 412. The prioritization criteria are used by the robot 120 (specifically, by the processor 220) to select between the self-assigned tasks. For example, prioritization criteria can include a predetermined target frequency for each task (e.g., weekly for calibration, and monthly for the mapping tasks, in the illustrated example). The prioritization criteria 412 can also include, as in the example of the post-processing task definition, a threshold volume “Y” of data to be processed (which may be combined with a target frequency in other examples). In further examples, as in the case of the task definition 400-1, the prioritization criteria can include elevation criteria, e.g., by which the corresponding task can receive a higher priority than indicated by target frequency. In the case of the calibration task 400-1, the task can be given an elevated priority (e.g., selected above any other self-assigned task) if a threshold “X” number of localization errors have been detected by the robot 120 since the previous calibration. In other examples, the prioritization criteria 412 can include priority levels (e.g., from one to four in this example), which can be used in conjunction with, or instead of, target frequencies, e.g., to select one self-assigned task when multiple tasks have aged sufficiently to meet their respective target frequencies.
In further examples, the prioritization criteria 412 can include location-based criteria, such as a distance threshold associated with either or both of the mapping tasks (400-3 and 400-4). For example, the distance threshold can define a distance between a current location of the robot 120 within the facility 100 and the corresponding region to be mapped, beyond which the corresponding mapping task will not be selected.
The task definitions 400 can also include metadata, such as a timestamp indicating the latest (i.e., most recent) execution of the corresponding task. The timestamp can be used in conjunction with target frequencies to determine whether a task has aged sufficiently to be performed again. In other examples, the timestamps can be used in the absence of target frequencies, e.g., to select the self-assigned task with the greatest age to perform.
A wide variety of other self-assigned tasks can also be defined in the repository 236, in addition to or instead of those shown in
Returning to
In other examples, the processor 220 can generate a plurality of local activity metrics, e.g., for each subsystem indicated in the repository 236. For example, the processor 220 can determine an idle time period for each of the charging subsystem and the navigational subsystem. Local activity metrics other than idle time periods are also contemplated. For example, a percentage or other suitable fraction of CPU cycles consumed by a server-assigned task can be used as a local activity metric for the processor 220 itself (e.g., to determine whether a self-assigned task can be performed simultaneously with the server-assigned task).
At block 315, the processor 220 is configured to determine whether an idle criterion is met, e.g., by the local activity metric(s) generated at block 310. In some examples, the idle criterion is a threshold idle time period, and the processor 220 can determine whether an idle time period determined at block 310 meets or exceeds the threshold idle time period. The threshold can be predetermined, e.g., as a value stored in the memory 224. In other examples, the threshold can be dynamically updated by the processor 220, e.g., based on historical data collected defining previous idle periods. For example, the processor 220 can store any idle period determined at block 310, and set the threshold at a predetermined fraction (e.g., 25%, although a wide variety of other fractions can be used) of an average or other aggregated value derived from the idle time periods. In other examples, the processor 220 can determine, from historical idle time periods, a threshold beyond which any idle time period is likely to continue for at least a further period (e.g., fifteen minutes). The determined threshold can be employed at block 315.
When multiple local activity metrics are generated at block 310, the processor 220 can compare each of the local activity metrics to a single idle criterion. In other examples, however, the processor 220 can compare each local activity metric to a distinct idle criterion (e.g., different threshold time periods can be employed for different subsystems of the robot 120).
When the determination at block 315 is negative, the processor 220 returns to block 310, to continue monitoring local activity metrics and repeating the determination at block 315. In some examples, the idle criterion evaluated at block 315 can include not only whether a subsystem-specific local activity metric meets a threshold, but also whether the repository 236 contains any self-assigned task definitions corresponding to that subsystem. For example, turning to
Turning to
In further examples, the idle criteria can include whether an indication of idle time has been received from the server 128. For example, the server 128 can send a command or other message to the robot 120 indicating that no further server-assigned tasks are expected to be allocated to the robot 120 for a time period specified in the command. In response to such a command, the determination at block 315 can be affirmative, e.g., regardless of whether the local activity metrics from block 310 satisfy other idle criteria such as the threshold 508.
Returning to
As will be apparent, other prioritization criteria, such as the volume of data in the task definition 400-2, the elevation criteria in the task definition 400-1, or the like, may also be employed to select a task at block 320. Priority indicators ranking the task definitions 400 can be used when prioritization criteria for multiple tasks are satisfied.
At block 325, the processor 220 is configured to initiate execution of the self-assigned task selected at block 320. Execution of the self-assigned task can be conducted according to the instructions contained in the corresponding task definition 400. In some examples, as shown in
At block 330, while executing the self-assigned task, the robot 120 is configured to await receipt of a server-assigned task. When no server-assigned task is received, the determination at block 330 is negative, and the robot 120 is configured to determine, at block 340, whether the self-assigned task is complete. When the determination at block 340 is negative, the robot 120 continues performance of the self-assigned task and repeats the determination at block 330. When the determination at block 340 is affirmative, the robot 120 returns to block 310.
When the determination at block 330 is affirmative, indicating that a new server-assigned task has been received at the robot 120, at block 335 the processor 220 is configured to interrupt the self-assigned task under execution, and initiate performance of the server-assigned task. Server-assigned tasks, in other words, take priority over any self-assigned tasks. In some examples, before interrupting the self-assigned task at block 335, the processor 220 can determine whether an estimated time to complete the self-assigned task is below a threshold (e.g., thirty seconds, or another suitable threshold). When the determination is affirmative, the robot 120 may instead complete the self-assigned task before initiating the server-assigned task. Following block 335, the robot 120 may also update the idle criterion used at block 315, e.g., if a dynamic idle time period threshold is employed. Specifically, the receipt of a server-assigned task signals the end of a period of idle time, which the processor 220 can add to the previously mentioned historical data.
Various other self-assigned tasks and prioritization criteria are contemplated, in addition to those set out above. For example, another self-assigned task that can be defined in the repository 236 is a seek-work task, in which the robot 120 travels to an area of the facility at which human workers, such as pickers, are stationed. The robot 120 can, upon arrival, advertise that the robot 120 is available for task assignments, e.g., on the display 216 or other output devices.
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.
The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The 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.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be 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, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
Certain expressions may be employed herein to list combinations of elements. Examples of such expressions 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”; “one or more of A, B, or C”. Unless expressly indicated otherwise, the above expressions encompass any combination of A and/or B and/or C.
It will be appreciated that some embodiments may be comprised of one or more specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used.
Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The 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. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the 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. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
| Number | Date | Country | |
|---|---|---|---|
| 20240131703 A1 | Apr 2024 | US |
