WO2020042385A1 - 机器人集群调度系统 - Google Patents

机器人集群调度系统 Download PDF

Info

Publication number
WO2020042385A1
WO2020042385A1 PCT/CN2018/116499 CN2018116499W WO2020042385A1 WO 2020042385 A1 WO2020042385 A1 WO 2020042385A1 CN 2018116499 W CN2018116499 W CN 2018116499W WO 2020042385 A1 WO2020042385 A1 WO 2020042385A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
robot
module
layer
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/116499
Other languages
English (en)
French (fr)
Inventor
沈东羽
苏衍宇
毛建财
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Bozhon Robot Co Ltd
Bozhon Precision Industry Technology Co Ltd
Original Assignee
Suzhou Bozhon Robot Co Ltd
Bozhon Precision Industry Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suzhou Bozhon Robot Co Ltd, Bozhon Precision Industry Technology Co Ltd filed Critical Suzhou Bozhon Robot Co Ltd
Priority to SG11202002289WA priority Critical patent/SG11202002289WA/en
Priority to EP18923759.7A priority patent/EP3636390B1/en
Priority to US16/628,465 priority patent/US11345020B2/en
Publication of WO2020042385A1 publication Critical patent/WO2020042385A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Program-controlled manipulators
    • B25J9/0084—Program-controlled manipulators comprising a plurality of manipulators
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Program-controlled manipulators
    • B25J9/16—Program controls
    • B25J9/1656—Program controls characterised by programming, planning systems for manipulators
    • B25J9/1661—Program controls characterised by programming, planning systems for manipulators characterised by task planning, object-oriented languages
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41865—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by job scheduling, process planning, material flow
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4189—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the transport system
    • G05B19/41895—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the transport system using automatic guided vehicles [AGV]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/39—Robotics, robotics to robotics hand
    • G05B2219/39146—Swarm, multiagent, distributed multitask fusion, cooperation multi robots
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/39—Robotics, robotics to robotics hand
    • G05B2219/39167—Resources scheduling and balancing
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/39—Robotics, robotics to robotics hand
    • G05B2219/39252—Autonomous distributed control, task distributed into each subsystem, task space
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/60—Electric or hybrid propulsion means for production processes

Definitions

  • the present disclosure relates to robotics, for example, to a robot cluster scheduling system.
  • a robot scheduling system includes: a robot control system and an intermediate control system.
  • the robot control system is configured to obtain robot management information from an intermediate control system, generate a task instruction according to the robot management information, and send the task instruction to a guide vehicle or an external device associated with the task instruction.
  • the intermediate control system includes a first interface layer, an intermediate service processing layer, and an access layer.
  • the first interface layer includes a service interface configured to obtain a task package from a service management system, and the intermediate service processing layer is configured to The task package generates robot management information.
  • the access layer includes a control interface. The access layer is connected to the robot control system through the control interface.
  • the above-mentioned robot scheduling system does not support secondary development.
  • the robot control system sends a task instruction to a guided vehicle or an external device associated with the task instruction, the robot control system does not Tasks are optimally assigned, and robots are not assigned optimal driving routes, which leads to lower execution efficiency of tasks after scheduling.
  • the disclosure provides a robot cluster scheduling system, which can solve the technical problem of low task execution efficiency after the robot scheduling system in the related art schedules a robot.
  • An embodiment provides a robot cluster scheduling system, the system includes: a user layer, the user layer includes a service object of the scheduling system, the service object is a user or a robot; an intermediate layer, the intermediate layer includes A processor mapping module and a state acquisition module; an application layer including a task scheduling module and a traffic scheduling module; a plug-in layer including a task solving engine and a traffic planning engine; and a data persistence layer;
  • the processor mapping module is configured to receive a task sent by the user or a traffic planning request sent by the robot, and after analyzing the task or the traffic planning request, write the task into the data In the persistence layer, the traffic planning request is forwarded to the traffic dispatching module of the application layer;
  • the state acquisition module is configured to receive the state data of the robot, and write the state data to the data persistence layer Medium;
  • the task scheduling module is configured to call the task solving engine after the task is obtained from the data persistence layer, and the task solving engine is set to be based on the task parameters and the status data Determine a target robot, and decompose the task into sub-task sequences and send to the target robot;
  • the traffic scheduling module is configured to call the traffic planning engine after receiving a traffic planning request from the processor mapping module, so that The traffic planning engine is configured to determine a target based on a parameter in the traffic planning request and the status data. Line and the goal line to send the robot to generate traffic planning request; the task of solving the transportation planning engine, and the engine are provided API.
  • FIG. 1 is a schematic structural diagram of a robot cluster scheduling system according to an embodiment
  • FIG. 2A is an execution flowchart of a processor mapping module in the embodiment shown in FIG. 1;
  • FIG. 2B is an execution flowchart of the state acquisition module in the embodiment shown in FIG. 1;
  • 2C is an execution flowchart of a task scheduling module in the embodiment shown in FIG. 1;
  • FIG. 2D is an execution flowchart of the traffic dispatching module in the embodiment shown in FIG. 1; FIG.
  • 2E is an execution flowchart of a task solving engine in the embodiment shown in FIG. 1;
  • 2F is an execution flowchart of the traffic planning engine in the embodiment shown in FIG. 1;
  • FIG. 3 is a schematic structural diagram of a robot cluster scheduling system according to another embodiment
  • FIG. 4 is an execution flowchart of the charge management module in the embodiment shown in FIG. 3.
  • FIG. 1 is a schematic structural diagram of a robot cluster scheduling system provided by this embodiment.
  • the robot cluster scheduling system includes a user layer, an intermediate layer, an application layer, a plug-in layer, and a data persistence layer.
  • the user layer includes service objects of the scheduling system, and the service objects are users or robots.
  • the middle layer includes a processor mapping module and a state acquisition module.
  • the application layer includes a task scheduling module and a traffic scheduling module.
  • the plug-in layer includes a task solving engine and a traffic planning engine.
  • the processor mapping module is configured to receive a task sent by a user or a traffic planning request sent by a robot, analyze the task or traffic planning request, write the task into a data persistence layer, and forward the traffic planning request to traffic scheduling at the application layer Module.
  • the state acquisition module is configured to receive the state data of the robot and write the state data into the data persistence layer.
  • the task scheduling module is set to call the task solving engine after obtaining the task and status data from the data persistence layer.
  • the task solving engine is set to determine the target robot based on the parameters and status data of the task, and decompose the task into subtask sequences and send Target robot.
  • the traffic scheduling module is configured to call a traffic planning engine after receiving a traffic planning request from the processor mapping module, and the traffic planning engine is configured to determine a target route according to parameters and status data in the traffic planning request, and send the target route to the generated traffic Planning the requested robot.
  • Both the task solving engine and the traffic planning engine provide Application Programming Interfaces (APIs).
  • APIs Application Programming Interfaces
  • the robot scheduling system is a cluster scheduling system.
  • the cluster scheduling system specifically refers to a scheduling system using cluster technology.
  • a cluster is a group of computers that are independent of each other and interconnected through a high-speed network.
  • the computers in the cluster form a group and are managed in a single system mode.
  • Cluster configuration can improve availability and scalability. Therefore, in this embodiment, the robot technology is used to schedule the robot, which can improve the utilization rate, stability, and scalability of the scheduling system.
  • the cluster scheduling system in this embodiment can implement scheduling for multiple robots.
  • the user may send a task to the processor mapping module in the middle layer.
  • the task here may be, for example, letting the robot go to a set position to pick up a specific item.
  • the task sent by the user may include task parameters.
  • the types of task parameters are different. For example, when the task is for the robot to go to a set position to fetch a specific item, the task parameters are the coordinates of the position and the name of the item.
  • Robots in the user layer can send traffic planning requests to the processor mapping module in the middle layer.
  • the robot can send a traffic planning request to the processor mapping module.
  • the traffic planning request may include the coordinates of the location to be reached and the identification of the robot.
  • FIG. 2A is an execution flowchart of a processor mapping module in the embodiment shown in FIG. 1.
  • FIG. 2A when the processor mapping module in this embodiment runs, the following steps are performed:
  • step 210 a task or traffic planning request is received.
  • step 220 the task or traffic planning request is analyzed. If the task is received, step 230 is performed, and if the traffic planning request is received, step 240 is performed.
  • the purpose of the analysis is to identify whether the type of information obtained is a task or a traffic planning request.
  • the task may also include an identifier indicating that the information is a task.
  • the traffic planning request may include an identifier indicating that the information is a traffic planning request.
  • the processor mapping module may parse the task or traffic planning request according to the identifier of the identification field to determine the type of information.
  • step 230 the task is written into the data persistence layer, and step 250 is continued. If the processor mapping module determines that the obtained task is a task, it writes the task to the data persistence layer and waits for the task scheduling module of the application layer to obtain the task from the data persistence layer.
  • step 240 the traffic planning request is forwarded to the traffic scheduling module, and step 260 is continued.
  • step 250 after the task is written into the data persistence layer, the successfully written information is fed back to the user in the user layer.
  • step 260 the execution result returned by the traffic scheduling module is received, and the execution result is fed back to the user layer.
  • the setting of steps 250 and 260 can improve the reliability of communication between the processor mapping module and the user.
  • FIG. 2B is an execution flowchart of the state acquisition module in the embodiment shown in FIG. 1. As shown in FIG. 2B, when the status acquisition module in this embodiment is running, the following steps are performed:
  • step 310 data monitoring is enabled.
  • the status acquisition module After the status acquisition module turns on data monitoring, it can start receiving status data of the robot.
  • step 320 status data of the robot is received.
  • the status data here may include the identification of the robot, the position of the robot, the task currently performed by the robot, and the task execution status.
  • step 330 the status data is parsed and written into the data persistence layer.
  • the state acquisition module parses the collected state data, the state data is written into the data persistence layer.
  • the state acquisition module is further configured to include the following steps after writing the state data into the data persistence layer:
  • step 340 the control parameters of the robot are obtained from the data persistence layer, and the control parameters are sent to the robot.
  • the control parameter includes at least one of the following information: the control mode of the robot or the maximum speed of the robot.
  • the control mode of the robot refers to whether the robot is in a manual mode or an automatic mode.
  • FIG. 2C is an execution flowchart of the task scheduling module in the embodiment shown in FIG. 1. As shown in FIG. 2C, when the task scheduling module of the application layer in this embodiment runs, it executes the following steps:
  • step 410 the hot backup data is restored.
  • step 410 needs to be performed to restore the historical state.
  • step 420 a task is obtained from the data persistence layer.
  • step 430 a project configuration file is loaded.
  • the data persistence layer also includes a description file, which includes a project configuration file.
  • the project configuration file here includes map information, robot list, and the number of robots.
  • step 440 it is determined whether a task is obtained. If the task is not obtained, return to step 420, and if the task is obtained, perform step 450.
  • step 450 a task solving engine is invoked.
  • the task configuration plug-in possessed by the current system is configured in the project configuration file.
  • step 460 after calling the task solving engine, the target robot is determined according to the parameters of the task and the state data of the robot acquired by the state acquisition module; this step needs to call the map information, the list of robots, and the number of robots in the engineering configuration file. Provides additional parameters required for task solving for the task solving engine.
  • step 470 it is determined whether a target robot is obtained. If the target robot is not obtained, step 420 is performed, and if it is determined that the target robot is obtained, step 480 is performed.
  • the task solving engine determines the target robot according to the parameters of the task and the state data of the robot obtained by the state acquisition module.
  • the target robot in this embodiment refers to the best and most suitable robot for performing the task.
  • the best and most suitable robot for performing the task refers to satisfying the conditions closest to the target point or not performing the task at the current stage Robot.
  • step 480 a subtask sequence is generated.
  • the task scheduling module can obtain the sub-task sequence generated according to the task by calling the task solving engine. After it is determined that the target robot is not obtained, it indicates that there is no robot suitable for performing the task at this time, and the process returns to step 420.
  • the task can be composed of a series of subtasks.
  • subtasks are tasks that can be performed.
  • the data persistence layer also records task execution status and task execution information.
  • the task scheduling module is further configured to perform step 480 after the task is decomposed into a subtask sequence:
  • step 490 the execution status of the task is changed from never executed to in progress.
  • step 4100 the sub-task sequence is sent to the target robot.
  • the task scheduling module is further configured to execute steps 4100 and 4110 after sending the sub-task sequence to the target robot:
  • step 4110 task execution information is obtained from the target robot.
  • the target robot can feed back task execution information to the task scheduling module during the task execution.
  • the task execution information here is set to indicate which subtask in the subtask sequence the task is executed to. For example, if a task is generated with three subtask sequences, the task execution information may be: the start of the execution of the second subtask, the execution of the second subtask, or the execution of the third subtask.
  • step 4120 the task execution information is written into the data persistence layer.
  • Writing task execution information into the data persistence layer can facilitate subsequent users to query the execution status of this task and control the progress of task execution to improve the user experience.
  • step 4130 it is determined whether the task is completed. If the task is not completed, step 4100 is performed, and if it is determined that the task is ended, step 4140 is performed.
  • the task scheduling module determines whether the task ends from the task execution information. When the execution of the last subtask is indicated in the task execution information, it is determined that the task ends.
  • step 4140 the task scheduling module is reset and the information written in the data persistence layer is cleared.
  • step 4140 is performed to reset the task scheduling module and clear the information written in the data persistence layer during the execution of this task to facilitate the execution of the next task and save storage space.
  • step 4140 is performed to reset the task scheduling module and clear the information written in the data persistence layer during the execution of this task to facilitate the execution of the next task and save storage space.
  • FIG. 2D is an execution flowchart of the traffic scheduling module in the embodiment shown in FIG. 1. As shown in FIG. 2C, when the traffic scheduling module of the application layer in this embodiment runs, the following steps are performed:
  • step 510 a project configuration file is loaded.
  • step 430 is the same as the implementation process of step 430, and details are not described herein again.
  • step 520 the traffic dispatching module information is updated and the information is passed to the data persistence layer. Load map information from the project configuration file.
  • a traffic planning request is received.
  • the traffic scheduling module receives a traffic planning request from the processor mapping module.
  • step 540 a traffic planning engine is invoked.
  • map information needs to be loaded from the project configuration file.
  • the traffic planning engine can determine the target route according to the parameters and status data in the traffic planning request.
  • step 550 the target route is sent to the robot that generates the traffic planning request.
  • FIG. 2E is an execution flowchart of the task solving engine in the embodiment shown in FIG. 1.
  • the target robot is obtained (that is, the target robot can be determined according to the parameters and status data of the task), and the task is decomposed to generate a sub-task sequence.
  • the task solving engine When the task solving engine generates a task into a subtask sequence, it has the following two implementation methods:
  • the task solving engine includes multiple task types and a sub-task sequence template corresponding to the task type. Based on this implementation, the task solving engine decomposes the task into subtask sequences and sends it to the target robot. In an embodiment, the task solving engine determines a subtask sequence template corresponding to the task according to the type of the task; the task solving engine brings the parameters of the task into the subtask sequence template corresponding to the task, obtains the subtask sequence corresponding to the task, and Send the subtask sequence to the target robot.
  • the subtask sequence template is: 1. Navigate to a set location; 2. retrieve a specific item.
  • the required task parameter information is: location coordinates and item names.
  • the processor mapping module obtains the following types of tasks: take a cup to point A, where the parameters of the task are: the coordinates of point A and the cup.
  • the task scheduling module obtains the task, it calls the task solving engine.
  • the task solving engine determines the subtask sequence template according to the task type, and fills the parameters of the task into the subtask sequence template to get the task subsequence: 1. Navigate to point A Coordinates); 2. Take the cup.
  • the task solving engine includes an intelligent solving algorithm.
  • the task solving engine divides the task into subtask sequences and sends them to the target robot.
  • the task solving engine determines a subtask sequence according to the intelligent solving algorithm and the parameters of the task, and sends the subtask sequence to the target robot.
  • the intelligent solution algorithm can obtain the task sub-sequences based on the task content and the environment information of the current robot.
  • the processor mapping module receives a task and retrieves a cup.
  • the task scheduling module calls the task solving engine.
  • the task parameter information is to retrieve a cup.
  • the task solving engine obtains the steps as follows: 1. Reach the cup location, 2. Get the cup, 3. Return to the starting point.
  • the task solving engine obtains environmental information, and the environmental information includes the position of the cup and the position of the robot.
  • the sub-task sequence generated by the task solving engine is: 1. Navigate to the cup location, 2. Take the cup, 3. Navigate to the starting point.
  • FIG. 2F is an execution flowchart of the traffic planning engine in the embodiment shown in FIG. 1.
  • the traffic planning engine performs a road condition analysis based on the parameters in the traffic planning request to determine the target route.
  • the target route in this embodiment may be a road name sequence composed of a group of road names, or a route composed of a group of coordinates.
  • both the task solving engine and the traffic planning engine provide APIs, and the task solving engine and the traffic planning engine can be developed through the API. That is, the robot cluster scheduling system provided by this embodiment is open.
  • the middle layer, the application layer, and the data persistence layer can all be implemented by using a virtualization container technology of an application container engine (Docker).
  • Docker is an application container engine that provides container solutions.
  • This embodiment uses the Docker container technology as the foundation, and has the following advantages: 1.
  • the use of Docker container technology makes the robot cluster scheduling system provided by this embodiment easy to deploy; 2.
  • the system resource utilization rate and disaster tolerance are improved; 3.
  • the robot cluster scheduling system of the embodiment has the capability of automatic fault recovery; 4.
  • the robot cluster scheduling system of this embodiment has a rolling upgrade function.
  • the robot cluster scheduling system provided in this embodiment supports scheduling of heterogeneous robots.
  • the robot cluster scheduling system provided by this embodiment is provided with a user layer, an intermediate layer, an application layer, a plug-in layer, and a data persistence layer.
  • the user layer includes service objects of the scheduling system, and the service objects are users or robots and the intermediate layer. It includes a processor mapping module and a state acquisition module, the application layer includes a task scheduling module and a traffic scheduling module, and the plug-in layer includes a task solving engine and a traffic planning engine.
  • the processor mapping module is configured to receive a task sent by a user or a traffic planning request sent by a robot.
  • the processor mapping module parses the task or traffic planning request, it writes the task into a data persistence layer and forwards the traffic planning request to In the traffic dispatching module of the application layer; the status acquisition module is set to receive the status data of the robot and write the status data to the data persistence layer; the task dispatching module is set to call the task after obtaining the task from the data persistence layer Solving engine; the task solving engine is set to determine the target robot based on the parameters and status data of the task, and the task is decomposed into a sequence of subtasks and sent to the target robot; the traffic dispatch module is set to call after receiving the traffic planning request from the processor mapping module Traffic planning engine; The traffic planning engine is set to determine the target route based on the parameters and status data in the traffic planning request, and sends the target route to the robot that generates the traffic planning request.
  • the task solving engine and the traffic planning engine both provide APIs.
  • real A robotic cluster scheduling system that supports secondary development can realize task solving and traffic planning according to actual needs, and the system has low coupling.
  • it can determine the target robot according to the task and achieve the optimal allocation of robot tasks.
  • the execution efficiency of the tasks after scheduling is improved.
  • the robot's transportation route can be intelligently planned to prevent the robot from being congested.
  • FIG. 3 is a schematic structural diagram of a robot cluster scheduling system according to another embodiment. Based on the embodiment shown in FIG. 1, this embodiment describes other modules of the robot cluster scheduling system in detail.
  • the status data collected by the status acquisition module includes power data of multiple robots.
  • the application layer further includes a charge management module.
  • the charge management module is configured to determine whether the robot needs to be charged according to the robot's power data; if it is determined that the robot needs to be charged, determine the robot to be charged and determine whether the charging resource can be found; when it is determined that the charging resource can be found, generate the charging Task, and write the identifier of the robot to be charged into the data persistence layer, and send the charging task to the processor mapping module.
  • the charging task includes identification of the robot to be charged.
  • the processor mapping module is further configured to, after receiving the charging task sent by the charging management module, analyze the charging task and write the charging task into a data persistence layer.
  • the task scheduling module is further configured to call the task solving engine after obtaining the charging task from the data persistence layer, and the task solving engine is set to decompose the charging task into a charging sub-task sequence and send it to the robot corresponding to the identifier of the robot in the charging task. .
  • FIG. 4 is an execution flowchart of the charge management module in the embodiment shown in FIG. 3. As shown in FIG. 4, when the charge management module of the application layer in this embodiment runs, the following steps are performed:
  • step 610 a project configuration file is obtained.
  • the charging management module obtains the project configuration file from the data persistence layer.
  • step 620 a project configuration file is loaded, and the state acquisition module obtains a robot list from the project configuration file.
  • step 630 the power of the robot is checked.
  • the charging management module checks the power of the robot according to the status data. In one embodiment, the charging management module determines the size of the robot power and the minimum power threshold based on the status data.
  • step 640 it is determined whether the robot needs to be charged. If it is determined that the robot does not need to be charged, go back to step 630, and if it is determined that the robot needs to be charged, go to step 650.
  • a robot to be charged may also be determined, that is, an identification of the robot to be charged may be determined.
  • step 650 it is determined whether a charging resource can be found, and the state acquisition module loads charging resource information from the engineering configuration file. . If no charging resource is found, go back to step 630. If it is determined that a charging resource can be found, go to step 660.
  • step 660 a charging task is generated.
  • a charging task is generated.
  • the charging task includes an identification of the robot to be charged.
  • step 670 it is determined whether the charging task is successfully generated. If it is determined that the charging task generation fails, step 630 is performed, and if it is determined that the charging task generation is performed, step 680 is performed.
  • step 680 the identifier of the robot to be charged is written into the data persistence layer.
  • step 690 the charging task is sent to the processor mapping module.
  • step 6100 check the execution status of the charging task.
  • step 6110 it is determined whether a charging task is completed. If no charging task is completed, step 6100 is performed, and if a charging task is completed, step 6120 is performed.
  • step 6120 the information written in the data persistence layer is cleared.
  • the user may also send an operation instruction.
  • the processor mapping module is further configured to receive an operation instruction sent by a user, and after analyzing the operation instruction, forward the operation instruction to a task scheduling module, a traffic scheduling module, or a charge management module of an application layer.
  • the task scheduling module, the traffic scheduling module, or the charge management module is further configured to operate according to an operation instruction.
  • the operation instruction includes at least one of the following instructions: task status query, delete task, pause task, and robot status query.
  • Parsing the operation instructions means analyzing the types of tasks in the operation instructions: when it is a task, it is forwarded to the task scheduling module; when it is a charging task, it is forwarded to the charging management module; when it is a traffic planning request To forward the traffic planning request to the traffic dispatch module.
  • the task scheduling module, the traffic scheduling module, or the charge management module operates according to the operation instructions, which means that the operations performed by the above three modules according to the operation instructions: when the operation instruction is a status query instruction, the current execution status is fed back; when it is a delete instruction When the operation instruction is a pause task instruction, the currently executing task is suspended; when the operation instruction is a robot status query instruction, the current robot status is fed back.
  • the status of the robot can be the status of performing a task or the idle status.
  • the processor mapping module analyzes the operation instruction after receiving the operation instruction, and determines that the operation instruction is a query of the status of the charging task, and then forwards the operation instruction to the application. Layer of charge management module. After receiving the operation instruction, the charging management module feedbacks the charging state of the robot, such as the charged amount, etc., according to the operation instruction.
  • the data persistence layer includes a relational database and a memory-level database. Tasks and charging tasks are stored in a relational database. Control parameters are stored in a memory-level database. Robot status data is stored in a memory-level database. Hot backup data is stored in a memory-level database.
  • a relational database such as a relational database (MyStructure, Quest, Language, MySQL).
  • MyStructure, Quest, Language, MySQL The advantage of this database is that the data structure is more complex and can be searched based on complex conditions.
  • a memory-level database such as a Remote Data Service Database (Remote Dictionary Server, Redis), has the advantage of fast query speed and frequent reading and writing.
  • the data persistence layer further includes a description file.
  • the description file includes the project configuration file.
  • the application layer to include a charge management module
  • intelligent charging of the robot can be realized when the power of the robot is lower than a threshold, and the reliability of the robot is improved.
  • the computer software product can be stored in a computer-readable storage medium, such as a computer's floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk, or An optical disc or the like, and the computer-readable storage medium is configured to include a plurality of instructions, so that a computer device (which may be a personal computer, a server, or a network device, etc.) executes the method described in the foregoing embodiment.
  • a computer device which may be a personal computer, a server, or a network device, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Robotics (AREA)
  • Mechanical Engineering (AREA)
  • Data Mining & Analysis (AREA)
  • Control Of Position, Course, Altitude, Or Attitude Of Moving Bodies (AREA)
  • Manipulator (AREA)

Abstract

一种机器人集群调度系统，包括：用户层、中间层、应用层、插件层以及数据持久化层，中间层包括处理器映射模块以及状态采集模块，应用层包括任务调度模块以及交通调度模块，插件层包括任务求解引擎以及交通规划引擎，任务求解引擎设置为根据任务的参数以及状态数据确定目标机器人，交通规划引擎设置为确定目标路线。

Description

机器人集群调度系统
本申请要求申请日为2018年8月28日、申请号为201810989933.6、名称为“机器人集群调度系统”的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本公开涉及机器人技术，例如涉及一种机器人集群调度系统。
背景技术
随着通信技术及电子技术的发展，机器人在工业领域中的应用越来越广泛。在机器人的应用中，如何对机器人进行调度非常重要。
在相关技术中，一种机器人调度系统包括：机器人控制系统和中间控制系统。其中，机器人控制系统设置为从中间控制系统获取机器人管理信息，根据机器人管理信息生成任务指令，并将任务指令发送至任务指令关联的引导车或者外部设备。中间控制系统包括：第一接口层、中间业务处理层以及接入层，第一接口层包括设置为从业务管理系统获取任务包的业务接口，中间业务处理层设置为根据从业务管理系统获取的任务包生成机器人管理信息，接入层包括控制接口，接入层通过控制接口连接于机器人控制系统。
但是，上述的机器人调度系统，一方面，不支持二次开发，另一方面，机器人控制系统在将任务指令发送至与任务指令关联的引导车或者外部设备时，并没有根据任务指令的参数对任务进行最优分配，也没有为机器人分配最优行驶路线，这导致调度后任务的执行效率较低。
发明内容
本公开提供了一种机器人集群调度系统，能够解决相关技术中的机器人调度系统对机器人调度后，任务执行效率低的技术问题。
一实施例提供了一种机器人集群调度系统，所述系统包括：用户层，所述用户层包括所述调度系统的服务对象，所述服务对象为用户或者机器人；中间层，所述中间层包括处理器映射模块以及状态采集模块；应用层，所述应用层包括任务调度模块以及交通调度模块；插件层，所述插件层包括任务求解引擎 以及交通规划引擎；以及数据持久化层；
其中，所述处理器映射模块设置为接收所述用户发送的任务或者所述机器人发送的交通规划请求，对所述任务或者所述交通规划请求进行解析后，将所述任务写入所述数据持久化层中，将所述交通规划请求转发到应用层的交通调度模块中；所述状态采集模块设置为接收所述机器人的状态数据，并将所述状态数据写入所述数据持久化层中；所述任务调度模块设置为在从所述数据持久化层中获取到所述任务后，调用所述任务求解引擎，所述任务求解引擎设置为根据所述任务的参数以及所述状态数据确定目标机器人，并将所述任务分解成子任务序列发送给所述目标机器人；所述交通调度模块设置为在从所述处理器映射模块接收到交通规划请求后，调用所述交通规划引擎，所述交通规划引擎设置为根据所述交通规划请求中的参数以及所述状态数据确定目标路线，并将所述目标路线发送给生成所述交通规划请求的机器人；所述任务求解引擎以及所述交通规划引擎均提供API。
附图说明
图1为一实施例提供的机器人集群调度系统的结构示意图；
图2A为图1所示实施例中处理器映射模块的执行流程图；
图2B为图1所示实施例中状态采集模块的执行流程图；
图2C为图1所示实施例中任务调度模块的执行流程图；
图2D为图1所示实施例中交通调度模块的执行流程图；
图2E为图1所示实施例中任务求解引擎的执行流程图；
图2F为图1所示实施例中交通规划引擎的执行流程图；
图3为另一实施例提供的机器人集群调度系统的结构示意图；
图4为图3所示实施例中充电管理模块的执行流程图。
具体实施方式
图1为本实施例提供的机器人集群调度系统的结构示意图。如图1所示，该机器人集群调度系统包括：用户层、中间层、应用层、插件层以及数据持久化层。
其中，用户层包括调度系统的服务对象，服务对象为用户或者机器人。中间层包括处理器映射模块以及状态采集模块。应用层包括任务调度模块以及交 通调度模块。插件层包括任务求解引擎以及交通规划引擎。
处理器映射模块设置为接收用户发送的任务或者机器人发送的交通规划请求，对任务或者交通规划请求进行解析后，将任务写入数据持久化层中，将交通规划请求转发到应用层的交通调度模块中。
状态采集模块设置为接收机器人的状态数据，并将状态数据写入数据持久化层中。
任务调度模块设置为在从数据持久化层中获取到任务及状态数据后，调用任务求解引擎，任务求解引擎设置为根据任务的参数以及状态数据确定目标机器人，并将任务分解成子任务序列发送给目标机器人。
交通调度模块设置为在从处理器映射模块接收到交通规划请求后，调用交通规划引擎，交通规划引擎设置为根据交通规划请求中的参数以及状态数据确定目标路线，并将目标路线发送给生成交通规划请求的机器人。
任务求解引擎以及交通规划引擎均提供应用编程接口(Application Programming Interface，API)。
本实施例中，对机器人进行调度的系统是集群调度系统。集群调度系统具体指的是采用集群技术的调度系统。集群是一组相互独立的，并通过高速网络互联的计算机，集群内的计算机构成了一个组，并以单一系统的模式加以管理。集群配置可以提高可用性和可缩放性。因此，本实施例中采用集群技术对机器人进行调度，可以提高调度系统的利用率、稳定性及可拓展性等。
本实施例中的集群调度系统能够实现对多个机器人的调度。
本实施例的用户层中，用户可以向中间层的处理器映射模块发送任务。这里的任务例如可以是让机器人去一个设定位置取一特定物品。用户发送的任务中，可以包括任务参数，根据不同的任务，这里的任务参数的类型不同。例如，当任务为让机器人去一个设定位置取一特定物品，任务参数为该位置的坐标以及该物品的名称。
用户层中的机器人可以向中间层的处理器映射模块发送交通规划请求。一种场景中，当一个机器人要到达一个设定位置，但不知道按照哪条路径走能最快到达时，该机器人可以向处理器映射模块发送交通规划请求。交通规划请求中可以包括要到达的位置的坐标以及该机器人的标识。
图2A为图1所示实施例中处理器映射模块的执行流程图。如图2A所示，本实施例中的处理器映射模块在运行时，执行以下步骤：
步骤210中，接收任务或者交通规划请求。
步骤220中，对任务或者交通规划请求进行解析。若接收的是任务，则执行步骤230，若接收的是交通规划请求，则执行步骤240。
进行解析的目的是为了识别获取到的信息类型到底是任务还是交通规划请求。任务中除了包括任务参数外，还可以包括指示该信息为任务的标识，交通规划请求中除了包括要到达的位置的坐标以及该机器人的标识外，还可以包括指示该信息为交通规划请求的标识。处理器映射模块可以根据标识字段的标识对任务或者交通规划请求进行解析，以确定信息类型。
步骤230中，将任务写入数据持久化层中，继续执行步骤250。如果处理器映射模块确定获取到的是任务，则将任务写入数据持久化层中，等待应用层的任务调度模块从数据持久化层中获取该任务。
步骤240中，将交通规划请求转发到交通调度模块，并继续执行步骤260。
步骤250中，在将任务写入数据持久化层后，将已写入成功的信息反馈给用户层中的用户。
步骤260中，接收交通调度模块返回的执行结果，并将执行结果反馈给用户层。
步骤250和步骤260的设置可以提高处理器映射模块与用户通信的可靠性。
图2B为图1所示实施例中状态采集模块的执行流程图。如图2B所示，本实施例中的状态采集模块在运行时，执行以下步骤：
步骤310中，开启数据监听。
状态采集模块在开启数据监听后，就可以开始接收机器人的状态数据。
步骤320中，接收机器人的状态数据。
这里的状态数据可以包括机器人的标识、机器人的位置、机器人当前执行的任务以及任务执行状态等。
步骤330中，解析状态数据，并将状态数据写入数据持久化层中。
状态采集模块对采集到的状态数据进行解析后，将这些状态数据写入数据持久化层中。
在一实施例中，状态采集模块还设置为在将这些状态数据写入数据持久化层后，还包括以下步骤：
步骤340中，从数据持久化层中获得机器人的控制参数，并将控制参数发送给机器人。
控制参数包括以下信息的至少一种：机器人的控制模式或者机器人的最大速度。机器人的控制模式指的是机器人是手动模式还是自动模式。
图2C为图1所示实施例中任务调度模块的执行流程图。如图2C所示，本实施例中应用层的任务调度模块在运行时，执行以下步骤：
步骤410中，热备份数据恢复。
在集群调度系统崩溃及重启之后，需要执行步骤410，以恢复历史状态。
步骤420中，从数据持久化层中获取任务。
步骤430中，装载工程配置文件。
数据持久化层还包括描述文件，描述文件中包括工程配置文件。这里的工程配置文件包括地图信息、机器人列表以及机器人的数量等信息。
步骤440中，判断是否得到任务。若没有得到任务，返回执行步骤420，若得到任务，则执行步骤450。
步骤450中，调用任务求解引擎。其中，工程配置文件中配置了当前系统具备的任务求解插件。
步骤460中，在调用任务求解引擎后，根据任务的参数以及状态采集模块获取到的机器人的状态数据确定目标机器人；该步骤需要调用工程配置文件中的地图信息、机器人列表以及机器人的数量等信息，为任务求解引擎提供任务求解所需的额外参数。
步骤470中，判断是否获得目标机器人。若没有获得目标机器人，则执行步骤420，若确定获得了目标机器人，则执行步骤480。
在调用任务求解引擎后，任务求解引擎会根据任务的参数以及状态采集模块获取到的机器人的状态数据确定目标机器人。本实施例中的目标机器人指的是执行任务的最佳、最合适的机器人，其中：执行任务的最佳、最合适的机器人，指的是满足距离目标点最近或者现阶段未执行任务等条件的机器人。
步骤480中，生成子任务序列。
在确定获取目标机器人后，任务调度模块可以通过调用任务求解引擎获取到根据任务生成的子任务序列。在确定没有获取到目标机器人后，说明此时没有适合执行该任务的机器人，返回执行步骤420。
其中，任务可以是由一系列子任务组成的。对于机器人来说，子任务才是可以执行的任务。
在一实施例中，数据持久化层中还记录任务的执行状态以及任务执行信息。 任务调度模块还设置为在将任务分解成子任务序列后，执行步骤480：
步骤490中，将任务的执行状态从未执行修改为执行中。
步骤4100中，将子任务序列发送给目标机器人。
任务调度模块还设置为在将子任务序列发送给目标机器人后，执行步骤4100及步骤4110：
步骤4110中，从目标机器人获取任务执行信息。
目标机器人在执行任务的过程中，可以向任务调度模块反馈任务执行信息。这里的任务执行信息设置为指示任务执行至子任务序列中的哪一个子任务。例如，一个任务被生成三个子任务序列，则任务执行信息可以是：开始执行第二个子任务、第二个子任务执行完成或者第三个子任务执行完成。
步骤4120中，将任务执行信息写入数据持久化层中。
将任务执行信息写入数据持久化层中，可以便于后续用户查询此任务的执行状态，掌控任务执行进度，以提高用户体验。
步骤4130中，判断任务是否结束。若任务没有结束，则执行步骤4100，若确定任务结束，则执行步骤4140。
任务调度模块从任务执行信息中确定任务是否结束。当任务执行信息中指示最后一个子任务执行完成时，确定该任务结束。
步骤4140中，重置任务调度模块及清除写入数据持久化层中的信息。
在确定任务结束时，执行步骤4140，重置任务调度模块以及清除在执行此任务的过程中写入数据持久化层中的信息，以便于下一个任务的执行和节省存储空间。在确定任务没有结束时，返回执行步骤4100。
图2D为图1所示实施例中交通调度模块的执行流程图。如图2C所示，本实施例中应用层的交通调度模块在运行时，执行以下步骤：
步骤510中，装载工程配置文件。
该步骤与步骤430实现过程相同，此处不再赘述。
步骤520中，更新交通调度模块信息，并将信息传递至数据持久化层中。从工程配置文件中装载地图信息。
步骤530中，接收交通规划请求。交通调度模块从处理器映射模块接收交通规划请求。
步骤540中，调用交通规划引擎。调用交通规划引擎时，需要从工程配置文件中装载地图信息。
交通调度模块调用交通规划引擎后，交通规划引擎可以根据交通规划请求中的参数以及状态数据确定目标路线。
步骤550中，将目标路线发送给生成交通规划请求的机器人。
图2E为图1所示实施例中任务求解引擎的执行流程图。如图2E所示，任务求解引擎信息收集后，获取目标机器人(即可以根据任务的参数以及状态数据确定目标机器人)，并将任务进行分解，生成子任务序列。
任务求解引擎在将任务生成子任务序列时，有以下两种实现方式：
第一种实现方式中，任务求解引擎包括多个任务类型以及与任务类型对应的子任务序列模板。基于该实现方式，任务求解引擎将任务分解成子任务序列发送给目标机器人。在一实施例中，任务求解引擎根据任务的类型确定与任务对应的子任务序列模板；任务求解引擎将任务的参数带入任务对应的子任务序列模板中，获取任务对应的子任务序列，并将子任务序列发送给目标机器人。
举例来说，针对拿取物品的任务，子任务序列模板为：1.导航到设定位置处；2.拿取特定物品。需要的任务参数信息为：地点坐标以及物品名称。比如：处理器映射模块获取到的是以下类型的任务：到A点拿取一个杯子，其中任务的参数为：A点的坐标以及杯子。任务调度模块获得该任务后，调用任务求解引擎，任务求解引擎根据任务类型确定子任务序列模板，将任务的参数填入子任务序列模板中，可以得到任务子序列：1.导航到A点(坐标)处；2.拿取杯子。
第二种实现方式中，任务求解引擎包括智能求解算法。任务求解引擎将任务分解成子任务序列发送给目标机器人。在一实施例中，任务求解引擎根据智能求解算法以及任务的参数，确定子任务序列，并将子任务序列发送给目标机器人。
智能求解算法可以根据任务内容及当前机器人所处环境信息求解任务所需步骤，得到任务子序列。
举例来说，处理器映射模块接收到任务，内容为拿回一个杯子。任务调度模块调用任务求解引擎，任务参数信息为拿回一个杯子，任务求解引擎求解得到步骤为：1.到达杯子所在位置，2.拿取杯子，3.返回出发点。在一实施例中，任务求解引擎获得环境信息，环境信息包括杯子位置以及机器人的位置。最终，任务求解引擎生成的子任务序列为：1.导航到杯子所在位置，2.拿取杯子，3.导航到出发点。
图2F为图1所示实施例中交通规划引擎的执行流程图。如图2F所示，交通规 划引擎根据交通规划请求中的参数，进行路况分析，确定目标路线。本实施例中的目标路线可以是由一组路名组成的路名序列，也可以是由一组坐标组成的路线。
本实施例中，任务求解引擎和交通规划引擎均提供API，可以通过API对任务求解引擎和交通规划引擎进行二次开发，即，本实施例提供的机器人集群调度系统具有开放性。
本实施例中，中间层、应用层以及数据持久化层均可采用应用容器引擎(Docker)的虚拟化容器技术实现。Docker是一个应用容器引擎，提供容器解决方案。本实施例采用Docker容器技术作为基础，具有以下优点：1、采用Docker容器技术使得本实施例提供的机器人集群调度系统容易部署；2、提高了系统资源利用率和容灾性；3、使本实施例的机器人集群调度系统具有故障自动恢复能力；4、使本实施例的机器人集群调度系统具有滚动升级功能。
本实施例提供的机器人集群调度系统支持异构机器人的调度。
本实施例提供的机器人集群调度系统，通过设置有用户层、中间层、应用层、插件层以及数据持久化层，其中，用户层包括调度系统的服务对象，服务对象为用户或者机器人，中间层包括处理器映射模块以及状态采集模块，应用层包括任务调度模块以及交通调度模块，插件层包括任务求解引擎以及交通规划引擎。处理器映射模块设置为接收用户发送的任务或者机器人发送的交通规划请求，处理器映射模块对任务或者交通规划请求进行解析后，将任务写入数据持久化层中，并将交通规划请求转发到应用层的交通调度模块中；状态采集模块设置为接收机器人的状态数据，并将状态数据写入数据持久化层中；任务调度模块设置为在从数据持久化层中获取到任务后，调用任务求解引擎；任务求解引擎设置为根据任务的参数以及状态数据确定目标机器人，并将任务分解成子任务序列发送给目标机器人；交通调度模块设置为在从处理器映射模块接收到交通规划请求后，调用交通规划引擎；交通规划引擎设置为根据交通规划请求中的参数以及状态数据确定目标路线，并将目标路线发送给生成交通规划请求的机器人，任务求解引擎以及交通规划引擎均提供API，一方面，实现了一种支持二次开发的机器人集群调度系统，可根据实际需求实现任务求解和交通规划，系统耦合性较低，另一方面，实现了根据任务确定目标机器人，实现机器人任务的最优分配，提高了调度后任务的执行效率，再一方面，可以智能规划机器人的交通路线，防止机器人出现交通堵塞。
图3为另一实施例提供的机器人集群调度系统的结构示意图。该实施例在图1所示实施例的基础上，对机器人集群调度系统的其他模块作一详细说明。本实施例中，状态采集模块采集到的状态数据包括多个机器人的电量数据。如图3所示，应用层还包括充电管理模块。
充电管理模块设置为根据机器人的电量数据确定机器人是否需要充电；若确定有机器人需要充电时，确定需充电的机器人，并确定是否能查找到充电资源；当确定能查找到充电资源时，生成充电任务，并将需充电的机器人的标识写入数据持久化层中，将充电任务发送到处理器映射模块。
充电任务包括需充电的机器人的标识。
处理器映射模块还设置为在接收到充电管理模块发送的充电任务后，对充电任务进行解析，并将充电任务写入数据持久化层中。任务调度模块还设置为在从数据持久化层获取到充电任务后，调用任务求解引擎，任务求解引擎设置为将充电任务分解成充电子任务序列发送给与充电任务中的机器人的标识对应的机器人。
图4为图3所示实施例中充电管理模块的执行流程图。如图4所示，本实施例中应用层的充电管理模块在运行时，执行以下步骤：
步骤610中，获取工程配置文件。充电管理模块从数据持久化层中获取工程配置文件。
步骤620中，装载工程配置文件，状态采集模块从工程配置文件中获得机器人列表。
步骤630中，检查机器人电量。
充电管理模块根据状态数据检查机器人电量，在一实施例中，充电管理模块根据状态数据确定机器人电量与最低电量阈值的大小。
步骤640中，判断机器人是否需要充电。若确定机器人不需要充电时，返回执行步骤630，若确定机器人需要充电时，执行步骤650。
在确定机器人电量小于最低电量阈值时，确定机器人需要充电。可选地，还可以确定需充电的机器人，即，确定需充电的机器人的标识。
步骤650中，判断是否能查找到充电资源，状态采集模块从工程配置文件中装载充电资源信息。。若没有查找到充电资源时，返回执行步骤630，若确定能够查找到充电资源时，执行步骤660。
在确定机器人需要充电时，根据周围环境信息，确定是否有充电座以及充 电距离是否小于预设阈值。在确定存在充电座，且充电距离小于预设阈值时，确定可以查找到充电资源。
在确定机器人不需要充电时，返回执行步骤630。
步骤660中，生成充电任务。
在确定查找到充电资源时，生成充电任务。可选地，充电任务中包括需充电的机器人的标识。
在确定没有查找到充电资源时，返回执行步骤630。
步骤670中，判断充电任务是否生成成功。若确定生成充电任务失败，则执行步骤630，若确定充电任务生成，则执行步骤680。
步骤680中，将需充电的机器人的标识写入数据持久化层中。
步骤690中，将充电任务发送到处理器映射模块。
步骤6100中，查看充电任务执行情况。
步骤6110中，判断是否有充电任务完成。若没有充电任务完成，则执行步骤6100，若有充电任务完成，则执行步骤6120。
步骤6120中，清除写入数据持久化层中的信息。
在一实施例中，用户还可以发送操作指令。处理器映射模块还设置为接收用户发送的操作指令，对操作指令进行解析后，将操作指令转发到应用层的任务调度模块、交通调度模块或者充电管理模块中。任务调度模块、交通调度模块或者充电管理模块还设置为根据操作指令进行操作。其中，操作指令包括以下指令的至少一种：任务状态查询、删除任务、暂停任务以及机器人状态查询。
对操作指令进行解析意为分析操作指令中任务的类型：当为任务时，将该任务转发给任务调度模块；当为充电任务时，将充电任务转发给充电管理模块；当为交通规划请求时，将交通规划请求转发给交通调度模块。
任务调度模块、交通调度模块或者充电管理模块根据操作指令进行操作，意为上述三个模块根据操作指令执行的动作进行操作：当操作指令为状态查询指令时，反馈当前执行状态；当为删除指令时，删除相关任务；当操作指令为暂停任务指令时，暂停当前执行的任务；当操作指令为机器人状态查询指令时，反馈当前机器人状态。机器人的状态可以是执行任务状态或者空闲状态。
例如，假设操作指令为充电任务状态查询指令，则处理器映射模块在接收到该操作指令后，对操作指令解析，确定操作指令为对充电任务的状态进行查询，则将该操作指令转发到应用层的充电管理模块中。充电管理模块在接收到 该操作指令后，根据该操作指令反馈机器人的充电状态，例如，已充电量等。
请继续参照图3，本实施例中，数据持久化层包括关系型数据库和内存级数据库。任务以及充电任务存储在关系型数据库中。控制参数存储在内存级数据库中。机器人的状态数据存储在内存级数据库中。热备份数据存储在内存级数据库中。
关系型数据库，例如关系型数据库(My Structure Quest Language，MySQL)，该数据库优点是数据结构更复杂，可根据复杂条件查找。内存级数据库，例如远程数据服务数据库(Remote Dictionary Server，Redis)，该数据库的优点是查询速度快，可频繁读写。
本实施例中，数据持久化层还包括描述文件。描述文件中包括工程配置文件。
本实施例提供的机器人集群调度系统中，一方面，通过设置应用层包括充电管理模块，可以实现在机器人的电量低于阈值时，实现机器人的智能充电，提高了机器人的可靠性，另一方面，可以处理用户发送的操作指令，提高了调度系统的灵活性。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本实施例可借助软件及必需的通用硬件来实现，也可以通过硬件实现。该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、闪存(FLASH)、硬盘或光盘等，计算机可读存储介质设置为包括多个指令，以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行上述实施例所述的方法。

Claims (10)

  1. 一种机器人集群调度系统，所述系统包括：
    用户层，所述用户层包括所述调度系统的服务对象，所述服务对象为用户或者机器人；中间层，所述中间层包括处理器映射模块以及状态采集模块；应用层，所述应用层包括任务调度模块以及交通调度模块；插件层，所述插件层包括任务求解引擎以及交通规划引擎；以及数据持久化层；
    其中，所述处理器映射模块设置为接收所述用户发送的任务或者所述机器人发送的交通规划请求，对所述任务或者所述交通规划请求进行解析后，将所述任务写入所述数据持久化层中，将所述交通规划请求转发到应用层的交通调度模块中；
    所述状态采集模块设置为接收所述机器人的状态数据，并将所述状态数据写入所述数据持久化层中；
    所述任务调度模块设置为在从所述数据持久化层中获取到所述任务后，调用所述任务求解引擎，所述任务求解引擎设置为根据所述任务的参数以及所述状态数据确定目标机器人，并将所述任务分解成子任务序列发送给所述目标机器人；所述交通调度模块设置为在从所述处理器映射模块接收到交通规划请求后，调用所述交通规划引擎，所述交通规划引擎设置为根据所述交通规划请求中的参数以及所述状态数据确定目标路线，并将所述目标路线发送给生成所述交通规划请求的机器人；所述任务求解引擎以及所述交通规划引擎均提供应用编程接口API。
  2. 根据权利要求1所述的系统，其中，所述状态数据包括机器人的电量数据；所述应用层还包括充电管理模块；
    所述充电管理模块设置为根据所述机器人的电量数据确定机器人是否需要充电；在确定有机器人需要充电时，确定需充电的机器人，并确定是否能查找到充电资源；当确定能查找到充电资源时，生成充电任务，并将所述充电任务发送到所述处理器映射模块；所述充电任务包括需充电的机器人的标识；
    所述处理器映射模块还设置为在接收到所述充电管理模块发送的充电任务后，对所述充电任务进行解析，并将所述充电任务写入数据持久化层中；
    所述任务调度模块还设置为在从所述数据持久化层获取到所述充电任务后，调用所述任务求解引擎，所述任务求解引擎设置为将所述充电任务分解成充电子任务序列发送给所述标识对应的机器人。
  3. 根据权利要求2所述的系统，其中，所述处理器映射模块还设置为接收 所述用户发送的操作指令，对所述操作指令进行解析后，将所述操作指令转发到所述任务调度模块、所述交通调度模块或者所述充电管理模块中；其中，所述操作指令包括以下指令的至少一种：任务状态查询、删除任务、暂停任务以及机器人状态查询；
    所述任务调度模块、所述交通调度模块或者所述充电管理模块还设置为根据所述操作指令进行操作。
  4. 根据权利要求1-3任一项所述的系统，其中，所述任务求解引擎存储有多个任务类型以及与所述任务类型对应的子任务序列模板；
    所述任务求解引擎设置为：根据所述任务的类型确定与所述任务对应的子任务序列模板；及将所述任务的参数带入所述任务对应的子任务序列模板中，获取所述任务对应的子任务序列，并将所述子任务序列发送给所述目标机器人。
  5. 根据权利要求1-3任一项所述的系统，其中，所述任务求解引擎存储有智能求解算法；
    所述任务求解引擎将设置为：所述任务求解引擎根据所述智能求解算法以及所述任务的参数，确定子任务序列，并将所述子任务序列发送给所述目标机器人。
  6. 根据权利要求2所述的系统，其中，所述数据持久化层中还存储有机器人的控制参数，所述状态采集模块还设置为在接收到所述机器人的状态数据后，从所述数据持久化层中获得所述控制参数，并将所述控制参数发送给所述机器人；所述控制参数包括以下信息的至少一种：机器人的控制模式或者机器人的最大速度。
  7. 根据权利要求1-3任一项所述的系统，其中，所述数据持久化层还设置为记录所述任务的执行状态以及任务执行信息；
    所述任务调度模块还设置为在将所述任务分解成子任务序列后，将所述任务的执行状态从未执行修改为执行中；
    所述任务调度模块还设置为调用所述任务求解引擎将所述子任务序列发送给所述目标机器人后，从所述目标机器人获取任务执行信息，并将所述任务执行信息写入所述数据持久化层中；所述任务执行信息设置为指示所述任务执行至所述子任务序列中的哪一个子任务。
  8. 根据权利要求6所述的系统，其中，所述数据持久化层储存有关系型数据库和内存级数据库；
    所述关系型数据库设置为存储所述任务以及所述充电任务；所述内存级数据库设置为存储所述控制参数。
  9. 根据权利要求8所述的系统，其中，所述数据持久化层还储存有描述文件，所述描述文件包括工程配置文件；
    所述任务调度模块、所述交通调度模块以及所述充电管理模块均设置为从所述描述文件中获取所述工程配置文件，并装载所述工程配置文件。
  10. 根据权利要求1-3任一项所述的系统，其中，所述中间层、所述应用层以及所述数据持久化层均采用应用容器引擎Docker的虚拟化容器技术实现。
PCT/CN2018/116499 2018-08-28 2018-11-20 机器人集群调度系统 Ceased WO2020042385A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
SG11202002289WA SG11202002289WA (en) 2018-08-28 2018-11-20 Robot cluster scheduling system
EP18923759.7A EP3636390B1 (en) 2018-08-28 2018-11-20 Robot cluster scheduling system
US16/628,465 US11345020B2 (en) 2018-08-28 2018-11-20 Robot cluster scheduling system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810989933.6 2018-08-28
CN201810989933.6A CN109800937B (zh) 2018-08-28 2018-08-28 机器人集群调度系统

Publications (1)

Publication Number Publication Date
WO2020042385A1 true WO2020042385A1 (zh) 2020-03-05

Family

ID=66556240

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/116499 Ceased WO2020042385A1 (zh) 2018-08-28 2018-11-20 机器人集群调度系统

Country Status (5)

Country Link
US (1) US11345020B2 (zh)
EP (1) EP3636390B1 (zh)
CN (1) CN109800937B (zh)
SG (1) SG11202002289WA (zh)
WO (1) WO2020042385A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120663328A (zh) * 2025-08-08 2025-09-19 安徽荣洲智能科技有限公司 一种智能机器人的分工协作方法及系统
CN120792589A (zh) * 2025-07-03 2025-10-17 北京中能聪聪科技有限公司 一种新能源汽车移动共享储充机器人

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110427036B (zh) * 2019-08-14 2025-05-09 成都普诺思博科技有限公司 一种商用清洁机器人的云端管理系统
CN111901384B (zh) * 2020-06-29 2023-10-24 成都质数斯达克科技有限公司 处理报文的系统、方法、电子设备以及可读存储介质
US11654566B2 (en) * 2020-08-12 2023-05-23 General Electric Company Robotic activity decomposition
KR102442064B1 (ko) * 2020-11-30 2022-09-08 네이버랩스 주식회사 서비스 어플리케이션과 연계하여 서비스를 제공하는 로봇을 제어하는 방법 및 클라우드 서버
CN112990727A (zh) * 2021-03-26 2021-06-18 中国人民财产保险股份有限公司深圳市分公司 一种机器人任务执行控制方法、装置、系统及介质
CN113253736B (zh) * 2021-06-17 2021-11-09 上海思岚科技有限公司 多机器人调度方法及设备
CN113988801B (zh) * 2021-10-27 2023-11-10 北京百度网讯科技有限公司 一种办公系统、工作任务管理方法及装置
CN114415691B (zh) * 2022-01-28 2024-04-02 中银金融科技(苏州)有限公司 一种机器人调度方法、调度平台及系统
CN114442635A (zh) * 2022-02-08 2022-05-06 北京百度网讯科技有限公司 机器人集群的调度方法、装置、电子设备和介质
US12257719B2 (en) 2022-06-02 2025-03-25 Intrinsic Innovation Llc Robot planning for concurrent execution of actions
US12105492B2 (en) * 2022-06-02 2024-10-01 Intrinsic Innovation Llc Robot planning for concurrent execution of actions
CN116587295B (zh) * 2023-04-26 2026-03-24 塔米智能科技（北京）有限公司 一种基于服务机器人社群状态的智能化运营管理方法
CN117370475A (zh) * 2023-10-10 2024-01-09 霞智科技有限公司 一种基于机器人数据的存储方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003001578A (ja) * 2001-06-26 2003-01-08 Casio Comput Co Ltd ロボット、ロボット管理システム、ロボット制御プログラム、ロボット管理処理プログラム、ロボット管理方法、及び機器管理システム、機器管理処理プログラム、機器管理方法
CN104199428A (zh) * 2014-09-17 2014-12-10 上海畔慧信息技术有限公司 群体机器人管理服务器及其方法
CN107450491A (zh) * 2017-08-04 2017-12-08 杭州南江机器人股份有限公司 一种机器人调度系统、方法、电子设备和存储介质
CN108121330A (zh) * 2016-11-26 2018-06-05 沈阳新松机器人自动化股份有限公司 一种调度方法、调度系统及地图路径规划方法
CN108227654A (zh) * 2017-12-28 2018-06-29 顺丰科技有限公司 一种调度服务端、调度装置、机器人系统及调度方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100607141B1 (ko) 2004-05-12 2006-08-01 한국생산기술연구원 개방형 분산처리구조의 로봇 제어 시스템
CN102231233B (zh) * 2011-06-29 2013-05-29 南京航空航天大学 自动引导车分布式自主协同控制系统的控制方法
US8831984B2 (en) * 2011-10-19 2014-09-09 Amazon Technologies, Inc. System and method for inventory management using mobile drive units
CN103309350A (zh) * 2013-05-24 2013-09-18 南京航空航天大学 基于全局无线精确定位的自动导引车调度系统及其方法
US10430744B2 (en) * 2015-08-21 2019-10-01 Autodesk, Inc. Robot service platform
ES2927298T3 (es) * 2015-10-28 2022-11-03 Univ Bar Ilan Sistema cooperativo robótico
CN105425791B (zh) * 2015-11-06 2019-01-29 武汉理工大学 一种基于视觉定位的群机器人控制系统及方法
US9513627B1 (en) * 2016-04-25 2016-12-06 inVia Robotics, LLC Autonomous coordination of resources amongst robots
US20180004202A1 (en) * 2016-07-01 2018-01-04 Innovation Matrix, Inc. Robot fleet dispatch request system
CN106228302A (zh) * 2016-07-21 2016-12-14 上海仙知机器人科技有限公司 一种用于在目标区域内进行任务调度的方法与设备
CN106452903A (zh) * 2016-10-31 2017-02-22 华南理工大学 一种基于云辅助的智能仓管机器人系统与方法
CN106527446B (zh) * 2016-12-02 2020-11-13 北京小米移动软件有限公司 扫地机器人的控制方法及装置
CN106444791A (zh) * 2016-12-20 2017-02-22 南阳师范学院 一种多agv小车上位机统一调度系统设计方法
CN107423952B (zh) * 2017-07-25 2020-10-27 苏州博纳讯动软件有限公司 一种可扩展的DevOps持续交付系统及其方法
CN108415944B (zh) * 2018-01-30 2019-03-22 长安大学 一种交通环境下基于微服务的实时计算系统及其实现方法
CN108388472A (zh) * 2018-03-01 2018-08-10 吉林大学 一种基于Docker集群的弹性任务调度系统及方法
US10678228B2 (en) * 2018-04-04 2020-06-09 Invia Robotics, Inc. Autonomous robots performing concerted operation based on shared sensory access and holistic flow of information

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003001578A (ja) * 2001-06-26 2003-01-08 Casio Comput Co Ltd ロボット、ロボット管理システム、ロボット制御プログラム、ロボット管理処理プログラム、ロボット管理方法、及び機器管理システム、機器管理処理プログラム、機器管理方法
CN104199428A (zh) * 2014-09-17 2014-12-10 上海畔慧信息技术有限公司 群体机器人管理服务器及其方法
CN108121330A (zh) * 2016-11-26 2018-06-05 沈阳新松机器人自动化股份有限公司 一种调度方法、调度系统及地图路径规划方法
CN107450491A (zh) * 2017-08-04 2017-12-08 杭州南江机器人股份有限公司 一种机器人调度系统、方法、电子设备和存储介质
CN108227654A (zh) * 2017-12-28 2018-06-29 顺丰科技有限公司 一种调度服务端、调度装置、机器人系统及调度方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3636390A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120792589A (zh) * 2025-07-03 2025-10-17 北京中能聪聪科技有限公司 一种新能源汽车移动共享储充机器人
CN120663328A (zh) * 2025-08-08 2025-09-19 安徽荣洲智能科技有限公司 一种智能机器人的分工协作方法及系统

Also Published As

Publication number Publication date
EP3636390A4 (en) 2021-03-31
CN109800937A (zh) 2019-05-24
CN109800937B (zh) 2020-12-01
SG11202002289WA (en) 2020-04-29
US11345020B2 (en) 2022-05-31
EP3636390B1 (en) 2023-01-25
US20210170575A1 (en) 2021-06-10
EP3636390A1 (en) 2020-04-15

Similar Documents

Publication Publication Date Title
WO2020042385A1 (zh) 机器人集群调度系统
CN106453551B (zh) 一种办公室内物品递送机器人任务规划与执行装置及方法
CN111897638B (zh) 分布式任务调度方法及系统
CN110908641B (zh) 基于可视化的流计算平台、方法、设备和存储介质
CN109033814B (zh) 智能合约触发方法、装置、设备及存储介质
CN102236580B (zh) 为etl任务分配节点的方法和调度系统
CN109885624A (zh) 数据处理方法、装置、计算机设备和存储介质
US20210382728A1 (en) Running pbs jobs in kubernetes
CN110096521A (zh) 日志信息处理方法及装置
CN115827250A (zh) 一种数据存储方法、装置及设备
CN113407331B (zh) 一种任务处理的方法、装置及存储介质
CN112527872A (zh) 数据查询方法及装置、存储介质及电子设备
CN114756375A (zh) Gpu资源调度方法、系统、电子设备和存储介质
CN113741961A (zh) 基于Kubernetes容器编排软件提交大数据计算作业的方法及装置
CN113986569A (zh) 一种消息处理方法、装置和电子设备
US20230274178A1 (en) Debugging executing quantum services using service definition layers
CN119916811B (zh) 多品牌机器人的任务调度方法、设备及存储介质
CN113535321A (zh) 虚拟化容器管理方法、系统和存储介质
CN113127441A (zh) 一种动态选择数据库组件的方法及自组装数据库管理系统
CN119938283A (zh) 时空数据分析计算的算子编排方法、设备及存储介质
EP4386555A1 (en) Report reexecution framework
CN112286990A (zh) 一种预测平台作业执行时间的方法、装置和电子设备
CN116069480B (zh) 一种处理器及计算设备
CN113434265A (zh) 工作流调度方法、服务器和介质
CN118502900A (zh) 多核神经矢量检索硬件加速器及其调度方法

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018923759

Country of ref document: EP

Effective date: 20200102

NENP Non-entry into the national phase

Ref country code: DE