Aerial vehicle controller

Abstract

This invention discloses an aerial transporter controller, comprising a first core and a second core. The first core includes a hot-switching module. The hot-switching module determines whether the second core is restarting or needs to restart after an application opens a virtual device node. If a restart is confirmed, the module removes the mapping between the virtual handle fed back to the application and the file descriptor obtained when the virtual device was opened. After confirming that the second core has completed its restart, the hot-switching module opens a newly created virtual device node at the first core, obtains the new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor mapped to the virtual handle to the new file descriptor. In this invention, the application on the first core is unaware of the restart of the second core, avoiding data transmission problems during second core restarts, ensuring high system availability, and improving program maintainability.

Description

Technical Field

[0001] This invention relates to the field of aerial transport vehicle transport systems, and in particular to aerial transport vehicle controllers. Background Technology

[0002] Semiconductor manufacturing involves hundreds of processes from production to finished product, resulting in the movement of hundreds of thousands of components. To prevent contamination, damage, and delivery accidents of semiconductor materials, Overhead Hoist Transfer (OHT) is used during this process. OHT moves along overhead tracks to transport FOUPs (Front Opening Unified Pods) containing wafers. Patent application CN114388411A discloses a usable OHT system.

[0003] As shown in the patent documents, the aerial transport vehicle is controlled by an aerial transport vehicle controller (control unit) to perform various actions.

[0004] As shown in patent document CN119094479A, the aerial transporter controller includes a first core and a second core that communicate between cores via the RPMSG protocol. The first core runs the main program, while the second core handles real-time, low-power control. Simultaneously, the second core undertakes virtual device driver tasks, such as driving virtual serial port devices and virtual network interface cards (NICs). The virtual serial port device forwards serial port data from the second core to the first core; the virtual NIC allows the second core to mount the first core's file system via NFS. Thus, the first and second cores can transmit data through the established RPMSG communication channel and the virtual devices created by the second core.

[0005] This will lead to the following problems:

[0006] When the second core needs to restart due to fault recovery or firmware upgrade, it will unload the built RPMSG communication channel, then unload the driver files of the first core, thereby unloading the virtual device. Furthermore, the second core will go through the initialization process again and recreate the virtual device.

[0007] However, if the application on the first core has already opened the RPMSG communication channel bound to the virtual device on the virtual device node corresponding to the first core and obtained the file descriptor corresponding to the virtual device node before the second core restarts, then the newly created virtual device and virtual device node after the second core restarts will be different from the virtual device and virtual device node before the restart. If the application performs data transmission according to the file descriptor obtained before the restart, logical errors or memory leaks will occur.

[0008] In the prior art, the following methods are typically used to solve the above problems:

[0009] (1) Adding other cores to achieve master-slave switching increases hardware costs and is not suitable for embedded scenarios.

[0010] (2) Moving the driver to the first core sacrifices real-time performance and violates the original design intention of the second core.

[0011] (3) The survival status of the M core is detected by heartbeat packets, but transient failures cannot be prevented. Summary of the Invention

[0012] The purpose of this invention is to solve the above-mentioned problems existing in the prior art and to provide an aerial transport vehicle controller.

[0013] The objective of this invention is achieved through the following technical solution:

[0014] The aerial transport vehicle controller includes a first core and a second core that realize inter-core communication via the RPMSG communication protocol. The first core is equipped with a hot-switching module.

[0015] The hot-switching module is used to determine whether the second core is restarting or needs to be restarted after the application opens a virtual device node. When it is determined that the second core is restarting or needs to be restarted, the file descriptor that has a mapping relationship with the virtual handle fed back to the application by the hot-switching module is updated to a negative value.

[0016] After determining that the second core has completed its restart, the hot-switching module opens a newly created virtual device node at the first core, obtains the new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor that has a mapping relationship with the virtual handle to the new file descriptor.

[0017] Preferably, the hot-switching module listens for the presence of a second core restart event and a second core startup event in the uevent event through the state proxy layer. If a second core restart event is detected, the second core is determined to be restarting; if a second core startup event is detected, the second core is determined to have completed restarting.

[0018] Preferably, it also includes an anomaly monitoring program running in the background, which monitors whether the second core is running normally after normal startup, and restarts the second core when it is detected that the second core is not running normally.

[0019] Preferably, after the script is invoked to start the second core, the exception monitoring program monitors the uevent events in the kernel space and determines whether a second core startup event is detected within a specified time. If so, the exception monitoring program uses inotify to monitor the Linux system's message log and determines whether the Linux system's message log has changed. When a change is determined, the exception monitoring program reads the Linux system's message log content and determines whether it contains an unfed dog flag. If so, the exception monitoring program invokes a custom script to restart the second core.

[0020] Preferably, the first core runs a main program, which communicates with the anomaly monitoring program via semaphores. The anomaly monitoring program monitors whether the main program runs normally after normal startup. When the main program is detected to be not running normally, the anomaly monitoring program shuts down the second core.

[0021] Preferably, when the aerial transporter controller starts, the systemd starts the anomaly monitoring program. After the anomaly monitoring program starts, it starts the main program and monitors whether the main program starts normally. When it is determined that the main program starts normally, the watchdog timer monitors whether the main program is running normally.

[0022] Preferably, the exception monitoring program determines whether the main program has started normally by monitoring the proc_events file in the kernel space to see if it receives an initialization event from the main program within a specified time.

[0023] Preferably, the anomaly monitoring program sends data packets to the hardware watchdog of the aerial transport vehicle controller at a certain period. If the anomaly monitoring program fails to send data packets on time, the hardware watchdog generates a restart signal to restart the aerial transport vehicle controller.

[0024] Preferably, the anomaly monitoring program determines the utilization rate and / or CPU utilization and / or CPU load of each core by periodically reading the / proc / stat file and stores it in shared memory;

[0025] And / or the aforementioned anomaly monitoring program monitors the real-time performance of each core of the aerial transporter controller and stores the monitored real-time data in shared memory.

[0026] Preferably, the main program obtains data collected by the anomaly monitoring program from shared memory and adjusts the running speed of the aerial transport vehicle based on the obtained data.

[0027] The advantages of the technical solution of this invention are mainly reflected in:

[0028] This invention decouples file descriptors and applications by setting a hot-switching module in the first core and monitors whether the second core is restarting or needs to be restarted. When it is determined that the second core is restarting or needs to be restarted, the mapping relationship between file descriptors and virtual handles is released to avoid errors in data transmission. After the second core completes its restart, a new mapping relationship between file descriptors and virtual handles is established, so that data transmission can continue. Therefore, the applications in the first core are also unaware of the restart of the second core, ensuring the high availability of the system and improving the maintainability of the program.

[0029] This invention monitors the operation of the main program by setting up an anomaly monitoring program. When the main program malfunctions, the second core controlling the aerial transport vehicle can be immediately stopped. This prevents erroneous control caused by the second core operating normally while the main program is malfunctioning, effectively avoiding the problem of the aerial transport vehicle colliding with the track and reducing safety accidents.

[0030] The anomaly monitoring program of the present invention also monitors the second core, which can detect abnormal situations of the second core in a timely manner, can promptly release the mapping relationship between file descriptors and virtual handles, can promptly interrupt data transmission, and can restart the second core to restore its reliable operation.

[0031] This invention also communicates with the anomaly monitoring program through a hardware watchdog, which can restart the entire operation control system when the anomaly monitoring program malfunctions, thereby further ensuring the reliable operation of the entire system.

[0032] The anomaly monitoring program of this invention can monitor the real-time performance and occupancy rate of each core of the operation control system in real time and share the data with the main program. The main program does not need to focus on monitoring the system load. Moreover, the main program can adjust the operation of the aerial transport vehicle and the system operation based on the system load and real-time data monitored by the anomaly monitoring program, making the main program more controllable over the aerial transport vehicle and avoiding situations where system lag leads to the inability to control the aerial transport vehicle. Attached Figure Description

[0033] Figure 1 This is a communication diagram of the first core and the second core of the aerial transport vehicle controller of the present invention;

[0034] Figure 2This is a schematic diagram of the main program and the second core of the aerial transport vehicle controller of the present invention communicating with the anomaly monitoring program and the anomaly monitoring program communicating with the hardware electronic dog.

[0035] Figure 3 This is a schematic diagram of the process of the anomaly monitoring program of the present invention performing the second core monitoring;

[0036] Figure 4 This is a schematic diagram illustrating the process of the anomaly monitoring program of the present invention monitoring the main program. Detailed Implementation

[0037] The objectives, advantages, and features of this invention will be illustrated and explained through the following non-limiting description of preferred embodiments. These embodiments are merely typical examples of applying the technical solutions of this invention, and all technical solutions formed by equivalent substitutions or equivalent transformations fall within the scope of protection claimed by this invention.

[0038] In the description of the solution, it should be noted that the terms "center," "upper," "lower," "left," "right," "front," "rear," "vertical," "horizontal," "inner," and "outer," etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience and simplification of description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0039] Example 1

[0040] The aerial transport vehicle controller disclosed in this invention will now be described in conjunction with the accompanying drawings, as shown below. Figure 1 As shown, it includes a first core and a second core that communicates with the first core via the RPMSG protocol. The first core is, for example, a master core or an A core, and the second core is, for example, a slave core or an M core. The technology of inter-core communication via the RPMSG protocol is known technology and not an innovation of this invention; therefore, it will not be elaborated upon here.

[0041] As attached Figure 2 As shown, the first core uses the Linux system, which is powerful and used to run high-performance programs such as the main program. The main program is used to communicate and interact with the server, and to send control commands to the second core to control the aerial transporter to perform certain actions, based on server instructions. Of course, other applications can also run on the first core.

[0042] The second core runs a real-time operating system (RTOS), exhibiting extremely high real-time performance. Due to its strong real-time characteristics, the second core is used to run the ECAT (EtherCAT) master station and execute corresponding control commands to enable the aerial transport vehicle to perform various actions. For example, it controls the aerial transport vehicle to perform forward and backward movement, steering, picking and placing actions by the gripping devices, lifting and lowering actions by the lifting mechanism, and translational actions by the translation mechanism.

[0043] When the main program needs the aerial transporter to perform a certain action, it sends a control command to the secondary core through the interface. The secondary core then executes the corresponding control command to make the aerial transporter complete the corresponding action and returns the execution result to the main program.

[0044] As attached Figure 1 As shown, the first core is equipped with a hot-switching module, which communicates with the application programs (including but not limited to the main program) running in the first core.

[0045] The hot-switching module is used to determine whether the second core is restarting or needs to restart after the application opens a virtual device node. When it is determined that the second core is restarting or needs to restart, the file descriptor that has a mapping relationship with the virtual handle fed back to the application by the hot-switching module is updated to a negative value. At this time, the application of the first core will report an error that the virtual device node does not exist and stop sending data.

[0046] After confirming that the second core has completed its restart, the hot-switching module opens a newly created virtual device node at the first core, obtains the new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor mapped to the virtual handle to the new file descriptor. At this time, the application of the first core can obtain the new file descriptor corresponding to the new virtual device node, so that the application can continue to send and receive previously unfinished data through the newly created RPMSG channel and virtual serial port.

[0047] Specifically, the hot-switching module includes a hot-switching control layer and a state proxy layer that communicate with each other;

[0048] The hot-switching control layer provides a set of interfaces, including functions such as `open()`, `close()`, `read()`, `write()`, and `select()`. When an application calls the `open()` function of the hot-switching control layer to open a virtual device node, the hot-switching control layer calculates a virtual handle (index) and feeds it back to the application and the state proxy layer. The state proxy layer calls the native `open()` interface to open the virtual device node, obtains the file descriptor corresponding to the virtual device node, and establishes a mapping relationship between the virtual handle and the file descriptor. Assuming the virtual handle is 1001 and the file descriptor is 3, the mapping relationship is 1001→3. Subsequently, the application can call other interfaces of the hot-switching control layer and perform various operations on the virtual device node through the aforementioned determined mapping relationship between the virtual handle and the file descriptor, including but not limited to `close()`, `read()`, `write()`, and `select()`.

[0049] The state proxy layer includes a state machine that listens for the presence of a second core restart event in the uevent event. If a second core restart event exists, it is determined that the second core is restarting. At this time, the state machine state can be updated to indicate that the virtual device node does not exist. If the virtual device node is not opened, no processing is required. If the virtual device node was opened before the second core restart, the file descriptor is closed and set to a negative number, such as -1, thereby updating the mapping relationship between the virtual handle and the real descriptor from 1001 to -1.

[0050] Meanwhile, the state proxy layer can determine whether the second core has completed its restart by listening to the uevent event to see if a second core startup event exists. When a second core startup event is detected, the state machine state is updated to indicate that the virtual device node exists. Preset events are automatically executed based on the current state. If no virtual device node was opened before the second core restarted, nothing is done. If a virtual device node was already opened before the second core restarted, the native open interface is called again to open a new virtual device node and obtain the new file descriptor corresponding to the new virtual device node, for example, 4. Thus, the mapping relationship between the virtual handle and the real descriptor is updated to 1001→4.

[0051] Subsequent applications can call the various interfaces of the hot-switching control layer and perform various operations on the newly created virtual device node through the mapping relationship between the updated virtual handle and the new file descriptor corresponding to the newly created virtual device node.

[0052] The aerial transporter controller also includes an anomaly monitoring program, which runs in the background of the first core system. The anomaly monitoring program uses JSON as a configuration file to improve its configurability, allowing users to enable or disable certain functions and modify parameters within the configuration file.

[0053] As attached Figure 3 As shown, the anomaly monitoring program communicates with the second core using the RPMSG protocol under the OpenAMP architecture. The anomaly monitoring program monitors whether the second core is running normally after a normal startup, and restarts the second core if it determines that the second core is not running normally.

[0054] Specifically, after the main program or exception monitoring program calls the script to start the second core, the exception monitoring program monitors the uevent events in the kernel space and determines whether a second core startup event is detected within a specified time. If not, it determines that the second core has failed to start, records this in the log file, and exits. If yes, it determines that the second core has started normally. At this time, the exception monitoring program uses inotify to monitor the Linux system's message log and determines whether there are any changes in the Linux system's message log. inotify is a subsystem (API) added in Linux kernel version 2.6.13 (June 18, 2005). It provides a mechanism for monitoring file system events, such as file modification, addition, and deletion, and can notify the application of the corresponding events.

[0055] When a change is detected in the Linux system's message log, the system reads the message log content and checks for the presence of a "not fed" flag. This flag is generated by the Linux driver file used by the exception monitoring program within the Linux kernel using the sysfs system. If the flag is present in the Linux system's message log, it's determined that the second core is not running properly, and a custom script is invoked to restart the second core. Otherwise, the system continues to monitor the Linux system's message log and checks for any changes.

[0056] This method effectively solves the problem that the second core is affected by the multi-core heterogeneous hardware architecture, which prevents it from having its own hardware watchdog and thus makes it impossible to monitor the second core independently. Furthermore, by using inotify monitoring, the CPU spends most of its time doing what it should do, and only checks the Linux system's message log when it changes. This achieves the monitoring effect without consuming resources.

[0057] Furthermore, during the operation of the aerial transport vehicle, if the main program malfunctions, the operation of the second core remains unaffected. However, if the main program malfunctions after issuing a control command to the second core instructing the aerial transport vehicle to travel at high speed, the second core will still control the aerial transport vehicle to travel at high speed according to the control command. This could result in the aerial transport vehicle potentially colliding with the track at high speed, causing economic losses. For example, if the main program issues a control command to the second core to move at a speed of 4.5 m / s, and the main program malfunctions after issuing the command, the second core will still control the aerial transport vehicle to move at 4.5 m / s. When the aerial transport vehicle reaches the turning track, it will collide with the turning track, causing damage to both the turning track and the aerial transport vehicle.

[0058] Therefore, the anomaly monitoring program also communicates with the main program and monitors whether the main program runs normally after it starts normally. When it detects that the main program is not running normally, it shuts down the second core.

[0059] As attached Figure 2 As shown, the anomaly monitoring program and the main program use semaphores to achieve inter-process communication. When the semaphore used for communication between the main program and the anomaly monitoring program is not incremented within a specified time, the anomaly monitoring program directly uses the Remoteproc framework to shut down the second core. When the second core is shut down, the ECAT master station deployed on the second core will stop running. At this time, the servo system on the aerial transport vehicle will automatically stop because it cannot receive periodic control data, thus stopping all actions of the aerial transport vehicle.

[0060] As attached Figure 4 As shown, when the aerial transporter controller is powered on, the systemd-started exception monitoring program initiates the main program and monitors whether the main program starts normally. Specifically, the exception monitoring program monitors the proc_events file in the kernel space to determine whether it receives an initialization event from the main program within a specified time, thereby determining whether the main program has started normally. When an initialization event is received, the exception monitoring program determines that the main program has started normally; when no initialization event is received, the exception monitoring program determines that the main program has failed to start, and at this time, the error script is called to inform the outside world that the main program has failed to start.

[0061] The reason for this operation is that the exception monitoring program is used to assist and monitor the main program. First, the exception monitoring program is started, and then the exception monitoring program starts the main program and monitors whether the main program starts successfully. This is to achieve a closed loop and ensure that the entire running process of the main program is under the monitoring of the exception monitoring program.

[0062] When the anomaly monitoring program determines that the main program has started normally, it uses a watchdog timer to monitor whether the main program is running normally. The watchdog timer can determine whether the main program is running normally based on whether it is feeding the watchdog according to the prescribed requirements. The relevant technology is known and will not be elaborated here. When the anomaly monitoring program determines that the main program is not running normally, it can call a custom script to shut down the second core and simultaneously restart the main program. The method of shutting down the second core is the same as above and will not be elaborated here. Furthermore, after determining that the main program has started normally, the second core can be restarted.

[0063] Meanwhile, the anomaly monitoring program also communicates with the hardware watchdog of the aerial transport vehicle controller. The anomaly monitoring program sends data packets to the hardware watchdog at a certain period. If the anomaly monitoring program fails to send data packets on time, it may be due to a serious problem in the operation control system, such as system lag, which may cause the anomaly monitoring program to fail to operate normally or the anomaly monitoring program to have an anomaly. At this time, the hardware watchdog generates a restart signal to restart the aerial transport vehicle controller.

[0064] Furthermore, the anomaly monitoring program periodically reads the / proc / stat file to determine the utilization rate and / or CPU utilization and / or CPU load of each core and stores it in shared memory. Monitoring these parameters is to monitor the current system load of the operating system.

[0065] Meanwhile, the anomaly monitoring program monitors the real-time performance of each core of the aerial transporter controller and stores the monitored real-time data in shared memory. The real-time performance of a core refers to the actual wake-up time when the core is awakened after a specified sleep time. Real-time monitoring can be achieved by creating a thread and binding it to different cores; the corresponding technology is known and will not be elaborated here.

[0066] The reason for real-time monitoring of each core is that if the real-time performance of each core is poor, then the faster the speed, the greater the offset position after the command is issued. For example, with excellent real-time performance of 1µs, controlling the aerial transport vehicle at a speed of 5m / s results in negligible offset position. However, when the real-time performance of a core becomes 100µs, the position offset becomes significant. Furthermore, during aerial transport vehicle control, there are multiple task switches, each adding another 100µs, resulting in a larger accumulated offset position and severely impacting the positioning accuracy of the aerial transport vehicle.

[0067] Therefore, the real-time data and occupancy data stored in the shared memory by the anomaly monitoring program will be synchronized to the main program, which can then perform various dynamic adjustments based on the real-time data and occupancy data.

[0068] For example, after the main program obtains the real-time data of each core from the shared memory, it can adjust the running speed of the aerial transport vehicle according to the real-time data, thereby achieving safer, smarter and more controllable control of the aerial transport vehicle.

[0069] For example, after the main program senses the system load of the operation control system, it can understand the current operating status of the operation control system and can make early warnings, control logic adjustments, and operation control adjustments of the aerial transport vehicle based on the current system load.

[0070] For example, a factor affecting system load is a large number of I / O operations. In such cases, the control logic can be adjusted. For instance, before performing an I / O operation, the system load can be checked. If the load is high, other operations can be performed instead, waiting for the system load to drop to a normal or lower level before resuming the I / O operation. Another example is when the CPU utilization reaches 99%, indicating an anomaly within the control system. The main program needs to detect this and signal it externally through various means, such as flashing red LEDs, displaying a high system load on the screen, or emitting an error alarm sound, thus providing early warning and prompting action. Furthermore, when the handling system is under high load, the aerial transport vehicle cannot be controlled to move at high speeds. For example, when the CPU utilization reaches 80%, the main program should limit the aerial transport vehicle's movement speed to no more than 3 m / s.

[0071] Furthermore, in other embodiments, the state proxy layer can also monitor whether the main program and / or the second core are running normally, just like the anomaly monitoring program. When it is determined that the main program and / or the second core are not running normally, it determines that the second core needs to be restarted. Of course, this is not mandatory.

[0072] This invention has many other embodiments, and all technical solutions formed by equivalent transformation or equivalent transformation fall within the protection scope of this invention.

Claims

1. An aerial transport vehicle controller, comprising a first core and a second core for inter-core communication via the RPMSG communication protocol, characterized in that: The first core is equipped with a hot-switching module; The hot-switching module is used to determine whether the second core is restarting or needs to be restarted after the application opens a virtual device node. When it is determined that the second core is restarting or needs to be restarted, the file descriptor that has a mapping relationship with the virtual handle fed back to the application by the hot-switching module is updated to a negative value. After determining that the second core has completed the restart, the hot-switching module opens a newly created virtual device node at the first core, obtains the new file descriptor corresponding to the newly created virtual device node, and updates the file descriptor that has a mapping relationship with the virtual handle to the new file descriptor. The hot-switching module listens for the presence of a second core restart event and a second core startup event in the uevent event through the state proxy layer. If a second core restart event is found, it is determined that the second core is restarting. If a second core startup event is confirmed, then the second core is confirmed to have completed its restart.

2. The aerial transport vehicle controller according to claim 1, characterized in that: It also includes an anomaly monitoring program running in the background, which monitors whether the second core is running normally after normal startup. When the anomaly monitoring program detects that the second core is not running normally, it restarts the second core.

3. The aerial transport vehicle controller according to claim 2, characterized in that: After the script is invoked to start the second core, the exception monitoring program monitors the uevent events in the kernel space and determines whether the second core startup event is detected within a specified time. If so, the exception monitoring program uses inotify to monitor the Linux system's message log and determines whether the Linux system's message log has changed. When a change is determined, the exception monitoring program reads the Linux system's message log content and determines whether it contains the "not fed dog" flag. If so, the exception monitoring program invokes the custom script to restart the second core.

4. The aerial transport vehicle controller according to claim 1, characterized in that: The first core runs a main program, which communicates with the exception monitoring program via semaphores. The exception monitoring program monitors whether the main program runs normally after normal startup. When it detects that the main program is not running normally, the exception monitoring program shuts down the second core.

5. The aerial transport vehicle controller according to claim 4, characterized in that: When the aerial transporter controller starts, the systemd starts the anomaly monitoring program. After the anomaly monitoring program starts, it starts the main program and monitors whether the main program starts normally. When it is determined that the main program starts normally, the watchdog timer monitors whether the main program is running normally.

6. The aerial transport vehicle controller according to claim 5, characterized in that: The exception monitoring program determines whether the main program has started normally by monitoring the proc_events file in the kernel space and whether it receives an initialization event from the main program within a specified time.

7. The aerial transport vehicle controller according to claim 2, characterized in that: The anomaly monitoring program sends data packets to the hardware watchdog of the aerial transport vehicle controller at regular intervals. If the anomaly monitoring program fails to send data packets on time, the hardware watchdog generates a restart signal to restart the aerial transport vehicle controller.

8. The aerial transport vehicle controller according to any one of claims 4-7, characterized in that: The anomaly monitoring program periodically reads the / proc / stat file to determine the utilization rate and / or CPU utilization and / or CPU load of each core and stores it in shared memory; And / or the aforementioned anomaly monitoring program monitors the real-time performance of each core of the aerial transporter controller and stores the monitored real-time data in shared memory.

9. The aerial transport vehicle controller according to claim 8, characterized in that: The main program retrieves data collected by the exception monitoring program from shared memory and adjusts the running speed of the aerial transport vehicle based on the retrieved data.

Images