CN108500978B

CN108500978B - Robot control device and method and robot

Info

Publication number: CN108500978B
Application number: CN201810189449.5A
Authority: CN
Inventors: 高巍; 张向东; 董伟
Original assignee: Goertek Inc
Current assignee: Goertek Inc
Priority date: 2018-03-08
Filing date: 2018-03-08
Publication date: 2021-04-30
Anticipated expiration: 2038-03-08
Also published as: CN108500978A

Abstract

The invention discloses a robot control device, a method and a robot. The control device comprises a main processor, a coprocessor and one or more subtask controllers, wherein the coprocessor comprises a first ROS lib library with an ROS communication module and an ROS management module; the main processor and one or more subtask controllers are respectively connected with the coprocessor; the coprocessor is used for managing task data sent by all the subtask controllers through the ROS management module; and the ROS communication module is used for sending the task data in the ROS message format to the main processor, receiving a control instruction in the ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to the corresponding subtask controller according to the management control of the ROS management module. By adopting the technical scheme, the processing time of the messages in the robot control process is saved, the burden of the main processor is reduced, the real-time performance of the robot control is ensured, and the use experience of a user is improved.

Description

Robot control device and method and robot

Technical Field

The invention relates to the technical field of robots, in particular to a robot control device, a method and a robot.

Background

With the increasing attention of people to robots in recent years, a variety of robots and related matched software and hardware platforms are continuously released in the market. At present, Robot systems in the market adopt a scheme design of a Robot Operating System (ROS) System, and use design modes of a main processor and a coprocessor. In this mode, the main processor runs the Linux System and the ROS System, and the coprocessor runs a bare machine program (a program without an Operating System) or a Real Time Operating System (RTOS). In the robot control process, a real-time operating system runs independently in a coprocessing mode, is responsible for reporting data of relevant units such as a chassis, a motor and a sensor to a main processor after acquiring the data, and converts the data into a message format which can be identified by an ROS system after analyzing the data at the main processor end, and the communication format between the main processor and the coprocessor is designed according to a private communication interface and carries out bidirectional communication by means of a serial port or an Ethernet.

The RTOS system is adopted in the coprocessor in the scheme, which is the real-time requirement of robot control, but the processing mode still occupies a large number of communication channels between the main processor and the coprocessor, and the conversion between the private data format and the ROS message format and the inherent delay (generally about 10 ms) of the minimum operation unit of the Linux system, so that the robot of the control mode cannot really realize real-time control. Meanwhile, a large amount of data is transmitted on a communication channel, a concept of bit error rate is introduced, the bit error rate in a communication system is in direct proportion to the communication capacity of the system, more data throughput amount can cause higher bit error rate, if a link of encoding and decoding is introduced for reducing the bit error rate, the system cost can be increased, and a new system time delay problem is caused.

Disclosure of Invention

In view of the above, a robot control device, method and robot of the present invention have been proposed in order to solve or at least partially solve the above problems.

According to one aspect of the invention, a robot control device is provided, which comprises a main processor, a coprocessor and one or more subtask controllers, wherein the coprocessor comprises a first ROS lib library, and the first ROS lib library comprises an ROS communication module and an ROS management module; the main processor and one or more subtask controllers are respectively connected with the coprocessor;

the coprocessor is used for managing task data sent by all the subtask controllers through the ROS management module; the method comprises the steps of sending task data in an ROS message format to a main processor through an ROS communication module, receiving a control instruction in the ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to a corresponding subtask controller according to management control of an ROS management module.

According to another aspect of the present invention, there is provided a method of controlling a robot including a main processor, a coprocessor and one or more subtask controllers, the method being applied in the coprocessor of the robot, the method including:

receiving task data sent by one or more subtask controllers of the robot, managing the task data sent by all subtask controllers, and sending the task data in an ROS message format to a main processor;

and receiving a control instruction of an ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to the corresponding subtask controller.

According to a further aspect of the present invention there is provided a robot comprising a robot control apparatus as described above.

In summary, the technical scheme of the invention has the beneficial effects that: the coprocessor receives the task data sent by the subtask controller, performs corresponding management and processing uniformly, and performs ROS communication transmission with the main processor, the coprocessor directly sends the task data in an ROS message format to the main processor and also can directly receive a control instruction in the ROS message format of the main processor without conversion of the main processor, so that the processes that the main processor performs ROS message format conversion on the message sent by the coprocessor and converts an ROS control command into a message format corresponding to a private protocol of the coprocessor in the prior art are saved, the processing time of the message in the robot control process is saved, the burden of the main processor is reduced, the processing efficiency is improved, the real-time performance of robot control is guaranteed, and the use experience of a user is improved.

Drawings

Fig. 1 is a functional structure diagram of a robot control device according to an embodiment of the present invention;

FIG. 2 is a diagram illustrating a subtask controller communicating with a coprocessor, according to an embodiment of the present invention;

FIG. 3 is a diagram illustrating a mutex backup operation according to an embodiment of the present invention;

fig. 4 is a functional structure diagram of a robot control device according to another embodiment of the present invention;

fig. 5 is a schematic flow chart of a robot control method according to an embodiment of the present invention;

fig. 6 is a functional structure diagram of a robot according to an embodiment of the present invention.

Detailed Description

The design idea of the invention is as follows: in the invention, the ROS lib library is integrated in the coprocessor, so that the coprocessor can share part of task data processing, the burden of the main processor is reduced, and the processing efficiency of the task data is improved. In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Fig. 1 is a functional structure diagram of a robot control device according to an embodiment of the present invention. As shown in fig. 1, the robot controller 100 includes a main processor 110, a co-processor 120, a subtask controller 131, a subtask controller 132, and a subtask controller 133, where the co-processor 120 includes a first ROS lib library, and the first ROS lib library includes an ROS communication module and an ROS management module; the main processor 110 and the

subtask controllers

131, 132, and 133 are connected to the coprocessor 120, respectively.

The coprocessor 120 is used for managing task data sent by the subtask controller 131, the subtask controller 132 and the subtask controller 133 through the ROS management module; the method comprises the steps of sending task data in an ROS message format to a main processor 110 through an ROS communication module, receiving a control instruction in the ROS message format generated according to the task data and issued by the main processor 110, and issuing the control instruction to a corresponding subtask controller according to management control of an ROS management module.

The ROS Lib is the basis of all ROS Client Libraries and tools, and comprises common tools such as generators of messages and services, common message definitions such as titles and logs, and a common path guide code of the ROS Python node and tools, so that the ROS communication can be conveniently realized by an independent software library. In the prior art, after the coprocessor sends the collected data to the main processor, the embedded ROS node on the main processor is responsible for converting the data into ROS messages, which brings huge delay, meanwhile, in the prior art, a serial port is generally used as a communication medium, serial port communication is a serial communication mode, data is calculated according to a minimum clock and sent bit by bit, the bandwidth and baud rate of the communication mode are generally 115200bps (bits per second), which cannot tolerate network transmission of a large amount of data at the same time, if a large amount of data is transmitted, precious network resource bandwidth is occupied, and network congestion is generated, which typically has the phenomena of data packet loss and data scrambling, and the communication between the robot coprocessor and the main processor is exactly the transmission of a large amount of data at the same time, so, in robot control, packet loss and messy codes are easy to appear, which directly causes inaccurate data or abnormal analysis of commands, and cannot really meet the real-time requirement of the robot.

In addition, in the architecture design based on the main and coprocessor modes in the prior art, only a bare computer program or an RTOS system is operated on a coprocessor chip, and an ROS Lib communication module is not integrated. The method comprises the steps that after a coprocessor collects task data of each sensor or each motor, the task data are organized into specific character strings according to formats specified in private protocols of a main processor and the coprocessor, the specific character strings are sent to the main processor through a serial port or a network interface of the coprocessor, and then are analyzed on the main processor, therefore, an ROS node communication node is required to be independently added on the main processor, the node assigns the analyzed data to an ROS data structure body in a newly added module and issues the data according to a uniform ROS message format, namely, all ROS message processing is carried out at the main processor, and the coprocessor is not responsible for ROS message processing. Therefore, two independent communication systems (one is communication inside the main processor, and the other is communication between the coprocessor and the main processor) are introduced into the communication mode in the process, the two communication modes can interact with each other only through conversion, the conversion between the two communication systems inevitably consumes system resources and occupies system running time, and the communication system is obviously not suitable for occasions with high real-time requirements and is not beneficial to real-time acquisition and distribution of messages.

The ROS management module is an ROS master module and is mainly used for receiving and managing ROS messages, registering or releasing ROS nodes, controlling the frequency of message sending and subscribing, managing services, calling requests and the like. In the embodiment, the co-processing comprises an ROS lib library, the ROS lib library comprises an ROS master module and an ROS communication module, when the subtask controller sends the task data to the co-processor, the ROS master module of the co-processor can manage the received task data, when the co-processor distributes the task to the received task data, the ROS communication module processes the task data needing to be processed by the main processor into the task data in an ROS message format, and then sends the task data to the main processor, so that the main processor directly identifies the received task data, converts the task data into corresponding control instructions and directly sends the control instructions to the co-processor, and according to the management control of the ROS master module, the co-processor sends the received control instructions to the corresponding subtask controller.

Therefore, according to the technical scheme of the embodiment, the communication in the main processor and the message conversion in the communication between the coprocessor and the main processor are saved, the processing time of the message in the robot control process is further saved, the processing efficiency is improved, the real-time performance of robot control is guaranteed, and the use experience of a user is improved.

The number of the subtask controllers shown in fig. 1 is not limited to 3, and one or more, for example, 4, may be set as necessary.

In one embodiment of the present invention, the subtask controller 131, the subtask controller 132, and the subtask controller 133 shown in FIG. 1 each include a second ROS lib library including an ROS communication module.

And each subtask controller is used for converting the task data acquired in the working process of the robot into the task data in the ROS message format through the ROS communication module in the second ROS lib library and sending the task data to the coprocessor.

The traditional ROS communication mode is that each specific processing task is abstracted into an independent subtask or a subnode to run, each independent subtask needs to be established according to the ROS communication message format, the independent subtasks publish or subscribe messages or topics relevant to the independent subtask, the node information of the independent subtask and an ROS Master node are registered, and once the registration is completed, the message of the node is distributed to each node needing to subscribe the message through the ROS Master.

In the embodiment, the ROS Lib library is integrated on each subtask controller so as to realize that the independently operated subtask can become an ROS node and can be operated independently. In this way, the subtasks running on the coprocessor can communicate with each other like using a normal ROS node. In other words, each subtask can be used as an ROS node, all nodes designed by adopting an ROS communication architecture can freely release topic messages of respective tasks, and can subscribe task messages interested by the tasks, so that the requirement of each link is really met, the step that task data collected by a coprocessor needs to be analyzed on a main processor and then converted into message types capable of being identified by the ROS is avoided, and meanwhile, the response time of the whole system is increased.

Meanwhile, each subtask can be used as an ROS node to communicate with the coprocessor, so that a star-shaped network communication architecture in the communication system is embodied. After each subtask controller integrates the ROS Lib library, point-to-point communication with the coprocessor can be realized, and the communication architecture has the advantages that: 1) the communication control of the star network is the simplest and straightforward. If a ring network design is adopted, after one node communication fails, the ring link (formed by connecting nodes in series) is lost in the whole ring network communication, so that the whole system cannot normally communicate. If a mesh network communication mode is adopted, the scheme has a remarkable advantage for communication of a large mesh network and hundreds of nodes, is typically applied to large and inter-city network communication, and is expensive and impractical for a small-range robot field. 2) The fault of the star network is easy to diagnose and the problem is easy to isolate, because each node operates independently, once a certain node has single fault, the fault point can be quickly positioned, the normal work of the whole system cannot be influenced by the faulted node, and especially for some nodes with higher requirements on non-real-time performance, the fault even cannot influence the normal work of the whole system. 3) The method can conveniently and dynamically add a sensor or a controller designed based on the ROS, only the data of the sensor or the controller needs to be issued according to the message format of the ROS if a novel sensor or controller is added in the existing system by means of the function of the ROS Lib library, and if the prior art is adopted, the service code and the processing logic of the coprocessor need to be independently changed, and a new network bandwidth needs to be developed for the purpose.

Fig. 2 is a schematic diagram of a subtask controller communicating with a co-processor according to an embodiment of the present invention. As shown in fig. 2, unit 1 is a main processor, unit 2 is a coprocessor (including a main task management and scheduler, a backup task management and scheduler, and an ROS Lib library having an ROS master module and an ROS communication module), and the ROS Lib libraries are integrated in the unit 4 power management subtask controller, the unit 5 security subtask controller, the unit 6 sensor subtask controller, and the unit 7 motor subtask controller, and perform independent ROS communication with the unit 2 coprocessor, and a "star" network is formed between the subtask controllers and the coprocessor.

In one embodiment of the invention, the co-processor 120 includes a master scheduler and a slave scheduler, each including a first ROS lib library. The master scheduler and the slave scheduler communicate with the master processor in a mutually exclusive backup operation mode.

In the prior art, a coprocessor is adopted to collect data of a sensor, control the starting or stopping of a motor, send collected or control signals to a main processor for resolving or processing through a serial port RS232 or a similar wired port mode according to a certain data format, and the main processor is converted into a topic or message format of an ROS system and then issued after resolving according to a private communication format. In the whole system, only two nodes of a main processor actually run node functions related to the ROS, one ROS Master node manages the other ROS nodes and serves as a network routing function and is responsible for subscribing ROS task programs and publishing topics or messages required by the running of the nodes, and once a coprocessor fails due to some reason, an embedded ROS node in the main processor cannot obtain data relied on by the running of the system, so that the running of the system is wrong, and a robot cannot work normally. Therefore, the prior art solutions do not guarantee the stability of the robot control.

In the embodiment, the coprocessor comprises a master scheduler and a slave scheduler, a ROS scheduling part adopts master-slave backup, the robustness of the system is improved, the ROS scheduler of the coprocessor cannot stop running when suddenly failing, even if the master task scheduler is abnormal due to some reason, the slave task scheduler can immediately execute backup operation, and uninterrupted running of the whole ROS system is ensured. In some occasions with high requirements on safety, the redundant design in the embodiment can play an important role, for example, in the robot field and the like for emphasizing the safety and stability of the whole system, and the like, the control on key modules such as a motor, a mechanical arm and the like can be realized.

Specifically, the aforementioned mutually exclusive backup operation includes:

for the main scheduler, when the main scheduler runs, locking the process of the system of the main scheduler, and starting an ROS management module and an ROS communication module in a first ROS lib library of the main scheduler to run; when the master scheduler operates abnormally, the ROS management module and the ROS communication module in the master scheduler are stopped to operate, and an unlocking permission signal is released to the slave scheduler;

for a slave scheduler, when a master scheduler runs, if an unlocking permission signal cannot be acquired within a preset number of times or preset time, entering a standby monitoring state, when the unlocking permission signal is monitored and the running of an ROS management module and an ROS communication module in the master scheduler is terminated, locking a process of a system of the slave scheduler, starting the ROS management module in a first ROS lib library of the slave scheduler, and starting the ROS communication module in the first ROS lib library of the slave scheduler to run; when the slave scheduler operates abnormally, the ROS management module and the ROS communication module in the slave scheduler are stopped from operating, and the unlocking permission signal is released to the master scheduler.

FIG. 3 is a diagram illustrating a mutex backup operation according to an embodiment of the present invention. As shown in fig. 3, when the ROS task management and scheduler 1 (i.e. the main scheduler) runs, the locking signal of the scheduler 1 is sent to lock the process of the scheduler 1 itself, the ROS master module in the first ROS lib library of the scheduler 1 is started, and the ROS communication module in the first ROS lib library of the scheduler 1 is started to run; judging whether the communication is abnormal or not, and if the communication is normal, continuing the communication; if the operation is abnormal, the scheduler 1 is determined to be abnormal, at this time, the operation of the ROS master module and the ROS communication module is stopped, the switching to the scheduler 2 is allowed, and the locking signal (the unlocking allowing signal) of the scheduler 2 is released. The task management and scheduler 2 (namely, a slave scheduler) enters a standby monitoring state when the scheduler 1 runs and if a lock signal of the scheduler 2 cannot be acquired within a preset number of times or a preset time, locks a process of a system of the scheduler 2 when the lock signal of the scheduler 2 is monitored and the running of an ROS master module and an ROS communication module in the scheduler 1 is terminated, starts an ROS master module in a first ROS lib library of the scheduler 2, and starts the running of the ROS communication module in the first ROS lib library of the scheduler 2; judging whether the communication is abnormal or not, and if the communication is normal, continuing the communication; if the operation of the dispatcher 2 is abnormal, the abnormal operation is determined, at the moment, the operation of the ROS master module and the ROS communication module is stopped, the switching to the dispatcher 1 is allowed, the locking signal (the unlocking allowing signal) of the dispatcher 1 is released, and the operation is started by the dispatcher 1.

It should be noted that, when the scheduler 1 runs, the transmitted lock signal (i.e., the locking signal) of the scheduler 1 may make the scheduler 2 unable to access the code region in the program, and the scheduler 2 may only start running when it waits to acquire its lock signal (i.e., the unlocking signal or the unlocking signal is allowed); similarly, when the scheduler 2 runs, the transmitted locking signal of the scheduler 2 may make the scheduler 1 unable to access the code region in the program, and the scheduler 1 may only start running after acquiring its own unlocking signal.

The mutual exclusion operation not only maintains the uniqueness of the ROS Master in the coprocessor, but also ensures that the function of node scheduling management in the ROS system is not interrupted, thereby ensuring the continuity of the communication of the whole node and the stability of the system.

In one embodiment of the invention, the robot further comprises a camera module;

the camera module is connected to the main processor 110 of the control device 100 shown in fig. 1, and is used for sending the image collected by the camera to the main processor. And the main processor 110 is configured to identify the received image, generate a corresponding obstacle avoidance control instruction according to the identification result, and send the instruction to the coprocessor.

Although the RTOS system runs in the coprocessor, only simple task data can be processed to ensure real-time performance, but complex data processing also needs a main processor to complete, for example, picture data. In this embodiment, the camera module is directly connected to the main processor, so that the main processor can perform timely processing, rather than performing data transmission through the coprocessor, and the real-time performance of robot control is further ensured.

In an embodiment of the present invention, the control apparatus 100 shown in fig. 1 further includes a communication forwarding module, and the coprocessor 120 is connected to the main processor through the communication forwarding module.

The robot also comprises a laser radar module, a grabbing module and an expanding module; the laser radar module, the grabbing module and the expanding module are respectively connected with a main processor of the control device through the communication forwarding station module.

The communication forwarding station module comprises an ROS TCP/IP serial port and an ROS serial port.

And the expansion module is used for providing one or more expansion interfaces for the external equipment to access the robot.

The ROS TCP/IP communication in the communication forwarding station module is suitable for high-speed large-data-volume communication, and because the current mainstream laser radar and the robot grabbing device both adopt a TCP/IP communication mode, a large amount of data interaction is generated in the operation process, and the maximum transmission rate of the traditional serial communication or RS485 communication modes cannot meet the requirement of the communication rate. Meanwhile, an ROS Serial communication interface is reserved for communication with small data volume (for example, some simple control commands are sent), so that the communication use of other modules is expanded conveniently. Meanwhile, the communication forwarding station is connected with the expansion module and used for the robot control device to be expanded, for example, an HDMI display, JoyStick handle control and a USB expansion interface are reserved on the expansion interface unit, so that the access of external equipment is facilitated, and the fact that mainstream equipment in the field of robots can be directly accessed to the robot control device is guaranteed.

In one embodiment of the invention, the subtask controller shown in FIG. 1 includes one or more of the following: a power management subtask controller; a secure subtask controller; a sensor subtask controller; a motor subtask controller.

Fig. 4 is a functional structure diagram of a robot control device according to another embodiment of the present invention. As shown in fig. 4:

the module 1 is a main processor, and a computer with a miniPC high-performance x86 architecture of Intel corporation is adopted, and on the basis, a Ubuntu Linux and ROS system are operated. The module 1 is physically connected to an RGBD depth camera module 10(Prime sense camera, 3D + Color data) through a USB interface, and the device is used for acquiring depth image information of an external environment, converting an image into point cloud information, and using the point cloud information for a local obstacle avoidance function of a robot. The module 2 is a coprocessor, an STM32F767 chip of 2 Italian semiconductor companies is adopted, the chip uses a cortex M7 kernel, the main frequency reaches 218Mhz and is suitable for running a real-time operating system, and a coprocessor controller runs a UCOS-III embedded real-time operating system and adds an ROS Lib library file, so that the module can be used as an independent ROS node and runs an ROS Master management node in a mutually exclusive manner on the basis. The communication between the master and slave controllers is realized through a communication forwarding station module 3(docker), and the forwarding station integrates the functions of ROS TCP/IP and ROS Serial Serial ports. The laser radar module 8(Sick TIM571/Hokuyo UST30-LX) and the robot gripping device module 9 are connected with the module 1 through the communication forwarding station module 3. Meanwhile, the communication forwarding station module 3 is connected with the expansion module 11, the expansion module is used for the expansion design of the robot control device, a high-definition multimedia HDMI display interface, a JoyStick handle control interface, a Gigabit Ethernet interface and a USB interface are reserved on the expansion module 11, the expansion of peripheral equipment is facilitated, and mainstream equipment in the robot field can be directly accessed into the robot control device for control.

Module 2 is a co-processor integrating a primary task management and scheduler (primary scheduler), a backup task management and scheduler (secondary scheduler). The main task management and scheduler and the backup task management and scheduler are two embedded chips (STM32F767), UCOS-III and software mutual exclusion operation are operated in the two chips, functions of an ROS Lib library are integrated in the two chips, only one ROS Master node can be independently operated at each time, and the ROS Master node is used for managing interactive communication of other nodes in an ROS network. After the module 2 integrates the function of the ROS, the module 2 can directly issue the theme and the message of the corresponding module through the ROS, and communicate with the module 1 by utilizing the ROS TCP/IP protocol. A plurality of subtask controller modules, namely a power management subtask controller module 4, a safety subtask controller module 5, a sensor subtask controller module 6 and an electric motor subtask controller module 7, are connected around the module, and all the modules are physically connected to the module 2.

The power management subtask controller 4 adopts a low-cost STM32F103Cortex M3 inner core as a controller, the module is used as a robot control device to measure battery voltage and automatically avoid barriers, the output voltage and the output current of the lead-acid battery are mainly sampled, and the module is used for connecting a high-precision voltage sensor and a high-precision current sensor. High accuracy voltage sensor is used for detecting lead acid battery's energy storage voltage, when battery voltage is less than a certain degree, for example when being less than 40% of total electric capacity, can send the low signal of electric quantity, tells the robot and need in time charge to realize independently charging. The high-precision current sensor is used for detecting the discharged current of the battery, if the robot circuit has an overcurrent condition due to some reason, the current sensor can also send an alarm signal to the slave controller, the slave controller can respond to the signal to emergently stop the operation of the robot, so that important parts in the robot are protected from being damaged due to continuous impact of large current, and meanwhile, the module integrates an ROS communication function (ROS Lib library) and issues Batts/msg messages conforming to an ROS message format.

The safety subtask controller 5 also adopts an STM32F103 chip, is mainly used as a safety strategy control in a robot system, and the module is used for physically connecting some safety sensors so that the robot can immediately stop and collect related safety strategies when meeting some emergency situations, and mainly covers breaker, an electromagnetic band-type brake system, a self-recovery fuse, collision sensors, indicator lights and the like. The circuit breaker and the self-recovery fuse are used for limiting the current of each branch in the circuit, and when the current in the loop exceeds a tolerance value, the load circuit is automatically disconnected so as to protect the load from continuous impact of large current. The electromagnetic band-type brake module is used for an emergency stop function in motor control, when the motor cannot receive a stop instruction due to an emergency, the motor needs to be stopped immediately in order to avoid potential damage caused by the operation of the motor, and at the moment, the band-type brake system can be used for stopping the operation of the motor within a short time (a few microseconds). The collision sensor is used for sending a digital quantity signal to the slave controller when the robot does not detect barrier information in the running direction of the robot by the sensor under certain conditions, and immediately adopting an emergency barrier avoidance strategy after receiving the signal from the slave controller to stop the robot from running or rotate in place for a certain angle to avoid the barrier. The indicating lamp module generally uses a lamp belt as an indication robot running state mark, in the scheme, a green constant is used for representing that the robot is in a normal running state, red flicker represents that the robot meets an obstacle and is in a calculating and processing process, the module integrates an ROS communication function (ROS Lib library) and issues IO/msgs messages conforming to an ROS message format.

The sensor subtask controller 6 adopts the STM32F103Cortex M3 kernel as a controller, and the robot needs to rely on various sensor modules to sense external 'information'. The module connects several important sensor modules including: the robot comprises an IMU, ultrasonic sensors and infrared sensors, wherein 9DOF sensors (acceleration, gyroscope and magnetometer) are physically connected in an IIC communication mode and used for acquiring deflection angle information of the robot in the moving process, meanwhile, the module 6 is also physically connected with sensors of single-point distance measurement types such as the ultrasonic sensors and the infrared sensors and used for sensing point distance information of each azimuth of the robot from obstacles, the relatively accurate point local obstacle avoidance function of the robot can be realized by means of the sensors, the module also inherits an ROS communication function (ROS Lib library) and issues a sensor/msgs message in an ROS message format.

The motor subtask controller 7 also uses an STM32F103 chip, is physically connected to an actual motor driving circuit in a CAN-BUS communication mode, receives a motion control instruction sent by the miniPC module, and converts the motion control instruction into an analog quantity signal (0-5 Vdc) for actually controlling the motor rotating speed through the driving circuit so as to control the motor operating speed. Meanwhile, the motor subtask controller 7 is also connected with the light spot encoder 1 and the photoelectric encoder 2, when the motor runs, a Hall code detection module arranged on the motor feeds back the pulse number generated on the encoder in unit time when the actual motor runs (note that the number of the fed-back pulse number is in a direct proportion relation with the running rotating speed of the motor), the fed-back pulse number collects the pulse number generated in the actual unit time in an interruption detection mode on the slave controller, then the pulse numbers of the left wheel and the right wheel are fed back to the slave controller through a CAN-BUS BUS, the data of the photoelectric encoder 1 of the left wheel and the data of the photoelectric encoder 2 of the right wheel are used for calculating the actual mileage of the motor running, and the ROS module node issues a cmd/vel message.

In the embodiment, the ROS Lib library is independently added into the processor of each subtask module, so that the requirements of other related subtasks can be greatly expanded, third-party hardware can be randomly added on the basis of the ROS Lib library and can be immediately identified by an ROS system, the step of converting a private control protocol into a general ROS message type is omitted, the links of transmission and conversion of intermediate signals are effectively reduced, and the task burden of a main processor is also effectively reduced. For a communication system, a large amount of data transmission must introduce an error rate, the probability is in direct proportion to the quantity of transmission data, and the error rate can be effectively reduced by reducing intermediate links of data transmission and conversion, so that the system design is more efficient and safer. Through testing, the control processing speed of the control device in the technical scheme to the motor can reach 100-200 Hz per second, and the system can guarantee stable operation at the speed, so that the processing efficiency can not be guaranteed by adopting the prior art. Meanwhile, for some equipment with low real-time requirement, the response priority can be properly reduced, and the control frequency is set to be 1-5 Hz per second, so that precious communication resources can be saved, and high-level important tasks can be processed preferentially.

Fig. 5 is a flowchart illustrating a robot control method according to an embodiment of the present invention, where the robot includes a main processor, a coprocessor, and one or more subtask controllers. The method is applied to a coprocessor of the robot. As shown in fig. 5, the method includes:

step S510, receiving task data sent by one or more subtask controllers of the robot, managing the task data sent by all subtask controllers, and sending the task data in the ROS message format to the main processor.

And step S520, receiving a control instruction of an ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to the corresponding subtask controller.

Specifically, the coprocessor comprises a first ROS lib library, the first ROS lib library comprises an ROS communication module and an ROS management module, the ROS communication module receives task data sent by one or more subtask controllers of the robot, and the ROS management module manages the received task data. And transmitting the task data in the ROS message format to the main processor through the ROS communication module. And receiving a control instruction of an ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to the corresponding subtask controller according to the management control of the ROS management module.

In one embodiment of the invention, the coprocessor includes a master scheduler and a slave scheduler. The method shown in fig. 5 further comprises:

the master scheduler and the slave scheduler communicate with the master processor in a mutual exclusion backup operation mode, wherein the mutual exclusion backup operation mode comprises the following steps: when the master scheduler operates, locking the process of the system of the master scheduler, forbidding unlocking of the slave scheduler, and when the master scheduler operates abnormally, releasing an unlocking permission signal to the slave scheduler; in the operation process of the master scheduler, if the slave scheduler cannot acquire the unlocking permission signal within the preset times or preset time, the slave scheduler enters a standby monitoring state, locks the process of the system of the slave scheduler when the unlocking permission signal is monitored, prohibits the master scheduler from unlocking, and releases the unlocking permission signal to the master scheduler when the slave scheduler operates abnormally.

Specifically, the master scheduler and the slave scheduler each include a first ROS lib library. The master scheduler and the slave scheduler communicate with the master processor in a mutually exclusive backup operation mode.

The above-mentioned manner of using the mutual exclusion backup operation includes:

for a slave scheduler, when a master scheduler runs, if an unlocking permission signal cannot be acquired within a preset time or preset times, entering a standby monitoring state, when the unlocking permission signal is monitored and the running of an ROS management module and an ROS communication module in the master scheduler is stopped, locking a process of a system of the slave scheduler, and starting the running of the ROS management module and the ROS communication module in a first ROS lib library of the slave scheduler; when the slave scheduler operates abnormally, the ROS management module and the ROS communication module in the slave scheduler are stopped from operating, and the unlocking permission signal is released to the master scheduler.

Fig. 6 is a functional structure diagram of a robot according to an embodiment of the present invention. As shown in fig. 6, the robot 600 includes a robot controller 610 shown in fig. 1 or 2.

It should be noted that the method illustrated in fig. 5 and the embodiments of the robot illustrated in fig. 6 correspond to the embodiments of the apparatus illustrated in fig. 1, and the detailed description is given above and will not be repeated here.

While the foregoing is directed to embodiments of the present invention, other modifications and variations of the present invention may be devised by those skilled in the art in light of the above teachings. It should be understood by those skilled in the art that the foregoing detailed description is for the purpose of better explaining the present invention, and the scope of the present invention should be determined by the scope of the appended claims.

Claims

1. A robot control device comprises a main processor, a coprocessor and one or more subtask controllers, and is characterized in that the coprocessor comprises a first ROS lib library, and the first ROS lib library comprises an ROS communication module and an ROS management module; the main processor and one or more subtask controllers are respectively connected with the coprocessor;

the coprocessor is used for managing task data sent by all the subtask controllers through the ROS management module; sending the task data in an ROS message format to the main processor through the ROS communication module, receiving a control instruction in the ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to a corresponding subtask controller according to the management control of the ROS management module;

the coprocessor is also used for processing the task data into task data in an ROS message format through the ROS communication module and sending the task data to the main processor;

each subtask controller comprises a second ROS lib library, and the second ROS lib library comprises an ROS communication module;

and the subtask controller is used for converting task data acquired in the working process of the robot into task data in an ROS message format through an ROS communication module in the second ROS lib library and sending the task data to the coprocessor.

2. The robot controller of claim 1, wherein the co-processor includes a master scheduler and a slave scheduler, the master scheduler and the slave scheduler respectively including the first ROS lib library;

and the master scheduler and the slave scheduler are communicated with the master processor in a mutually exclusive backup operation mode.

3. The robot control apparatus of claim 2, wherein the mutually exclusive backup operation comprises:

for a main scheduler, when the main scheduler runs, locking a process of a system of the main scheduler, and starting an ROS management module and an ROS communication module in a first ROS lib library of the main scheduler to run; when the master scheduler is abnormal in operation, the ROS management module and the ROS communication module in the master scheduler are stopped from operating, and an unlocking permission signal is released to the slave scheduler;

for a slave scheduler, when the master scheduler operates, if an unlocking allowing signal cannot be obtained within a preset time or preset time, entering a standby monitoring state, and when the unlocking allowing signal is monitored and the running of the ROS management module and the ROS communication module in the master scheduler is terminated, locking the process of the system of the slave scheduler and starting the running of the ROS management module and the ROS communication module in a first ROS lib library of the slave scheduler; when the slave scheduler operates abnormally, the ROS management module and the ROS communication module in the slave scheduler are stopped from operating, and an unlocking allowing signal is released to the master scheduler.

4. The robot control apparatus of claim 1, wherein the robot includes a camera module;

the camera module is connected with a main processor of the control device and sends images acquired by the camera to the main processor;

and the main processor is used for identifying the received image, generating a corresponding obstacle avoidance control instruction according to the identification result and issuing the obstacle avoidance control instruction to the coprocessor.

5. The robot controller of claim 1, wherein the controller further comprises a communication forwarding station module, the coprocessor being connected to the main processor through the communication forwarding station module;

the robot also comprises a laser radar module, a grabbing module and an expanding module; the laser radar module, the grabbing module and the expanding module are respectively connected with the main processor through the communication forwarding station module; the communication forwarding station module comprises an ROS TCP/IP serial port and an ROS serial port, and the expansion module is used for providing one or more expansion interfaces for the external equipment to access the robot.

6. The robot control apparatus of claim 1, wherein the subtask controller includes one or more of:

a power management subtask controller;

a secure subtask controller;

a sensor subtask controller;

a motor subtask controller.

7. A method of controlling a robot, the robot comprising a main processor, a co-processor and one or more subtask controllers, the method being applied in a co-processor of a robot, the method comprising:

receiving task data sent by one or more subtask controllers of the robot, managing the task data sent by all the subtask controllers, and sending the task data in an ROS message format to a main processor;

receiving a control instruction of an ROS message format generated according to the task data and issued by the main processor, and issuing the control instruction to a corresponding subtask controller;

processing the task data into task data in an ROS message format and sending the task data to the main processor;

and the subtask controller converts the task data acquired in the working process of the robot into the task data in the ROS message format through the ROS communication module in the second ROS lib library and sends the task data to the coprocessor.

8. The robot control method of claim 7, wherein the co-processor includes a master scheduler and a slave scheduler, the method further comprising:

the master scheduler and the slave scheduler communicate with the master processor in a mutually exclusive backup operation mode, wherein the mutually exclusive backup operation mode comprises the following steps:

when the master scheduler operates, locking the process of the system of the master scheduler, prohibiting the slave scheduler from unlocking, and when the master scheduler operates abnormally, releasing an unlocking permission signal to the slave scheduler; in the operation process of the master scheduler, if the slave scheduler cannot acquire the unlocking permission signal within the preset times or preset time, the slave scheduler enters a standby monitoring state, locks the process of the system of the slave scheduler when the unlocking permission signal is monitored, forbids the master scheduler to unlock, and releases the unlocking permission signal to the master scheduler when the slave scheduler is abnormally operated.

9. A robot, characterized in that the robot comprises a robot control device according to any of claims 1-6.