An Embedded Robot Operating State Monitoring Method

Abstract

The present invention provides a method for monitoring the running state of an embedded robot, which is characterized by including the following operations: an operation of constructing a running state data set of the embedded robot, where the running state data set includes state variables of multiple embedded robots and data packets bound to the state variables. Among them, the state variables include first-class state variables and second-class state variables; an operation of synchronizing the running state data set, including obtaining real-time measured values of the first-class state variables according to the running state of the peripherals of the embedded robot and synchronously updating them, and controlling the running state of the peripherals of the embedded robot according to the real-time set values of the second-class state variables and synchronously updating them. The technical solution of the present application can effectively avoid modifying global variables at the kernel layer and ensure safe and stable monitoring of the running state of the embedded robot.

Description

Technical Field

[0001] This application belongs to the technical field of robot control, involves embedded robot monitoring technology, and specifically provides a method for monitoring the running state of an embedded robot. Background Art

[0002] An embedded robot refers to a robot device that uses an embedded operating system for control and autonomously completes specific tasks through functional components such as sensors and actuators. Since it can be customized according to different tasks and environments, it has strong flexibility and adaptability. In addition, the embedded operating system runs stably and has strong anti-interference ability, with the advantages of less hardware resource occupation, small volume, space saving, and manufacturing and usage cost savings. Therefore, using it to control robots has significant advantages compared to other large operating systems. Robots developed using the embedded system have currently been widely used in industrial automation production lines, healthcare, home services, intelligent transportation and other fields to perform intelligent manufacturing assembly, intelligent surgery, home cleaning, traffic monitoring, and intelligent navigation and other tasks.

[0003] During the operation of an embedded robot, it is necessary to process and analyze the state variables obtained by a large number of sensor peripherals or set by controller peripherals such as motors and servos to achieve real-time monitoring of the robot. The acquisition methods and setting methods of the above state variables are different, and may be accessed by different functional modules at the same time. In the case of low hardware configurations such as the processor and memory of the embedded operating system, generally, it does not have a powerful and perfect variable anti-collision synchronization mechanism like a large operating system. Therefore, during the operation of an embedded robot, various types of failures may occur due to conflicts in variable synchronization.

[0004] Therefore, it is necessary to improve the existing variable acquisition and setting methods of the embedded operating system according to different types of state variables during the operation of the robot to ensure more effective monitoring of the running state of the robot. Summary of the Invention

[0005] To solve the problems existing in the above-mentioned prior art, this application provides a method for monitoring the running state of an embedded robot through embodiments. The method includes the following operations:

[0006] An operation of constructing a running state data set of the embedded robot, where the running state data set includes multiple state variables of the embedded robot and data packets bound to the state variables. Among them, the state variables include a first type of state variable and a second type of state variable;

[0007] The operation of synchronizing the operating status data set includes obtaining real-time measurement values of the first type of status variables according to the operating status of the peripherals of the embedded robot and synchronously updating them, and controlling the operating status of the peripherals of the embedded robot according to the real-time setting values of the second type of status variables and synchronously updating them.

[0008] Furthermore, the real-time measurement values of the first type of status variables are obtained through the first type of peripherals of the embedded robot; and the real-time setting values of the second type of status variables are used to drive the second type of peripherals of the embedded robot.

[0009] Furthermore, the first type of peripherals are sensor-type peripherals.

[0010] Preferably, the second type of peripherals includes at least one of the following devices: motor, servo, heating device.

[0011] Preferably, the status variables have at least two storage addresses, and the data packet at least includes the following data items: the ID of the status variable bound to the data packet, the current value, the storage address list, and the storage address locking status.

[0012] Furthermore, for each of the status variables, the following steps are used for synchronous update:

[0013] Step 100, obtain the real-time measurement value or real-time setting value of the status variable to be updated;

[0014] Step 200, determine the data packet bound to the status variable to be updated;

[0015] Step 300, read the locking status in the data packet. If the locking status is unlocked, execute Step 400. If the locking status is locked, wait until the locking status of the status variable becomes unlocked and there is no earlier update operation for the status variable, and then enter Step 400;

[0016] Step 400, set the locking status in the data packet to locked;

[0017] Step 500, read the storage address list from the data packet;

[0018] Step 600, use the obtained real-time measurement value or real-time setting value to update each storage address on the storage address list in the data packet;

[0019] Step 600, use the obtained real-time measurement value or real-time setting value to update the current value in the data packet;

[0020] Step 800, set the locking status in the data packet to unlocked.

[0021] Preferably, the data packet further includes a pointer to a synchronization function, and the synchronization function is used to synchronously store the current value of the state variable at the storage address of the state variable.

[0022] Preferably, the multiple state variables further include at least one third type of state variable, and synchronizing the operating state data set further includes: synchronously updating the third type of state variable according to the real-time measurement value of the first type of state variable and / or the real-time setting value of the second type of state variable.

[0023] Preferably, synchronizing the operating state data set further includes: synchronously updating the third type of state variable according to the communication status between the peripherals of the embedded robot.

[0024] Preferably, the method for monitoring the operating state of the embedded robot further includes an operation of judging whether there is an abnormality in the operating state of the embedded robot.

[0025] The method for monitoring the operating state of the embedded robot provided by the embodiments of the present application respectively establishes data packets bound to different types of state variables involved in the operation of the embedded robot, and each functional function or module running in the application layer can synchronously update at multiple storage addresses through the current value of the state variable in the data packet, thus avoiding changes to global variables in the kernel layer and ensuring safe and stable monitoring of the operating state of the embedded robot. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a schematic diagram of the architecture of an embedded robot;

[0027] Figure 2 is a schematic diagram of the method for monitoring the operating state of the embedded robot provided by some embodiments of the present application;

[0028] Figure 3 is a schematic diagram of the steps for synchronously updating state variables according to some embodiments of the present application;

[0029] Figure 4 is a schematic diagram of the method for monitoring the operating state of the embedded robot provided by some embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0030] Hereinafter, the present application will be further described based on preferred embodiments with reference to the accompanying drawings.

[0031] The terms used in this specification are for the purpose of describing the embodiments of the present application, but are not intended to limit the present application. It should also be noted that unless otherwise clearly specified and defined, the terms "arranged", "connected", and "coupled" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection, a direct connection, or an indirect connection through an intermediate medium, and it can be the communication inside two components. For those skilled in the art, the specific meanings of the above terms in the present application can be specifically understood.

[0032] Figure 1 shows a schematic diagram of the architecture of a specific embedded robot, as Figure 1 shown, the embedded robot consists of a control unit, a power supply unit, a communication unit, a storage unit, a power supply unit, and multiple peripherals.

[0033] Specifically, as Figure 1 shown, the control unit consists of a main chip and multiple sub-chips controlled by it. Among them, the embedded operating system runs on the main chip, and multiple sub-chips are respectively connected to each functional unit to perform operations such as transmission, analysis, and preprocessing of data and control signals. In addition, data communication can also be carried out between multiple sub-chips. For example, in Figure 1 , data communication can be carried out between the first sub-chip and the third sub-chip through the second sub-chip.

[0034] Figure 1 The shown embedded robot can further include multiple first-class peripherals and multiple second-class peripherals. The difference between the above two types of peripherals lies in the different signal transmission directions.

[0035] In some embodiments of the present application, as Figure 1 shown, the first-class peripherals include temperature sensors, photosensitive sensors, trigger sensors (such as microswitches), attitude sensors (such as accelerometers), image sensors (such as cameras), infrared sensors, encoders, ultrasonic sensors, magnetic sensors, etc. The information of the measured values obtained by them can reflect the operating states of various positions or components of the robot, such as the temperature, attitude, etc. of specific parts or devices. In some preferred embodiments, as Figure 1 shown, the information obtained by the above-mentioned various sensors can be uniformly managed by the first sub-chip and transmitted to the embedded operating system on the main chip as the first-class state variables; in addition, in some embodiments, the first sub-chip can also perform processing such as format conversion, analog-to-digital conversion, data value abnormality judgment, and data reception status verification on the measured values obtained by the sensors.

[0036] In some embodiments of the present application, as Figure 1As shown, the second type of peripheral devices include motors, servos, heating devices (heating elements), etc. They receive the set values sent from the embedded operating system, such as the rotational speed / power value of the motor, the angle value of the servo, and the heating current signal of the heating element, etc., so that the above-mentioned second type of peripheral devices can reach the desired operating state. In this application, this type of peripheral device is also called a controller. In some preferred embodiments, as Figure 2 shown, multiple second type of peripheral devices can be uniformly managed by the third sub-chip. The third sub-chip receives the set values of different motors, servos, heating elements, etc. from the embedded operating system of the main chip and transmits them as second type of state variables to the corresponding second type of peripheral devices.

[0037] Figure 1 During the operation of the embedded robot shown, it is necessary to accurately obtain the real-time measured values of the above-mentioned first type of state variables to monitor whether there are faults or abnormalities in each functional unit, module, and component of the robot, and control devices such as motors and servos in a timely manner through the real-time set values of the second type of state variables so that the robot can perform the desired actions or reach the desired operating state; in addition, since different functional modules may need to obtain the same state variable or have the right to control the same state variable separately during the operation of the embedded robot, such state variables generally need to be stored in different modules or storage addresses, that is, each state variable has at least two storage addresses.

[0038] During the process of accessing the state variables stored in multiple addresses, if the variable values stored in multiple addresses are not synchronously updated, it may lead to system data conflicts and even cause the system to crash in severe cases. For this reason, this application proposes an improved method for monitoring the operating state of an embedded robot, which is used to monitor the embedded robot in real time and accurately to ensure the stable operation of the embedded robot.

[0039] Figure 2 shows a schematic diagram of the operations included in the method for monitoring the operating state of the embedded robot in some embodiments, as Figure 2 shown, the method for monitoring the operating state of the embedded robot includes an operation of constructing an operating state data set of the embedded robot and an operation of synchronizing the operating state data set.

[0040] Specifically, the operating state data set includes multiple state variables of the embedded robot and data packets respectively bound to each state variable. Among the multiple state variables, there are at least one first type of state variable ( Figure 2 state variable 1 in Figure 2For the state variables in [description], as described above, the real-time measurement values of the first type of state variables can be obtained through the first type of peripherals of the embedded robot; and, the real-time set values of the second type of state variables are used to drive the second type of peripherals of the embedded robot. The specific meanings of the first type of peripherals, the first type of state variables, the second type of peripherals, and the second type of state variables have been described in detail above and will not be elaborated here.

[0041] In the embodiments of the present application, by constructing a data packet bound to the state variable, the conventional direct access to the state variable is changed to access to the data packet. The reason for using this data access mechanism is as follows: In the variable management mechanism of existing embedded robots, for multi-address variables during operation, generally, global variables are set to achieve access by multiple modules. Since the declaration and access of the above global variables involve the kernel layer, careful handling is required. Especially in the final development (especially the application layer), if the variable access mechanism is not coordinated among multiple developers, it is easy to have the situation where global variables (variables declared with extern) are independently called in different programs developed by multiple developers, and even modified separately at multiple storage addresses without unified coordination. This situation is very dangerous and may even cause the system to crash. In addition, some embedded robots stipulate that a locking protection operation is required when accessing global variables during the development stage. However, in the actual development process, it is difficult to ensure that the code of all developers complies with the above specifications through mandatory measures. Therefore, a more robust variable synchronization update mechanism independent of the underlying architecture is needed to avoid the damage to variable synchronization caused by the non-standard code of developers.

[0042] In the embodiments of the present application, the synchronization update of the above state variables is carried out through a data packet bound to the state variable, and the construction, access, and update operations of the data packet are carried out in the application layer of the embedded system and can be accessed or called by different functions, so that the management of the state variable is decoupled from the underlying hardware architecture, which more effectively ensures the robustness of the system.

[0043] In the embodiments of the present application, as Figure 2 shown, each data packet includes at least the following items: the ID of the state variable bound to the data packet, the current value, the storage address list, and the locking state. Among them, the ID value of the state variable is used to uniquely identify the state variable, and the current value corresponds to the real-time measurement value of the first type of peripherals or the implementation setting value of the second type of peripherals according to the type of the state variable; the storage address list stores the storage addresses of the state variable in each module authorized to access it. After the current value changes, it is synchronously updated in its storage address list. The locking state is used to represent the locked or unlocked state of the state variable in real time during the synchronization update process.

[0044] Specifically, when a status variable is in an unlocked state, all programs or functions with access permissions are entitled to read or update it. When a status variable is in a locked state, except for the programs / functions that have currently entered the read or update operation, other programs / functions that need to access this status variable wait in a queue for the locked state to switch. In some specific embodiments, a semaphore in an embedded system can be used as the locked state.

[0045] As Figure 2 shown, in the method for monitoring the running state of an embedded robot provided by this application, the operation of synchronizing the running state data set includes obtaining the real-time measurement values of the first type of status variables according to the running states of the peripherals of the embedded robot and synchronously updating them, and controlling the running states of the peripherals of the embedded robot according to the real-time set values of the second type of status variables and synchronously updating them.

[0046] Figure 3 shows the schematic diagram of the specific implementation process for synchronously updating the running state data set in some specific embodiments. As Figure 3 shown, the synchronous update includes the following steps:

[0047] Step 100: Obtain the real-time measurement values or real-time set values of the status variables to be updated;

[0048] Step 200: Determine the data packet bound to the status variable to be updated;

[0049] Step 300: Read the locked state in this data packet. If the locked state is unlocked, execute Step 400. If the locked state is locked, wait until the locked state of this status variable becomes unlocked and there is no earlier update operation for this status variable, and then enter Step 400;

[0050] Step 400: Set the locked state in this data packet to locked;

[0051] Step 500: Read the storage address list from this data packet;

[0052] Step 600: Use the obtained real-time measurement values or real-time set values to update each storage address on the storage address list in this data packet;

[0053] Step 700: Use the obtained real-time measurement values or real-time set values to update the current value in this data packet;

[0054] Step 800: Set the locked state in this data packet to unlocked.

[0055] In an embodiment of the present application, when the real-time measured value of the first state variable obtained by any one of the first type of peripheral devices changes, a reception interrupt is generally triggered, and after entering the reception interrupt, the first state variable can be synchronously updated through the above steps 100 to 600; in addition, when it is necessary to reset any one of the second type of peripheral devices with the real-time set value of the second state variable, the above steps 100 to 600 are generally executed through a function to synchronously update the second state variable.

[0056] Specifically, when implementing the above synchronous update, first, it is judged whether the state variable is being updated by other programs or functions according to whether the state variable is locked. If it is not locked, it directly enters the update operation of the state variable. Otherwise, it enters the queuing queue for updating the state variable and waits until all the previous update operations are completed before entering the update operation of the state variable.

[0057] Further, in the update operation of the state variable, first lock the state variable to avoid conflicts caused by other programs or functions operating on the state variable simultaneously during the update operation. Then, obtain all the storage addresses of the state variable from the bound data packet and update them at all the above addresses. Finally, unlock the state variable after the update is completed. The above update mechanism can prevent the occurrence of a new reception interrupt or controller output that causes the value of a certain storage address to change during the access to the state variable, resulting in the problem of each updating the value of the state variable at different storage locations with different real-time measured values or real-time set values.

[0058] Table 1 below shows the data format of the data packet in some preferred embodiments. As shown in Table 1, in this embodiment, in addition to including ID, current value, storage address list and its locked state, the data packet also includes information such as the moment when the variable changed most recently and the number of times the current value changed within a unit time.

[0059] Table 1 Data Format of the Data Packet

[0060]

[0061]

[0062] In some preferred embodiments, such as Figure 4As shown, the data packet further includes a pointer to a synchronization function. Specifically, the synchronization function can be a callback function known to those skilled in the art. When it is called, the current value of the state variable is synchronously stored at the storage address of the corresponding state variable, and after the call is completed, it returns to the position before the call to continue executing the program that was running before the call. Through the above callback function, programs developed by different developers can call it at the software layer to achieve synchronous update of the state variables of the embedded robot, thus avoiding the access to global variables by different programs at the kernel layer, and greatly improving the robustness and security of the system.

[0063] As described above, in the present application, the current values of the first type of variables, the second type of variables, the variable refresh time, and the refresh frequency information can be processed by a unified processing module (such as Figure 1 the first sub-chip in the [description of the chip] for receiving multiple first type of variables and the third sub-chip for sending multiple second type of variables); in addition, in some preferred embodiments, as Figure 3 shown, the second sub-chip connected between the first sub-chip and the third sub-chip can be further used to receive the first type of variables and the second type of variables, and generate a third type of variables by processing the first type of variables and the second type of variables; in some other preferred embodiments, the third type of variables can also be the CRC check value reflecting the CAN communication or board communication between the various units of the embedded robot to reflect the communication status of the embedded robot.

[0064] After synchronously updating the above first type of variables, second type of variables, and third type of variables, in some preferred embodiments of the present application, it is also possible to determine whether the operating state of the robot is abnormal through the synchronized operating state data set. For example, for a wheeled robot, if the roll axis angle obtained by its encoder has a problem of being too large, it is very likely that a rollover or other situation has occurred.

[0065] In the embodiments of the application, according to the operating states of different aspects of the embedded robot reflected by different types of variables, one or several state variables can be selectively monitored and the corresponding judgment method can be used to judge the abnormality of the operating state of the embedded robot. For example:

[0066] (1) In some embodiments, the abnormality can be judged based on the comparison result between the state variable and a preset threshold. When the current value of a certain state variable exceeds the preset threshold range, it can be judged that the operating state of the embedded robot is abnormal. As described above, when the roll angle is greater than the preset angle threshold, it is judged that a rollover fault has occurred:

[0067] (2) In some embodiments, anomaly judgment can be performed based on the duration for which the current value of the state variable remains in a certain state. For example, when the output of the motor remains at a high level for a long time, problems such as motor blockage and feedback failure may occur;

[0068] (3) In some embodiments, anomaly judgment can be performed based on the fluctuation frequency / amplitude of the state variable. For some peripherals such as motors, high-frequency and large-amplitude vibrations in certain situations are extremely harmful and may cause consequences such as controller instability and motor overheating and demagnetization. Therefore, for peripherals such as motors, an acceleration sensor can be used to obtain the amplitude and frequency of their vibrations for anomaly judgment;

[0069] (4) In some embodiments, anomaly judgment can be performed based on the update frequency of the state variable. When the update frequency of certain state variables of the embedded robot decreases, it often indicates problems such as loose connections, poor contact, overheating, and worn connection wires during the operation of certain peripherals (such as sensors), or problems such as abnormal control threads of certain peripherals (such as controllers) and frequent triggering of trigger thresholds. The variable refresh frequency data in the data packet bound to the state variable can be used to detect the above-mentioned low-frequency and large-amplitude fluctuation situations.

[0070] The results of the above anomaly judgment on the operating state of the embedded robot can be transmitted online to a control device such as a host computer through communication or recording methods known to those skilled in the art, or saved to a storage device such as a hard disk or FLASH for further fault analysis and troubleshooting.

[0071] The specific embodiments of the present application have been described in detail above. For those skilled in the art of this technology, without departing from the principle of the present application, several improvements and modifications can still be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. An embedded robot operating state monitoring method, characterized in that Including the following operations: An operation of constructing a running state data set of an embedded robot, where the running state data set includes state variables of multiple embedded robots and data packets bound to the state variables. Among them, the state variables include first-class state variables and second-class state variables; An operation of synchronizing the running state data set, including obtaining real-time measurement values of the first-class state variables according to the running states of the peripherals of the embedded robot and synchronously updating them, and controlling the running states of the peripherals of the embedded robot according to the real-time setting values of the second-class state variables and synchronously updating them; The state variables have at least two storage addresses, and the data packet at least includes the following data items: the ID of the state variable bound to the data packet, the current value, the storage address list, and the locked state; For each of the state variables, perform synchronous update through the following steps: Step 100, obtain the real-time measurement value or real-time setting value of the state variable to be updated; Step 200, determine the data packet bound to the state variable to be updated; Step 300, read the locked state in the data packet. If the locked state is unlocked, execute Step 400. If the locked state is locked, wait until the locked state of the state variable becomes unlocked and there is no earlier update operation for the state variable and then enter Step 400; Step 400, set the locked state in the data packet to locked; Step 500, read the storage address list from the data packet; Step 600, use the obtained real-time measurement value or real-time setting value to update each storage address on the storage address list in the data packet; Step 700, use the obtained real-time measurement value or real-time setting value to update the current value in the data packet; Step 800, set the locked state in the data packet to unlocked.

2. The method for monitoring the running state of an embedded robot according to claim 1, characterized in that: The real-time measurement value of the first-class state variable is obtained through the first-class peripherals of the embedded robot; and, The real-time setting value of the second-class state variable is used to drive the second-class peripherals of the embedded robot.

3. The method for monitoring the running state of an embedded robot according to claim 2, characterized in that: The first-class peripherals are sensor peripherals.

4. The embedded robot operation state monitoring method according to claim 2, characterized in that, The second-class peripherals include at least one of the following devices: Motors, servos, heating devices.

5. The method for monitoring the running state of an embedded robot according to claim 1, characterized in that: The data packet further includes a pointer to a synchronization function, and the synchronization function is used to synchronously store the current value of the state variable at the storage address of the state variable.

6. The method for monitoring the running state of an embedded robot according to claim 1, characterized in that, The multiple state variables further include at least one third-class state variable, and synchronizing the running state data set further includes: Synchronously updating the third-class state variable according to the real-time measurement value of the first-class state variable and / or the real-time setting value of the second-class state variable.

7. The embedded robot operation status monitoring method according to claim 6, characterized in that Synchronizing the operating state data set further includes: Synchronously updating the third type of state variable according to the communication status among the peripherals of the embedded robot.

8. The method for monitoring the operating state of an embedded robot according to claim 1, wherein: It further includes an operation of judging whether there is an abnormality in the operating state of the embedded robot.

Images