Mobile control system
The mobile control system addresses inefficiencies in controlling multiple mobile entities by using a control input correction unit and finite state transition model to dynamically generate avoidance trajectories, ensuring safe and cost-effective movement despite communication interruptions.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-02-28
- Publication Date
- 2026-03-30
AI Technical Summary
Existing technologies for controlling multiple mobile entities, such as robots and vehicles, face inefficiencies due to communication interruptions and the need to re-plan actions when deviations occur, leading to reduced operational efficiency and high verification costs, especially in environments like logistics warehouses and construction sites.
A mobile control system that includes a destination movement control input determination unit, control input correction unit, deadlock detection unit, and finite state transition model dynamic generation unit to dynamically generate avoidance trajectories, ensuring safe and cost-effective movement even with communication interruptions.
Ensures safe and cost-effective movement of multiple mobile entities by treating communication interruptions as non-deterministic transitions, maintaining operational efficiency and reducing the need for frequent re-planning.
Smart Images

Figure 0007837021000001 
Figure 0007837021000002 
Figure 0007837021000003
Abstract
Description
Technical Field
[0001] The present invention relates to a mobile control system for controlling a plurality of mobile bodies.
Background Art
[0002] Due to labor shortages and the like, the development of robots, vehicles, and UAVs (Unmanned Aerial Vehicles) that autonomously move on the ground or in the air at logistics warehouses, construction sites, airports, roads, etc. is expected. In these cases, since there are a plurality of mobile bodies in the same field, it is required to safely move each mobile body to a predetermined destination without colliding with obstacles or other mobile bodies.
[0003] As a technology related to this field, there is the technology described in Patent Document 1. In this publication, while considering the presence of a plurality of robots, it is an issue to provide a robot cooperative transportation planning technology that can reduce the calculation time and the storage capacity of the computer required for planning calculation. And as a solution means, a Markov state space is hierarchically configured (the article trajectory calculation process is the first layer, the switching position determination process is the second layer, and the movement route planning process is the third layer), and the search for the operation plan is performed from the layer with a low change frequency (the first layer), and using the result of the search calculation in the layer with a low change frequency, the search range in the layer with a high change frequency is limited, and it is described that the search is performed in the lower layers (the second layer and the third layer) with a high change frequency in the limited state space.
[0004] Furthermore, according to Patent Document 2, the objective is to provide a motion prediction control device and method that can generate predicted values (control command values) necessary for controlling the robot at a predetermined control cycle without being affected by the time required for updating the internal state, when estimating the internal state of one or both of the object and the robot and generating predicted values (control command values) necessary for controlling the robot based on these internal states. To achieve this objective, the invention provides a motion prediction control device comprising: a measuring device that acquires sensor information by measuring one or both of the object and the robot; a state estimation device that predicts and updates the internal state of one or both of the object and the robot based on the sensor information; a data storage device that stores the internal state; and a robot control device that controls the robot. The state estimation device updates the internal state at any timing independent of the robot's control cycle, and the robot control device calculates predicted values necessary for controlling the robot at the control cycle based on the latest internal state stored in the data storage device. [Prior art documents] [Patent Documents]
[0005] [Patent Document 1] Japanese Patent Publication No. 2012-227349 [Patent Document 2] International Publication No. 2012 / 153629 [Overview of the project] [Problems that the invention aims to solve]
[0006] According to Patent Document 1, while directly considering the possible states of multiple robots would result in an enormous number of states, creating a Markov transition model that divides the state space into finite parts and searching for trajectories or action plans on this transition model makes it possible to reduce the computation time and computer memory capacity required for planning calculations. However, this known example assumes the cooperative operation of robots, and since it is necessary to plan the action plan for each robot in advance, if a situation that deviates from the action plan occurs, such as a delay or interruption of some communication packets during operation, it is necessary to stop all robots and create a new action plan. This reduces the overall system's operational efficiency. In particular, for robots and vehicles that move autonomously in logistics warehouses, construction sites, airports, roads, etc., not all robots or vehicles necessarily cooperate with each other, and as the number of robots or vehicles increases and the amount of communication increases, delays or interruptions of one or more packets can easily occur with high frequency. Therefore, it cannot be applied because it would severely reduce the overall system's operational efficiency.
[0007] On the other hand, Patent Document 2 presents a method in which sensing information from outside the robot and information from other robots are predicted using techniques such as Kalman filters before receiving such information, and the received information is reflected in the prediction as an observation result. This makes it possible to continue control by correcting the prediction even if situations that deviate from the original plan occur, such as communication failure. However, such predictive control calculations are complex, and verification tests must be conducted under all conditions to confirm that the correct calculation results are always obtained within a certain control cycle, which is costly. Furthermore, it is not obvious what effect the correction of the prediction due to the occurrence of situations that deviate from the original plan will have on each robot or the overall system. In particular, when it is necessary to consider multiple robots simultaneously, the number of combinations of conditions that need to be verified becomes enormous, and it is impossible to verify all of them.
[0008] Based on the above, the present invention aims to realize the missions assigned to each mobile entity sharing a field (e.g., destination travel or surveillance) while ensuring safety and low cost. The challenge is to maintain both safety and low cost even when unexpected interruptions in communication packets occur, or when the location of obstacles in the field or the number of mobile entities differs from (changes from) the initial assumptions. [Means for solving the problem]
[0009] To solve the above problems, a mobile body control system according to one embodiment of the present invention is a mobile body control system comprising a plurality of mobile bodies, each having a destination movement control input determination unit for controlling movement to a destination, a control input correction unit for correcting the value input to the destination movement control input determination unit, a deadlock detection unit for detecting deadlocks, and a drive unit for driving itself, wherein each mobile body has a finite state transition model dynamic generation unit for avoidance movement and an output unit, the control input correction unit of a mobile body determines that avoidance movement is necessary when the deadlock detection unit detects a deadlock and instructs the finite state transition model dynamic generation unit for avoidance movement when it receives an instruction for avoidance movement from the control input correction unit, dynamically generates a finite state transition model for avoidance movement based on its own position information, obstacle position information, other robot position information and other robot lock position information and generates an avoidance trajectory, and the output unit outputs its own robot position information indicating its current position and its own robot lock position information indicating positions on the generated avoidance trajectory that the mobile body has not yet passed through, to other mobile bodies. [Effects of the Invention]
[0010] According to the present invention, by treating communication interruptions as non-deterministic transitions on a finite state transition model, it becomes possible to control the movement of each mobile object sharing a field to its respective destination while ensuring safety and low cost. Further features related to the present invention will become apparent from the description herein and the accompanying drawings. Problems, configurations, and effects other than those described above will be revealed by the following description of the embodiments. [Brief explanation of the drawing]
[0011] [Figure 1] A diagram showing the overall configuration of the control system 0 in the first embodiment. [Figure 2] A diagram showing the coordinate system in this embodiment. [Figure 3] This figure shows the abstraction control system 6 in this embodiment. [Figure 4] A block diagram showing the functional configuration of the mobile control system in this embodiment. [Figure 5] A diagram showing an example of the structure of the mobile robot in this embodiment. [Figure 6] This figure shows a portion of the first finite state transition model 13 as seen from the first high-level control 7 in this embodiment. [Figure 7A] This figure shows an example of source code for generating the first finite state transition model 13. [Figure 7B] This figure shows an example of source code for generating the first finite state transition model 13. [Figure 7C] This figure shows an example of source code for generating the first finite state transition model 13. [Figure 8] This figure shows a portion of the first directed graph 16 generated from the first finite state transition model 13 for generating the first high-level control 7 in this embodiment. [Figure 9] This figure shows the shortest path and input sequence determined by the first high-level control 7 in this embodiment. [Figure 10] This figure shows the communication packets 19 communicated between each mobile robot in this embodiment. [Figure 11] This diagram shows the processes that each mobile robot performs within each time step time interval. [Figure 12] This is pseudocode illustrating the determination of transmission and non-transmission in the safety confirmation of control input for the first mobile robot 3 in this embodiment. [Figure 13] This diagram shows the state immediately before a deadlock occurs due to a safety check of the control input. [Figure 14] A diagram showing the state at the time of deadlock due to safety confirmation of control input. [Figure 15] A diagram showing the procedure for generating an avoidance trajectory. [Figure 16] A diagram showing the lock position packet 20. [Figure 17] A diagram showing the operation of the third mobile robot 5 avoiding and the operations of other mobile robots during that time after the third mobile robot 5 generates an avoidance trajectory in FIG. 14. [Figure 18] A diagram showing the lock position packet 20 transmitted by the third mobile robot 5 in the state of FIG. 17.
Embodiments for Carrying Out the Invention
[0012] This embodiment relates to a control system for controlling a plurality of moving bodies. Hereinafter, an example (embodiment) of an embodiment suitable for the present invention will be described. In this embodiment, an example of safely moving three mobile robots to a destination will be described, but the number of mobile robots may be other than 3, the mobile robots may be vehicles, and the size of the area (field) where the mobile robots move, the positions of obstacles, the initial positions of each mobile robot, and the destination are merely examples and are not limited thereto.
[0013] <Overall Configuration of Control System 0> FIG. 1 is a diagram showing the overall configuration of the control system 0 in this embodiment. As shown in FIG. 1, the control system 0 has a field 1, an obstacle 2, a first mobile robot 3, a second mobile robot 4, and a third mobile robot 5. In this embodiment, the size of the field 1 is 2 meters square, and the position of the obstacle 2 is as shown in the figure and its width is 10 centimeters.
[0014] <Coordinate System> FIG. 2 is a diagram showing the coordinate system in this embodiment. The origin is set at the center of Field 1, which is 2 meters square, and the X and Y axes are set as shown in the diagram. The angle indicating the direction of each mobile robot is expressed as a value from greater than -π radians to less than or equal to +π radians, with counterclockwise rotation from the X axis being positive. The state of the first mobile robot 3 is expressed as (X_1, Y_1, θ_1), the state of the second mobile robot 4 as (X_2, Y_2, θ_2), and the state of the third mobile robot 5 as (X_3, Y_3, θ_3). Thus, the state of control system 0 is represented as ((X_1, Y_1, θ_1), (X_2, Y_2, θ_2), (X_3, Y_3, θ_3)). Therefore, the state space of control system 0 is the Cartesian product of six real numbers from -1 to 1 (X_1, X_2, X_3, Y_1, Y_2, Y_3) and three real numbers from -π to π (θ_1, θ_2, θ_3).
[0015] <Abstract Control System 6> Figure 3 shows the abstraction control system 6 in this embodiment. Abstraction control system 6 is a model that reduces the state space of control system 0. By using abstraction control system 6, control can be considered by dividing it into low-level and high-level components. That is, the high-level control plans the movement of the mobile robot and issues instructions to the low-level control, and the low-level control drives the actuators based on the instructions from the high-level control.
[0016] In this embodiment, a grid with a width of 0.2 meters is configured in the X and Y axes, and each mobile robot is configured to move by plus or minus 0.2 meters in one translation cycle. The direction of each mobile robot is set to one of 0, π / 2 radians, π radians, or -π / 2 radians, and the rotation of each mobile robot is set to plus or minus π / 2 radians. At each time step (the time when the control cycle begins), the high-level control sends one of the following instructions to the low-level control: translation by plus or minus 0.2 meters, rotation by plus or minus π / 2 radians, or doing nothing and maintaining the previous state (hereinafter referred to as stop). The low-level control drives the actuator according to the instruction. Both the high-level control and the low-level control are mounted on each mobile robot. Therefore, the first mobile robot 3 is equipped with the first high-level control 7 and the first low-level control 8, the second mobile robot 4 is equipped with the second high-level control 9 and the second low-level control 10, and the third mobile robot 5 is equipped with the third high-level control 11 and the third low-level control 12.
[0017] <System Functional Configuration> Figure 4 is a block diagram showing the overall functional configuration of the mobile control system in this embodiment. As shown in Figure 4, the mobile control system includes multiple mobile bodies 100. Each mobile body 100 receives input of other robot position information 201 and other robot lock position information 202, and outputs its own robot position information 206 and its own robot lock position information 207. In this invention, a lock position is a position on the field that a particular robot can exclusively enter. Each robot can designate a portion of the field as a lock position by using a lock position packet 20, which will be described later.
[0018] The mobile unit 100 includes a self-position acquisition unit 101, a control input determination unit 102 for destination movement, a control input correction unit 103, a deadlock detection unit 104, a finite state transition system dynamic generation unit 105 for avoidance movement, a drive unit 106, a self-lock position output unit 107, and a self-position output unit 108.
[0019] Each of the mobile units 100 is equipped with a CPU (Central Processing Unit) and memory (not shown), and the functions of the above-mentioned functional units are performed by the CPU executing various programs stored in the memory.
[0020] The self-position acquisition unit 101 acquires its own coordinate position using GPS (Global Positioning System). The destination movement control input determination unit 102 calculates a movement path from the current position to the destination based on the positional relationship between the acquired self-position and the destination, and the obstacle position information 203, and determines the necessary control as the destination movement control input 204. The control input correction unit 103 calculates a path to be avoided based on the destination movement control input 204, the other robot position information 201, and the other robot lock position information 202, and outputs it as the final control input 205.
[0021] The deadlock detection unit 104 detects a deadlock based on the output from the control input correction unit 103. The finite state transition system dynamic generation unit 105 for avoidance movement calculates and outputs an avoidance path that allows the robot to move to the destination while avoiding obstacles and other robots, based on the detection result from the deadlock detection unit 104, its own position, other robot position information 201, other robot lock position information 202, and obstacle position information 203. The drive unit 106 drives the robot based on the final control input 205, which is the sum of the outputs of the control input correction unit 103 and the finite state transition system dynamic generation unit 105 for avoidance movement. The self-lock position output unit calculates its own lock position based on the output result of the finite state transition system dynamic generation unit 105 for avoidance movement and outputs it as self-robot lock position information 207. The self-position output unit 108 outputs its own position as self-robot position information 206.
[0022] <Low-level control> This section describes the low-level control systems implemented in each mobile robot. Figure 5 shows the structure of the robot in this embodiment (in this figure, the first mobile robot 3 is shown). The structure of each mobile robot is common to all of them. The mobile robot is represented as a typical two-wheeled model, and the rotation amount of each wheel can be independently controlled by a servo motor. Specifically, the left servo motor 303 is connected to the left wheel 301, and the right servo motor 304 is connected to the right wheel 302. The left servo motor 303 and the right servo motor 304 have rotary encoders inside, and by providing a target position from outside the servo motor, the motor can be rotated by a certain angle. Furthermore, low-level control and high-level control, which will be described later, are calculated and processed by software, and this software is implemented on the control microcontroller 305 mounted on the mobile robot.
[0023] If the first high-level control 7 instructs a translation of +0.2 meters, the first low-level control 8 sets the target position for the left servo motor 303 to (current left servo motor position) + 0.2 / (wheel radius: meters) and the target position for the right servo motor 304 to (current right servo motor position) + 0.2 / (wheel radius: meters). As a result, the left servo motor 303 and the right servo motor 304 rotate in the same direction to the target position, and the first mobile robot 3 moves forward 0.2 meters. If the first high-level control 7 instructs a rotation of +π / 2 radians, the first low-level control 8 sets the target position for the left servo motor 303 to (current left servo motor position) - (π / 2) * (tread length: meters) / (wheel diameter: meters) and the target position for the right servo motor to (current right servo motor position) + (π / 2) * (tread length: meters) / (wheel diameter: meters). As a result, the left servo motor 303 and the right servo motor 304 rotate in opposite directions to the target position, and the first mobile robot 3 rotates counterclockwise by π / 2 radians. Translation and rotation in the negative direction can be controlled similarly. If the first high-level control 7 instructs the first low-level control 8 to maintain the previous state, the first low-level control 8 does not change the target position of each servo motor. As a result, the first mobile robot 3 does not perform translation or rotation and maintains the same state as before. The second low-level control 10 and the third low-level control 12 of the second mobile robot 4 and the third mobile robot 5 also operate in the same way as the first low-level control 8, according to instructions from the second high-level control 9 or the third high-level control 11.
[0024] <Time step> In this embodiment, the first mobile robot 3, the second mobile robot 4, and the third mobile robot 5 are synchronized in time with each other. In this embodiment, each mobile robot can communicate with each other, so time synchronization can be performed using a known time synchronization method, such as NTP (Network Time Protocol). Alternatively, a time synchronization signal may be provided from outside the mobile control system. As described above, in low-level control, each servo motor rotates to the instructed position, but servo positioning control is performed using a known control method such as PID control, and some time is required between specifying a target position for the servo motor and the servo motor actually reaching that target position. Therefore, the time step is set to be a length greater than or equal to the maximum time required from specifying a target position for the servo motor until the servo motor reaches that target position.
[0025] The time it takes for a servo motor to reach a target position after being instructed to do so generally depends on the difference between the current servo motor position and the target position. Therefore, the time step should be set to a value greater than or equal to the time it takes to reach the target position after being instructed to do so for the control input that takes the most time to position among the five control input patterns selected in low-level control (+0.2m translation, -0.2m translation, +π / 2 radian rotation, -π / radian rotation, stop). The time step is the time interval, i.e., the control cycle, during which each mobile robot performs one of the following actions: translation, rotation, or stopping. In this embodiment, the first mobile robot 3, the second mobile robot 4, and the third mobile robot 5 all have the same hardware configuration, and the time step is the same for all mobile robots.
[0026] <Receiving Processing> The first mobile robot 3 (or the second mobile robot 4 or the third mobile robot 5) receives a communication packet 19 and a lock position packet 20 transmitted by another mobile robot at the beginning of the time step. The communication packet 19 and the lock position packet 20 will be described later.
[0027] <Finite State Transition Model> Each mobile robot with low-level control implemented can be viewed as a finite state transition model from the perspective of high-level control. Figure 6 shows a portion of the first finite state transition model 13 as seen from the first high-level control 7 in this embodiment.
[0028] The first finite state transition model 13 is a model that shows the dynamics of the first mobile robot 3 equipped with the first low-level control 8 from the perspective of the first high-level control 7. For example, consider the case in Figure 6 where the state of the first mobile robot 3 is (0,0,0). If the first high-level control 7 instructs U1 (+0.2 meter translation), the first mobile robot 3 moves +0.2 meters in the X-axis direction, so in the next time step, the state transitions to (0.2,0,0). If the first high-level control 7 instructs U2 (-0.2 meter translation), the first mobile robot 3 moves -0.2 meters in the X-axis direction, so in the next time step, the state transitions to (-0.2,0,0). However, since there is an obstacle at coordinates (-0.2,0), this transition does not occur. When the first high-level control 7 instructs U3 (+π / 2 radian rotation), the first mobile robot 3 rotates by +π / 2 radians, so the state in the next time step becomes (0, 0, π / 2). When U4 (-π / 2 radian rotation) is instructed, the state in the next time step becomes (0, 0, -π / 2). When the first high-level control 7 instructs U5 (no movement), the state in the next time step also becomes (0, 0, 0). By repeatedly applying this operation to each state such as (0, 0, π / 2) and (0.2, 0, 0), a first finite state transition model 13 for the first mobile robot 3 is obtained. Similarly, a second finite state transition model 14 and a third finite state transition model 15 are obtained for the second mobile robot 4 and the third mobile robot 5, respectively.
[0029] Figures 7A-7C show example source code for generating the first finite state transition model 13 described above. In this embodiment, source code written in C++ is described, but the type of source code is not limited to this.
[0030] <Generation of finite state transition models> The source code for generating the first finite state transition model 13 is described below. The process is exactly the same for generating the second finite state transition model 14 and the third finite state transition model 15.
[0031] First, as shown in Figure 7A, we define structures and arrays. The structure `plantstate` has the robot's coordinates x, y, and θ, and a pointer array that stores which state (i.e., another `plantstate` structure) the robot will transition to when each input is applied. The structure `input` has the input value, a Boolean variable to distinguish whether the input indicates rotation or translation, and weight values for Dijkstra's algorithm (more details will be described later; it is used for high-level control) (although in reality, they are all 1). The `position` structure also has variables to store the x and y coordinates. In this embodiment of the finite state transition model, the X and Y coordinates are 10 points in increments of 0.2, and θ is 4 points in increments of π / 2, but these will be managed by associating them with integer values from 0 to 10 or 0 to 4, respectively. For example, the coordinates (-0.6, 0.4, π / 2) are associated with (2, 7, 1). This mapping operation is called encoding, and conversely, the operation of mapping (2, 7, 1) to the coordinates (-0.6, 0.4, π / 2) is called decoding. These defined structures and encoding / decoding operations are used to define array data. The array plant
[11]
[11] [4] is used to represent the first finite state transition model 13 as an array of plantstate structures. At the stage shown in Figure 6-1, only the arrays have been declared, and the first finite state transition model 13 has not yet been represented. Next, the array input[] stores the input as the grid size, i.e., the forward / backward translation of 0.2 meters and the rotation of the θ axis in the plus / minus π / 2 radian direction. Finally, the array obstacle[] holds the obstacle position encoded and described as a position structure. Note that the contents of the obstacle array in Figure 7A correspond to the obstacle position in Figure 3.
[0032] Next, as shown in Figure 7B, a function `transition()` is defined in the first finite state transition model 13 to calculate which state the system will transition to when a certain input is applied to a given state. The calculation results of the transition destinations are stored in integer variables i, j, and k, respectively, and finally the addresses are returned as `&plant[i][j][k]`. First, if the input is a rotation instruction, i and j remain unchanged, and only k changes. The calculation is performed using the decoded raw radian angle, and finally encoded into an integer value. Although omitted in Figure 7B, in reality, to properly manage the angle, if the decoded value is less than or equal to -π / 2, 2π is added, and if the decoded value is greater than π / 2, 2π is subtracted. On the other hand, if the input is a translation instruction, k remains unchanged, while i and j change. The variable `trans_step` stores a value obtained by replacing the translation distance with the number of grids. In this case, the translation is plus or minus 0.2 meters and the grid size is 0.2 meters, so either +1 or -1 is stored. Then, the value of trans_step is added to or subtracted from i or j, but whether i or j changes or whether it's added or subtracted depends on the direction the robot is facing. Therefore, the calculation is performed by dividing it into four cases (positive and negative directions of the X and Y axes).
[0033] Figure 7B specifically describes the case where the robot is facing the positive direction of the X-axis, and this will be explained in the main text. First, a boundary check is performed. If the current X-coordinate is 9 and trans_step is +1, the X-coordinate should be 10, but this is unsuitable because it will collide with the boundary (obstacle). Similarly, if the current X-coordinate is 1 and trans_step is -1, the X-coordinate should be 0, but this is also unsuitable because it will collide with the boundary (obstacle). For such unsuitable transitions, transition() returns NULL. After confirming that there is no collision with the boundary, the transition is executed. To check whether the robot attempts to pass through an obstacle during the transition, the obstacle detection function obstacle_check() is executed each time i is incremented or decremented. The definition of this function is not shown in Figure 6-2, but it returns true if the coordinates (i, j, k), especially the pair (i, j), which are the arguments, are not included in the array obstacle[], and false otherwise. After confirming that the program does not pass through the obstacle, it returns &plant[i][j][k] using the incremented or decremented i. If it is determined that the program does pass through the obstacle, it is invalid and returns NULL.
[0034] Finally, the first finite state transition model 13 is generated in Figure 7C. This is achieved by calculating the next transition destination for each element (state) of plant
[11]
[11] [4] using the function transition() and adding it to a pointer array. In other words, a triple loop is used. The x, y, and θ of the element plant[i][j][k] are stored as their corresponding encoded values i, j, and k, respectively. After confirming that the state (i, j, k) is not on or outside the boundary or on an obstacle, the state transition is calculated for each input. Since there are NUMBER_OF_INPUTS inputs (5 in this case), the For loop is executed 5 times. Note that std::vector<struct plantstate*> plant[i][j][k].next[u] represents the destination when the input[u] is applied. This is calculated by the function transition() shown in Figure 7B and stored in the pointer next. If the pointer next is not NULL, it indicates that a transition is possible, and that pointer is used as the destination in std::vector<struct plantstate*> Register in plant[i][j][k].next[u]. As will be described later, in this embodiment, when communication is lost (i.e., when no communication packet 19 is received from another robot), the low-level control cancels the high-level control and stops in place to maintain the state in order to avoid collisions between robots. Therefore, std::vector<struct plantstate*> In plant[i][j][k].next[u], not only next but also &plant[i][j][k] itself is registered. Through the above operations, the first finite state transition model 13 is generated as an array of structures that hold the transition destinations as pointers.
[0035] <Control microcontroller 305> The control microcontroller 305 mounted on the robot is a device that includes a CPU and memory, and performs calculations for low-level control and high-level control. In this embodiment, the array plant
[11]
[11] [4], which is an implementation of the finite state transition model, contains three variables x, y, and θ in each element to represent its own state, and can contain up to NUMBER_OF_INPUTS*2 pointers to represent transitions. If the required amount of memory cannot be secured, the finite state transition model will not be implemented correctly, the control will become undefined, and safety cannot be guaranteed, so estimating the required amount of memory is important. If the three variables x, y, and θ are each represented by a 1-byte variable, and one pointer is represented by 4 bytes, the amount of memory required to represent one finite state transition model is calculated to be (1*3+4*5*2)*11*11*4 = 20812 bytes, or approximately 20 kilobytes. Assuming that the finite state transition model for evasive movement, described later, will also consume approximately 20 kilobytes, a memory capacity of around 100 kilobytes for the control microcontroller 305 should be sufficient.
[0036] However, in this embodiment, it is not possible to specify a destination with an accuracy of less than 20 centimeters. This is because each position within a 20-centimeter square grid is considered identical in the abstract control system 6. On the other hand, if the grid size of the abstract control system 6 in Figure 3 is reduced to one-tenth and the intervals are 2 centimeters, the accuracy of destination specification improves to 2 centimeters, but the implementation array of the finite state transition model becomes plant
[0101]
[0101] [4], and the amount of memory required to represent one finite state transition model is calculated to be (1*3+4*5*2)*101*101*4 = 1,754,572 bytes, or approximately 1.7 megabytes. If we estimate that approximately 1.7 megabytes will also be consumed for the finite state transition model for avoidance movement described later, the control microcontroller 305 will need about 4 megabytes of memory.
[0037] Generally, microcontrollers with larger memory capacities are more expensive than those with smaller memory capacities. Therefore, by modeling as a finite state transition model, it is possible to estimate the amount of memory required for the desired control performance (accuracy of destination designation) and select a microcontroller sufficient for this estimation as the control microcontroller 305. Conversely, by determining the smallest grid size that fits within the memory capacity of a given control microcontroller 305, it is possible to achieve maximum control performance under the given cost constraints.
[0038] Figure 8 shows a portion of the first directed graph 16 generated from the first finite state transition model 13 for generating the first high-level control 7 in this embodiment. Figure 9 shows the shortest path and input sequence determined by the first high-level control 7 in this embodiment.
[0039] <High-level control> The following describes high-level control. The first high-level control 7 plans the path for moving the first mobile robot 3 to its destination and gives instructions to the first low-level control 8 to translate, rotate, or stop. This can be obtained by applying shortest path search on the first finite state transition model 13. That is, a first directed graph 16 is constructed by replacing the control inputs U1 to U5 with weight 1 on the first finite state transition model 13, and the shortest path is obtained by applying Dijkstra's algorithm on the first directed graph 16. The first high-level control 7 associates the first finite state transition model 13 with this shortest path and associates the control inputs before replacing the weights with 1, thereby giving instructions to the first low-level control 8 to translate, rotate, or stop.
[0040] Figure 9 shows the shortest path and input sequence obtained by the first high-level control 7 after applying Dijkstra's algorithm when the initial position is (0,0,0) and the destination is (0,0.2,π / 2). First, in the initial state (0,0,0), the first high-level control 7 selects control input U3 (+π / 2 radian rotation). This control input is executed by the first low-level control 8 to drive the servo motor, so in the next time step, the state of the first mobile robot 3 transitions to (0,0,π / 2). The first high-level control 7 selects control input U1 (+0.2 meter translation), and in the next time step, the state of the first mobile robot 3 transitions to (0,0.2,π / 2) and arrives at the destination. The second directed graph 17 and the third directed graph 18 are similarly generated to produce the second high-level control 9 and the third high-level control 11.
[0041] Figure 10 shows a communication packet 19 that is communicated between each mobile robot in this embodiment.
[0042] <Communication Packet> In this embodiment, the first mobile robot 3, the second mobile robot 4, and the third mobile robot 5 are able to communicate with each other. At the beginning of each time step, the received data is checked, high-level control and low-level control are activated, and finally the data is transmitted. Each mobile robot transmits one communication packet 19 in each time step. Each communication packet 19 is also broadcast to all other mobile robots. For example, the communication packet 19 transmitted by the first mobile robot 3 includes the state of the first mobile robot 3 in that time step, the position of the first mobile robot 3 in the next time step which will be determined by the result of the control input selected by the first high-level control 7, and the target state of the first mobile robot 3. In this embodiment, in addition to the communication packet 19, a lock position packet 20 (described later) is also communicated between each mobile robot.
[0043] <Processing to be performed for each time step duration> Figure 11 shows the processing that each mobile robot performs within the time step duration. As mentioned above, each mobile robot is time-synchronized, and the time step set for each mobile robot is the same. Figure 10 shows the processing that each mobile robot performs within each time step. First, at the start time of the time step, it acquires a communication packet 19 received from another mobile robot. Next, the first mobile robot 3's first high-level control 7 (the second mobile robot 4 and the third mobile robot 5 have their second high-level control 9 and third high-level control 11, respectively) determines one control input based on the path to reach the target state. Next, it performs a "control input safety check" to confirm whether or not to transmit the control input to the first low-level control 8 (the second mobile robot 4 and the third mobile robot 5 have their second low-level control 10 and third low-level control 12, respectively). The control input safety check will be described later. Subsequently, the first low-level control 8 (the second mobile robot 4 and the third mobile robot 5 are controlled by the second low-level control 10 and the third low-level control 12, respectively) controls the left servo motor 303 and the right servo motor 304, causing the first mobile robot 3 (or the second mobile robot or the third mobile robot 5) to translate, rotate, or stop. When the low-level control is completed, the high-level control acquires the current state of the mobile robot and performs a state transition according to the acquired result. This state transition will be described later. At the end of the time step, the first mobile robot 3 (or the second mobile robot or the third mobile robot 5) transmits a communication packet 19 to the other mobile robots.
[0044] <Safety check of control input> Figure 12 is a pseudocode showing the determination of transmission and non-transmission in the safety confirmation of control input for the first mobile robot 3 in this embodiment. The safety check of the control input is responsible for determining whether or not to transmit the control input from the high-level control to the low-level control in each mobile robot. If it is decided to transmit, the control input from the high-level control is passed directly to the low-level control; if it is decided not to transmit, the control input from the high-level control is invalidated and replaced with a stop before being transmitted to the low-level control. Figure 12 is pseudocode showing the specific determination method for safety check of the control input. If even a portion of the packets from other mobile units are missing, it is determined that there is no safety and it is decided immediately not to transmit to the low-level controller (replace with a stop). If no packet interruption occurs, the process proceeds to the following: First, the state of the first mobile robot 3 at the next time step is calculated assuming that the control input determined by the first high-level control 7 is input directly, and this is stored in next_tmp_state.
[0045] Next, we calculate the safe state for the first mobile robot 3. A safe state is a subset of the entire state space that represents the set of states where safety is ensured. In this embodiment, a safe state is a position where no other mobile robots, namely the second mobile robot 4 and the third mobile robot 5, can exist. On the other hand, an unsafe state is a position where at least one of the other mobile robots, namely the second mobile robot 4 or the third mobile robot 5, may exist. Since safe and unsafe states are complementary, we will consider the unsafe state in this case. That is, we create an array called unsafe_list and register the states contained in the received communication packet 19 and the locked position packet 20 (described later).
[0046] In this embodiment, the current state, next state, and locked position of the second mobile robot 4 and the third mobile robot 5 are registered. Finally, each state registered in unsafe_list is checked, and if any state is included where the X and Y coordinates of next_tmp_state match, the control input determined by the first high-level control 7 is unsafe, i.e., returns FALSE, and instructs the first low-level control 8 to stop instead of the control input determined by the first high-level control 7. If at least one of the X or Y coordinates of next_tmp_state differs for all states registered in unsafe_list, the control input determined by the first high-level control 7 is determined to be safe, and the control input determined by the first high-level control 7 is transmitted to the first low-level control 8 as is. The same safety check is performed for the second mobile robot 4 and the third mobile robot 5.
[0047] Figure 13 shows the state immediately before a deadlock occurs due to a safety check of the control input. Figure 14 shows the state at the point when a deadlock occurs due to safety checks of the control input.
[0048] <Generating evasive trajectories during continuous stops> Depending on the position and target state of each robot, multiple robots may stop to prevent collisions during the safety check of the control input, potentially resulting in a deadlock. In Figure 13, the second mobile robot 4 attempts to move to a target state ahead of the third mobile robot 5, and the third mobile robot 5 attempts to move to a target state ahead of the second mobile robot 4. As a result, as shown in Figure 14, the positions of the second mobile robot 4 and the third mobile robot 5 overlap with the next desired position, resulting in a deadlock. The first mobile robot 3 continues to move normally.
[0049] To resolve the deadlock, at least one of the second mobile robot 4 or the third mobile robot 5 needs to temporarily generate an avoidance trajectory. Therefore, if the number of consecutive stops (unsafe) in the safety check of the control input exceeds a certain threshold, an avoidance trajectory will be generated. This threshold may be, for example, 3 times, or any other positive integer. Furthermore, stops due to packet loss may not be included in the count of consecutive stops. This prevents the generation of unnecessary avoidance trajectories when a deadlock has not occurred between the mobile robots, but only due to overlapping packet loss timings. In addition, instead of necessarily generating an avoidance trajectory when the threshold is exceeded, a mechanism may be implemented to probabilistically determine whether or not to generate an avoidance trajectory when the threshold is exceeded. This would allow only one of the robots to generate an avoidance trajectory, while the other robot does not deviate from its original destination.
[0050] Figure 15 shows the procedure for generating an avoidance trajectory. First, in step S1, the array `obstacle2[]` stores all the positions contained in `obstacle[]`, along with the sum of the other's own position and lock position received by the moving object.
[0051] Next, in step S2, a finite state transition model for avoidance movement is generated. This finite state transition model for avoidance movement is similar to the first finite state transition model 13. The difference between this model and the first finite state transition model 13 is that while the first finite state transition model 13 prohibited transitions to obstacle locations, the finite state transition model for avoidance movement prohibits not only transitions to obstacle locations but also transitions to locations where other mobile robots are currently located and locations currently locked (occupied) by other mobile robots. This can be generated by replacing the references to `obstacle[]` in the `transition()` and `plant_init()` functions used to generate the first finite state transition model 13 with references to `obstacle2[]` generated in step S1. This replacement can also be implemented by copying `transition()` and `plant_init()`, defining functions with different names `transition2()` and `plant_init2()`, and rewriting the parts of `transition2()` and `plant_init2()` that reference `obstacle[]` to reference `obstacle2()`.
[0052] In step S3, a temporary, provisional destination is set for generating an avoidance trajectory. Since generating an avoidance trajectory is likely to move the robot away from its original destination, it is advisable to set a location as close to the current position as possible. Additionally, probabilistic behavior, such as random number generation, may be incorporated into setting this destination. By incorporating probabilistic behavior, even if the generation of an avoidance trajectory fails the first time, for example, due to overlapping with another mobile robot, it is expected that the next generation will generate a different avoidance trajectory, thus ensuring successful avoidance.
[0053] In step S4, a path is generated to the destination determined in step S3 using the finite state transition model for avoidance movement generated in step S2. This can be done by performing a shortest path search using Dijkstra's algorithm, as shown in Figure 8.
[0054] Finally, in step S5, the finite state transition model for avoidance movement is used to verify whether the path generated in step S4 can actually reach the destination determined in step S3 from the current position of the moving object. If the verification shows that the destination can be reached, the generation of the avoidance trajectory is terminated. If the destination cannot be reached, it is determined that the destination determined in step S3 is unsuitable, so the process returns to step S3 and steps S4 and S5 are repeated.
[0055] Furthermore, in the time step in which an avoidance trajectory is generated, the mobile robot does not enter the avoidance trajectory but maintains a stationary position. This is because there is a possibility that the avoidance trajectory generated by the other mobile robot, which needs to avoid a deadlock, may overlap with the avoidance trajectory generated by the mobile robot itself. Therefore, in the safety check of the control input in the time step following the generation of the avoidance trajectory, the mobile robot analyzes the communication packet 19 and lock position packet 20 (described later) received from the other mobile robot, and enters the avoidance trajectory only after confirming that the avoidance trajectory it generated does not overlap with these. If an overlap occurs, the avoidance trajectory is generated again. In this way, avoidance trajectories do not overlap with each other, and it is guaranteed that the mobile robot will always be safe while moving along the avoidance trajectory. This generation and regeneration of avoidance trajectories realizes a kind of negotiation between mobile robots, where they generate avoidance trajectories themselves in case of misunderstandings, and then decide whether the generated avoidance trajectory is usable by looking at information from other mobile robots. As a result, each mobile robot can achieve collision and deadlock avoidance on its own without the need to formulate an overall plan for all mobile robots in the field.
[0056] <Lock Position Packet 20> Figure 16 shows the locked position packet 20. The lock position packet 20 is a packet indicating a position on the avoidance trajectory generated by the mobile robot that sends the lock position packet 20, but which has not yet been passed, and is sent to all other mobile robots. To explain the lock position packet 20, as an example, in Figure 14, the third mobile robot 5 is in the state of (0.8, -0.2, -π / 2), and as a result of the avoidance trajectory generation procedure shown in Figure 15, a temporary destination for avoidance (step S3) is specified as (0.6, 0, -π / 2), and in step S4 of Figure 15, at (0.8, -0.2, -π / 2), a control input U4 (-π / 2 radian rotation) is input to transition to (0.8, -0.2, π), and (0.8, -0.2, Let's consider the case where the first mobile robot generates an avoidance trajectory by inputting control input U1 (+0.2 meter translation) at π, transitioning to (0.6, -0.2, π), inputting control input U3 (+π / 2 radian rotation) at (0.6, -0.2, π), and inputting control input U2 (-0.2 meter translation) at 0.6, -0.2, -π / 2), transitioning to (0.6, 0, -π / 2), and also consider the case where the second mobile robot 4 does not generate an avoidance trajectory.
[0057] Figure 17 shows the operation of the third mobile robot 5 after it has generated an avoidance trajectory in Figure 14, and the operation of the other mobile robots during that time. Figure 18 shows the lock position packet 20 transmitted by the third mobile robot 5 in the state shown in Figure 17.
[0058] In Figure 17, the third mobile robot 5 is in the state of (0.6, -0.2, π) following an avoidance trajectory, and then transitions to (0.6, -0.2, -π / 2) by receiving control input U3. While the mobile robot is moving along the avoidance trajectory, the information in the communication packet 19 transmitted by the mobile robot will be information according to the avoidance trajectory. That is, the information contained in the communication packet 19 transmitted by the third mobile robot 5 in the state of Figure 17 will be the robot's own state (0.6, -0.2, π), the robot's next state (0.6, -0.2, -π / 2), and the robot's target state (0.6, 0, -π / 2).
[0059] Furthermore, in this state, the third mobile robot 5 has already reached the position (0.6, -0.2) and this information is recorded in the communication packet 19. Therefore, the first mobile robot 3 and the second mobile robot 4 will not take any control inputs that would cause them to reach (0.6, -0.2) at the next time step, due to safety checks of the control inputs. Consequently, there is no need to declare (0.6, -0.2) as a locked position. Thus, the locked position packet 20 transmitted by the third mobile robot 5 at this time will only include (0.6, 0), which is on the avoidance trajectory but has not yet been passed, as shown in Figure 18. In this way, by sequentially releasing the locked positions from the positions that have already been passed on the avoidance trajectory, all locked positions will be released when the third mobile robot 5 reaches the end of the avoidance trajectory, (0.6, 0, -π / 2).
[0060] <State transitions in high-level control> A state transition in high-level control is the process of updating the current state of the first mobile robot 3 (or the second mobile robot 4 or the third mobile robot 5) in the first finite state transition model 13 (or the second finite state transition model 14 or the third finite state transition model 15) shown in Figure 6. In this embodiment, when a control input is applied in a certain state, the transition destination is not predetermined to one state. If the safety of the control input is determined to be safe, the system transitions to the next state; otherwise, it remains in the same state (stopped).
[0061] For example, consider the time step in Figure 6 when the state of the first mobile robot 3 is (0, 0, 0). At this time, suppose the first high-level control 7 instructs a control input U3 (+π / 2 radian rotation), as shown in Figure 8. If the safety check of the control input at this time step determines that it is safe, the control input U3 is applied to the first mobile robot 3, and the state of the first finite state transition model 13 transitions to (0, 0, π / 2); otherwise, it remains at (0, 0, 0). Note that the state transition of the first finite state transition model 13 may be determined not only by the safety or unsafety result of the safety check of the control input described above, but also by the current position and attitude information obtained using GPS to acquire position information and IMU (Inertial Measurement Unit) to acquire attitude information for the first mobile robot 3. In other words, in the previous example, the first finite state transition model 13 could transition to either (0, 0, π / 2) or (0, 0, 0). However, if location information (0.00123, 0.00311) is detected by GPS and the Z-axis angle is detected by IMU as 0.0001 radians, then the first finite state transition model 13 can determine that it should transition to (0, 0, 0).
[0062] <Sending process> The first mobile robot 3 (or the second mobile robot 4 or the third mobile robot 5) sends a communication packet 19 and a lock position packet 20 at the end of the time step.
[0063] According to this embodiment, the state space of each mobile robot is divided into a finite number of states in the same way and modeled as a finite state transition model, and a safety check process for the control input is performed, overwriting the control input with a stop signal if it is unsafe. As a result, communication interruptions can be treated as non-deterministic transitions on the finite state transition model, and control can be safely continued even if a communication interruption occurs. Furthermore, when the obstacle position / number of mobile robots is changed, the finite state transition model can be automatically regenerated by updating the array obstacle[] showing the obstacle position information in Figures 7A~C to the new obstacle position for changes in the obstacle position, and as for changes in the number of mobile robots, only the number of communication packets 19 and lock position packets 20 sent and received changes, which does not affect the control at all. Thus, it has the effect of enabling the construction of a controller with theoretically guaranteed safety without requiring much effort.
[0064] The embodiments of the present invention described above provide the following effects. (1) A mobile body control system according to one embodiment of the present invention is a mobile body control system comprising a plurality of mobile bodies, each having a destination movement control input determination unit for controlling movement to a destination, a control input correction unit for correcting the value input to the destination movement control input determination unit, a deadlock detection unit for detecting deadlocks, and a drive unit for driving itself, wherein each mobile body has a finite state transition model dynamic generation unit for avoidance movement and an output unit, the control input correction unit of a mobile body determines that avoidance movement is necessary when the deadlock detection unit detects a deadlock and instructs the finite state transition model dynamic generation unit for avoidance movement to do so when it receives an instruction for avoidance movement from the control input correction unit, dynamically generates a finite state transition model for avoidance movement based on its own position information, obstacle position information, other robot position information and other robot lock position information and generates an avoidance trajectory, and the output unit outputs to other mobile bodies self-robot position information indicating its current position and self-robot lock position information indicating positions on the generated avoidance trajectory that the mobile body has not yet passed through.
[0065] With the above configuration, by treating communication interruptions as non-deterministic transitions on a finite state transition model, it becomes possible to control the movement of each mobile object sharing a field to its respective destination while ensuring safety and low cost.
[0066] (2) When the control input modification unit detects the possibility of collision with another robot, it instructs the drive unit to stop the mobile body on which the control input modification unit is mounted, regardless of the control input determined by the destination movement control input determination unit. As a result, stopping takes priority over path movement when there is a possibility of collision with another robot, making it possible to reliably avoid collisions with other robots.
[0067] (3) The control input correction unit stops the mobile robot when it attempts to enter a position included in the other robot's position information and the other robot's locked position information, and the deadlock detection unit detects a deadlock when the mobile robot stops a certain number of times in a row. It is not possible to conclude that a deadlock has occurred with only one stop, and it is preferable to detect a deadlock when the robot stops a certain number of times in this manner.
[0068] (4) If the control input correction unit fails to receive at least one of the other robot's position information or the other robot's locked position information, it instructs the drive unit to stop the mobile body on which the control input correction unit is mounted, regardless of the control input determined by the destination movement control input determination unit. If information reception fails in this manner, it may not be possible to accurately determine the positional relationship between the self-mobile body and the other robot, and such stopping measures are taken to avoid collisions.
[0069] (5) Overwriting of stop instructions by the control input correction unit due to failure to receive other robot position information or other robot lock position information will not be included in the count of consecutive stops for deadlock detection determination by the deadlock detection unit. This will prevent false detection of deadlocks.
[0070] (6) The control input modification unit compares the received other robot position information and other robot lock position information with the self-lock position generated by the avoidance movement finite state transition model dynamic generation unit included in the mobile body on which the control input modification unit is mounted and transmitted to the other robot. If the received position information and the self-lock position do not overlap, the unit determines the control input according to the avoidance movement finite state transition model generated by the avoidance movement finite state transition model dynamic generation unit and applies the control input to the drive unit. If the received position information and the self-lock position overlap, the unit discards the avoidance movement finite state transition model, issues a stop command to the drive unit, and instructs the avoidance movement finite state transition model dynamic generation unit to regenerate the avoidance movement finite state transition model. This makes it possible to control the mobile body while constantly monitoring whether the generated avoidance movement finite state transition model avoids collisions with other robots.
[0071] (7) Each destination movement control input determination unit and control input modification unit has a high-level controller, and each moving body has a low-level controller. The high-level controller constructs an abstract state space by dividing the state space of the moving body into a finite number of states, and generates a finite state transition model based on which state the body transitions to when each control input is applied in each state of the abstract state space. The high-level controller plans the movement path to the destination on the generated finite state transition model and decides whether to apply the control input to translation or rotation based on the plan. The low-level controller controls the motor or engine or other device that generates the driving force to move the moving body included in the drive unit so that each moving body performs translation or rotation according to the instructions of the high-level controller. Specifically, the movement control of the present invention is performed in this manner.
[0072] (8) The finite state transition model for avoidance movement generated by the dynamic generation unit is obtained by prohibiting state transitions to the locked position received from another moving object in the configuration of the finite state transition model in the high-level controller. Specifically, the finite state transition model for avoidance movement in the present invention is generated in this manner.
[0073] (9) The high-level controller contained in each mobile unit constitutes an abstract state space in the same manner, and the other robot position information, self-robot position information, other robot lock position information, and self-robot lock position information transmitted and received by each mobile unit are described as position information in the abstract state space. This makes it possible to easily handle position information as coordinate information.
[0074] (10) Each moving unit has a control microcontroller, and the high-level controller is implemented on the control microcontroller, and the control microcontroller has a memory area of a size greater than or equal to the size required for implementing the finite state transition model. A microcontroller with such specifications is required to generate the finite state transition model for avoidance movement.
[0075] (11) The planning of the travel path to the destination by the high-level controller is obtained by applying dynamic programming to the finite state transition model generated by the high-level controller, treating it as a weighted directed graph. This allows for weighting of each path, making it possible to plan the travel path while considering the priority between paths.
[0076] (12) The generation of avoidance trajectories by the dynamic generation unit of the finite state transition model for avoidance movement probabilistically selects the destination set when applying dynamic programming by random number generation. By adopting such a method, it becomes possible to easily generate avoidance trajectories.
[0077] (13) The finite state transition model is represented by a structure array, and each structure element of the structure array stores the position and angle of at least one moving object, and a pointer to a structure corresponding to the state of the moving object that can be transitioned to when each control input is applied. This makes it possible to visually grasp the finite state transition model for avoidance movement and to process it in an easy-to-use manner.
[0078] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are possible. For example, the embodiments described above are explained in detail to make the present invention easier to understand, and the present invention is not necessarily limited to embodiments having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment. It is also possible to add configurations from other embodiments to the configuration of one embodiment. Furthermore, it is possible to delete parts of the configuration of each embodiment, or to add or replace other configurations. [Explanation of Symbols]
[0079] 0 Control system, 3, 4, 5 Mobile robot, 100 Mobile body, 101 Self-position acquisition unit, 102 Control input determination unit for destination movement, 103 Control input correction unit, 104 Deadlock detection unit, 105 Dynamic generation unit for finite state transition system for avoidance movement, 106 Drive unit, 107 Self-lock position output unit, 108 Self-position output unit
Claims
1. A mobile body control system comprising a plurality of mobile bodies, each having a destination movement control input determination unit for controlling movement to a destination, a control input correction unit for correcting the value input to the destination movement control input determination unit, a deadlock detection unit for detecting a deadlock, and a drive unit for driving itself, Each of the aforementioned moving bodies has a dynamic generation unit and an output unit for a finite state transition model for avoidance movement. The control input correction unit of the moving body determines that avoidance movement is necessary when the deadlock detection unit detects a deadlock and instructs the dynamic generation unit of the finite state transition model for avoidance movement. The aforementioned finite state transition model dynamic generation unit for avoidance movement, upon receiving an instruction for avoidance movement from the control input correction unit, dynamically generates a finite state transition model for avoidance movement based on its own position information, obstacle position information, other robot position information, and other robot lock position information, and generates an avoidance trajectory. The output unit outputs to other mobile bodies self-robot position information indicating its current position and positions on the generated avoidance trajectory that the mobile body has not yet passed through, as self-robot lock position information. A mobile control system characterized by the following features.
2. A mobile body control system according to claim 1, When the control input modification unit detects the possibility of collision with another robot, it instructs the drive unit to stop the mobile body on which the control input modification unit is mounted, regardless of the control input determined by the destination movement control input determination unit. A mobile control system characterized by the following features.
3. A mobile body control system according to claim 2, The control input correction unit stops the mobile body when it attempts to enter a position included in the other robot's position information and the other robot's locked position information. The deadlock detection unit detects a deadlock when the moving body stops a certain number of times or more consecutively. A mobile control system characterized by the following features.
4. A mobile control system according to claim 3, If the control input correction unit fails to receive at least one of the other robot's position information or the other robot's locked position information, it instructs the drive unit to stop the mobile body on which the control input correction unit is mounted, regardless of the control input determined by the destination movement control input determination unit. A mobile control system characterized by the following features.
5. A mobile control system according to claim 4, Overwriting of a stop instruction by the control input correction unit due to failure to receive the other robot's position information or the other robot's locked position information shall not be included in the count of consecutive stops for deadlock detection determination by the deadlock detection unit. A mobile control system characterized by the following features.
6. A mobile body control system according to claim 5, The control input modification unit compares the received other robot position information and other robot lock position information with the self-lock position generated by the avoidance movement finite state transition model dynamic generation unit included in the mobile body on which the control input modification unit is mounted and transmitted to the other robot. If the received position information and the self-lock position do not overlap, the control input is determined according to the avoidance movement finite state transition model generated by the avoidance movement finite state transition model dynamic generation unit and applied to the drive unit. If the received position information and the self-lock position overlap, the avoidance movement finite state transition model is discarded and a stop command is applied to the drive unit, and the avoidance movement finite state transition model dynamic generation unit is instructed to regenerate the avoidance movement finite state transition model. A mobile control system characterized by the following features.
7. A mobile control system according to claim 6, The destination movement control input determination unit and the control input modification unit each have a high-level controller. Each of the aforementioned mobile units has a low-level controller, The high-level controller constructs an abstract state space by dividing the state space of the moving object into a finite number of states, generates a finite state transition model based on which state the object transitions to when each control input is applied to each state in the abstract state space, plans the movement path to the destination on the generated finite state transition model, and decides whether to apply the control input to translation or rotation based on the plan, The low-level controller controls the motor, engine, or other device included in the drive unit that generates the driving force to move the moving bodies, so that each of the moving bodies translates or rotates, in accordance with the instructions of the high-level controller. A mobile control system characterized by the following features.
8. A mobile control system according to claim 7, The finite state transition model for avoidance movement generated by the dynamic generation unit for the finite state transition model for avoidance movement is obtained by prohibiting state transitions to the locked position received from another moving object in the configuration of the finite state transition model in the high-level controller. A mobile control system characterized by the following features.
9. A mobile body control system according to claim 8, Each of the aforementioned moving bodies contains the aforementioned high-level controllers, which constitute the abstract state space in the same manner. The other robot position information, the self-robot position information, the other robot lock position information, and the self-robot lock position information transmitted and received by each of the aforementioned mobile units are described as position information in the abstract state space. A mobile control system characterized by the following features.
10. A mobile control system according to claim 9, Each of the aforementioned mobile units has a control microcontroller. The aforementioned high-level controller is implemented on the control microcontroller. The control microcontroller has a memory area larger than the size required to implement the finite state transition model. A mobile control system characterized by the following features.
11. A mobile body control system according to claim 10, The planning of the travel path to the destination by the high-level controller is obtained by applying dynamic programming to the finite state transition model generated by the high-level controller, treating it as a weighted directed graph. A mobile control system characterized by the following features.
12. A mobile body control system according to claim 11, The generation of avoidance trajectories by the dynamic generation unit of the finite state transition model for avoidance movement involves probabilistically selecting the destination set when applying the dynamic programming method by random number generation. A mobile control system characterized by the following features.
13. A mobile body control system according to claim 12, The finite state transition model is represented by a structure array, and each of the structures that are elements of the structure array stores the position and angle of at least one moving body, and a pointer to a structure corresponding to the state of the moving body that can be transitioned to when each control input is applied. A mobile control system characterized by the following features.
Citation Information
Patent Citations
Distributed autonomous mobile robot scheduling system
CN111885550A
Unit and method for operation management control
JP1995219633A
Distributed path planning device and method, and distributed path planning program
JP2004280213A
Carriage system
JP2010160696A
Electronic component mounting method
JP2012227349A