Configuring and managing a fleet of dynamic mechanical systems

Abstract

A distributed robot management system is provided, comprising: a first fleet of robots at a first facility; and a robot management server system communicatively coupled to the first fleet of robots via a network and remote from the first facility, wherein the robot management server system is configured to: provide configuration information to the first fleet of robots, maintain a remote representation of a state of robots in the first fleet of robots, receive and store data from the first fleet of robots, and provide computing resources through which robots in the first fleet of robots are trained.

Description

[0001] Cross-reference to related applications

[0002] This patent claims the benefit of U.S. Provisional Patent Application 63 / 169,719, filed April 1, 2021, entitled "Configuring and Managing Fleets of Dynamic Mechanical Systems." The entire contents of each of the aforementioned patent applications are hereby incorporated by reference.

[0003] background

[0004] This disclosure generally relates to mechanical systems, and more specifically to fleets of dynamic mechanical systems (such as robots) for configuration and management.

[0005] Dynamic mechanical systems are typically controlled using computational processes. Examples include robots, industrial processes, life support systems, and medical devices. Typically, such processes take input from sensors indicating the state of the dynamic mechanical system and its environment, and determine the outputs used to control various types of actuators within the dynamic mechanical system, thereby altering the state of the system and, possibly, its environment.

[0006] Overview

[0007] The following is a non-exhaustive list of some aspects of the present invention. These and other aspects are described in the following disclosure.

[0008] Some aspects include a distributed robot management system comprising: a first robot fleet located at a first facility; and a robot management server system located remotely from the first facility and communicatively coupled to the first robot fleet via a network, wherein the robot management server system is configured to: provide configuration information to the first robot fleet, maintain a remote representation of the state of the robots in the first robot fleet, receive and store data from the first robot fleet, and provide computing resources for training the robots in the first robot fleet.

[0009] Some aspects include a system comprising: one or more robot management servers, the robot management server comprising: a management module; an experience collection module; a configuration module; and a training module, wherein the robot management server is operable to manage and configure a robot fleet.

[0010] Some aspects include a tangible, non-transitory, machine-readable medium storing instructions that, when executed by a data processing device, cause the data processing device to perform operations including the processes described above.

[0011] Some aspects include a system comprising: one or more processors; and a memory storing instructions that, when executed by the processor, cause the processor to perform the operations described above. Brief description of the attached diagram

[0013] To facilitate the identification of any particular element or action in discussion, one or more of the highest significant digits in the figure references refer to the figure number in which the element was first introduced.

[0014] Figure 1 An example architecture of servers and services for configuring, deploying, and managing one or more dynamic mechanical systems, according to some embodiments, is shown.

[0015] Figure 2 An example machine learning system for managing dynamic mechanical systems is shown according to some embodiments.

[0016] Figures 3A-3D Sample code for configuring dynamic mechanical systems is shown according to some embodiments.

[0017] Figure 4 An example dependency model of a dynamic mechanical system according to some embodiments is shown.

[0018] Figure 5 An example system for the collection and management of experience for dynamic mechanical systems, according to some embodiments, is shown.

[0019] Figure 6 A flowchart of a method for managing a dynamic mechanical system according to some embodiments is shown.

[0020] Figure 7 A block diagram of a representative system comprising one or more robot systems is shown according to some embodiments.

[0021] Figure 8 An example computing device is shown that can be used to implement the above-mentioned techniques.

[0022] While the present invention is susceptible to various modifications and alternatives, specific embodiments thereof are illustrated by way of example in the accompanying drawings and will be described in detail herein. The drawings may not be drawn to scale. However, it should be understood that the drawings and their detailed description are not intended to limit the invention to the specific forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

[0023] Detailed description

[0024] To alleviate the problems described herein, the inventors must invent solutions, and in some cases, it is equally important to recognize problems in the fields of artificial intelligence and robotics that have been overlooked (or not yet foreseen) by others. In fact, the inventors wish to emphasize the difficulty of identifying those emerging problems, and that those problems will become even more apparent in the future if industry trends continue as the inventors anticipate. Furthermore, because multiple problems are addressed, it should be understood that some embodiments are problem-specific, and not all embodiments solve every problem of the conventional systems described herein or provide every benefit described herein. That is, improvements to various permutations of solutions to these problems are described below.

[0025] The following technical product specification describes examples of computer systems that can be used to configure and manage robot fleets, such as those described in U.S. Patent Application 16 / 918,999, filed July 1, 2020, entitled “Artificial Intelligence-Actuated Robot,” the contents of which are hereby incorporated by reference. Other types of robots can also be configured and managed using the techniques of the present invention, which are expected to be particularly advantageous in unstructured and semi-structured environments, such as those encountered by drones and autonomous vehicles. Alternatively, other types of dynamic mechanical systems can be similarly configured and managed using these techniques. It should be understood that “dynamic mechanical system” and “robot” and “robot system” are used interchangeably herein.

[0026] Figure 1 An example architecture of servers and services for configuring, deploying, and managing one or more dynamic mechanical systems, according to some embodiments, is shown. Example architecture 100 includes a management server 102, a manufacturer 112 (e.g., its computing device), a partner 124 (e.g., its computing device), and an administrator 128 (e.g., its computing device).

[0027] Management server 102 may be one or more servers including management module 104, experience collection 106, configuration 108, and training 110. Management server 102 can provide management functions, including verifying application programming interface (API) and assigning robots. The server cluster of management server 102 can be replicated and implemented for redundancy (e.g., using a load balancer or as a distributed fault-tolerant architecture).

[0028] The management server 102 can maintain the connections between each dynamic mechanical system. In some embodiments, the fleet management module 104 is responsible for providing information about each robot in the fleet on demand. The information for each robot may include manufacturing date, model, and transient information (e.g., physical location, robot owner, current power status, current configuration).

[0029] Experience collection 106 may include information obtained from one or more robots performing one or more tasks. Various forms of experience data can be obtained, including sensor data and any available contextual information (e.g., information related to the environment in which the tasks are performed).

[0030] Configuration Management 108 stores robot configuration information and associated assets. Configuration Management 108 stores information including hardware configuration, task information, assets, and dependencies for performing tasks for each robot, as well as system configuration data. Configuration assets may include neural network weights, software libraries, third-party software libraries, or any suitable data used for robot deployment and execution. Configuration Management 108 can be configured to detect faults in dynamic mechanical systems before, during, or after execution. Configuration 108 may include any combination of: hardware configuration, task configuration, and system configuration. Hardware configuration is performed on the robot to configure the physical hardware of the system. For example, hardware configuration includes selecting the effective range of motion of servo mechanisms, the field of view of cameras, and GPS coordinate identifiers. Task configuration includes information related to a specific task the robot is to perform. In some embodiments, task configuration includes data describing parameters associated with neural networks and algorithms, as well as the physical requirements for performing a specific task. System configuration includes information related to one or more software programs running on the robot. For example, the robot includes the giant.ai software library and its version.

[0031] Training 110 may include training data associated with training one or more machine learning models. Training 110 may also include sensor data obtained by robot client device 118. Sensor data may be used as input to training module 110 when updating and training machine learning models. In some embodiments, training module 110 may train one or more robots (e.g., robot client device 118) while the robot is still at the factory (e.g., manufacturer 112). In some embodiments, when the robot is ready to enter training mode, training 110 may perform any combination of the following tasks: establishing a connection with the robot client via robot web application (webapp) 116; training the robot using training data and configuration information from previous training; training the robot to perform new tasks through manual input, audio prompts, demonstrations, and remote control; sending experience data to experience collection 106; and sharing training-related data with one or more modules including configuration 108, management module 104, and experience collection 106. In one example, training may be performed on a dynamic mechanical system. During the performance of a new task, the user may provide auditory feedback (e.g., "yes", "no", "good", "bad") to the dynamic mechanical system. Dynamic mechanical systems can automatically adjust the execution of new tasks based on received auditory feedback. User-generated auditory feedback can be transmitted to one or more servers for further processing.

[0032] Manufacturer 112 provides dynamic mechanical systems (e.g., robot client devices 118) and may include site management 114 and robot web applications 116. Robot client devices 118 may include code running on physical, mechanical equipment (e.g., robots). Each robot client may provide a web interface, robot web application 116, to assist in robot configuration and uploading experience data. Site management 114 may be an application supported by a machine hosted at manufacturer 112, which is the location for producing, installing, and / or deploying dynamic mechanical systems. It should be understood that there may be more than one site management 114 console at manufacturer 112. In some embodiments, the console for site management 114 is configured to manage a portion of manufacturer 112's site.

[0033] The robot client device 118 includes a runtime module 120 and a nobot 122. The runtime module 120 includes a robot computer associated with the robot and responsible for the robot's performance, including driving servo mechanisms, collecting sensor data from sensors, and running strategies, neural networks, or any algorithms related to task execution. In some embodiments, the runtime 120 coordinates with a configuration 108 to configure the robot, with an experience collection 106 to transfer experience data, and with a management module 104 to provide the robot's status. Additionally, the runtime 120 may include an interface for configuring and training tasks on the robot itself. The nobot 122 is a computing system that, in some embodiments, may be physically decoupled from the robot client device 118 or the runtime 120. The task of the nobot 122 is to host in-depth introspection and feedback tools without unnecessarily burdening the robot computer (e.g., the runtime 120). While the robot client device 118 is running, nobot 122 can process statistical visualizations, perform troubleshooting, and develop applications via a high-speed data pipeline (e.g., GigE). In some embodiments, a single robot 122 is associated with multiple robots. In some embodiments, nobot 122 performs all non-essential processing (e.g., processing not directly related to robot control or performance), preventing non-critical functions from consuming resources on the robot's computer (e.g., runtime 120).

[0034] In some embodiments, the Site Management 114 console is used to perform various management tasks. The Site Management 114 console is configured to allow administrators at Manufacturer 112 to obtain information about the performance of robots in the facility and can be configured to communicate directly with each robot on the site. Site Management 114 can perform tasks including, but not limited to: configuring robots to perform specific tasks, checking robot status, remotely starting / stopping / pausing / resuming robot activity, generating and viewing reports on robot performance, creating location hierarchies, assigning robots to specific locations, and creating and managing users at a specific site. It is conceivable that Site Management 114 can be one or more site management consoles at a specific site, each console controlling a selected building, floor, assembly line, or other department. A specific Site Management 114 console can be configured to view sites at a specific floor in the location hierarchy (e.g., building A or floor 2).

[0035] Partner 124 can be the environment for deploying the mechanical system. Partner 124 can be a third party, sandbox, work area, assembly line, or any other suitable environment for the execution of the dynamic mechanical system. Fleet Management 126 includes an application running on the machine that can be used for advanced management and reporting of the activities of the dynamic mechanical system within Partner 124. Fleet Management 126 can be configured to perform tasks including site creation management, user management, report creation management, and viewing robot status on a dashboard.

[0036] Administrator 128 can be the global management console, managing and configuring any partners, users, and manufacturers discussed herein. Administrator 128 can be configured to perform tasks including managing users and their corresponding access levels, managing partners, viewing robot data, viewing fleet statistics, requesting robot status, creating and managing tasks, managing the configuration of individual robots, managing the configuration of robot fleets, managing the configuration of robot models, creating and viewing reports, and analyzing experience data. Typically, the various system APIs described herein have three types of users—administrators, partner employees, and robots. Generally, the broadest level of access is granted to giant.ai administrators. Partners (e.g., third parties) may be restricted in their access to APIs related to their own services and their own robot fleets. Robots are then further restricted in their access to APIs related to themselves. For example, a robot may request a task from the server that it is capable of performing. The server can provide a list of tasks that can be performed by the robot. Additionally, the server can provide a filtered list of tasks enabled for the robot. Access can be restricted or constrained based on one or more robot characteristics (e.g., hardware capabilities, robot location). In some embodiments, the system supports access control lists (ACLs) that can be used to fine-tune which features a particular user can access. These features can be grouped into broadly useful user capabilities—for example, a “reporting” capability would allow access to features requiring “ROBOT_READ,” “SITE_READ,” or “PARTNER_READ” permissions. Administrators can customize these categories as needed. Typically, requests and commands can occur in a series of exchanges and do not need to be combined into a single transmission. For example, a request for configuration may include a request to authenticate the requester, followed by a request to send configuration data via a secure, encrypted channel established using the first request. This can be used collectively as an example of a request for configuration data, where a second request can also be used independently as an example of a request for configuration data.

[0037] Figure 2An example machine learning model 200 according to some embodiments is illustrated. The machine learning model 202 may receive input 204 and provide output 206. In one use case, output 206 may be fed back to the machine learning model 202 as input for training the machine learning model 202 (e.g., alone or in conjunction with user indications of the accuracy of output 206, and labels associated with the input, or in combination with other reference feedback and / or performance metrics). In another use case, the machine learning model 202 may update its configuration (e.g., weights, biases, or other parameters) based on its evaluation of its predictions (e.g., output 206) and reference feedback information (e.g., user indications of accuracy, reference labels, or some other information). In another example use case, where the machine learning model 202 is a neural network, the connection weights may be adjusted to reconcile discrepancies between the neural network's predictions and reference feedback. In yet another use case, one or more neurons (or nodes) of the neural network may need to backpropagate their respective errors to facilitate the update process (e.g., error backpropagation). For example, updates to connection weights may reflect the magnitude of the backpropagated error after the forward pass has been completed. In this way, for example, machine learning model 202 can be trained to generate results with better recall, accuracy, and / or precision (e.g., task completion time prediction, urgency, maintenance timeline, end-of-life prediction).

[0038] Machine learning model 202 can be constructed as a factorization machine model. Machine learning model 202 can be a nonlinear model and / or a supervised learning model capable of performing classification and / or regression. For example, machine learning model 202 can be a general supervised learning algorithm for the system to perform classification and regression tasks. Alternatively, machine learning model 202 can include a Bayesian model configured to perform variational inference, such as predicting whether an action will be completed before a deadline. Machine learning model 202 can be implemented as a decision tree and / or an ensemble model (e.g., using random forests, bagging, adaptive boosters, gradient boosting, XGBoost, etc.).

[0039] Figures 3A-3D An example of sample code for the configuration of a dynamic mechanical system according to some embodiments is shown. Figure 3A Includes code 300a, which describes the sample task configuration file "task_pnp_103.yaml". Code 300a of the task configuration file includes details about the task. In the given example, the task is a "pick and place task from right to left". Code 300a includes a description of the assets and dependencies used in the task execution.

[0040] Figure 3BThis includes code 300b, which describes the hardware configuration of a robot according to some embodiments. Code 300b includes a description of the hardware used by the robot, including cameras, fingers, and joint sensors. Each hardware component may include the physical limitations described in code 300b.

[0041] Figure 3C Code 300c includes system configuration code for software running on the robot according to descriptions of some embodiments. Code 300c includes descriptions of various software programs currently installed or running on the robot. The example code 300c shown includes six discrete software programs, but it should be understood that the robot may use more or fewer software programs depending on the selected parameters and operating environment.

[0042] Additionally and / or alternatively, code 300c can be contained in a single Dockerfile 300d stored on the robot, such as Figure 3D As shown.

[0043] Figure 4 An example dependency model 400 of a dynamic mechanical system according to some embodiments is shown. The robot management server 402 may be an embodiment of the management server 102 and includes a configuration manager 404 (similar to...). Figure 1 104) and Asset Manager 406. Robot Client 408 may be an embodiment of Robot Client Device 118, which includes Dependency Manager 410 and File System 412. As mentioned above regarding Figure 1 As described, hardware, system, and task configurations can be managed separately. In some embodiments, hardware, system, and task configurations are managed together because dependencies may exist between different configurations. As an example, the first task may be run using a specific system configuration.

[0044] Hardware configuration may include details related to basic information (which is relevant to a specific robot model, such as model number), calibration information (which is relevant to a specific robot), and peripheral information specific to that robot. Because calibration data and peripheral data may change over the duration of the robot's lifecycle, hardware configuration updates may be pushed from the robot to the server.

[0045] Each individual task has an associated task profile that specifies assets, dependencies, and additional configuration metadata that provides information for the robot to perform the task. In some embodiments, the task profile includes data common to multiple robots performing the same task (e.g., task name and basic algorithm used for task training) as well as robot-specific data (e.g., data created during task training for a particular robot). In some embodiments, the configuration manager 404 may maintain a dependency map that tracks the interdependencies between tasks, hardware configurations, and system configurations. In some embodiments, dependencies are checked by a component on the robot client 408 (e.g., dependency manager 410) that can reconfigure the robot client 408 to match dependencies associated with task execution and can also raise a flag if a dependency cannot be fulfilled. While a single robot typically has one hardware or system configuration, there is no hard limit to the number of tasks that a robot can be configured to perform simultaneously. The robot management server 402 stores a list of tasks available for a particular robot; operators can select tasks that enable the robot to perform by selecting from the list of available tasks, and in some embodiments, the robot will then need to be trained for the task before it is deemed operable. Multiple tasks can be enabled or operated simultaneously on a single robot, although only one of these tasks is the current task, i.e., the task currently being performed by the robot. In some embodiments, the task configuration is synchronized with the server as needed, at the end of training, or when the current task changes.

[0046] The system configuration file includes the operating system, firmware, and libraries used to run the robot. In some embodiments, the system configuration may be specified as a set of libraries / modules, or as an image (or possibly a Docker file) with optional modifications. In some embodiments, the system configuration is managed as a very small set of basic configurations, plus multiple "add-ons" for optional modules to be installed on the robot.

[0047] In some embodiments, dependencies (hardware, tasks, and systems) are hierarchical. For example, a task may use specific hardware and system configurations, and the hardware configuration may require specific system configurations. However, the system configuration may not have any hardware or task requirements to prevent cyclic redundancy. In some embodiments, configuration assets are received from asset manager 406 to maintain separation and security. According to some embodiments, communication between the robot and robot management server 402 is encrypted. For authentication, the server can provide its public key to establish its identifier and establish an encrypted channel. Client devices (e.g., robot client 408) verify their own identifiers and can exchange data between the server and the client. In some embodiments, the robot's unique identifier may be encoded in a client certificate and used in API requests to the server. The server may track the robot's unique identifier associated with the encrypted session and respond with configuration data suitable for the requesting robot.

[0048] During robot operation, the robot can exchange configuration data with the server under various circumstances. These circumstances may include the following:

[0049] • When the robot starts up. When the robot is powered on, it will request the current configuration from the server. All three configuration types—task, hardware, and system—are expected to be received at this time.

[0050] • When recalibrating or updating hardware. When the robot undergoes physical modifications as part of routine maintenance or receives hardware upgrades, the robot's web application can be used to update the hardware configuration on the robot and synchronize this data with the Giant server suite.

[0051] • When a request is made by the site management console or the robot web application. The operator of the site management console can trigger the download or upload of the current configuration data.

[0052] When configuration data is downloaded to the robot, in some embodiments, it is handed over to a dependency manager 410 to resolve dependencies and ensure that all associated assets are available on the robot. This includes making changes to software libraries installed on the robot, as well as downloading any assets required for the task configuration. These assets include, but are not limited to (this is not to imply that the other list is limiting), neural network configurations and weights.

[0053] If the dependencies cannot be resolved or the assets cannot be found, in some embodiments, the dependency manager rejects the entire configuration and the robot reverts to its previous state.

[0054] Note that in some embodiments, the robot's unique ID is included in all requests from the robot to the server (including configuration requests). In some embodiments, the configuration data sent by the server will be specific to the requesting robot and may depend not only on the robot's brand and model but also on other properties associated with the robot—such as partners or management groups.

[0055] Configuration data can be stored as one or more YAML files on the robot client 408. In some embodiments, these files are stored in the configuration directories configs / hw, configs / sw, and configs / task. For data management purposes, there may be multiple YAML files in each directory; however, the data in each directory may be exposed in a unified API. That is, although the hardware directory may contain files "model.yaml" and "instance.yaml" (which describe the hardware configuration associated with all robots for a particular model and the configuration associated with a particular robot, respectively), API calls to the hw_config module hide that specific implementation detail.

[0056] In some embodiments, dependencies are specified in the dependency section of the configuration file. Software dependencies can be specified as package names and version numbers. Hardware dependencies can be specified by an ID corresponding to verified hardware.

[0057] Figure 5 An example system for experience collection and management of dynamic mechanical systems, according to some embodiments, is shown. System 500 includes a management server 102, which includes an experience collection 106 that communicates with a robot client 408, the robot client 408 having an experience management 502 module and an experience collector 504.

[0058] While the robot is running, in some embodiments, it is collecting runtime experience via experience collector 504. This may include data streams from the robot's sensors, information about the task the robot is performing, the robot's successes in that task, and any unusual conditions encountered by the robot. In some embodiments, this information may be transmitted back to the robot management server 102 via experience management 502 for analysis.

[0059] Because the total volume of runtime experience can be very large, various mechanisms can be used to reduce the amount of data sent to the server. In some embodiments, at a high level, the robot's configuration can specify experience filters to reduce the amount of data processed. These filters can tell the system to capture data only at a specific frequency, only at a specific level, or only for a specific module. In some embodiments, partners (e.g., third-party users) can also specify filters if they want to ensure that certain types of data are not transmitted to the server.

[0060] In some embodiments, after processing the data through a filter, the compressor reduces the data size and packages it into blocks for storage and subsequent transmission. In some embodiments, the experience collector 504 is responsible for sending data to the server or deleting data when there is no longer space available for it on local storage. The experience collector 504 can be configured to preferentially purge data from designated modules, giving data from other modules a greater chance of being sent back to the server. In some embodiments, data can also be tagged with an "interest metric" at runtime, which also increases the importance of the data (and thus increases its lifetime).

[0061] During standard operation, the robot is activated, located for its task, and given a command to start the task. The robot performs the task until it is completed, stopped, or paused. The robot can stop or pause if 1) the local operator presses the "stop" or "pause" button on the robot, 2) the remote operator stops or pauses the robot, 3) the task has been completed, or 4) the robot encounters a condition that would cause it to stop or pause.

[0062] In some embodiments, during a normal stop, the robot undergoes its standard shutdown procedure, which may include moving to a standard shutdown position. According to IEC 60204-1, this is considered a Level 1 stop, where the robot is controlled during shutdown and power is removed from the servo mechanism when the stop is complete.

[0063] According to IEC 60204-1, "pause" is considered a Level 2 stop, where the servo mechanism no longer receives commands but continues to be powered. In some embodiments, when paused, the robot maintains its position and awaits additional commands from the operator. In some embodiments, during the paused state, the operator is free to correct any conditions that prompted the pause, stop the robot, enter a troubleshooting session (see Troubleshooting section), or provide training feedback to the robot (see Training section). In some embodiments, the robot will not resume operation from the paused state without an explicit command from the operator.

[0064] "Servo Power" is Level 0 (Uncontrolled) Stop, where power is immediately removed from the servo mechanism. In some embodiments, "Stop" and "Pause" commands are available via physical buttons attached to the robot and via API calls from the site management console. "Start" and "Resume" commands are similar, except that in some embodiments, the "Start" and "Resume" API calls are available if a physical "Remote Start" switch on the robot is set to "ON" and "Remote Start" is implemented. This prevents unintentional starting or restarting of the robot in situations where starting or restarting the robot might be harmful to the robot or its environment.

[0065] Data collected during task execution (including start time, elapsed time, pause time, and completion time) can be transmitted from robot client 408 to experience collector 106 via experience collector 504. Experience collector 106 can use some or all of the collected data to integrate with the established monitoring and management system.

[0066] Figure 6 A flowchart of a method for managing a dynamic mechanical system according to some embodiments is shown. Method 600 is executed at a computing device (e.g., management server 102). In some embodiments, the steps of method 600 are implemented at a robot client (e.g., robot client device 118).

[0067] Method 600 begins when the computing device prepares (602) a mechanical system (e.g., a dynamic mechanical system). Preparation of the mechanical system may include physically assembling the mechanical system. The computing device may then obtain (604) configuration data for the mechanical system. In some embodiments, the configuration data includes hardware configuration data, task configuration data, and system configuration data. The computing system may then train (606) the mechanical system using any of the methods described herein. After training the mechanical system, the computing device may assign (608) the mechanical system to a location. For example, the mechanical system is one of many mechanical systems configured to perform harmoniously as a fleet of mechanical systems. A first mechanical system may be assigned to location A, while a second mechanical system may be assigned to location B. The assigned locations and the assignment of mechanical systems to a particular fleet may be changed or updated at any time.

[0068] After the computing system assigns a position to the mechanical system, it provides (610) one or more tasks to be performed by the mechanical system. As an example, a robot (e.g., the mechanical system) is part of an assembly line manufacturing a car. The robot's task might be to install tires onto the car body. The computing system monitors (612) the execution of the tasks and may receive data streams related to sensor information captured by the robot. The computing system can then retrieve (614) task execution data. Task execution data may include details about how the task was performed, whether the task was successfully performed, the duration of the task, sensor readings from the robot performing the task, or any other details related to the task execution. Additionally, and / or alternatively, the computing system retrieves (616) task experience data. Task experience data may differ from task execution data. Task experience data refers to data collected about peripheral conditions observed during task execution, while task execution data refers to data collected about the actual execution of the task. In some embodiments, task execution data is sent (618) to a server for processing. For example, task execution data is sent to machine learning model 202. Method 600 may also include the computing system sending (620) task experience data to train the mechanical system.

[0069] Figure 7 A block diagram of a representative system 700 comprising one or more robot systems 702 according to some embodiments is shown.

[0070] The computing system 700 may include a robot system 702, a robot system 716, a development system 722, a server 708, a user device 710, and a task database 714. The robot system (e.g., robot system 716) may include a sensor module 718, a machine learning subsystem 720, and a communication module 724.

[0071] Robot system 702 is an example of a robot that includes sensor module 704 and machine learning subsystem 706. Additional modules may be included, but... Figure 7 Not shown in the diagram. Robot system 702 can be configured modularly, meaning that one or more modules can be added to or removed from robot system 702. Robot system 716 can be a robot substantially the same as robot system 702.

[0072] The sensor module 704 of the robot system 702 may include multiple sensors, including temperature sensors, pressure sensors, cameras, inertial measurement units (IMUs), and various other configurable sensors. Each sensor may be configured to provide sensor data to an onboard computer system or to transmit sensor data via network 712 to one or more computing devices, including server 708 and / or user equipment 710.

[0073] Machine learning subsystem 706 may include multiple machine learning models. For example, machine learning subsystem 706 may pipeline an encoder and a reinforcement learning model, which are jointly trained through end-to-end learning. The encoder is operable to convert the relatively high-dimensional outputs of the robot's sensor suite into low-dimensional vector representations for each time slice in the latent embedding space, and the reinforcement learning model is configured to update the setpoint of the robot's actuators based on those vectors. Some embodiments of machine learning subsystem 706 may include encoder models, dynamic models, actor-critic models, reward models, anomaly detection models, or various other machine learning models (e.g., combined with...). Figure 2 (Any model described). One or more parts of the machine learning subsystem 706 may be implemented on the robot system 702, server 708, or development system 722. Although in Figure 7 Although shown as different objects, the functions described below in conjunction with robot system 702, server 708, or development system 722 can be performed by any one of robot system 702, server 708, or development system 722. Robot system 702, server 708, or development system 722 can communicate with each other via network 712.

[0074] Robot system 716 can use communication module 724 to communicate with another robot system (e.g., robot system 702), server 708, development system 722, user equipment 710, task database 714, or any other networked peripheral device.

[0075] The development system 722 can communicate with robot systems, user equipment, predictive databases, and servers, serving as a platform for application development. Applications are understood to mean any type of robot interface, robot task, dashboard display, or any other application that utilizes sensor data collected from the robot within the robot system.

[0076] The task database 714 may include a catalog of possible tasks that the robot fleet can handle. For example, the task database 714 includes a list of various task categories that the robots can perform. Robot A may be able to pick up, move, and store objects weighing up to 25 pounds, while robot B may only be able to pick up, move, and store objects weighing up to 5 pounds. The actuation database may include data related to robot capabilities and historical information about task execution (e.g., wear state vectors for each actuator of each robot). Additional information may be stored in the actuation database, including optimization algorithms, one or more machine learning models, training data, historical data, metadata, performance data, and cost schedules.

[0077] Robot system 702 can acquire records generated from one or more user devices 710. User device 710 can be used as an input device for a human operator who instructs the robot to perform one or more tasks. For example, user A of user device 710 submits a request to perform a set of tasks. This request can be routed via network 712 to task database 714, server 708, development system 722, and / or robot system 702 or robot system 716 to perform the set of tasks.

[0078] Robot system 702 may include one or more cameras for recording the environment around it. The cameras may include one or more RGB cameras (e.g., those with complementary metal-oxide-semiconductor), one or more infrared cameras, one or more depth-sensing cameras, or various other cameras. In some cases, the cameras are arranged in a stereo array, and some embodiments use structured light, time-of-flight, or LiDAR to sense depth. Development system 722 may output video or images obtained via the cameras of robot system 702 to a display device (not shown) on the robot. The display device may include a virtual reality headset, an augmented reality display (e.g., augmented reality glasses), a screen, or various other displays.

[0079] In some embodiments, the robot implementing the technology of the present invention can be trained and controlled using models such as those described in U.S. Patent Application No. 059692-0567703 entitled “SPATIO-TEMPORAL CONSISTENCYEMBEDDINGS FROM MULTIPLE OBSERVED MODALITIES”, filed on the same day as this patent application by the same applicant.

[0080] In some embodiments, the robot implementing the technology of the present invention can be trained and controlled using models such as those described in U.S. Patent Application No. 059692-0567705 entitled "HYBRID COMPUTING ARCHITECTURES WITH SPECIALIZED PROCESSORS TO ENCODE / DECODE LATENT REPRESENTATIONS FOR CONTROLLING DYNAMICMECHANICAL SYSTEMS", filed on the same day as this patent application by the same applicant.

[0081] In some embodiments, the robot implementing the technology of the present invention can be managed by a system such as those described in U.S. Patent Application No. 059692-0567707 entitled “SYSTEM FOR PRESENTING ROBOTIC DATA FLOWS FOR APPLICATIONDEVELOPMENT”, filed on the same day as this patent application by the same applicant.

[0082] In some embodiments, the robot implementing the technology of the present invention may have touch sensors, such as those described in U.S. Patent Application No. 059692-0567709 entitled "COMBINED ANALOG AND DIGITAL ARCHITECTURE FOR HANDLINGSENSORY INPUT DATA", filed on the same day as this patent application by the same applicant.

[0083] In some embodiments, a fleet of robots implementing the technology of the present invention can be managed by a system such as those described in U.S. Patent Application No. 059692-0567713 entitled “SCHEDULER FOR ROBOT FLEETS”, filed on the same day as this patent application by the same applicant.

[0084] Figure 8 Example system 800 is illustrated, which depicts an example computing system for implementing a method for managing a dynamic mechanical system according to some embodiments. Various parts of the systems and methods described herein may include or execute on one or more computer systems similar to computing system 800. Furthermore, the processes and modules described herein may be executed by one or more processing systems similar to computing system 800.

[0085] Computer system 802 may include one or more processors (e.g., processors 804, 806, 808) coupled to system memory 816, input / output 814, and network interface 812 via input / output I / O interface 810. The processors may include a single processor or multiple processors (e.g., a distributed processor). The processor may be any suitable processor capable of executing or otherwise implementing instructions. The processor may include a central processing unit (CPU) that executes program instructions to perform arithmetic, logical, and input / output operations of computer system 802. The processor may execute code that creates an execution environment for the program instructions (e.g., processor firmware, protocol stack, database management system, operating system, or combinations thereof). The processor may include a programmable processor. The processor may include a general-purpose or special-purpose microprocessor. The processor may receive instructions and data from memory (e.g., system memory 816). Computer system 802 may be a single-processor system including one processor (e.g., processor 804), or a multiprocessor system including any number of suitable processors (e.g., 804-808). Multiple processors can be employed to provide parallel or sequential execution of one or more portions of the techniques described herein. Processes such as logical flows described herein can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating corresponding outputs. Processes described herein can be executed by special-purpose logic circuits (e.g., FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits)), and devices can also be implemented as special-purpose logic circuits (e.g., FPGAs or ASICs). Computer system 802 may include multiple computing devices (e.g., a distributed computer system) to implement various processing functions.

[0086] I / O device interface 814 provides an interface for connecting one or more I / O devices 824 to computer system 802. I / O devices may include devices for receiving input (e.g., from a user) or outputting information (e.g., to a user). I / O devices 824 may include, for example, graphical user interfaces presented on a display (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, etc. I / O devices 824 can be connected to computer system 802 via wired or wireless connections. I / O devices 824 can be connected to computer system 802 from remote locations. For example, I / O devices 824 located on a remote computer system can be connected to computer system 802 via network 822 and network interface 812.

[0087] Network interface 812 may include a network adapter that provides connectivity from computer system 802 to network 822. Network interface 812 facilitates data exchange between computer system 802 and other devices connected to the network. Network interface 812 may support wired or wireless communication. The network may include electronic communication networks such as the Internet, local area network (LAN), wide area network (WAN), cellular communication network, etc.

[0088] System memory 816 may be configured to store program instructions 818 or data 820. Program instructions 818 may be executed by a processor (e.g., one or more processors 804-808) to implement one or more embodiments of the present invention. Instructions 818 may include modules for implementing one or more of the techniques described herein with respect to various processing modules. Program instructions may include computer programs (which are referred to in some forms as programs, software, software applications, scripts, or code). Computer programs may be written in programming languages, including compiled or interpreted languages, or declarative or procedural languages. Computer programs may include units suitable for use in a computing environment, including units as stand-alone programs, modules, components, or subroutines. Computer programs may or may not correspond to files in a file system. Programs may be stored as a portion of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., portions of files storing one or more modules, subroutines, or code). Computer programs can be deployed to execute on one or more computer processors, which are located locally at a site or distributed across multiple remote sites and interconnected via a communication network.

[0089] System memory 816 may include a tangible program carrier on which program instructions are stored. The tangible program carrier may include a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium may include a machine-readable storage device, a machine-readable storage substrate, a memory device, or any combination thereof. A non-transitory computer-readable storage medium may include non-volatile memory (e.g., flash memory, ROM, PROM, EPROM, EEPROM memory), volatile memory (e.g., random access memory (RAM), static random access memory (SRAM), synchronous dynamic RAM (SDRAM)), mass storage memory (e.g., CD-ROM and / or DVD-ROM, hard disk drive), etc. System memory 816 may include a non-transitory computer-readable storage medium on which program instructions may be stored, which may be executed by a computer processor (e.g., one or more processors 804-808) to cause the operation of the subjects and functions described herein. Memory (e.g., system memory 816) may include a single memory device and / or multiple memory devices (e.g., distributed memory devices).

[0090] I / O interface 810 can be configured to coordinate I / O traffic between processors 804-808, system memory 816, network interface 812, I / O devices 824, and / or other peripheral devices. I / O interface 810 can perform protocol, timing, or other data conversions to transform data signals from one component (e.g., system memory 816) into a format suitable for use by another component (e.g., processors 804-808). I / O interface 810 may include support for devices attached via various types of peripheral buses (e.g., Peripheral Component Interconnect (PCI) bus standards or variants of the Universal Serial Bus (USB) standard).

[0091] Embodiments of the techniques described herein can be implemented using a single instance of computer system 802 or multiple computing systems 800 configured to host different portions or instances of the embodiments. Multiple computing systems 800 can provide parallel or sequential processing / execution of one or more portions of the techniques described herein.

[0092] Those skilled in the art will understand that the computing system 800 is merely illustrative and not intended to limit the scope of the techniques described herein. The computing system 800 may include any combination of devices or software, provided that such combination can perform or otherwise provide the performance of the techniques described herein. For example, the computing system 800 may include, or a combination thereof, cloud computing systems, data centers, server racks, servers, virtual servers, desktop computers, laptop computers, tablet computers, server equipment, client devices, mobile phones, personal digital assistants (PDAs), mobile audio or video players, game consoles, in-vehicle computers, or global positioning systems (GPS), etc. The computing system 800 may also be connected to other devices not shown, or may operate as a standalone system. Furthermore, in some embodiments, the functionality provided by the illustrated components may be combined in fewer components or distributed across additional components. Similarly, in some embodiments, the functionality of some illustrated components may not be provided, or other additional functionality may be available.

[0093] Those skilled in the art will also understand that while various items are shown as being stored in memory or on storage devices during use, these items, or portions thereof, may be transferred between memory and other storage devices for memory management and data integrity purposes. Alternatively, in other embodiments, some or all of the software components may be executed in memory on another device and communicate with the illustrated computer system via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as instructions or structured data) on a computer-accessible medium or a portable item to be read by a suitable drive, various examples of which are described above. In some embodiments, instructions stored on a computer-accessible medium separate from the computing system 800 may be transmitted to the computing system 800 via a transmission medium or signal (e.g., electrical, electromagnetic, or digital signal) transmitted via a communication medium such as a network or wireless link. Various embodiments may also include receiving, transmitting, or storing instructions or data implemented according to the foregoing description on a computer-accessible medium. Therefore, this disclosure can be practiced with other computer system configurations.

[0094] In the block diagram, the components are depicted as discrete functional blocks, but the embodiments are not limited to a system in which the functions described herein are organized as shown. The functionality provided by each component may be provided by software or hardware modules organized in a different manner than those currently depicted; for example, such software or hardware may be intermingled, conjoined, replicated, decomposed, distributed (e.g., within a data center or geographically), or otherwise organized differently. The functions described herein may be provided by one or more processors of one or more computers, which execute code stored on a tangible, non-transitory machine-readable medium. In some cases, a third-party content delivery network may host some or all of the information transmitted over the network, in which case the information (e.g., content) may be provided, to the extent that it is said to be supplied or otherwise made available, by sending an instruction to retrieve the information from the content delivery network.

[0095] Readers should understand that this application describes several independently useful techniques. Instead of separating these techniques into multiple isolated patent applications, the applicant has combined them into a single document because their related topics help save costs during the application process. However, the unique advantages and aspects of such techniques should not be confused. In some cases, embodiments address all the deficiencies mentioned herein; however, it should be understood that these techniques are independently useful, and some embodiments address only a subset of these problems or provide other unmentioned benefits that will be apparent to those skilled in the art upon review of this disclosure. Due to cost constraints, some techniques disclosed herein may not currently be claimed but may be claimed in a later application (e.g., a continuation application or by amending the claims of this invention). Similarly, due to space limitations, the abstract or summary of the inventive portion of this document should not be considered a comprehensive list encompassing all of these techniques or all aspects of these techniques.

[0096] This description is not intended to limit the invention to the specific forms disclosed, but rather to cover all modifications, equivalents, and substitutions falling within the spirit and scope of the invention as defined by the appended claims. Further modifications and alternative embodiments of various aspects of the invention will be apparent to those skilled in the art in light of this description. Therefore, this description and drawings are to be interpreted as illustrative only and as a general way of practicing the invention for the purpose of teaching those skilled in the art. It should be understood that the forms of the invention shown and described herein will be considered as examples of embodiments. Elements and materials may be substituted for those shown and described herein, components and processes may be reversed or omitted, and certain features of the invention may be utilized independently, all of which will be apparent to those skilled in the art after benefiting from this description. Changes may be made to the elements described herein without departing from the spirit and scope of the invention as described in the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of the description.

[0097] As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning possible) rather than a mandatory sense (i.e., meaning must). The words “include,” “including,” and “includes,” etc., mean including but not limited to. As used throughout this application, the singular forms “a,” “an,” and “the” include the plural objects referred to, unless the content expressly indicates otherwise. Thus, for example, a reference to “one element” or “one element” includes a combination of two or more elements, even though other terms and phrases (e.g., “one or more”) are used for one or more elements. Unless otherwise indicated, the term “or” is non-exclusive, i.e., includes both “and” and “or.” Terms describing conditional relationships (e.g., "in response to X, Y", "on X, Y", "if X, Y", "when X, Y", etc.) contain causal relationships, where the antecedent is a necessary causal condition, the antecedent is a sufficient causal condition, or the antecedent is a contributing causal condition to the outcome. For example, "state X occurs when condition Y is acquired" is common to "X occurs only on Y" and "X occurs on Y and Z". Such conditional relationships are not limited to outcomes that occur immediately after the antecedent is acquired, as some outcomes may be delayed, and in a conditional statement, the antecedent is related to its outcome; for example, the antecedent is related to the probability of the outcome occurring. Unless otherwise indicated, a statement in which multiple attributes or functions are mapped to multiple objects (e.g., one or more processors performing steps A, B, C, and D) includes all such attributes or functions mapped to all such objects and subsets of attributes or functions mapped to subsets of attributes or functions (e.g., all processors each perform steps A-D, and the case where processor 1 performs step A, processor 2 performs a portion of steps B and C, and processor 3 performs a portion of steps C and D). Similarly, references to the “computer system” performing step A and the “computer system” performing step B can include the same computing device within the computer system performing both steps, or different computing devices within the computer system performing steps A and B. Furthermore, unless otherwise indicated, a statement that a value or action is “based on” another condition or value includes both the case where the condition or value is the only factor and the case where the condition or value is one of several factors. Unless otherwise indicated, a statement that “each” instance in a certain set possesses a certain property should not be interpreted as excluding the case where other identical or similar members in a larger set do not possess that property; that is, each does not necessarily mean every and every.Limitations on the order of steps should not be interpreted in the claims unless explicitly stated, for example, using explicit language such as “after performing X, perform Y,” in contrast to statements that might be inappropriately interpreted as implying a restriction on order (such as “perform X on item, perform Y on item for which X has already been performed”), which are used to make the claims more readable rather than specifying an order. Statements involving “at least Z of A, B, and C” (e.g., “at least Z of A, B, or C”) refer to at least Z of the listed categories (A, B, and C) and do not require at least Z units in each category. Unless otherwise specifically stated, as is apparent from the discussion, it should be understood that throughout this specification, discussions using terms such as “processing,” “computing,” “calculating,” and “determining” refer to the actions or processes of a particular apparatus (e.g., a dedicated computer or similar dedicated electronic processing / computing device). Features described with reference to the geometry (such as "parallel," "perpendicular / orthogonal," "square," "cylindrical," etc.) should be interpreted as including items that substantially embody the properties of the geometry; for example, a reference to a "parallel" surface includes substantially parallel surfaces. The permissible deviations of these geometries from the Platonic ideal will be determined by the ranges in the specification, and where no such range is specified, reference will be made to industry standards in the field of application; where no such range is defined, reference will be made to industry standards in the field of manufacturing the specified feature; and where no such range is defined, features substantially embodying the geometry should be interpreted as including those features within 15% of the defined properties of that geometry. The terms "first," "second," "third," "given," etc., if used in the claims, are used to distinguish or otherwise identify, rather than to indicate order or numerical limitation. As is common practice in this field, data structures and formats described with reference to human-natured uses do not need to be presented in a human-understandable format to constitute the described data structure or format. For example, text does not need to be reproduced in Unicode or ASCII or even encoded to constitute text; images, maps, and data visualizations do not need to be displayed or decoded to constitute images, maps, and data visualizations, respectively; speech, music, and other audio do not need to be emitted through a speaker or decoded to constitute speech, music, or other audio, respectively. Computer-implemented instructions, commands, etc., are not limited to executable code and can be implemented in the form of data that causes a function to be invoked (e.g., in the form of parameters of a function or API call). Where a claim uses a custom noun phrase (and other inventive terms) and lacks a self-evident structure, the definition of such a phrase may be stated in the claim itself. In such cases, the use of such a custom noun phrase should not be considered an invitation to impose additional limitations by reviewing the specification or external evidence.

[0098] In this patent, to the extent that any U.S. patent, U.S. patent application, or other material (e.g., an article) has been incorporated by reference, the text of such material is incorporated only to the extent that there is no conflict between such material and the statements and figures set forth herein. In the event of such conflict, the text of this document shall prevail, and the terminology in this document shall not be given a narrower interpretation due to the manner in which such terminology is used in other materials incorporated by reference.

[0099] The present invention will be better understood by referring to the following examples:

[0100] 1. A distributed robot management system, comprising: a first robot fleet located at a first facility; and a robot management server system located remotely from the first facility and communicatively coupled to the first robot fleet via a network, wherein the robot management server system is configured to: provide configuration information to the first robot fleet, maintain a remote representation of the state of the robots in the first robot fleet, receive and store data from the first robot fleet, and provide computing resources for training the robots in the first robot fleet.

[0101] 2. The system according to Embodiment 1, wherein: the system includes a second robot fleet located at a second facility remote from both the robot management server system and the first robot fleet, the first robot fleet being associated with a first tenant account, and the second robot fleet being associated with a second tenant account; the robot management server system is configured to: provide configuration information to the second robot fleet, maintain a remote representation of the state of the robots in the second robot fleet, receive and store data from the second robot fleet, and provide computing resources for training the robots in the second robot fleet; the first robot fleet includes more than 5 humanoid robots; and the second robot fleet includes more than 5 humanoid robots.

[0102] 3. The system according to Embodiment 1, wherein providing configuration information to the first robot fleet includes providing a corresponding hardware and software configuration specific to each robot model in the first fleet and each instance of the corresponding robot model in the first fleet.

[0103] 4. The system according to Embodiment 1, wherein providing configuration information to the first robot fleet includes providing task information that describes the configuration, assets and dependencies required to perform a task using the robots in the first fleet.

[0104] 5. The system according to Embodiment 1, wherein providing configuration information to the first robot fleet includes: receiving a request for configuration data from a given robot in the first robot fleet; authenticating the request as originating from a given robot in the first robot fleet using public-key cryptography; and determining authorized access confirmation information for the given robot, and providing configuration information in response.

[0105] 6. The system according to Embodiment 1, wherein the configuration information includes the neural network weights of the model, and at least some of the robots in the first robot fleet will be controlled by the model.

[0106] 7. The system according to Embodiment 1, wherein maintaining a remote representation of the state of the robots in the first robot fleet includes: providing at least some of the robots in the first fleet with data such as manufacturing date, model, geographical location, power status, configuration, and instructions on the tasks that the respective robots can perform.

[0107] 8. The system according to embodiment 1, wherein receiving and storing data from the first robot fleet includes: receiving and storing information acquired by at least some of the robots in the first robot fleet during operation.

[0108] 9. The system according to embodiment 8, wherein the information obtained by at least some robots includes data based on sensor trajectories from sensors of at least some robots and data indicating the context in which the sensor trajectories were obtained.

[0109] 10. The system according to embodiment 1, wherein a given robot in a first robot fleet is configured to provide at least some of the data from the robot fleet to a robot management server system, wherein providing at least some of the data to the robot management server system includes: applying an experience filter to data indicating the running time experience of the given robot; grouping the data indicating the running time experience into groups; compressing the data indicating the running time experience; and clearing the data indicating the running time experience from the memory of the given robot after sending the groups to the robot management server system.

[0110] 11. The system according to embodiment 1, wherein a given robot in a first robot fleet includes a robot computer configured to operate as a client of a robot management server system, and: controls the given robot during the execution of a task runtime; cooperates with the robot management server system to configure the given robot; trains the given robot; and provides status and experience data to the robot management server system.

[0111] 12. The system according to embodiment 11, wherein: the robot computer is configured to control more than 20 servo motors of a given robot via a reinforcement learning model, the reinforcement learning model being configured to take as input a temporally slidable latent embedding space representation of sensor data from at least five sensors of the given robot.

[0112] 13. The system according to embodiment 11, wherein: the robot computer is configured to host a web application or application programming interface accessible by a local mobile application on a user's mobile computing device; the web application or local application provides a user interface through which the user trains or configures a given robot.

[0113] 14. The system according to embodiment 11, wherein a given robot is coupled to an auxiliary computing device that is different from a robot computer, the auxiliary computing device being configured to present a visualization of robot performance when the given robot is operating.

[0114] 15. A method comprising: providing instructions to a robot using a computer system for performing one or more tasks in the first set; receiving instructions from the computer system for the robot to perform one or more tasks in the first set; receiving sensor data collected by the robot during the performance of one or more tasks using the computer system; preparing instructions for the robot to perform one or more tasks in the second set using the sensor data; and providing instructions to the robot using the computer system for performing one or more tasks in the second set.

[0115] 16. The method according to embodiment 15, wherein the robot is a first robot, and the system includes: providing instructions to a second robot via a computer system for performing one or more tasks in a second set.

[0116] 17. The method according to embodiment 15 includes: receiving an instruction to power on a first robot and a request for a current configuration using a computer system; and sending the current configuration for the first robot, including tasks, hardware, and system configuration files, using the computer system.

[0117] 18. The method according to embodiment 15 includes: receiving a fault report from a robot using a computer system; providing a troubleshooting procedure using the computer system to resolve one or more faults provided in the fault report; and sending a power-off command to the robot based on an indication that the troubleshooting procedure is unsuccessful.

[0118] 19. The method according to embodiment 15 includes: training a machine learning model associated with providing tasks to a robot using sensor data; and using the machine learning model to provide instructions for performing a second set of tasks.

[0119] 20. The method according to embodiment 15 includes: providing access to a robot to a third party using a computer system; receiving from the third party a third request for the robot to perform a third set of tasks; sending the third set of tasks to the robot for performance; maintaining logs for one or more robots, including the physical location of each robot; and assigning tasks in the set of tasks to robots, at least in part based on the robot's location; and determining that the robot is a first type of robot, wherein the first type is compatible with the performance of the first task.

Claims

1. A distributed robot management system, comprising: First robot fleet; as well as A robot management server system, which is communicatively coupled to the first robot fleet via a network, wherein the robot management server system provides multiple types of interfaces including the following: A management interface accessed by the system administrator, which is configured to perform system management functions; A partner interface accessed by a first user of the first facility, enabling the deployment of the first robot fleet at the first facility, the partner interface being configured to manage tasks of the first robot fleet at the first facility; and A robot interface accessed by a single robot in the first robot fleet, the robot interface being configured to: - Request a task; - Provide first configuration information to the first robot fleet, wherein the first configuration information includes hardware configuration, system configuration and asset configuration for one or more robots in the first robot fleet, wherein the asset configuration includes neural network weights of a model, through which the one or more robots are controlled; - Maintaining a remote representation of the state of the robots in the first robot fleet, wherein maintaining the remote representation of the state of the robots in the first robot fleet includes: -- Provide at least some of the robots in the first robot fleet with the manufacturing date of the respective robot, the model of the respective robot, the geographical location of the respective robot, the current power status of the respective robot, the current configuration information of the respective robot, and data indicating the tasks that the respective robot can perform; - Receive and store data from the first robot fleet, and - Provide computing resources to train the robots in the first robot fleet; Wherein, a given robot in the first robot fleet includes a robot computer, the robot computer being configured to operate as a client of the robot management server system via the robot interface, and: Control the given robot during the execution of the task's runtime; The given robot is configured in collaboration with the robot management server system via the robot interface; Training the given robot; and The robot provides status and experience data to the robot management server system via the robot interface; Furthermore, the robot computer is configured to control more than 20 servo motors of the given robot via a reinforcement learning model, the reinforcement learning model being configured to take a temporally slidable latent embedding space representation of sensor data from at least five sensors of the given robot as input; It further includes a second robot fleet, wherein the partner interface is also configured to be accessed by a second user of the second facility, the second robot fleet being deployable at the second facility, and the partner interface being configured to manage the tasks of the second robot fleet at the second facility.

2. The system according to claim 1, wherein, Providing the first configuration information to the first robot fleet includes providing the corresponding hardware and system configurations specific to each robot model in the first robot fleet and for each instance of the corresponding robot model in the first robot fleet.

3. The system according to claim 1, wherein, The first configuration information provided to the first robot fleet also includes task information and dependencies required to perform tasks using the robots in the first robot fleet.

4. The system according to claim 1, wherein, Providing the first configuration information to the first robot fleet includes: Receive a request for configuration information from a given robot in the first robot fleet; The request is authenticated as originating from the given robot in the first robot fleet using public-key cryptography; Determine that the given robot is authorized to access the configuration information, and provide the configuration information in response.

5. The system according to claim 1, wherein, The robot interface is also configured to receive and deliver updates to machine learning models that can be deployed by individual robots in the first robot fleet.

6. The system according to claim 1, wherein, Each robot in the first robot fleet includes a corresponding onboard machine learning subsystem with an encoder operable to convert high-dimensional sensor outputs into low-dimensional vector representations in a potential embedding space.

7. The system according to claim 1, wherein, Receiving and storing data from the first robot fleet includes: Receive and store information acquired by at least some of the robots in the first robot fleet during operation.

8. The system according to claim 7, wherein, The information obtained by the at least some of the robots includes: data based on sensor trajectories from sensors of the at least some of the robots and data indicating the context in which the sensor trajectories were obtained.

9. The system according to claim 1, wherein, A given robot in the first robot fleet is configured to provide at least some of the data from the robot fleet to the robot management server system via the robot interface, wherein providing at least some of the data to the robot management server system includes: An experience filter is applied to the data indicating the running time experience of the given robot; The data indicating runtime experience is grouped; The data provided by the compression indicator running time experience; and After the group is sent to the robot management server system via the robot interface, the data indicating runtime experience is cleared from the memory of the given robot.

10. The system according to claim 1, wherein: The robot computer is configured to be a web application or application programming interface accessible to a local mobile application on the user's mobile computing device. and The web application or local application provides access to the robot interface, through which the user trains or configures the given robot.

11. The system according to claim 1, wherein, The given robot is coupled to an auxiliary computing device, which is different from the robot computer, and the auxiliary computing device is configured to present a visualization of the robot's performance via the robot interface when the given robot is in operation.

12. The system according to claim 1, wherein, The management interface is also configured to enable the system administrator to control the first user's access to the first robot fleet via the partner interface and the second user's access to the second robot fleet via the partner interface.

Images