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

Description

Monitoring, diagnostic 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/537730, filed on 9/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 ranking and display of operating parameters of autonomous mobile robots for analysis and support by remote personnel.

Background

In recent years, autonomous mobile robots and software for controlling the autonomous mobile robots have been steadily developed in both complexity and function. Robotic and automated vehicles for delivering or transporting materials indoors (as well as outdoors) have been developed and used in many applications. For example, autonomous mobile robots for towing carts or carts have been developed, which are useful in industrial environments such as hospitals and the like. In fact, the cart or wagon may include any items needed for delivery or retrieval. For example, in a hospital environment, such items may include, but are not limited to, laboratory work/results, blood, patient files, medications, Emergency Room (ER) materials/equipment, supplies, food, and the like. Further, the cart or cargo conveyance area may be integrated with the autonomous mobile robotic vehicle.

Such autonomous mobile robots are designed to be able to navigate alongside a person in real world situations, even when facing complex and varied environments. For example, U.S. patent nos. 7,100,725, 7,431,115, and 7,894,939, which are owned by the owner of the present invention and are incorporated herein by reference in their entirety, describe exemplary autonomous mobile robotic vehicles that can be used 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 robotic systems are inherently stable, unpredictable situations necessarily arise that require human intervention to analyze and resolve. These conditions include robot idle time (e.g., not moving), etc., which may be caused by facility events such as, but not limited to: elevator delays, blocked paths (e.g., obstructions in hallways), and failed devices (e.g., automatic doors not opening on command). The support personnel are typically located at a central location remote from the location of the autonomous mobile robotic vehicle. Support personnel will typically monitor and be responsible for any number of autonomous mobile robotic fleets at different locations. In prior art systems, when an autonomous mobile robot encounters a navigation problem or an obstacle that it is unable to navigate around, an email is sent to a remote central support location reporting the problem. The support person would then receive and read the email, infer the problem, and then may control and navigate the autonomous mobile robot around the problem or, if necessary, contact the appropriate individual at the vehicle location that could resolve the problem. However, there are inherent problems with applying this prior art method.

During the time it takes for support personnel at the remote location to receive and read the email, the autonomous mobile robot may have handled itself bypassing the problem or obstacle and is continuing on its path. The support personnel will have no way of knowing this unless the autonomous mobile robot sends another email that will be received and read only after the support personnel has wasted time trying to solve the problem that is no longer present. Furthermore, the information contained in the email may be insufficient to support the problems encountered by personnel in finding autonomous mobile robots. This is simply because one cannot predict all the problems and obstacles that such a device may encounter. In addition, when multiple autonomous mobile robotic vehicles encounter navigation problems at or near the same time, support personnel must be able to quickly and accurately find out which problems are the most serious in order to resolve them first. Solving navigational problems with email reporting systems is typically done on a first come first served basis. In addition, it is desirable to monitor navigation problems encountered by different autonomous mobile robots at different locations, and to analyze these problems to determine whether certain areas of certain locations are subject to a large number of navigation events. Modification of these regions at this location can help reduce problems from continuing to occur.

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

Disclosure of Invention

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

The operational parameter data is representative of operational and navigational events experienced by the mobile robot. The data analysis module applies the service rule set to process the operation data and sequence the mobile robots. Typically, business rules are specific to the location and mobile robot.

In ranking mobile robots for action, the data analysis module generates a list that ranks the mobile robots and ranks 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 staff using a web-based application. The list includes links to other information about the mobile robot and the location where the mobile robot is operating, which may be used by support personnel to help identify the problem that the mobile robot is experiencing and correct the problem. The list generated by the data analysis module includes operational information about the mobile robot. In one form, the operational information is color coded to identify potential critical events.

As an additional feature, mobile robots appearing in the list generated by the data analysis module may be hidden for a predetermined period of time after which the mobile robots will reappear on the list. This is typically done while the support personnel wait for something to happen with respect to the mobile robot. To keep the list from cluttering, the support person may hide the particular content from view for a predetermined period of time.

As a further feature, the data analysis module stores information in a database relating to various events experienced by the mobile robot. The database may be mined by support personnel to generate maps and charts showing the frequency of problems being experienced by the mobile robot or location.

According to the present invention, there is also provided a method of managing and sequencing action queues of mobile robots deployed at various locations. The method generally comprises the steps of: receiving, at a base server deployed at a particular location, operating parameter data from a plurality of mobile robots operating at the particular location; receiving, at a central server, operating parameter data for the mobile robot from a plurality of base servers, each base server typically deployed at a different location; analyzing, by a data analysis module at the central server, operational parameter data of a mobile robot; and sequencing the mobile robots operated at the various positions through a data analysis module for action by support personnel.

The method further includes the step of displaying an ordered list to the support personnel by the data analysis module, the ordered list ordering the mobile robots in order of importance for the support personnel to act on. The ordered list may rank the mobile robots based on the severity of the operational and/or navigational events experienced. The ordered list may be accessible by the support personnel using a web-based application. In one form, the ordered list includes links to other information relating to the mobile robot and the location at which the mobile robot is operating. Further, the ordered list may include operation information on the mobile robot. To assist support personnel in identifying events and resolving events, the operational information may be color coded to identify potential key events.

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

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

The method of the invention further comprises the step of storing, by said data analysis module, information in a database relating to the various running and navigation events experienced by said mobile robot. The method of the invention may further comprise the step of analysing the stored information relating to the various operational and navigational events experienced by the mobile robot, and the step of generating a map and/or chart showing the frequency of problems experienced by the mobile robot or location.

In further embodiments, the base server may be omitted. The functions associated with the base server would be contained in a central server that would receive raw operational data directly from the mobile robots by known or conventional methods and techniques and process the data to sequence the mobile robots for action by support personnel.

The invention aims to provide a system and a method for managing and sequencing action queues of mobile robots deployed at various positions.

It is a further object of the present invention to provide support personnel with an ordered list of mobile robots that require action so that the support personnel can quickly and easily determine which event to resolve first.

An additional object of the present invention is to provide data mining capabilities to enable tracking of events related to mobile robots and locations 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, the drawings and the appended claims.

Drawings

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

FIG. 1 is a schematic diagram of an exemplary system architecture including a mobile robot in accordance with the present systems and methods;

FIG. 2 is a schematic diagram of an exemplary system architecture including a fleet of mobile robots at multiple locations in accordance with the systems and methods of the present invention;

FIG. 3 is an exemplary view of a mobile robot including a plurality of sensors for detecting obstacles;

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

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

FIG. 9 is a heat map showing the frequency of navigation events experienced by a mobile robot;

FIG. 10 is a chart of colors or other codes used to identify particular problems experienced by a mobile robot;

FIG. 11 illustrates a drop down list for selection by firmware version filtering Tug, e.g., for use at Tug;

FIG. 12 illustrates a drop down list for selection by various parameter filters Tug preset in the system of the present invention; and

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

Detailed Description

With many autonomous mobile robots deployed at many facilities or locations, remote monitoring, diagnostic, and tracking systems are necessary to enable support personnel at a central location, remote from the facility, to effectively manage the operation of the autonomous mobile robots. As used herein, the terms "autonomous mobile robot," "robot Tug," "robot," and "Tug" are used to refer to the same or similar devices. The system and method of the present invention utilizes heuristics to analyze operational events encountered by a fleet of mobile robots traversing multiple facilities. Applying these algorithms, the central system determines the most critical navigation events and rapidly cycles these robots to the "top of stack" for analysis and support by support personnel at the remote location. 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 key operating parameters and data and reports the key operating parameters and data to a central server located at each facility. Key operating parameters and data are monitored/acquired on each mobile robot and transmitted to the central facility server in real time. This technique allows for rapid analysis, display and processing of real-time sensor data from each robot. Further, 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 (heatmaps), 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 arranges and displays the operating parameters of each active robot. A central server at the remote location records and manages data from multiple sites and robots. A web-based application at the central server parses the information and displays the information to the remote support in a useful, arranged form. This information is displayed to the support in a manner that can quickly and easily identify those robots with the most severe navigation events and resolve those robots first.

A key element of this function is the application of knowledge-based parameter permutations to optimize robot movement and identify serious navigation events. In addition, the graphical data mining tool applies prioritization and rapid identification of robot navigation events to assist remote support personnel based on problem frequency display. A heat map display of frequency may be applied to highlight operational events, sensor readings, performance factors, etc.

Each facility in which the mobile robot is located includes its own base server. Each such base server includes a software module running thereon that receives operating parameter data from mobile robots operating at the facility. The software module tracks and aggregates relevant information on each mobile robot. The key operating parameters are then reported to the remote central server by the base server.

Software and sensors located on each mobile robot monitor and report key operating parameters to the base server at each facility. Each mobile robot or all mobile robots at a site may be tuned to provide an 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 the mobile robots with events in order of "navigation" severity. Navigation severity is due to robot idle time (not moving), etc., which is caused by facility issues such as, but not limited to: elevator delays, blocked paths (obstructions in the hallway), and failed devices (automatic doors not opening on command). From this information, support personnel at the remote location can assist in robot navigation and notify facility personnel about their equipment events that affect the robot. Further, the system and method of the present invention records all mobile robots and other activities in a decision support system for future product improvements. Finally, visual data mining tools may be applied to quickly identify patterns in the behavioral changes of the mobile robot, thereby helping to identify and correct root events.

Many implementations of the systems and methods of the present invention can be configured without departing from the spirit and scope of the present invention. For example, no particular 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 technique for sending data to the base server may be written using, for example, a combination of TCL and MySQL. Software parsing and display of data can be written using, for example, a combination of HTML, Javascript, PHP, and MySQL. In one implementation, software parsing and display of data for the helpdesk employee only requires hardware capable of running a PHP-based web server. The base server (at each facility where autonomous mobile robots are deployed) may 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 technical platforms as needed. In addition, the system of the present invention utilizes various libraries and plug-ins such as, for example, Jquery, mysqltcl, and datatable. However, these libraries/plug-ins are not essential, and any library/plug-in may be replaced with other techniques to achieve the same functionality.

According to the system and method of the present invention, software typically exists in three locations. (1) On Aethon's web server (Helios) (i.e., a remote location central server). Which is software that parses and displays data to support personnel. (2) On each base server at each client or customer location. Each location has a home server with which all Tug communicate and share details of their current situation. Which is software that aggregates state information and data for return to a database at a 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 to directly reach the central system. Depending on the severity of the event and the impact on the customer operation, the data may be configured or "tuned" to various levels of data.

Referring to fig. 1-2, a system for monitoring, diagnosing and tracking an automated mobile robot is shown generally at 100. The 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 for a fleet of mobile robots 110 deployed at that location. The data received by the base server 105, which includes error status bits and status information for each mobile robot 110 deployed at the location, 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 robot 110 and an Aethon Elevator Controller (EC) 160. The base server 105 also includes an elevator module 120 and a tracking lock module 125, the elevator module 120 receiving data from the robot 110 regarding robot position and queue status, the tracking lock module 125 managing locks and lock queues. The EC160 (typically one for each room) receives operational status information for the elevator rooms in the hospital and reports this information to the status module 115 at the base server 105, including, for example, room location/status and door location/status. The command center module 130 at the base server 105 receives data from the status module 115, the elevator module 120, and the tracking lock module 125. The command center module 130 synchronizes data for the site devices, orders the data, and passes the information to the database 140 at the helpdesk server 135.

The command center module 130 transmits the processed data to the remote location central server 135. In one form, the data is synchronized and periodically sent to the central server 135 over a secure connection, such as, for example, a VPN (virtual private network) tunnel or the like. The central server 135 receives data from the respective base servers 105 located at the respective facilities and stores the received data in the database 140. The central server 135 includes a data analysis module 145, and the data analysis module 145 applies heuristics to process 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 operating parameters according to both the operating parameters and the status of the operating parameters in order to rank the various navigational events experienced by the mobile robot 110 in order of severity. Various operating parameters analyzed by the data analysis module may include, but are not limited to, idle time, status, trip, communication status, whether an alarm has been raised (as will be described below), Tug what is being done, where Tug is in operation at Tug, what blocks Tug, what generates idle time, and the like, as well as other parameters related to the mobile robot, including at least those discussed below with respect to fig. 5.

The data analysis module 145 processes the operational parameters and orders Tug with events using advanced business rules. Some of the business rules may be site specific, Tug specific, job specific, etc. Thus, business rules may change not only between sites but also between Tug. Some examples of business rules are utilized by the data analysis module 145 to translate operational parameters into settings for recovery prioritization, including but not limited to:

tug navigation path (based on hospital map).

Path attributes such as speed, throughput, etc.

Channel sensor settings-e.g. which sensors are active at any point.

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

Destination and lock point latency.

The location of the lock point and the table area.

Elevator interaction-e.g. waiting time, Tug transporting performance elevator sequence, standby elevator, etc.

Minimum charge time (generally, charge is not considered "idle time").

Scheduled Tug run.

Prioritization/filtering of sites and Tug (typically used for new site "start-up" monitoring).

The data analysis module 145 determines the most critical navigation events and moves those mobile robots 110 that are subject to these critical navigation events to the top of the list for action by the support person 150. Support person 150 may access central server 135 using a PC or other computing and display tool through world wide web 155 using a web-based application. Alternatively, central server 135 may be located at the same location as support personnel 150. The central server 135 displays the information to the support person 150 in a ranked format to enable the support person 150 to quickly and easily determine which mobile robots 110 are experiencing the most critical navigation events and to resolve those events first.

In addition to processing and displaying the navigation information, the data analysis module 145 also stores information in the database 140 about various events that each mobile robot 110 is experiencing. The support person 150 may utilize this stored information to generate maps and charts showing the frequency of problems that the mobile robot 110 or location is experiencing.

FIG. 3 illustrates an exemplary mobile robot 110 that may 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 may be implemented by an integrated cart or storage area. FIG. 3 also illustrates an exemplary configuration of sensors that may be implemented to sense potential obstructions. For example, two sensors 165 may be positioned approximately 90 degrees from 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. The two sensors 170 may be directed nearly perpendicularly to the exterior of the robot 110 and may be used to detect objects or the like that may protrude from a ceiling suspension or wall. A plurality of different rows of forward sensors 175 may be provided that are capable of detecting obstacles generally in front of the robot 110. The sensors 175 may be grouped in a series of planar rows at various angles relative to the ground and may, if desired, intersect one another. The row and number of sensors should be configured to minimize the number of potential obstacles that may be able to be located between the sensor beams and thus remain undetected.

Depending on the particular application and/or location of deployment, the mobile robot 110 may include one or more specifically placed sensors to detect unique obstacles that may be encountered. Further, one or more rear facing sensors may be provided on the robot 110 or cart 163, as desired. The sensor may be any type of sensor capable of detecting an obstacle, and the sensor may include an infrared sensor, an ultrasonic sensor (such as sonar), or the like. 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. The software utilizes detailed maps of the hospital and sophisticated navigation and operation software to plan the route of the mobile robot, avoid obstacles, track its position, and provide raw operation data to the base server 105 through the use of sensors and other devices.

Fig. 4 illustrates an exemplary network diagram for implementation of the system and method of the present invention. The main communication hub of the network is the existing hospital (or other location) network 180. Which may be a wired or wireless ethernet connection, those skilled in the art will recognize that many alternatives may be employed, all of which are 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 recharge these batteries. An elevator control 195 is provided which is operatively attached at one end to the hospital robot for communication with the mobile robot 110 and at the other end to an elevator control panel for controlling the elevator upon request by the mobile robot 110.

The base server 105 is connected to the hospital network 180 by a wired or wireless connection. The base server 105 receives raw operational data from the mobile robot 110. The base server 105 processes the data and transmits it to the remote location central server 135. As previously described, the central server 135 processes the data using complex algorithms and displays the information to the support person 150 in a ranked format so that the support person 150 effectively determines which mobile robot 110 is experiencing the most severe navigation events so that those events can be resolved first.

Fig. 5 shows a screen image representing an embodiment of a web application at the central server 135 for organizing and sequencing active autonomous mobile robots 110 at a number of facilities. As shown in fig. 5, 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 providing the robot 110 in a list format, various information may be formatted, for example, color coded according to the extent of events encountered. Thus, in addition to listing the mobile robots 110 from top to bottom, color coding (or other format) provides an additional indication of navigation severity that support personnel can use to rank which robot 110 is addressed first.

Various operating parameters are displayed for each active robot 110. For example, at 200, the mobile robot is identified by Tug number and location. The identifier "Tug-120-1" represents Tug #1 at position "120", and the identifier "Tug-116-4" represents Tug #4 at position "116". At 205, the status of each Tug is provided. This status tells support personnel Tug what to do. For example, Tug may be charging, waiting, blocked, navigating, etc. At 210, a battery charge status is provided that informs support personnel how much battery life remains. At 215, the amount of time that has elapsed since Tug started its last work or operation is indicated. At 220, the amount of time that the 78 has been idle (not moving) is provided Tug. Typically, this is an important parameter because idle Tug is Tug may be experiencing the first signs of a navigation event. At 225, Tug strokes are provided. The itinerary indication Tug is a list of the location(s) to which it is presumed to go. A check mark or other identifier next to the location means Tug has completed the run and reached the destination. For example, Tug "Tug-98-3" near the middle lists "Traumal" and "WW 5S" as its two destinations. The support personnel can tell Tug the destination "traffic" arrived at because there is a check mark next to it and Tug is now on the way to "WW 5S". At 230, the locked state of Tug is indicated. The locked state tells support personnel Tug whether to wait at the lock or hold point. Hospitals and other facilities have various locks in various locations. For example, it may be in a particular corridor that can accommodate only one Tug at a time. The corridor will have a lock at either end. When Tug arrives in the hallway, if another Tug is navigating through the hallway, then the Tug waits at the lock. Once the corridor is clear Tug will travel down the corridor, while the other Tug will be forced to wait at the lock until the corridor is clear. As a further example, the lock may also be located outside the elevator, Tug where it will wait for the elevator. At 235, the amount of time elapsed since Tug most recently communicated with the base is provided. This is an important parameter because all Tug should be in communication with the base system at all times. If Tug loses communication with the system, it must be determined when, where, and why the communication was lost. At 240, the number of outstanding service tickets is provided. Which informs the support personnel that certain actions have been performed to correct the problem associated with the particular Tug. The service ticket 240 informs support personnel Tug that they have been handed up to the service group and that there are pending service tickets that the service personnel are scheduled to view Tug. At 245, the column entitled "previous week" shows the number of recoveries performed by support personnel in the area currently experiencing the problem at Tug in the past week. "area" refers to the X-Y-Z coordinate location on the ground plane of the location of deployment Tug. For example, the area may be a 10 'x 10' location on a ground plan view of the location. However, the physical area may be larger or smaller depending on the particular application and/or location. The "last week" data is useful to support personnel because support personnel can see that the other Tug also have problems in the area where the current Tug experienced problems. Information about problems other Tug have had in the same area is useful to find both short-term and long-term solutions. At 250, clicking the "C" button allows the support staff member to ask the particular Tug to continue working. This helps to avoid repetitive work. At 255, support personnel can hide Tug from the list, the personnel knowing that Tug will not need action for a period of time, even though the Tug may be idle. Typically, Tug must be associated with the service ticket so that Tug is hidden. The reason for the concealment is listed on the service ticket. For example, the reason may be "reconnect with department about restart" or "check to see if elevator is working", etc. The hidden feature has a timer built into it. After a period of time, Tug will reappear on the screen to alert support personnel that action needs to be taken. Those skilled in the art will appreciate that the above identified parameters are merely exemplary and that other parameters may be displayed and analyzed in the arrangement of Tug without departing from the spirit and scope of the present invention.

As discussed previously, the information provided may be color coded or shaded, or otherwise include visual distinctions, to help support personnel in identifying key events. The color or visual coding will depend on the particular state of Tug. For example, as shown in fig. 10, various different colors and/or shades and/or other visual distinctions may be implemented when listing Tug to identify various key events. As shown in FIG. 10, the color specification column 500 includes various visual distinctions when listed Tug, which represent a particular state of Tug, as displayed in the immediately right question column 505. The chart of fig. 10 is merely exemplary, and more or less colors, shading, and/or visual differentiation/coding may be implemented depending on the application and/or location.

For example, if Tug waited for an elevator or hallway clear at a lock, then rules are set to provide Tug a reasonable amount of time that may have to wait at a particular lock. Similarly, if Tug is at a destination, a rule is set to provide Tug a reasonable amount of time that may have to wait at a particular destination. The reasonable time at each location/destination may be different. The rules allow for the setting of a particular Tug at a particular location or destination for applying color or other coding.

For example, assume 5 minutes is set to a reasonable amount of time for Tug to wait at a particular lock. After 5 minutes have elapsed, the idle time may be colored or otherwise coded to identify an idle time that exceeds the usual wait. After 15 minutes, the idle time may be coded as a different color, shade, etc. to identify potential critical events. The color or other coding may continue in increments of time to indicate continued wait severity. Of course, other parameters shown in fig. 5 may also be colored or otherwise encoded, depending on the parameter or combination of parameters.

The system and method of the present invention applies different weights to each parameter depending on all parameters, their states, and other parameters and their states, pertaining to a particular Tug. Business rules are utilized including Tug what is being done, where Tug is in the work of Tug, what blocks Tug, what generates idle time, and various conditions that establish those of the ordered list shown in fig. 5, as well as other parameters. Colors are associated with various parameters to mark not only the order of precedence on the list, but also the relevant areas where problems may occur.

For example, Tug "Tug-120-1" first appears on the list of FIG. 5. It shows that Tug was charged at the second tier (205), started its most recent work (215) before about 41 minutes, had been idle for more than 15 hours (220), had no trip (225), had lost communication for more than 19 hours (235), and had a 1 service ticket (240). In addition, another Tug has experienced problems in the area where Tug-120-1 currently experienced problems, as shown by 1 in the upper week column (245). The work start and idle time data is meaningless and all other data is suspect because the Tug has lost communication for almost 20 hours. Based on a combination of these factors, Tug "Tug-120-1" is placed at the top of the list. The other Tug in the list are similarly arranged based on a combination of the respective parameters. Thus, the support personnel need not find out which Tug should be addressed first.

In addition, the list of Tug to be checked can be filtered by site # (e.g., "all sites"), software version (e.g., "all MNZ versions"), firmware version, e.g., on the 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 the entire Tug team for events or to monitor newly developed functions. For example, clicking on button 510 on FIG. 5 may display a drop down list of firmware versions currently running on Tug, as shown in FIG. 11. The user may check some or all of the currently running firmware version to be displayed on the exemplary screen of fig. 5. Similarly, clicking on button 515 of FIG. 5 may display a drop down list of the various parameters identified for monitoring, as shown in FIG. 12. The user may review some or all of the parameters to be displayed on the exemplary screen of fig. 5. Likewise, clicking on button 520 on FIG. 5 may display a drop down list (not shown) of the various sites with Tug running. The user may review some or all of the sites to be displayed on the exemplary screen of fig. 5. By examining various combinations of sites, PROM versions and parameters, support personnel can implement various filter options and check box functions.

Fig. 6 shows a screen image providing additional support data to remote support personnel 150. By clicking Tug on the "+" symbol next to identifier 200, support personnel is provided with additional information about Tug, including the navigation status of Tug, hardware attributes, etc., and facility information that assists support personnel in resolving Tug any events that may have. For example, Tug "Tug-107-5" recognizes as idle and no communication time exceeds 2 hours, which may be the reason for accessing this Tug. The table shown at 300 provides Tug various operating parameters for support personnel. "MM" informs support personnel Tug whether or not in maintenance mode, meaning Tug is being serviced by service personnel. In maintenance mode, Tug cannot go out. A "0" means "no" and a "1" means "yes". As an example, the Tug identifiers 200 for Tug "Tug-86-1" and "Tug-86-2" are shaded, which is an indication that support personnel these Tug are in maintenance mode. Thus, while they are at the top of the list, the support staff knows that they are serving and can move to the next Tug.

In table 300, "charge" indicates Tug whether or not it is charging. The "floor" and "map" parameters indicate Tug on which floor and on which portion of the floor. The "MNZ version" tells what version of software is running on Tug, while the "push state" indicates the state of the processing software of Tug. The "error status" and "alarm status" are associated and provide an indication of a software error. The "obstacle status" informs Tug whether any obstacles are detected. "route mode" indicates Tug travel mode. For example, Tug may be in a yaw drive mode at Tug capable of maneuvering around an obstacle, or in a non-yaw drive mode at Tug incapable of maneuvering around an obstacle. The "wait state" tells Tug whether or not to wait at the lock. The "pick-up state" tells Tug whether the cart is attached. The "recent HB update" tells when the most recent communication with the base occurred. Thus, looking at FIG. 6, the support personnel may determine Tug that "Tug-107-5" is scheduled to go to the "3 MotherBaby" location and has been idle for more than 2 hours, but communicated with the base 7 seconds ago. This indicates that the system is functioning properly and Tug has a problem.

Table 305 in fig. 6 provides information about Tug the elevator is being used. The table 305 is typically colored or otherwise coded to indicate Tug the location in the elevator process. Table 305 informs support personnel Tug that "Tug-107-5" was inferred as going from floor 1 to floor 3 and Tug is an elevator below floor 3. This provides clues to the support personnel as to where Tug was located when Tug was last heard. Table 305 further indicates that elevator "EC-107-2" is at the first floor.

Table 310 provides alarm information when an alarm occurs. The alarm is generated by Tug when it experiences a problem. The alarm summarizes Tug the overall status and may provide Tug an indication of what the error is believed to be. The alert informs support personnel that there is additional information to be viewed that has been generated by Tug that can help solve the problem experienced by Tug. The support person would click on the alarm link provided in the table to view information related to the alarm. Likewise, table 315 provides service information when the service ticket is opened. The support person would click on the service ticket link provided in the table to view information relating to the alert. As shown in Table 315, Tug "Tug-107-5" has no alerts or open service tickets.

FIG. 7 shows a diagram of the system of the present invention linked to a customer support database that allows events to be recorded in support tickets. This screen may be accessed by clicking on the service ticket link in table 315 (see fig. 6). The screen shot of FIG. 7 provides the support person with information about the opened service ticket. Block 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. Block 355 identifies the site location, the device type, and the device number of Tug in service. Block 360 identifies the class of service being executed and the current state of the service. Block 365 and the following blocks provide further information to the support person regarding the particular service ticket. Block 370 provides a description of the problem being experienced by Tug. Block 375 is a resolution block for supporting human input entries. Each time an update exists, the support person will enter a new entry describing the update. Clicking the "submit" button adds the entry to the list of entries below resolution box 375, typically in the most recent, top order.

Additional information may be provided to the support person by clicking on the various icons appearing in fig. 7. For example, clicking on the icon displayed at 380 will display any other tickets opened at a particular site. There may be other Tug that are problematic, other devices such as elevators may have opened tickets, or the base may have some problem. Clicking on the icon 380 will provide the support person with additional information about the problems that may occur at a particular location. Clicking on the icon displayed at 385 will display a resolved window listing any state changes and the reason for the change. This again provides the support person with additional information about what happened in a particular situation. All of the information is designed to assist support personnel in solving the problem.

Existing site information may also be displayed to assist support personnel, as shown in FIG. 8. This screen can be accessed by clicking on the device name in fig. 5. For example, the particular screen may be accessed by clicking on the device name "Tug-107-5" in the window behind it. Clicking on this link brings up all information about location 107. At 400, the site name and address will be provided. Table 405 has various labels. The displayed "helpdesk" tag identifies that the helpdesk (i.e., support person) infers the object to be called in the event they need to assist in handling the event. Clicking on the "site" tab will provide a list of people at the site, inferred as contacting those people for each event. Clicking on the "Aethon" tab will provide a list of Aethon support people for a particular site.

Table 410 provides various information for each Tug at a particular site. "Tug" provides the Tug identification number. The "application" identifies Tug a particular application. The "location" identifies the location of the cradle for Tug. The "cart type" identifies Tug whether a cart is being dragged. "CC type" refers to the type of processor used by the computer at Tug. The "network" identifies the type of network used. The "laser" identifies the presence or absence of a laser sensor. The remaining columns identify the inventory quantity for Tug, as well as the various components and devices associated with Tug. The "site spare" row below the column is for the service department and identifies the hardware and equipment available at the site, which can be used as a replacement component for Tug.

Below table 410 is another table that provides information about elevators at a particular stop. The support person may view more information about a particular site as they scroll down.

Fig. 9 shows an example of a data mining function that uses a "heatmap" tool to display robotic navigation events at a facility. Figure 9 shows a fifth level of a particular installation. As shown in fig. 9, a particular Tug is traveling between destinations "5W" and "5E" along the route shown at 425. Tug also visit the elevator to travel to different floors as shown in fig. 9. As shown in the heat map image Tug has a particular event in the elevator lobby on that particular floor, shown generally at 430. Aethon support personnel can use this information to take action to correct the event. They may contact the customer and request live assistance to help correct the event. Alternatively, support personnel may work with the user to make mapping changes to the instructions of the robot so that the robot can travel through other corridors to avoid future problems.

It should be understood by those of ordinary skill in the art that although the presently described systems and methods have been described herein as including a base server 105 located at each facility where a plurality of teams of mobile robots are deployed, the base server 105 may be omitted without departing from the spirit and scope of the present invention. In this embodiment, the functionality associated with the base server 105 would be included in the central server 135. The mobile robots 110 at each facility transmit raw business data directly to the central server 135 by known or conventional methods and techniques, and the central server 135 processes the data in the manner previously described to order the mobile robots for action by support personnel.

It should be appreciated that one or more exemplary embodiments of the invention may employ hardware and/or software aspects. Software includes, but is not limited to, firmware, resident software, microcode, etc., which has been compiled to program a general purpose computer to a specific use computer, or to run a specific use computer. The storage device may be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices, including the storage portion described above with respect to the card. It should be noted that if distributed processors are employed, each distributed processor that constitutes a processor that performs a function or step typically contains its own addressable memory space. It should also be noted that some or all of the computer system and server may be incorporated in a dedicated or general purpose integrated circuit. For example, one or more method steps may be implemented in hardware in an ASIC without application of firmware. The displays used in conjunction with each entity, server, and processor represent a variety of possible input/output devices.

It should therefore be appreciated that one or more embodiments of the present disclosure may comprise a computer program comprising computer program code means adapted to perform one or all of the steps of any of the methods or claims described herein when the program is run on a computer, and that the program may be presented on a computer readable medium. Furthermore, one or more embodiments of the present disclosure may comprise a computer comprising code adapted to cause the computer to perform one or more steps of the methods or claims described herein, in conjunction with one or more apparatus elements and features as illustrated and described herein.

As is well known in the art, and as described with respect to fig. 13, all or portions of one or more aspects of the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. In conjunction with a computer system, the computer readable program code means is operable to perform all or part of the steps to perform a method or construct an apparatus as 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, etc. 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, magnetic variations on a magnetic medium or optical property variations on the surface of an optical disc. The computer readable medium may be distributed over multiple physical devices (or over multiple networks). For example, one device may be a physical storage medium associated with the terminal, while another device may be a physical storage medium associated with the processing center.

The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. The memories may be distributed or local and the processors may be distributed or singular. The memories 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 able to be read from or written to an address in the addressable space accessed by the associated processor.

Although the exemplary embodiments are described herein in terms of methods or systems/apparatus, it is contemplated that they may be implemented by a microprocessor of a computer, such as, for example, computer system 1300 shown in FIG. 13. In various embodiments, one or more of the functions of the various components may be implemented in software that controls a computing device, such as computer system 1300 described below with reference to FIG. 13. 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 disk drive, a ROM, a flash memory, an optical memory, or any other type of non-volatile memory.

The aspects of the disclosure illustrated in fig. 1-12, or any portion or function thereof, may be implemented using, for example, hardware, software modules, firmware, tangible computer-readable media having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. Fig. 13 illustrates an exemplary computer system 1300 in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the systems and methods of the invention can be implemented in a computer system 1300 using hardware, software, firmware, non-transitory computer readable media having instructions stored thereon, or a combination thereof, and can be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may represent any modules and components for implementing the systems, methods, and architectures of fig. 1-12.

If programmable logic is applied, the logic may be executed on a commercially available processing platform or on a dedicated device. Those of ordinary skill in the art will appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers with linked or aggregated distributed functionality, as well as ordinary or microcomputer systems that can be embedded in virtually any device. For example, at least one processor device and memory may be used to implement the above-described embodiments. The processor device may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores," as that term is commonly understood.

Various embodiments of the present disclosure are described in terms of an exemplary computer system 1300 shown in fig. 13. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the disclosure using other computer systems and/or computer architectures. Although operations may be described as a sequential process, some of the operations may in fact be performed concurrently, and/or in a distributed environment, with program code stored locally or remotely for access by single or multi-processor machines. Further, in certain embodiments, the order of the operations may be rearranged without departing from the spirit of the disclosed subject matter.

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

Computer system 1300 also includes a main memory 1308, such as Random Access Memory (RAM), and also includes a secondary memory 1310. The secondary memory 1310 may include, for example, a hard disk drive 1312, a removable storage drive 1314, or the like. Removable storage drive 1314 may comprise, for example, a floppy disk drive, a magnetic 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. Removable storage unit 1318 may comprise, for example, a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 1314. One skilled in the relevant art will appreciate that removable storage unit 1318 includes a non-transitory computer-usable storage medium having stored thereon computer software and/or data.

In alternative implementations, secondary memory 1310 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 400. The tool 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 that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 1322 and interfaces 1320, interface 1320 allowing software and data to be transferred from removable storage unit 1322 to computer system 1300. Computer system 1300 may also include a communications interface 1324.

Communications interface 1324 allows software and data to be transferred between computer system 1300 and external devices. Communications interface 1324 can include, for example, a modem, a network interface (such as an ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface 1324 may be in the form of signals. The signal may be electronic, electromagnetic, optical, or other signal capable of being received by communications interface 1324. These signals can be provided to communications interface 1324 through internal connection 1328 and communications path 1326. Communications path 1326 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, or other communications channels.

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

Computer programs (also called computer control logic) are stored in main memory 1308 and/or secondary memory 1310. Computer programs may also be received via communications interface 1324. Which when executed, enables computer system 1300 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable the processor device 1304 to implement the processes of the present disclosure. Accordingly, such computer programs represent controllers of the computer system 1300. In implementing the present disclosure as application software, the software may be stored in a computer program product and loaded into computer system 1300 using removable storage drive 1314, interface 1320, and hard disk drive 1312, or communications interface 1324. Embodiments of the present disclosure may also be directed to computer program products comprising software stored on any computer usable medium. The software, when executed in one or more data processing devices, causes the data processing devices to operate as described herein. Embodiments of the present disclosure 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, 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.).

It will thus be appreciated by those of ordinary skill in the art that one or more embodiments of the invention may comprise a computer program comprising computer program code means adapted to perform one or all of the steps of any of the methods or claims described herein when the program is run on a computer, and that the program may be presented on a computer readable medium. Furthermore, one or more embodiments of the present invention may comprise a computer comprising code adapted to cause the computer to perform one or more steps of the methods or claims described herein, in conjunction with one or more apparatus elements and features as illustrated and described herein.

It should be appreciated that the detailed description section, and not just the summary and abstract sections, is intended to be used to interpret the claims. The summary and abstract sections may set forth one or more (but not all) exemplary embodiments of the disclosure, as contemplated by the inventors, and are, therefore, not intended to limit the disclosure and the appended claims in any way. Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specific functions and relationships thereof. Boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.

The foregoing description of the specific embodiments will so fully reveal the general nature of the disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, based on the teachings and guidance provided herein, such adaptations and modifications are intended to be within the meaning and range of equivalents of the discussed embodiments. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of 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 invention is described herein with particular reference to the accompanying drawings, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Those skilled in the art will appreciate that various other modifications and variations may be developed in light of the overall teachings of the disclosure. The presently preferred embodiments described herein are meant to be illustrative only and not limiting as to the scope of the invention which is to be given the full breadth of the appended claims and any and all equivalents thereof.

Claims (30)

1. A system for managing and sequencing action queues of mobile robots deployed at various locations, the system comprising:

a plurality of base servers, each base server corresponding to a different location, wherein each base server receives operating parameter data from a plurality of mobile robots operating at a particular location; and

a central server receiving the operational parameter data from a plurality of base servers, the central server including a data analysis module that processes the operational parameter data and utilizes a set of location and mobile robot specific business rules to sort mobile robots operating at respective locations based on operational parameter data for each mobile robot to obtain a sorted list and provide the sorted list to a display associated with the data analysis module, and

wherein the operational parameter data comprises information relating to operational and navigational events experienced by the mobile robot; and

wherein ranking the mobile robots comprises ranking each mobile robot relative to each of the other mobile robots at the respective locations based on severity of the operational and navigational events experienced by each mobile robot in the information contained in the operational parameter data related to the operational and navigational events experienced by each mobile robot.

2. The system of claim 1, wherein the information related to navigation events includes information related to robot idle time caused by elevator delays, blocked paths, and/or failed devices.

3. The system of claim 1, wherein the central server receives operational status information for an elevator cab.

4. The system of claim 3, wherein the operational status information for the elevator cab includes at least one of a cab position, a cab state, a door position, and a door state.

5. The system of claim 1, wherein the data analysis module generates the list that ranks mobile robots based on the operational parameter data and ranks mobile robots in order of importance for action by support personnel.

6. The system of claim 5, wherein the list generated by the data analysis module is accessible with a web-based application, and wherein the list includes links to other information related to the mobile robot and a location where the mobile robot is operating.

7. The system of claim 5, wherein the list generated by the data analysis module includes operational information related to the mobile robot, wherein the operational information includes at least one of idle time of the mobile robot, status of the mobile robot, travel of the mobile robot, communication status of the mobile robot, whether an alert has been issued, task of the mobile robot, where the mobile robot is in its task, cause of mobile robot delay, and cause of idle time of the mobile robot, and wherein the operational information is encoded to identify potential critical events.

8. The system of claim 5, wherein data related to mobile robots appearing in the list generated by the data analysis module can be hidden for a predetermined period of time after which the data related to the mobile robots will reappear on the list.

9. The system of claim 1, wherein the data analysis module stores information in a database relating to operational and navigational events experienced by the mobile robot.

10. The system of claim 9, wherein the data analysis module utilizes the stored information related to the operational and navigational events experienced by the mobile robot to generate maps and graphs that show the frequency of problems experienced by the mobile robot or location.

11. The system of claim 1, wherein the data analysis module arranges a first mobile robot at a first position in the ordered list and the data analysis module arranges a second mobile robot at a second position in the ordered list, wherein the first position is in a higher order in the ordered list than the second position, the data analysis module modifying an order of the second mobile robot such that the second mobile robot is in a higher order in the ordered list than the first mobile robot.

12. A method of managing and sequencing action queues of mobile robots deployed at various locations, the method comprising the steps of:

receiving, at a base server deployed at a particular location, operating parameter data from a plurality of mobile robots operating at the particular location;

receiving, at a central server, operating parameter data for the mobile robot from a plurality of base servers, each base server deployed at a different location;

analyzing, by a data analysis module at the central server, operational parameter data of a mobile robot;

processing the operation parameter data of the mobile robot by the data analysis module by using the business rule set; and

ranking, by the data analysis module at the central server, mobile robots operating at respective locations based on the operational parameter data and the set of business rules,

wherein the operational parameter data comprises information relating to operational and navigational events experienced by each mobile robot;

wherein the data analysis module sequencing the mobile robots operating at the respective locations comprises: ranking each mobile robot relative to each of the other mobile robots at the respective locations based on severity of the operational and navigational events experienced by each mobile robot in the information contained in the operational parameter data relating to the operational and navigational events experienced by each mobile robot; and

wherein each business rule in the set of business rules is specific to a location and a mobile robot.

13. The method of claim 12, further comprising the step of displaying an ordered list via a display associated with the data analysis module, wherein the ordered list arranges the mobile robots in order of severity for action by support personnel.

14. The method of claim 13, wherein the ordered list is accessible with a web-based application, and wherein the ordered list includes links to other information related to the mobile robot and a location where the mobile robot is operating.

15. The method of claim 13, wherein the ordered list includes operational information about the mobile robot, and wherein the operational information is encoded to identify potential critical events.

16. The method of claim 13, wherein data related to mobile robots appearing in the ordered list can be hidden for a predetermined period of time after which the data related to the mobile robots will reappear on the ordered list.

17. The method of claim 12, further comprising the step of storing, by the data analysis module, information in a database relating to operational and navigational events experienced by the mobile robot.

18. The method of claim 17, further comprising the step of analyzing the stored information relating to operational and navigational events experienced by the mobile robot, and the step of generating a map and/or chart showing the frequency of problems experienced by the mobile robot or location.

19. The method of claim 12, wherein the information related to navigation events includes information related to robot idle time caused by elevator delays, blocked paths, and/or failed devices.

20. The method of claim 12, wherein the set of business rules includes information related to at least one of mobile robot navigation paths, mobile robot path attributes, mobile robot path sensor settings, mobile robot voice messages, mobile robot destination wait times, mobile robot lock point wait times, location of mobile robot lock points, location of mobile robot work station areas, mobile robot elevator interactions, mobile robot minimum charge times, and scheduled mobile robot runs.

21. The method of claim 12, further comprising receiving operational status information for an elevator cab at the central server.

22. The method of claim 12, wherein the data analysis module ranking the mobile robots operating at the respective locations comprises: the data analysis module ranks a first mobile robot at a first position in the ordered list and the data analysis module ranks a second mobile robot at a second position in the ordered list, wherein the first position is in a higher order in the ordered list than the second position, the method further comprising the data analysis module modifying an order of the second mobile robot such that the second mobile robot is in a higher order in the ordered list than the first mobile robot.

23. A system for managing and sequencing action queues of mobile robots deployed at various locations, the system comprising:

a central server receiving operating parameter data from a plurality of mobile robots operating at least one location, the operating parameter data representing operating and navigation events experienced by the mobile robots, wherein the central server comprises a data analysis module that processes the operating parameter data and ranks the mobile robots based on the operating parameter data using a set of location and mobile robot specific business rules, and

wherein the operational parameter data comprises information relating to operational and navigational events experienced by the mobile robot; and

wherein sequencing the mobile robots comprises: ranking each mobile robot relative to each of the other mobile robots at the respective locations based on severity of the operational and navigational events experienced by each mobile robot in the information contained in the operational parameter data relating to the operational and navigational events experienced by each mobile robot.

24. The system of claim 23, wherein the data analysis module generates a list that ranks mobile robots based on the operational parameter data and ranks mobile robots in order of severity for action by support personnel.

25. The system of claim 24, wherein the list generated by the data analysis module is accessible with a web-based application, and wherein the list includes links to other information related to the mobile robot and a location where the mobile robot is operating.

26. The system of claim 23, wherein the data analysis module arranges a first mobile robot at a first position in the ordered list and the data analysis module arranges a second mobile robot at a second position in the ordered list, wherein the first position is in a higher order in the ordered list than the second position, and wherein the data analysis module modifies an order of the second mobile robot such that the second mobile robot is in a higher order in the ordered list than the first mobile robot.

27. A method of managing and sequencing action queues of mobile robots deployed at various locations, the method comprising the steps of:

receiving, at a central server, operational parameter data from a plurality of mobile robots operating at least one location, the operational parameter data representing operational and navigational events experienced by the mobile robots;

analyzing, by a data analysis module at the central server, operational parameter data of the mobile robot;

processing the operation parameter data of the mobile robot by the data analysis module by using the business rule set; and

ranking, by the data analysis module at the central server, mobile robots based on the operational parameter data and the set of business rules, an

Wherein the operational parameter data comprises information relating to operational and navigational events experienced by the mobile robot,

wherein the data analysis module sequencing the mobile robots operating at the respective locations comprises: ranking each mobile robot relative to each of the other mobile robots at the respective locations based on severity of the operational and navigational events experienced by each mobile robot in the information contained in the operational parameter data relating to the operational and navigational events experienced by each mobile robot; and

wherein each rule in the set of business rules is specific to a location and a mobile robot.

28. The method of claim 27, further comprising the step of displaying, by a display associated with the data analysis module, an ordered list that ranks mobile robots in order of severity based on the operational parameter data for action by support personnel.

29. The method of claim 28, wherein the ordered list is accessible using a web-based application, and wherein the ordered list includes links to other information related to the mobile robot and the location where the mobile robot is operating.

30. The method of claim 27, wherein the data analysis module ranking the mobile robots operating at the respective locations comprises: the data analysis module ranks a first mobile robot at a first position in the ordered list and the data analysis module ranks a second mobile robot at a second position in the ordered list, wherein the first position is in a higher order in the ordered list than the second position, the method further comprising the data analysis module modifying an order of the second mobile robot such that the second mobile robot is in a higher order in the ordered list than the first mobile robot.