HK1224400B - Monitoring, diagnostic and tracking tool for autonomous mobile robots - Google Patents

Description

Monitoring, diagnostics, and tracking tools for autonomous mobile robots

This application is a divisional application of the invention patent application with application date of September 21, 2012, application number 201280045948.8, and invention name “Monitoring, diagnosis and tracking tool for autonomous mobile robots”.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of co-pending U.S. Provisional Patent Application No. 61/537,730, filed September 22, 2011, which is incorporated herein by reference in its entirety.

Technical Field

The present invention is directed to remote monitoring of autonomous mobile robots, and more particularly, to the arrangement and display of operating parameters of autonomous mobile robots for analysis and support by remote personnel.

Background Art

In recent years, autonomous mobile robots and the software that controls them have steadily developed in both complexity and functionality. Robotic and automated vehicles for delivering or transporting materials indoors (and outdoors) have been developed and used in many applications. For example, autonomous mobile robots for towing carts or delivery trucks have been developed, which are useful in industrial environments such as hospitals. In fact, a cart or delivery truck can include any item needed for delivery or retrieval. For example, in a hospital environment, such items can include, but are not limited to, laboratory work/results, blood, patient files, medications, emergency room (ER) materials/equipment, supplies, food, etc. In addition, a cart or cargo delivery area can be integrated with an autonomous mobile robot vehicle.

Such autonomous mobile robots are designed to navigate alongside humans in real-world situations, even when faced with complex and changing environments. For example, U.S. Patent Nos. 7,100,725, 7,431,115, and 7,894,939, which are assigned to the owner of the present invention and are incorporated herein by reference in their entirety, describe exemplary autonomous mobile robotic vehicles that may be employed or implemented in accordance with the systems and methods of the present invention described herein. However, other types of autonomous mobile robotic vehicles may also be employed/implemented without departing from the spirit and scope of the present invention.

While such autonomous mobile robot systems are inherently stable, unpredictable situations inevitably arise that require human intervention to analyze and resolve. These situations include periods of robot idle time (e.g., not moving), which may be caused by facility events such as, but not limited to, elevator delays, blocked paths (e.g., obstacles in hallways), and failed equipment (e.g., automatic doors not opening on command). Support personnel are typically located in a central location remote from the location of the autonomous mobile robot vehicle. Support personnel typically monitor and are responsible for any number of autonomous mobile robot fleets in different locations. In prior art systems, when an autonomous mobile robot encounters a navigation problem or an obstacle that it cannot navigate around, an email reporting the problem is sent to a remote central support location. The support personnel then receives and reads the email, infers the problem, and can then control the autonomous mobile robot and navigate around the problem or, if necessary, contact the appropriate individual at the vehicle location who can resolve the problem. However, there are inherent problems with applying this prior art approach.

During the time it takes a support person at a remote location to receive and read an email, the autonomous mobile robot may have already navigated around the problem or obstacle and is continuing on its path. The support person would have no way of knowing this unless the autonomous mobile robot sends another email, which is only received and read after the support person has wasted time trying to resolve the problem, which no longer exists. Furthermore, the information contained in the email may not be sufficient for the support person to determine the problem encountered by the autonomous mobile robot. This is simply because a single person cannot predict all the problems and obstacles that such equipment may encounter. Furthermore, when multiple autonomous mobile robot vehicles experience navigation problems simultaneously or nearly simultaneously, support personnel must be able to quickly and accurately determine which problems are most severe so that they can be addressed first. Resolving navigation issues through email reporting systems is typically done on a first-come, first-served basis. Furthermore, it would be desirable to monitor navigation issues encountered by different autonomous mobile robots at different locations and analyze them to determine whether certain areas at certain locations experience a high number of navigation incidents. Modifying these areas at that location can help reduce the likelihood of further problems.

The presently described systems and methods are directed to overcoming one or more of the aforementioned problems. Although various aspects of the systems and methods of the present invention will be described herein with reference to preferred embodiments in a hospital setting, the systems and methods of the present invention can be applied to a wide variety of delivery-related applications in a variety of environments (both indoors and outdoors) without departing from the spirit and scope of the present invention.

Summary of the Invention

According to the present invention, a system for managing and prioritizing action queues for mobile robots deployed at various locations is provided. The system includes multiple base servers, each corresponding to a different location, wherein each base server receives operational parameter data from multiple mobile robots operating at the specific location where the base server is deployed. A central server receives the operational parameter data from the multiple base servers and includes a data analysis module that processes the operational parameter data and prioritizes the mobile robots operating at the various locations for action by support personnel.

The operational parameter data represents operational and navigation events experienced by the mobile robot. The data analysis module applies a set of business rules to process the operational data and rank the mobile robots. Typically, the business rules are specific to a location and a mobile robot.

In ordering the mobile robots for action, the data analysis module generates a list that orders the mobile robots and arranges the mobile robots in order of importance for action by support personnel. The list generated by the data analysis module is typically accessed by the support personnel using a web-based application. The list includes links to other information related to the mobile robots and the locations where the mobile robots are operating, which can be used by support personnel to help identify problems that the mobile robots are experiencing and correct the problems. The list generated by the data analysis module includes operational information about the mobile robots. In one form, the operational information is color-coded to identify potential critical events.

As an additional feature, a mobile robot that appears in the list generated by the data analysis module can be hidden for a predetermined period of time, after which the mobile robot will reappear on the list. This is typically done while support personnel are waiting for something to happen regarding the mobile robot. To reduce clutter in the list, support personnel can hide that particular content from view for a predetermined period of time.

As a further feature, the data analysis module stores information about various events experienced by the mobile robot in a database.The database can be mined by support personnel to generate maps and charts showing the frequency of problems that mobile robots or locations are experiencing.

According to the present invention, a method for managing and sorting action queues of mobile robots deployed at various locations is also provided. The method generally includes the following steps: receiving, at a base server deployed at a specific location, operating parameter data from multiple mobile robots operating at the specific location; receiving, at a central server, the operating parameter data of the mobile robots from multiple base servers, each base server typically deployed at a different location; analyzing the operating parameter data of the mobile robots using a data analysis module at the central server; and sorting, by the data analysis module, the mobile robots operating at the various locations for action by support personnel.

The method further includes the step of displaying a ranked list to the support personnel via the data analysis module, the ranked list arranging the mobile robots in order of importance for the support personnel to take action. The ranked list may rank the mobile robots based on the severity of the operational and/or navigation events experienced. The ranked list may be accessed by the support personnel using a web-based application. In one form, the ranked list includes links to other information related to the mobile robots and the locations where the mobile robots are operating. Additionally, the ranked list may include operational information about the mobile robots. To assist support personnel in identifying and resolving events, the operational information may be color-coded to identify potentially critical events.

The operational parameter data generally represents operational and navigation events experienced by the mobile robot. The operational parameter data is processed by the data analysis module using a set of business rules. The business rules may be specific to a location and a mobile robot.

As an organizational feature, a mobile robot appearing on the ranked list may be hidden for a predetermined period of time, after which the mobile robot will reappear on the ranked list.

The method of the present invention further comprises the step of storing, by the data analysis module, information related to various operational and navigation events experienced by the mobile robot in a database. The method of the present invention may further comprise the step of analyzing the stored information related to various operational and navigation events experienced by the mobile robot, and the step of generating a map and/or graph showing the frequency of problems experienced by the mobile robot or location.

In further embodiments, the base server may be omitted. The functionality associated with the base server may be contained in the central server, which may receive raw operational data directly from the mobile robot using known or conventional methods and techniques and process the data to prioritize the mobile robot for action by the support personnel.

The object of the present invention is to provide a system and method for managing and sequencing action queues of mobile robots deployed at various locations.

It is a further object of the present invention to provide support personnel with a ranked list of mobile robots requiring action, so that the support personnel can quickly and easily determine which incident to address first.

An additional object of the present invention is to provide data mining capabilities so that events related to mobile robots and locations can be tracked for analysis and correction of the events.

Other objects, aspects, and advantages of the presently described systems and methods can be obtained from a study of the specification, drawings, and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The system and method of the present invention are described in more detail below by way of example and by way of exemplary embodiments shown in the various drawings included herein. In the drawings:

FIG1 is a schematic diagram of an exemplary system architecture including a mobile robot according to the system and method of the present invention;

2 is a schematic diagram of an exemplary system architecture including a fleet of mobile robots at multiple locations according to the systems and methods of the present invention;

FIG3 is an exemplary diagram of a mobile robot including multiple sensors for detecting obstacles;

FIG4 is a schematic diagram of an exemplary network architecture for use with the systems and methods of the present invention;

5-8 are exemplary screen shots of web pages generated by the system and method of the present invention in organizing and sequencing mobile robots operating at a number of facilities;

FIG9 is a heat map illustrating the frequency of navigation events experienced by a mobile robot;

FIG10 is a color or other coded chart for identifying specific problems experienced by a mobile robot;

Figure 11 shows a drop-down list for filtering Tug selections by firmware version, e.g., for use on a Tug;

FIG12 shows a drop-down list for filtering Tug selections by various parameters preset in the system of the present invention; and

FIG13 illustrates an exemplary computer system in which embodiments of the present disclosure may be implemented.

DETAILED DESCRIPTION

With numerous autonomous mobile robots deployed across numerous facilities or locations, remote monitoring, diagnostic, and tracking systems are necessary to enable support personnel at a central location, remote from the facilities, to effectively manage the operations of the autonomous mobile robots. As used herein, the terms "autonomous mobile robot," "mobile robot," "robot Tug," "robot," and "Tug" are used to refer to the same or similar devices. The systems and methods of the present invention utilize heuristic algorithms to analyze operational events encountered by a fleet of mobile robots traversing multiple facilities. Applying these algorithms, a central system identifies the most critical navigation events and quickly cycles these robots to the "top of the stack" for analysis and support by support personnel at remote locations. Each mobile robot is equipped with sensors that detect errors, status, navigation, and other data affecting the mobile robot. Software on each mobile robot monitors and reports key operational parameters and data to a central server located at each facility. Key operational parameters and data are monitored/acquired on each mobile robot and transmitted in real time to the central facility server. This technology allows for rapid analysis, display, and processing of real-time sensor data from each robot. Additionally, the system of the present invention may provide a visual display of operational events including, but not limited to, facility changes (configuration changes), frequency of robot sensor errors (heat maps), and a "top ten" list of site events for support personnel.

The system and method of the present invention includes a multi-user, web-based application that ranks and displays the operating parameters of each active robot. A central server at a remote location records and manages data from multiple sites and robots. The web-based application at the central server parses the information and displays it to remote support in a useful, ranked format. This information is displayed to support in a manner that enables quick and easy identification of those robots with the most severe navigation issues and their resolution first.

A key element of this functionality is the application of knowledge-based parameter ranking to optimize robot movement and identify critical navigation events. Additionally, graphical data mining tools assist remote support personnel by prioritizing and quickly identifying robot navigation events based on problem frequency displays. Frequency heatmap displays can be applied to highlight operational events, sensor readings, performance factors, and more.

Each facility where a mobile robot is located includes its own base server. Each base server runs a software module that receives operational parameter data from the mobile robots operating at the facility. This software module tracks and aggregates relevant information on each mobile robot. Key operational parameters are then reported to a remote central server via the base server.

Software and sensors located on each mobile robot monitor key operating parameters and report them to a base server at each facility. Each mobile robot or all mobile robots at a site can be tuned to provide the appropriate level of information and data for remote support personnel.

The system and method of the present invention applies a complex algorithm that tracks multiple data points in real time and ranks mobile robots with events in order of "navigation" severity. Navigation severity is attributed to, among other things, robot idle time (not moving) caused by facility problems such as, but not limited to: elevator delays, blocked paths (obstructions in hallways), and failed equipment (automatic doors not opening on command). Based on this information, support personnel at remote locations can assist with robot navigation, as well as notify facility personnel about their equipment events that affect the robots. In addition, the system and method of the present invention records all mobile robot and other activities in a decision support system for future product improvements. Finally, visual data mining tools can be applied to quickly identify patterns in changes in the mobile robot's behavior, thereby helping to identify and correct root cause events.

Many implementations of the system and method of the present invention can be configured without departing from the spirit and scope of the present invention. For example, no specific operating system is required, and the system/method of the present invention can run on any operating system that supports TCL, PHP, MySQL, etc. An implementation of the technology used to send data to the base server can be written using, for example, a combination of TCL and MySQL. The software parsing and displaying of data can be written using, for example, a combination of HTML, JavaScript, PHP, and MySQL. In one implementation, the software parsing and displaying data for help desk personnel only requires hardware capable of running a PHP-based web server. The base server (located at each facility where the autonomous mobile robot is deployed) can utilize hardware capable of running, for example, SSH, TCL, and MySQL clients. Of course, those skilled in the art will recognize that this technical architecture allows the system of the present invention to be easily ported to many equivalent technology platforms as needed. Furthermore, the system of the present invention utilizes various libraries and plug-ins such as jQuery, MySQL, TCL, and DataTables. However, these libraries/plug-ins are not essential, and any library/plug-in can be replaced with other technologies to achieve the same functionality.

According to the system and method of the present invention, the software typically exists in three locations. (1) On Aethon's network server (Helios) (i.e., the remote location central server). This is the software that parses the data and displays it to support personnel. (2) On each base server at each client or customer location. Each location has a base server that all Tugs communicate with and share details of their current situation. This is the software that aggregates status information and data back to the database at the central server. (3) On each mobile robot at the customer location. Each robot runs an algorithm to provide raw operational data to the base server, and thus directly to the central system. The data can be configured or "tuned" for various levels depending on the severity of the incident and the impact on the customer's operations.

Referring to Figures 1-2, a system for monitoring, diagnosing, and tracking autonomous mobile robots is generally shown at 100. System 100 includes a plurality of base servers 105 that receive data from one or more mobile robots 110. Each base server 105 is typically located at a different location and receives data from a fleet of mobile robots 110 deployed at that location. The data received by base server 105 includes error status bits and status information for each mobile robot 110 deployed at that location, which is monitored by sensors and software provided on the mobile robots 110.

The base server 105 includes a status module 115 that receives data from the mobile robots 110 and an Aethon elevator controller (EC) 160. The base server 105 also includes an elevator module 120, which receives data about the robot's location and queue status from the robot 110, and a tracking and locking module 125, which manages locks and lock queues. The EC 160 (typically one per bay) receives operational status information about the hospital's elevator rooms and reports this information to the status module 115 on the base server 105, including, for example, bay location/status and door location/status. The command center module 130 on the base server 105 receives data from the status module 115, the elevator module 120, and the tracking and locking module 125. The command center module 130 synchronizes data for site devices, sorts the data, and transmits the information to the database 140 on the service desk server 135.

The command center module 130 transmits the processed data to a remotely located central server 135. In one form, the data is synchronized and periodically sent to the central server 135 via a secure connection (e.g., a VPN (virtual private network) tunnel, etc.). The central server 135 receives data from the various base servers 105 located at various facilities and stores the received data in a database 140. The central server 135 includes a data analysis module 145 that applies a heuristic algorithm to the data from the database 140 to analyze operational events encountered by the mobile robots 110 at various locations. The data analysis module 145 applies different weights to the various operational parameters based on both the operational parameters and the status of the operational parameters, so as to rank the various navigation events experienced by the mobile robots 110 in order of severity. The various operating parameters analyzed by the data analysis module may include, but are not limited to, idle time, status, travel, communication status, whether an alarm has been issued (as described below), what the Tug is doing, where the Tug is during the Tug's work, what is blocking the Tug, what is generating idle time, etc., as well as other parameters related to the mobile robot, including at least those discussed below with respect to Figure 5.

The data analysis module 145 utilizes high-level business rules to process operational parameters and prioritize Tugs with events. Some of the business rules may be site-specific, Tug-specific, job-specific, and so on. Thus, business rules may vary not only between sites but also between Tugs. Some examples of business rules utilized by the data analysis module 145 to convert operational parameters into recovery priority settings include, but are not limited to:

Tug navigation path (based on hospital map).

Path attributes, such as speed, throughput, etc.

• Channel sensor settings - ie which sensors are active at any point.

Voice messages - e.g. travel, destination, elevator, etc.

Destination and lock point waiting times.

Location of locking points and workbench areas.

Elevator interactions - e.g., wait times, Tug delivery performance, elevator sequence, backup elevators, etc.

Minimum charging time (generally, charging is not considered “idle time”).

Scheduled Tug runs.

Prioritization/filtering of sites and Tugs (typically used for "startup" monitoring of new sites).

The data analysis module 145 determines the most critical navigation events and moves those mobile robots 110 experiencing these critical navigation events to the top of the list for action by the support personnel 150. The support personnel 150 can access the central server 135 using a PC or other computing and display tool using a web-based application via the World Wide Web 155. Alternatively, the central server 135 can be co-located with the support personnel 150. The central server 135 displays the information to the support personnel 150 in an arranged format so that the support personnel 150 can quickly and easily determine which mobile robots 110 are experiencing the most critical navigation events and address those events first.

In addition to processing and displaying navigation information, the data analysis module 145 also stores information in the database 140 about various events that each mobile robot 110 is experiencing. Support personnel 150 can use this stored information to generate maps and charts showing the frequency of problems that mobile robots 110 or locations are experiencing.

FIG3 illustrates an exemplary mobile robot 110 that can be used in accordance with the systems and methods of the present invention. The mobile robot 110 includes an additional exemplary cart 163. Of course, the mobile robot can be implemented with an integrated cart or storage area. FIG3 also illustrates an exemplary configuration of sensors that can be implemented to sense potential obstacles. For example, two sensors 165 can be positioned approximately 90 degrees to the direction of movement of the robot 110 and parallel to the ground. These "side" sensors 165 determine the distance to a wall or other object. Two sensors 170 can be pointed almost perpendicularly toward the exterior of the robot 110 and can be used to detect objects that may be hanging from a ceiling or protruding from a wall. Multiple rows of forward-facing sensors 175 can be provided to detect obstacles generally in front of the robot 110. The sensors 175 can be grouped into a series of planar rows positioned at various angles relative to the ground and, if desired, intersecting with one another. The number and number of sensor rows should be configured to minimize the number of potential obstacles that could potentially lie between the sensor beams and thus remain undetected.

Depending on the specific application and/or deployment location, the mobile robot 110 may include one or more specially placed sensors to detect unique obstacles that may be encountered. In addition, one or more rear-facing sensors may be provided on the robot 110 or the cart 163 as needed. The sensors may be any type of sensor capable of detecting obstacles, and the sensors may include infrared sensors, ultrasonic sensors (such as sonar), etc. Those skilled in the art will appreciate that virtually any configuration and positioning of the sensors may be implemented without departing from the spirit and scope of the present invention.

The mobile robot 110 includes a built-in computer (not shown) loaded with robot operating system software. This software uses a detailed map of the hospital and sophisticated navigation and operating software to plan the mobile robot's route, avoid obstacles, track its position, and provide raw operating data to the base server 105 through the use of sensors and other devices.

FIG4 shows an exemplary network diagram for an implementation of the systems and methods of the present invention. The main communication hub of the network is the existing hospital (or other location) network 180. This can be a wired or wireless Ethernet connection, but those skilled in the art will appreciate that many alternatives can be used that are all within the spirit and scope of the present invention. Connected to the hospital network 180 are a docking station 185 and a base computer 190. The mobile robot 110 typically uses rechargeable batteries, and the docking station 185 is used to charge these batteries. An elevator control 195 is provided that is operably attached to the hospital robot at one end for communication with the mobile robot 110, and is operably attached to the elevator control panel at the other end for controlling the elevator when requested by the mobile robot 110.

The base server 105 is connected to the hospital network 180 via a wired or wireless connection. The base server 105 receives raw operational data from the mobile robots 110. The base server 105 processes the data and transmits it to the remote central server 135. As previously described, the central server 135 processes the data using complex algorithms and displays the information to the support personnel 150 in an organized format, allowing the support personnel 150 to efficiently determine which mobile robots 110 are experiencing the most severe navigation events so that those events can be addressed first.

FIG5 shows a screen shot of an embodiment of a web application on a central server 135 for organizing and prioritizing active autonomous mobile robots 110 at a number of facilities. As shown in FIG5 , the mobile robots 110 deployed at various locations are organized in a list that ranks the mobile robots 110 by the severity of the navigation. In addition to presenting the robots 110 in a list format, various information can be formatted, such as color coding based on the severity of the incidents encountered. Thus, in addition to listing the mobile robots 110 from top to bottom, the color coding (or other formatting) provides an additional indication of navigation severity that support personnel can use to prioritize which robot 110 to address first.

Various operational parameters are displayed for each active robot 110. For example, at 200, a mobile robot is identified by Tug number and location. The identifier "Tug-120-1" represents Tug #1 at location "120," while the identifier "Tug-116-4" represents Tug #4 at location "116." At 205, the status of each Tug is provided. This status tells support personnel what the Tug is doing. For example, the Tug may be charging, waiting, blocked, navigating, etc. At 210, the battery charge status is provided, which tells support personnel how much battery life is remaining. At 215, the amount of time that has elapsed since the Tug began its most recent work or operation is indicated. At 220, the amount of time the Tug has been idle (not moving) is provided. This is generally an important parameter, as an idle Tug is the first sign that the Tug may be experiencing a navigation event. At 225, the Tug's itinerary is provided. The itinerary indicates a list of one or more locations that the Tug is presumed to be traveling to. A check mark or other identifier next to a location means the Tug has completed that run and reached its destination. For example, the Tug "Tug-98-3" near the center lists "Traumal" and "WW5S" as its two destinations. Support personnel can tell the Tug has arrived at the destination "Traumal" because of the check mark next to it, and that the Tug is currently en route to "WW5S." At 230, the Tug's lock status is indicated. The lock status tells support personnel whether the Tug is waiting at a lock or holding point. Hospitals and other facilities have various locks in various locations. For example, a specific corridor may only accommodate one Tug at a time. This corridor may have a lock at either end. When a Tug arrives at this corridor, if another Tug is navigating through it, it will wait at the lock. Once the corridor is clear, the Tug will proceed along the corridor, while the other Tug will be forced to wait at the lock until the corridor is clear. As another example, a lock may be located outside an elevator, where the Tug will wait for the elevator. At 235, the amount of time that has elapsed since the Tug last communicated with the base is provided. This is an important parameter, as all Tugs should always be communicating with the base system. If a Tug loses communication with the system, it is necessary to determine when, where, and why the communication was lost. At 240, the number of outstanding service tickets is provided. This informs support personnel that certain actions have been taken to correct the problem associated with a particular Tug. Service Ticket 240 informs support personnel that the Tug has been escalated to the service team and that there are pending service tickets for which service personnel have been dispatched to review the Tug. At 245, the column titled "Last Week" displays the number of restores performed by support personnel in the area where the Tug is currently experiencing problems over the past week. "Area" refers to the X-Y-Z coordinate location on the ground plan of the location where the Tug is deployed. For example, the area could be a 10' x 10' location on the ground plan of the location. However, the physical area can be larger or smaller depending on the specific application and/or location. "Last Week" data is useful for support personnel because they can see that other Tugs are also experiencing problems in the area where the current Tug is experiencing problems. Information about problems that other Tugs in the same area have had can be useful in finding both short-term and long-term solutions. At 250, clicking the "C" button allows a support staff member to request that a specific Tug continue working. This helps avoid duplication of work. At 255, the support staff can hide a Tug from the list, knowing that the Tug will not require action for a period of time, even though the Tug may be idle. Typically, a Tug must be associated with a service ticket in order for the Tug to be hidden. The reason for hiding is listed on the service ticket. For example, the reason could be "Contact the department regarding restart" or "Check to see if the elevator is working," etc. The hiding feature has a timer built into it. After a period of time, the Tug will reappear on the screen to alert the support staff that action is needed. It will be understood by those skilled in the art that the parameters identified above are merely exemplary and that other parameters can be displayed and analyzed in the arrangement of Tugs without departing from the spirit and scope of the present invention.

As previously discussed, the information provided can be color-coded or shaded, or otherwise include visual distinctions, to assist support personnel in identifying critical events. The color or visual coding will depend on the particular state of the Tug. For example, as shown in FIG10 , various different colors and/or shading and/or other visual distinctions can be implemented when listing Tugs to identify various critical events. As shown in FIG10 , the color description column 500 includes various visual distinctions when listing Tugs that indicate the particular state of the Tug, as shown in the question column 505 immediately to the right. The chart of FIG10 is merely exemplary, and more or less colors, shading, and/or visual distinctions/coding can be implemented depending on the application and/or location.

For example, if a Tug is at a locker waiting for an elevator or hallway to clear, rules can be set to provide a reasonable amount of time the Tug might have to wait at a specific locker. Similarly, if the Tug is at a destination, rules can be set to provide a reasonable amount of time the Tug might have to wait at a specific destination. The reasonable amount of time can be different at each location/destination. Rules can take into account the settings of a specific Tug at a specific location or destination so that color or other coding can be applied.

In some embodiments, the idle time of Tug can be colored or coded to identify the idle time that exceeds usual waiting. After 15 minutes, the idle time can be coded to different colors, shadows etc., to identify potential critical events. This color or other codings can continue to indicate the waiting severity according to the time increment. Of course, according to the combination of parameter or parameter, other parameters shown in Figure 5 also can be colored or coded in addition.

The system and method of the present invention weights each parameter differently based on all parameters associated with a particular Tug, its status, and other parameters and their status. Business rules are utilized, including what the Tug is doing, where the Tug is in its work, what is blocking the Tug, what is causing idle time, and various conditions that create the sorted list shown in Figure 5, along with other parameters. Colors are associated with various parameters to not only indicate priority on the list, but also to identify relevant areas where problems may occur.

For example, Tug "Tug-120-1" appears first on the list in Figure 5. It shows that this Tug is charging on the second floor (205), started its most recent work approximately 41 minutes ago (215), has been idle for more than 15 hours (220), has no trips (225), has lost communication for more than 19 hours (235), and has 1 service ticket (240). In addition, another Tug has experienced a problem in the area where Tug-120-1 is currently experiencing the problem, as shown by the 1 in the last week column (245). The work starts and idle time data are meaningless, and because this Tug has been out of communication for almost 20 hours, all other data is suspect. Based on this combination of factors, Tug "Tug-120-1" is placed at the top of the list. The other Tugs in the list are similarly ranked based on a combination of various parameters. Therefore, support personnel do not need to figure out which Tug should be addressed first.

Additionally, the list of Tugs to be checked can be filtered by site # (e.g., "All Sites"), software version (e.g., "All MNZ Versions"), firmware version, such as on a robot (e.g., "All PROMs"), and any newly implemented code modules (e.g., "All Parameters"). These filters are useful tools for both support personnel and developers to check events for an entire fleet of Tugs or to monitor newly developed functionality. For example, clicking button 510 on FIG5 can display a drop-down list of firmware versions currently running on the Tugs, as shown in FIG11. The user can check some or all of the currently running firmware versions to be displayed on the example screen of FIG5. Similarly, clicking button 515 on FIG5 can display a drop-down list of various parameters identified for monitoring, as shown in FIG12. The user can check some or all of the parameters to be displayed on the example screen of FIG5. Similarly, clicking button 520 on FIG5 can display a drop-down list of various sites with running Tugs (not shown). The user can check some or all of the sites to be displayed on the example screen of FIG5. By checking various combinations of sites, PROM versions, and parameters, support personnel can implement various filtering options and check box functions.

FIG6 shows a screen image of a remote support person 150 providing additional support data. By clicking the "+" symbol next to a Tug identifier 200, the support person is provided with additional information about the Tug, including the Tug's navigational status, hardware attributes, and facility information, which assists the support person in resolving any incidents the Tug may have. For example, Tug "Tug-107-5" is identified as idle and has not communicated for over two hours, which may be grounds for visiting the Tug. The table displayed at 300 provides the support person with various operating parameters for the Tug. "MM" informs the support person whether the Tug is in maintenance mode, meaning it is being serviced by a service person. In maintenance mode, the Tug cannot be removed. "0" indicates "no," while "1" indicates "yes." As an example, the Tug identifiers 200 for Tugs "Tug-86-1" and "Tug-86-2" are shaded, indicating to the support person that these Tugs are in maintenance mode. Therefore, although they are at the top of the list, the support person knows they are being serviced and can move on to the next Tug.

In table 300, "Charging" indicates whether the Tug is charging. The "Floor" and "Map" parameters indicate which floor and part of the floor the Tug is on. "MNZ Version" indicates the software version running on the Tug, while "Push Status" indicates the status of the Tug's processing software. "Error Status" and "Alarm Status" are associated and provide an indication of software errors. "Obstacle Status" indicates whether the Tug has detected any obstacles. "Route Mode" indicates the Tug's driving mode. For example, the Tug can be in a yaw driving mode, where the Tug can maneuver around obstacles, or in a non-yaw driving mode, where the Tug cannot maneuver around obstacles. "Waiting Status" indicates whether the Tug is waiting at a lock. "Hooking Status" indicates whether a cart is attached to the Tug. "Last HB Update" indicates when the most recent communication with base occurred. Thus, by looking at Figure 6, support personnel can determine that Tug "Tug-107-5" is scheduled to travel to the "3MotherBaby" location and has been idle for over two hours, but communicated with base seven seconds ago. This indicates that the system is operating normally, but the Tug has a problem.

Table 305 in FIG6 provides information about the elevator a Tug is currently using. Table 305 is typically colored or otherwise coded to indicate the Tug's position in the elevator process. Table 305 informs support personnel that Tug "Tug-107-5" was presumed to be traveling from floor 1 to floor 3 and that the Tug exited the elevator at floor 3. This provides support personnel with a clue as to where the Tug was when last heard from. Table 305 further indicates that elevator "EC-107-2" is on the first floor.

Table 310 provides alert information when an alert occurs. An alert is generated by a Tug when it experiences a problem. An alert summarizes the overall status of the Tug and may provide an indication of what the Tug believes is wrong. An alert informs support personnel that there is additional information that has been generated by the Tug to be reviewed that may be helpful in resolving the problem that the Tug is experiencing. Support personnel would click on the alert link provided in the table to view information related to the alert. Similarly, Table 315 provides service information when a service ticket is opened. Support personnel would click on the service ticket link provided in the table to view information related to the alert. As shown in Table 315, Tug "Tug-107-5" has no alerts or open service tickets.

FIG7 shows a diagram of the system of the present invention linked to a customer support database that allows incidents to be recorded in support tickets. This screen can be accessed by clicking the Service Ticket link in table 315 (see FIG6 ). The screenshot of FIG7 provides support personnel with information about open service tickets. Box 350 identifies the ticket number, who opened the service ticket, the date the service ticket was opened, and the date the service ticket was updated. Box 355 identifies the site location, device type, and device number of the Tug in service. Box 360 identifies the type of service being performed and the current status of the service. Box 365 and the boxes below it provide support personnel with further information about a particular service ticket. Box 370 provides a description of the problem being experienced by the Tug. Box 375 is the Resolution box for support personnel to enter entries. Each time an update is made, the support personnel will enter a new entry describing the update. Clicking the "Submit" button adds the entry to the list of entries below Resolution box 375, generally in order of most recent at the top.

Additional information can be provided to support personnel by clicking on the various icons shown in FIG7 . For example, clicking on the icon shown at 380 will display any other open tickets at a particular site. There may be other Tugs with problems, other devices such as elevators may have open tickets, or there may be some issues at the base. Clicking on icon 380 will provide support personnel with additional information about possible issues at a particular location. Clicking on the icon shown at 385 will display a broken-down window listing any status changes and the reasons for the change. This again provides support personnel with additional information about what is happening in a particular situation. All of this information is designed to assist support personnel in resolving issues.

Existing site information can also be displayed to assist support personnel, as shown in Figure 8. This screen can be accessed by clicking on the device name in Figure 5. For example, this particular screen might be accessed by clicking on the device name "Tug-107-5" in the window behind it. Clicking on this link will bring up all the information about location 107. At 400, the site name and address will be provided. Table 405 has various labels. The "Help Desk" label displayed identifies who the help desk (i.e., support personnel) is expected to call if they need assistance handling an incident. Clicking on the "Site" label will provide a list of people at the site who are expected to be contacted for each incident. Clicking on the "Aethon" label will provide a list of Aethon support personnel for a particular site.

Table 410 provides various information for each Tug at a particular site. "Tug" provides the Tug identification number. "Application" identifies the specific application of the Tug. "Location" identifies the location of the charging dock for the Tug. "Cart Type" identifies whether the Tug is towing a cart. "CC Type" refers to the type of processor used by the Tug's computer. "Network" identifies the type of network used. "Laser" identifies the presence or absence of a laser sensor. The remaining columns identify the inventory quantities for the Tug, as well as the various components and equipment associated with the Tug. The "Site Spares" row below the columns is for the service department and identifies the hardware and equipment available at the site that can be used as replacement parts for the Tug.

Below table 410 is another table that provides information about the elevators at a specific station. As the support staff scrolls down, they can view more information about the specific station.

Figure 9 shows an example of data mining functionality using a "heat map" tool to display robot navigation events at a facility. Figure 9 represents the fifth floor of a particular facility. As shown in Figure 9, the particular Tug traveled between destinations "5W" and "5E" along the route shown at 425. As shown in Figure 9, the Tug also accessed the elevator to travel to different floors. As shown in the heat map image, the Tug had a specific event in the elevator lobby on that particular floor, generally shown at 430. Aethon support personnel can use this information to take action to correct the event. They can contact the customer and request on-site assistance to help correct the event. Alternatively, the support personnel can work with the user to make mapping changes to the robot's instructions so that the robot can travel through other corridors to avoid future problems.

Those skilled in the art will appreciate that while the presently described systems and methods have been described herein as including a base server 105 located at each facility where multiple fleets of mobile robots are deployed, the base server 105 may be omitted without departing from the spirit and scope of the present invention. In such an embodiment, the functionality associated with the base server 105 would be included in the central server 135. The mobile robots 110 located at each facility transmit raw service data directly to the central server 135 using known or conventional methods and techniques, and the central server 135 processes the data as previously described to prioritize the mobile robots for action by support personnel.

It should be understood that one or more exemplary embodiments of the present invention can be implemented in hardware and/or software. Software includes, but is not limited to, firmware, resident software, microcode, etc., which have been compiled to program a general-purpose computer into a special-purpose computer, or to run a special-purpose computer. The storage device can be implemented as an electrical, magnetic, or optical memory, or any combination of these or other types of storage devices (including the storage portion of the card as described above). It should be noted that if a distributed processor is used, each distributed processor that constitutes the processor that performs the function or step typically contains its own addressable storage space. It should also be noted that some or all of the computer systems and servers can be incorporated into a dedicated or general-purpose integrated circuit. For example, one or more method steps can be implemented in hardware in an ASIC without applying firmware. The display used in conjunction with each entity, server, and processor represents a variety of possible input/output devices.

Thus, it should be understood that one or more embodiments of the present disclosure may include a computer program comprising computer program code means adapted to perform one or all steps of any method or claim described herein when the program is run on a computer, and it should be understood that the program may be embodied on a computer-readable medium. Furthermore, one or more embodiments of the present disclosure may include a computer comprising code adapted to cause the computer, together with one or more device elements and features as illustrated and described herein, to perform one or more steps of the method or claim described herein.

As is well known in the art, and as described with respect to FIG. 13 , all or part of one or more aspects of the methods and apparatuses discussed herein may be distributed as an article of manufacture that itself includes a computer-readable medium having computer-readable code means embodied thereon. In conjunction with a computer system, the computer-readable program code means may be operable to perform all or part of the steps to perform the methods or construct the apparatuses discussed herein. The computer-readable medium may be a recordable medium, such as a floppy disk, a hard disk, an optical disk, an EEPROM, a memory card, or the like. Any tangible medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means may be any mechanism for enabling a computer to read instructions and data, such as, for example, a magnetic change on a magnetic medium or a change in optical properties on the surface of an optical disk. The computer-readable medium may be distributed across multiple physical devices (or across multiple networks). For example, one device may be a physical storage medium associated with a terminal, while another device may be a physical storage medium associated with a processing center.

The computer systems and servers described herein each include memory that configures the associated processor to implement the methods, steps, and functions disclosed herein. The memory may be distributed or local, and the processor may be distributed or single. The memory may be implemented as electrical, magnetic, or optical memory, or any combination of these or other types of storage devices. Furthermore, the term "memory" should be understood to be broad enough to encompass any information that can be read or written at an address in the addressable space accessible by the associated processor.

Although exemplary embodiments are described herein in terms of methods or systems/apparatus, it should be appreciated that the exemplary embodiments may be implemented by a microprocessor of a computer, such as, for example, the computer system 1300 shown in FIG13. In various embodiments, one or more functions of various components may be implemented in software that controls a computing device, such as the computer system 1300 described below with reference to FIG13. The processor of the computer system 1300 is configured to execute software recorded on a non-transitory computer-readable recording medium, such as, for example, a hard drive, ROM, flash memory, optical memory, or any other type of non-volatile memory.

The aspects of the present disclosure shown in Figures 1-12 or any portion or functionality thereof can be implemented using, for example, hardware, software modules, firmware, tangible computer-readable media storing instructions, or a combination thereof, and can be implemented in one or more computer systems or other processing systems. Figure 13 shows an exemplary computer system 1300 in which embodiments of the present disclosure or portions thereof can be implemented as computer-readable code. For example, the systems and methods of the present invention can be implemented in a computer system 1300 that uses hardware, software, firmware, a non-transitory computer-readable medium storing instructions, or a combination thereof, and can be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof can present any modules and components for implementing the systems, methods, and architectures of Figures 1-12.

If programmable logic is used, the logic can be executed on a commercial processing platform or a dedicated device. It should be appreciated by those skilled in the art that embodiments of the disclosed subject matter can be implemented using a variety of computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, computers that link or aggregate distributed functions, and general-purpose or microcomputers that can be embedded in almost any device. For example, at least one processor device and memory can be used to implement the above embodiments. The processor device can be a single processor, multiple processors, or a combination thereof. The processor device can have one or more processor "cores," as the term is commonly understood.

Various embodiments of the present disclosure are described with reference to the exemplary computer system 1300 shown in FIG13 . After reading this specification, it will become apparent to those skilled in the relevant art how to implement the present disclosure using other computer systems and/or computer architectures. Although operations may be described as sequential processes, some operations may in fact be performed simultaneously in parallel and/or in a distributed environment, and may be performed using program code stored locally or remotely and accessed by a single or multi-processor machine. Furthermore, in certain embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

Computer system 1300 includes a display 1330 that can be operated by a user through conventional means, which is connected to a communication infrastructure 1306 via a display interface 1302 and controlled by a processor device 1304. Processor device 1304 can be a dedicated or general-purpose processor device. Those skilled in the relevant art will appreciate that processor device 1304 can also be a single processor in a multi-core/multi-processor system (the system operates alone), or a single processor in a cluster of computing devices operating in a cluster or server farm. Processor device 1304 is connected to a communication infrastructure 1306, which can be, for example, a bus, a message queue, a network, or a multi-core message passing mechanism.

The computer system 1300 also includes a main memory 1308, such as random access memory (RAM), and a secondary memory 1310. The secondary memory 1310 may include, for example, a hard disk drive 1312, a removable storage drive 1314, etc. The removable storage drive 1314 may include, for example, a floppy disk drive, a tape drive, an optical disk drive, a flash memory, etc.

The removable storage drive 1314 reads from and/or writes to a removable storage unit 1318 in a well-known manner. The removable storage unit 1318 may include, for example, a floppy disk, a magnetic tape, an optical disk, etc., which is read by and written to by the removable storage drive 1314. Those skilled in the relevant art will appreciate that the removable storage unit 1318 comprises a non-transitory computer-usable storage medium having stored thereon computer software and/or data.

In alternative implementations, the secondary memory 1310 may include other similar means for allowing computer programs or other instructions to be loaded into the computer system 400. Such means may include, for example, an interface 1320 and a removable storage unit 1322 connected to the interface 1320. Examples of such means may include, for example, a program cartridge and cartridge interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and an associated socket, and other removable storage units 1322 and interfaces 1320 that allow software and data to be transferred from the removable storage unit 1322 to the computer system 1300. The computer system 1300 may also include a communications interface 1324.

The communication interface 1324 allows software and data to be transferred between the computer system 1300 and external devices. The communication interface 1324 may include, for example, a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transferred through the communication interface 1324 may be in the form of signals. The signals may be electronic, electromagnetic, optical, or other signals capable of being received by the communication interface 1324. These signals may be provided to the communication interface 1324 via the internal connection 1328 and the communication path 1326. The communication path 1326 carries the signals and may be implemented using wires or cables, optical fibers, telephone lines, mobile phone links, radio frequency links, or other communication channels.

In this application, the terms "computer program medium," "non-transitory computer-readable medium," and "computer-usable medium" are generally used to refer to media, such as removable storage unit 1318, removable storage unit 1322, and the hard disk installed in hard disk drive 1312. Signals carried by communication path 1326 may also embody the logic described herein. "Computer program medium" and "computer-usable medium" may also refer to memory, such as main memory 1308 and secondary memory 1310, which may be semiconductor memories (e.g., DRAM, etc.). These computer program products are tools for providing software to computer system 1300.

Computer programs (also referred to as computer control logic) are stored in main memory 1308 and/or secondary memory 1310. The computer program may also be received via communication interface 1324. When executed, the computer program enables computer system 1300 to implement the present disclosure discussed herein. In particular, when executed, the computer program enables processor device 1304 to implement the processes of the present disclosure. Thus, the computer program represents the controller of computer system 1300. When software is used to implement the present disclosure, the software may be stored in a computer program product and loaded into computer system 1300 using removable storage drive 1314, interface 1320, hard disk drive 1312, or communication interface 1324. Embodiments of the present disclosure may also be directed to computer program products comprising software stored on any computer-usable medium. When the software is executed in one or more data processing devices, the software causes the data processing devices to operate as described herein. Embodiments of the present disclosure may employ any computer-usable or readable medium. Examples of computer-usable media include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard disks, floppy disks, CDROMs, compact disks, magnetic tapes, magnetic and optical storage devices, MEMS, nanotechnology storage devices, etc.), and communication media (e.g., wired and wireless communication networks, local area networks, wide area networks, intranets, etc.).

Therefore, it should be understood by those skilled in the art that one or more embodiments of the present invention may include a computer program including computer program code means adapted to perform one or all steps of any method or claim described herein when the program is run on a computer, and that the program may be embodied on a computer-readable medium. In addition, one or more embodiments of the present invention may include a computer including code adapted to cause the computer to perform one or more steps of the method or claim described herein together with one or more device elements and features as illustrated and described herein.

It should be understood that the detailed description section, and not just the summary and abstract sections, is intended to be used to interpret the claims. As intended by the inventors, the summary and abstract sections may set forth one or more (but not all) exemplary embodiments of the present disclosure, and therefore, the summary and abstract sections are not intended to limit the present disclosure and the appended claims in any way. The embodiments of the present disclosure have been described above with the aid of functional architectural blocks that illustrate the implementation of specific functions and their relationships. For ease of description, the boundaries of these functional architectural blocks have been arbitrarily defined herein. Alternative boundaries may be defined as long as the specific functions and their relationships are properly performed.

The above description of specific embodiments will therefore fully reveal the general nature of the present disclosure, and others can easily modify and/or adapt various applications of these specific embodiments by applying techniques within the art without undue experimentation and without departing from the general concepts of the present disclosure. Therefore, based on the teachings and guidance provided herein, these adjustments and modifications are intended to be within the intention and scope of the equivalents of the embodiments discussed. It should be understood that the grammar or terminology used herein is intended to be descriptive and not limiting, and thus the terminology or grammar of this specification is to be interpreted by those skilled in the art based on the teachings and guidance.

The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Although the present invention is described herein with particular reference to the accompanying drawings, it will be appreciated that various modifications may be made without departing from the spirit and scope of the present invention. Those skilled in the art will appreciate that various other modifications and variations may be developed based on the overall teachings of this disclosure. The presently preferred embodiments described herein are merely illustrative and do not limit the scope of the present invention, which is to be understood as being within the full scope of the appended claims and all their equivalents.

Claims (26)

1. A system for managing and sequencing a convoy of autonomous mobile vehicles deployed at various locations, the system comprising: Multiple base servers, each corresponding to a different location, wherein each base server receives operational parameter data from multiple autonomous mobile vehicles operating at a specific location; and A central server receives the operational parameter data from multiple base servers. The central server includes a data analysis module that processes the operational parameter data and uses a set of business rules to sort the autonomous mobile vehicles operating at various locations based on the operational parameter data of each autonomous mobile vehicle to obtain a sorted list. The sorted list is then provided to a display associated with the data analysis module. The operational parameter data includes information related to operational and/or navigation events experienced by the autonomous mobile vehicle; and The sorting of autonomous mobile vehicles includes sorting each autonomous mobile vehicle based on the severity of the operating and/or navigation events experienced by each autonomous mobile vehicle, as contained in the operating parameter data related to the operating and/or navigation events experienced by each autonomous mobile vehicle. 2. The system of claim 1, wherein the information relating to navigation events includes information relating to the idle time of autonomous moving vehicles caused by elevator delays, blocked paths, and/or malfunctioning equipment. 3. The system according to claim 1, wherein the central server receives the operating status information of the elevator room. 4. The system according to claim 3, wherein the elevator room's operating status information includes at least one of room location, room status, door location, and door status. 5. The system of claim 1, wherein the data analysis module generates the list, the list sorting the autonomous mobile vehicles based on the operating parameter data, and arranging the autonomous mobile vehicles in order of importance for support personnel to carry out actions. 6. The system of claim 5, wherein the list generated by the data analysis module is accessible via a web-based application, and wherein the list includes links to other information relating to the autonomous mobile vehicle and the location of the autonomous mobile vehicle. 7. The system of claim 5, wherein the list generated by the data analysis module includes operational information related to the autonomous mobile vehicle, wherein the operational information includes at least one of the following: the autonomous mobile vehicle's idle time, the autonomous mobile vehicle's status, the autonomous mobile vehicle's trip, the autonomous mobile vehicle's communication status, whether an alarm has been issued, the autonomous mobile vehicle's task, the location of the autonomous mobile vehicle in its task, the reason for the autonomous mobile vehicle's delay, and the reason for the autonomous mobile vehicle's idle time, and wherein the operational information is encoded to identify potential critical events. 8. The system of claim 5, wherein data relating to autonomous mobile vehicles appearing in the list generated by the data analysis module can be hidden for a predetermined period of time, after which the data relating to the autonomous mobile vehicles will reappear in the list. 9. The system of claim 1, wherein the data analysis module stores information in a database relating to operational and/or navigation events experienced by the autonomous mobile vehicle. 10. The system of claim 9, wherein the data analysis module generates maps and charts using stored information relating to operational and/or navigation events experienced by the autonomous mobile vehicle, the maps and charts showing the frequency of problems experienced by the autonomous mobile vehicle or location. 11. A method for managing and sorting the action queues of autonomous mobile vehicles deployed at various locations, the method comprising the following steps: At a base server deployed in a specific location, operational parameter data is received from multiple autonomous mobile vehicles operating at that specific location; At the central server, operational parameter data of autonomous mobile vehicles are received from multiple base servers, each deployed in a different location. The data analysis module at the central server analyzes the operating parameter data of the autonomous mobile vehicle. The data analysis module uses business rule groups to process the operating parameter data of autonomous mobile vehicles; and The data analysis module at the central server sorts the autonomous mobile vehicles operating at various locations based on the operating parameter data and the business rule group. The operational parameter data includes information related to operational and/or navigation events experienced by each autonomous mobile vehicle; The data analysis module sorts the autonomous mobile vehicles operating at various locations by: sorting each autonomous mobile vehicle based on the severity of the operating and/or navigation events experienced by each autonomous mobile vehicle, as contained in the operating parameter data related to the operating and/or navigation events experienced by each autonomous mobile vehicle. 12. The method of claim 11, further comprising the step of displaying a sorted list via a display associated with the data analysis module, wherein the sorted list arranges the autonomous mobile vehicles in order of severity for support personnel to act upon. 13. The method of claim 12, wherein the sorted list is accessible via a web-based application, and wherein the sorted list includes links to other information relating to the autonomous mobile vehicle and the location where the autonomous mobile vehicle is operating. 14. The method of claim 12, wherein the sorted list includes operational information about the autonomous mobile vehicle, and wherein the operational information is encoded to identify potential critical events. 15. The method of claim 12, wherein data relating to autonomous mobile vehicles appearing in the sorting list can be hidden for a predetermined time period, after which the data relating to the autonomous mobile vehicles will reappear in the sorting list. 16. The method of claim 11, further comprising the step of storing information relating to operational and/or navigation events experienced by the autonomous mobile vehicle in a database via the data analysis module. 17. The method of claim 16, further comprising the steps of analyzing stored information relating to operational and/or navigation events experienced by the autonomous mobile vehicle, and generating maps and/or charts showing the frequency of problems experienced by the autonomous mobile vehicle or location. 18. The method of claim 11, wherein the information relating to navigation events includes information relating to idle time caused by elevator delays, blocked paths, and/or malfunctioning equipment. 19. The method of claim 11, wherein the set of business rules includes information relating to at least one of the following: autonomous vehicle navigation path, autonomous vehicle path attributes, autonomous vehicle path sensor settings, autonomous vehicle audio messages, autonomous vehicle destination waiting time, autonomous vehicle lock point waiting time, autonomous vehicle lock point location, autonomous vehicle workbench area location, autonomous vehicle elevator interaction, autonomous vehicle minimum charging time, and scheduled autonomous vehicle operation. 20. The method of claim 11, further comprising receiving elevator room operation status information at the central server. 21. A system for managing and sequencing a convoy of autonomous mobile vehicles deployed at various locations, the system comprising: A central server receives operational parameter data from multiple autonomous mobile vehicles operating at at least one location, the operational parameter data representing operational and/or navigation events experienced by the autonomous mobile vehicles, wherein the central server includes a data analysis module that processes the operational parameter data and sorts the autonomous mobile vehicles based on the operational parameter data. The operational parameter data includes information related to operational and/or navigation events experienced by the autonomous mobile vehicle; and The sorting of autonomous mobile vehicles includes: sorting each autonomous mobile vehicle based on the severity of the operating and/or navigation events experienced by each autonomous mobile vehicle, as contained in the operating parameter data related to the operating and/or navigation events experienced by each autonomous mobile vehicle. 22. The system of claim 21, wherein the data analysis module generates a list that sorts autonomous mobile vehicles based on the operating parameter data and arranges the autonomous mobile vehicles in order of severity for support personnel to take action. 23. The system of claim 22, wherein the list generated by the data analysis module is accessible via a web-based application, and wherein the list includes links to other information relating to the autonomous mobile vehicle and the location of the autonomous mobile vehicle. 24. A method for managing and sorting a queue of autonomous mobile vehicles deployed at various locations, the method comprising the following steps: At a central server, operational parameter data is received from multiple autonomous mobile vehicles operating at at least one location, the operational parameter data representing operational and/or navigation events experienced by the autonomous mobile vehicles. The data analysis module at the central server analyzes the operating parameter data of the autonomous mobile vehicle; The data analysis module uses business rule groups to process the operating parameter data of autonomous mobile vehicles; and The autonomous mobile vehicles are sorted based on the operating parameter data and the business rule group by the data analysis module at the central server, and The operational parameter data includes information related to operational and/or navigation events experienced by the autonomous mobile vehicle, and The data analysis module sorts the autonomous mobile vehicles operating at various locations by: sorting each autonomous mobile vehicle based on the severity of the operating and/or navigation events experienced by each autonomous mobile vehicle, as contained in the operating parameter data related to the operating and/or navigation events experienced by each autonomous mobile vehicle. 25. The method of claim 24, further comprising the step of displaying a sorting list via a display associated with the data analysis module, the sorting list arranging the autonomous mobile vehicles in order of severity based on the operational parameter data for support personnel to take action. 26. The method of claim 25, wherein the sorted list is accessible via a web-based application, and wherein the sorted list includes links to other information relating to the autonomous mobile vehicle and the location where the autonomous mobile vehicle is operating.