Elevator control system and control device, robot management method, and robot

Abstract

To prevent a robot from falling into a dead lock state on any floor of an elevator.SOLUTION: When receiving an allocation request for a first robot from a robot management device, a control device of an elevator sets the allocation request as a target request, sets a destination floor transmitted by the allocation request as a target floor, and determines (A) whether or not a second robot different from the first robot is arranged on the target floor. When the control device determines that the second robot is "deployed" in the determination (A), the control device puts the target request in a suspended state without executing the allocation according to the request, and then performs determination (B) of whether or not the second robot is no longer deployed to the target floor. When it is determined that "there is no more deployment" in the determination (B), the control device releases the holding state for the target request and executes the allocation according to the request.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a control technique for moving a robot between floors using an elevator. [Background technology]

[0002] In recent years, robots have been increasingly used for various tasks in buildings (cleaning, monitoring, transportation, etc.) (see, for example, Patent Document 1). Accordingly, elevators are increasingly being used to move robots between floors in buildings. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7380793 Summary of the Invention [Problem to be solved by the invention]

[0004] On the other hand, if multiple robots are deployed on the same floor, they may encounter each other facing each other, which could lead to a deadlock situation in which they block each other's routes and are unable to continue moving.

[0005] Therefore, an object of the present invention is to prevent the robot from getting into a deadlock state on any floor of the elevator. [Means for solving the problem]

[0006] A control system according to the present invention has the following configuration (Aspect 1). The control system includes an elevator control device and a robot management device. When a first robot is moved between floors using an elevator, the robot management device issues an allocation request for the first robot by transmitting the departure floor and destination floor of the first robot to the elevator control device. When the elevator control device receives an allocation request for the first robot from the robot management device, the elevator control device determines (A) whether a second robot other than the first robot is deployed on the target floor, with the destination floor transmitted in the allocation request as a target floor. If the control device determines in (A) that a second robot is deployed, it places the target request on hold without executing the allocation according to the request, and then determines (B) whether the second robot is no longer deployed on the target floor. If the control device determines in (B) that a second robot is no longer deployed, it releases the hold status for the target request and executes the allocation according to the request.

[0007] According to the above-mentioned aspect 1, it is possible to control the timing of moving the robot between floors so that the number of robots deployed on any floor of the elevator is not more than one (two or more) (so that the number of robots deployed is at most one).

[0008] The control system according to the above-mentioned aspect 1 may have the following configuration (aspect 2): In the determination (B), the elevator control device determines whether or not an allocation request for the second robot, in which the target floor is the departure floor, has been received from the robot management device, and if it can be determined that such an allocation request for the second robot has been received, it may determine that the second robot is "no longer deployed" to the target floor.

[0009] Assuming that the second robot is not determined to be decommissioned until it actually leaves the target floor, if the allocation request for the second robot must also be put on hold when the second robot needs to move between floors, a chain of pending states will occur. If such a chain of pending states occurs and the chain of pending states becomes a loop, it will be impossible to release all of the pending states, making it impossible to move the robot between floors. Even if the chain of pending states is releasable, it will take a long time to release all of the chained pending states. On the other hand, according to the above-mentioned aspect 2, even if the allocation request for the second robot is put on hold, the pending state for the allocation request for the first robot can be released when the second robot needs to move between floors. Therefore, the timing of moving the robot between floors can be controlled without causing the chain of pending states described above.

[0010] The control system according to the above-described aspect 1 may have the following configuration (aspect 3). When a second robot is to be moved between floors while an allocation request for a first robot is on hold, the robot management device may treat the second robot as a new, separate first robot and make an allocation request for the new, separate first robot to the elevator control device. In this case, the elevator control device must also put on hold the allocation request for the new, separate first robot, which results in a chain of pending states. Furthermore, if at least a portion of the chain of pending states forms a loop, the control device may release all of the pending states for the portion of the chain that forms the loop.

[0011] According to the third aspect, it is possible to simultaneously move all robots between floors in a loop-shaped chain, which allows the robots to circulate along the loop, and as a result, it becomes possible to move the robots between floors without creating a deadlock on each floor.

[0012] The control device according to the present invention is obtained by extracting only an elevator control device from the control system according to any one of the above aspects 1 to 3 as the subject of the invention (aspect 4).

[0013] A robot management method according to the present invention has the following configuration (Aspect 5). In the robot control method, when a first robot is moved from a current floor to a destination floor using an elevator, a determination (A) is made as to whether a second robot other than the first robot is deployed at the destination floor. If the determination (A) determines that a second robot is deployed, a request for allocation of the first robot is put on hold without being sent to the elevator control device, and then a determination (B) is made as to whether the second robot is no longer deployed at the destination floor. Then, if the determination (B) determines that a second robot is no longer deployed, the request for allocation of the first robot is released from the hold state and sent to the elevator control device.

[0014] A robot according to the present invention has the following configuration (Aspect 6). When the robot travels from a current floor to a destination floor using an elevator, it determines (A) whether or not another robot other than itself is deployed at the destination floor. If the robot determines in (A) that another robot is deployed, it puts its own allocation request on hold without sending it to the elevator control device, and then determines (B) whether or not another robot is no longer deployed at the destination floor. If the robot determines in (B) that another robot is no longer deployed, it releases the hold on its own allocation request and sends it to the elevator control device.

[0015] According to the above-mentioned aspects 5 or 6, it is also possible to control the timing of moving the robot between floors so that the number of robots deployed on any floor of the elevator is not more than one (two or more) (so that the number of robots deployed is at most one). [Effects of the Invention]

[0016] According to the present invention, it is possible to prevent the robot from getting into a deadlock state on any floor of the elevator. [Brief explanation of the drawings]

[0017] [Figure 1] 1 is a conceptual diagram showing the overall configuration of an elevator according to an embodiment. [Figure 2] 1A and 1B are conceptual diagrams illustrating examples of robot management data and assignment request management data used in an embodiment. [Figure 3] 1A and 1B are conceptual diagrams illustrating examples of robot deployment data and hall call management data used in an embodiment. [Figure 4] 10 is a flowchart showing allocation request processing executed in the embodiment. [Figure 5] 10 is a flowchart illustrating an allocation process executed in the embodiment. [Figure 6] FIG. 10 is a conceptual diagram showing how information in hall call management data is updated as allocation processing is performed in an embodiment. [Figure 7] FIG. 10 is a conceptual diagram showing changes in information within robot deployment data (changes in deployment status) accompanying the movement of a robot. [Figure 8] FIG. 1 is a conceptual diagram illustrating four cases (A) to (D) in which pending states are linked together. [Figure 9] FIG. 10 is a conceptual diagram illustrating information in hall call management data used in the description of a first modified example. [Figure 10] FIG. 10 is a conceptual diagram illustrating information in hall call management data used in the description of a second modified example. [Figure 11]FIG. 10 is a conceptual diagram showing the overall configuration of an elevator according to a third modified example. [Figure 12] 10A and 10B are conceptual diagrams illustrating examples of assignment request management data and hall call management data used in a third modified example. [Figure 13] 13 is a flowchart showing allocation request processing executed in a third modified example. [Figure 14] FIG. 13 is a conceptual diagram showing how information in allocation request management data is updated as allocation request processing is performed in a third modified example. [Figure 15] 13 is a flowchart showing an allocation process executed in a third modified example. DETAILED DESCRIPTION OF THE INVENTION

[0018] [1] Implementation [1-1] Overall structure of the elevator FIG. 1 is a conceptual diagram showing the overall configuration of an elevator according to an embodiment. The elevator of this embodiment is equipped with multiple elevator cars G, and is used not only by passengers but also by robots H that perform various tasks (cleaning, monitoring, transport, etc.) in the building where the elevator is installed, when moving between floors. The robots H are managed centrally by a robot management device 1. The elevator cars G are also managed centrally by a group management control device 2. A control system that prevents the robots H from falling into a deadlock state on each floor of the elevator is constructed by the robot management device 1 and the group management control device 2. The robot management device 1 is not limited to being installed in the same building as the elevator, and may be a server or program that manages (controls) the robots H on the cloud. The configuration of each part will be described in detail below.

[0019] <Robot management device> In this embodiment, when each robot H needs to move between floors, it transmits the destination floor Fy to the robot management device 1. At this time, the robot H also transmits robot information Ph to the robot management device 1 to enable it to be distinguished from other robots H, so that the robot management device 1 can recognize which robot H has transmitted the destination floor Fy.

[0020] When the robot management device 1 is notified by a destination floor Fy that a robot H needs to move between floors, it requests the group management control device 2 to allocate a hall call X for the robot H by transmitting the current floor Fx and destination floor Fy of the robot H as the departure floor Fc and destination floor Fd, respectively (allocation request process; see FIG. 4). Details of this allocation request process will be described later.

[0021] Specifically, the robot management device 1 includes a storage unit 11 and a control unit 12 (see FIG. 1).

[0022] The storage unit 11 is a part configured with storage devices such as ROM and RAM, and stores information necessary for the control processing performed by the robot management device 1. In this embodiment, the storage unit 11 stores robot management data Dp and assignment request management data Dq as such information.

[0023] Here, the robot management data Dp is a database for managing, for each robot H, multiple pieces of information related to that robot H by linking them together (see FIG. 2(A)). The allocation request management data Dq is data for managing information on allocation requests for the robot H (see FIG. 2(B)). Specifically, it is as follows.

[0024] 2(A) is a conceptual diagram illustrating the robot management data Dp used in this embodiment. In the robot management data Dp, the robot information Ph and the current floor Fx of each robot H are recorded in a mutually associated state. Here, the current floor Fx associated with each robot H records the floor on which the robot H is deployed, and is updated each time the robot H moves between floors.

[0025] As a result, when the robot management device 1 receives robot information Ph together with the destination floor Fy from each robot H, it becomes possible to identify the current floor Fx of the robot H from the robot information Ph. In this embodiment, the current floor Fx of the robot H is used as the departure floor Fc when the robot H moves between floors using an elevator.

[0026] 2(B) is a conceptual diagram illustrating the allocation request management data Dq used in this embodiment. In the allocation request management data Dq, for each robot H that has transmitted a destination floor Fy (robot H that has requested inter-floor movement), the robot information Ph of that robot H, the departure floor Fc, and the destination floor Fd are recorded in a mutually associated state. Here, the departure floor Fc and destination floor Fd associated with each robot H respectively record the current floor Fx and destination floor Fy of that robot H that are transmitted to the group management control device 2 when the robot management device 1 makes an allocation request for that robot H. In this embodiment, a series of information about each allocation request is deleted from the allocation request management data Dq when the elevator car G arrives at the destination floor Fd (= destination floor Fy) associated with that allocation request.

[0027] This allows the robot management device 1 to refer to the allocation request management data Dq at any time to check which robot H is scheduled to move between floors at that time, and further, which floors the robot H is scheduled to move from and to.

[0028] The control unit 12 is a part that is responsible for executing the control processes (including allocation request processes) performed by the robot management device 1. Specifically, the control unit 12 is composed of processing devices such as a CPU and an MPU, and executes a control program installed in the robot management device 1 to realize the execution of its own control processes in software. Note that, before being installed in the robot management device 1, this control program may be stored in a readable state on a portable storage medium (for example, a flash memory, etc.), or may be stored in a downloadable state on another server, etc. Furthermore, the control processes performed by the robot management device 1 are not limited to being realized in software by executing a program, but may also be realized in hardware by a processing circuit (control unit 12) built in the robot management device 1.

[0029] <Group management control device> Each time the group management control device 2 receives an allocation request for the robot H from the robot management device 1, it can execute allocation in accordance with the request (allocation process; see FIG. 5). In this embodiment, in order to prevent the robot H from falling into a deadlock state on each elevator floor, the group management control device 2 controls the execution timing of the allocation in accordance with the request for each allocation request for the robot H within the allocation process, thereby controlling the timing of moving the robot H between floors. Details of this allocation process will be described later.

[0030] Although detailed explanation will be omitted, when the group management control device 2 receives an allocation request from a user, it can also execute allocation in accordance with the request. An allocation request from a user is transmitted to the group management control device 2, for example, when the user registers their destination floor Fd in a destination floor registration device installed at the landing of each floor, or when the user presses a destination direction button installed at the landing of each floor. In addition, the group management control device 2 controls the cars G via the elevator control device (see FIG. 1), causing each car G to execute an operation of responding to the hall call X assigned to that car.

[0031] Specifically, the group management control device 2 includes a storage unit 21 and a control unit 22 (see FIG. 1).

[0032] The storage unit 21 is a part configured with storage devices such as ROM and RAM, and stores information necessary for the control processing performed by the group management control device 2. In this embodiment, the storage unit 21 stores, as such information, robot deployment data Dr and hall call management data Dx.

[0033] Here, the robot deployment data Dr is data for managing the deployment status of the robot H on each elevator floor (see FIG. 3(A)). The hall call management data Dx is data for managing the allocation status of hall calls X for the robot H (see FIG. 3(B)). Specifically, it is as follows.

[0034] 3(A) is a conceptual diagram illustrating the robot deployment data Dr used in this embodiment. In the robot deployment data Dr, deployment information Pz is associated with each elevator floor. Here, the deployment information Pz associated with each floor records robot information Ph of the robot H deployed on that floor. The deployment information Pz in the robot deployment data Dr is updated each time each robot H moves between floors.

[0035] This allows the group management control device 2 to refer to the robot deployment data Dr at any time to confirm which robot H is deployed on which floor at that time.

[0036] 3(B) is a conceptual diagram illustrating the hall call management data Dx used in this embodiment. In the hall call management data Dx, for each allocation request for a robot H received by the group management control device 2, the robot information Ph of that robot H, the departure floor Fc, the destination floor Fd, the status flag Pf, and the allocation destination information Py are recorded in a mutually associated state.

[0037] Here, the departure floor Fc and destination floor Fd associated with each allocation request are recorded with the current floor Fx and destination floor Fy of the robot H transmitted in the allocation request from the robot management device 1. In this embodiment, when allocation according to the request is executed, the departure floor Fc (= current floor Fx) and destination floor Fd (= destination floor Fy) of the robot H are assigned to one of the cars G as a hall call X for the robot H.

[0038] The status flag Pf associated with each allocation request is a flag indicating whether allocation according to the allocation request should be executed or whether the allocation request should be put on hold without being executed. In this embodiment, the status flag Pf associated with each allocation request is set to "0" when allocation according to the allocation request should be executed (see FIGS. 3(B) and 6(D)), and is set to "1" when allocation should be put on hold without being executed (see FIG. 6(C)). The allocation destination information Py associated with each allocation request records car information Pg of the car G to which the hall call X (hall call X for the robot H) is assigned when allocation of the hall call X according to the request is executed. In this embodiment, a series of information indicating the allocation status of each hall call X is erased from the hall call management data Dx when the hall call X has completed its role.

[0039] This allows the group management control device 2 to refer to the hall call management data Dx at any time to check which robot H is currently moving between floors, and which robot H is currently waiting at floor Fx with its movement between floors restricted.

[0040] The control unit 22 is a part that is responsible for executing the control processing (including allocation processing) performed by the group management control device 2. Specifically, the control unit 22 is composed of processing devices such as a CPU or MPU, and executes a control program installed in the group management control device 2 to realize the execution of its own control processing in software. Note that, before being installed in the group management control device 2, this control program may be stored in a readable state on a portable storage medium (for example, a flash memory, etc.), or may be stored in a downloadable state on another server, etc. Furthermore, the control processing performed by the group management control device 2 is not limited to being realized in software by executing a program, but may also be realized in hardware by a processing circuit (control unit 22) built into the group management control device 2.

[0041] [1-2] Control process executed by elevator [1-2-1] Allocation request processing performed by the robot management device 4 is a flowchart showing the allocation request process executed in this embodiment. This allocation request process is started each time the robot management device 1 receives a destination floor Fy and robot information Ph from any robot H. Hereinafter, the robot H that has transmitted the destination floor Fy and robot information Ph for inter-floor movement will be referred to as the "first robot Hk1," and the information received by the robot management device 1 at that time (including the destination floor Fy and robot information Ph) will be collectively referred to as the "received information Pr1."

[0042] When the allocation request process begins, the robot management device 1 uses the robot information Ph in the received information Pr1 to extract the current floor Fx associated with the robot information Ph from the robot management data Dp, and sets it as the current floor Fx of the first robot Hk1 (step S101).

[0043] Thereafter, the robot management device 1 requests the first robot Hk1 to allocate the hall call X by transmitting the first robot Hk1's current floor Fx (the current floor Fx extracted in step S101) and destination floor Fy (the destination floor Fy in the received information Pr1) as the departure floor Fc and destination floor Fd, respectively, to the group management control device 2 (step S102). At this time, the robot management device 1 also transmits the robot information Ph of the first robot Hk1 to the group management control device 2 so that the group management control device 2 can recognize which robot H the transmitted allocation request is for.

[0044] Furthermore, in step S102, the robot management device 1 records the allocation request information (robot information Ph, current floor Fx, destination floor Fy) for the first robot Hk1 transmitted to the group management control device 2 in the allocation request management data Dq in a mutually associated state (see FIG. 2(B)). The example of FIG. 2(B) shows a case in which allocation request information (Ph="H-01", Fx="1st floor", Fy="7th floor") for the first robot Hk1 that needs to move from the 1st floor to the 7th floor has been recorded. After step S102, the robot management device 1 ends the allocation request process.

[0045] [1-2-2] Allocation process performed by the group management control device FIG. 5 is a flowchart showing the allocation process executed in this embodiment. This allocation process is initiated each time the group management control device 2 receives an allocation request for a hall call X for a robot H from the robot management device 1. Hereinafter, an allocation request for a robot H transmitted from the robot management device 1 will be referred to as a "target request," and the information received by the group management control device 2 at that time (robot information Ph, departure floor Fc (= current floor Fx), destination floor Fd (= destination floor Fy)) will be collectively referred to as "received information Pr2." Also, FIGS. 6(A) to 6(E) are conceptual diagrams showing how information in the hall call management data Dx is updated as the allocation process of FIG. 5 is performed, using as an example a case where the target request is an allocation request for a robot H that needs to move from the first floor to the seventh floor (received information Pr2 is Ph="H-01," Fc="1st floor," Fd="7th floor").

[0046] When the allocation process begins, the group management control device 2 first uses the robot information Ph in the received information Pr2 to create a storage location in the hall call management data Dx in association with the robot information Ph so that various information (departure floor Fc, destination floor Fd, status flag Pf, allocation destination information Py) about the robot H identified by that information (here, this robot H will be referred to as the "first robot Hk1") can be input (step S200, see FIG. 6(A)). FIG. 6(A) shows the state immediately after the storage location is created in step S200 (a state in which various information other than the robot information Ph has not yet been input).

[0047] Thereafter, the group management control device 2 records the departure floor Fc (= current floor Fx) and destination floor Fd (= destination floor Fy) in the received information Pr2 in the hall call management data Dx as the departure floor Fc and destination floor Fd for the first robot Hk1 (step S201, see FIG. 6(B)). Hereinafter, the destination floor Fd (= destination floor Fy) in the received information Pr2 will be referred to as the "target floor Fk." Furthermore, in step S201, the group management control device 2 sets the status flag Pf for the first robot Hk1 to the initial state (Pf="0") (see FIG. 6(B)).

[0048] After step S201, the group management control device 2 determines whether or not a robot H other than the first robot Hk1 (hereinafter, the other robot H will be referred to as the "second robot Hk2") is deployed on the target floor Fk at that time (step S202). Specifically, the group management control device 2 determines whether or not robot information Ph is recorded in deployment information Pz associated with the same floor as the target floor Fk, by referring to the robot deployment data Dr.

[0049] Taking the case where the first robot Hk1 moves to the 7th floor as an example, if robot information Ph is recorded in the deployment information Pz for the 7th floor at the time the group management control device 2 references the robot deployment data Dr in step S202 (see FIG. 7(A)), the group management control device 2 will determine in step S202 that the robot is "deployed (Yes)." On the other hand, if robot information Ph is not recorded in the deployment information Pz for the 7th floor (see FIG. 3(A)), the group management control device 2 will determine in step S202 that the robot is "not deployed (No)."

[0050] If the group management control device 2 determines "deployed (Yes)" in step S202, it can determine that if the first robot Hk1 were to be moved to the target floor Fk based on that determination, the number of robots H deployed on the target floor Fk would be multiple (two or more). In this case, the group management control device 2 puts the target request on hold without executing an allocation in accordance with the request (step S210). Specifically, the group management control device 2 changes the setting of the status flag Pf for the target request in the hall call management data Dx from Pf="0" to Pf="1" (see FIG. 6(C)) without executing an allocation in accordance with the target request. As a result, the first robot Hk1 is restricted from moving between floors and is placed in a standby state at the current floor Fx.

[0051] After step S210, the group management control device 2 determines whether the second robot Hk2 is no longer deployed on the target floor Fk in order to time the inter-floor movement of the first robot Hk1 (step S211). Specifically, the group management control device 2 determines whether the record of robot information Ph (specifically, the robot information Ph of the second robot Hk2) has been deleted from the deployment information Pz associated with the same floor as the target floor Fk, by referring to the robot deployment data Dr. Then, the group management control device 2 repeatedly executes step S211 until it can determine in step S211 that "deployment has been eliminated (Yes)."

[0052] As an example, when the first robot Hk1 moves to the 7th floor and the deployment status of the robot H at that time is the deployment status shown in Figure 7(A) (a situation in which the second robot Hk2 with robot information Ph "H-04" is deployed on the 7th floor), if the second robot Hk2 moves from that deployment status to another floor (see Figure 7(B). Figure 7(B) shows the case in which it has moved to the 4th floor), the group management control device 2 will determine in step S211 that "deployment is no longer available (Yes)."

[0053] If the group management control device 2 determines in step S211 that "there are no more robots deployed (Yes)", then it can determine based on that determination that even if the first robot Hk1 is moved to the target floor Fk, the number of robots H deployed on the target floor Fk will no longer be multiple (two or more). In this case, the group management control device 2 releases the hold state for the target request (step S212). Specifically, the group management control device 2 changes the setting of the status flag Pf for the target request back from Pf="1" to Pf="0" in the hall call management data Dx (see FIG. 6(D)).

[0054] Then, the group management control device 2 executes allocation according to the target request (step S220). Specifically, the group management control device 2 executes allocation to the car G by treating the departure floor Fc and the destination floor Fd in the received information Pr2 as one hall call X. Furthermore, the group management control device 2 records the car information Pg of the car G to which the hall call X is assigned as allocation destination information Py for the first robot Hk1 in the hall call management data Dx (see FIG. 6(E)). Thereafter, the group management control device 2 ends the allocation process.

[0055] On the other hand, if the group management control device 2 determines in step S202 that the robots H are not deployed (No), it can determine at that point that the number of robots H deployed on the target floor Fk will not be more than one (two or more) even if the first robot Hk1 is moved to the target floor Fk. In this case, the group management control device 2 proceeds to step S220 and executes allocation according to the target request without putting the target request on hold (without executing steps S210 to S212) (see FIG. 3(B)).

[0056] According to the above-described embodiment, it is possible to control the timing of moving the first robot Hk1 between floors so that the number of robots H deployed on any floor of the elevator is not more than one (two or more) (so that the number of robots H deployed is at most one). As a result, it is possible to prevent the robots H from falling into a deadlock state on any floor of the elevator.

[0057] [2] Variation [2-1] First modified example In the above-described embodiment, the judgment process (see FIG. 5) does not determine that the second robot Hk2 is no longer deployed (Yes) until the second robot Hk2 actually leaves the target floor Fk. If the second robot Hk2 needs to move between floors and the allocation request for the second robot Hk2 also goes on hold (if a robot H is also deployed at the destination of the second robot Hk2), the hold state will continue.

[0058] When such a chain of pending states occurs, if the chain of pending states becomes a loop as illustrated in Figures 8(A) to 8(C), it becomes impossible to release all of the pending states, and it becomes impossible to move robot H between floors. Furthermore, even if the chain of pending states is releasable as illustrated in Figure 8(D) (in the example of Figure 8(D), the chain is released when robot H, whose robot information Ph is "H-03", completes its movement between floors), it will take a long time before all of the chained pending states can be released.

[0059] 5, the group management control device 2 may determine whether the second robot Hk2 is no longer deployed at the target floor Fk by determining whether an allocation request for the second robot Hk2 specifying the target floor Fk as the departure floor Fc has been received from the robot management device 1. Specifically, the group management control device 2 determines whether there is a departure floor Fc that matches the target floor Fk among the departure floors Fc recorded in the hall call management data Dx.

[0060] 9 shows a case where a first robot Hk1 moves to the seventh floor and a second robot Hk2 (Ph="H-04") is deployed on the seventh floor, and the group management control device 2 receives an allocation request for the second robot Hk2 (an allocation request with the fourth floor as the destination floor Fd) from the robot management device 1 and records that information in the hall call management data Dx (a case where step S201 is executed in the allocation process for that allocation request). In this case, the group management control device 2 can find a departure floor Fc that matches the target floor Fk (="7th floor") from the departure floors Fc recorded in the hall call management data Dx, and as a result, can determine in step S211 that "there is no longer any deployment (Yes)."

[0061] According to the first modification, even if the allocation request for the second robot Hk2 is put on hold, the hold on the allocation request for the first robot Hk1 can be released at the point when the second robot Hk2 needs to move between floors. Therefore, the timing of moving the robot H between floors can be controlled without causing a chain of hold states as described above.

[0062] [2-2] Second variant In the above-described embodiment, if a chain of pending states occurs as described at the beginning of the first variant, and further, as illustrated in Figures 8(A) to 8(C), in the series of chains of pending states, at least some of which occur in a loop, the group management control device 2 may be configured to release all pending states for the part of the chain that has occurred in the loop (the part surrounded by the dashed line in the figure).

[0063] Fig. 10(A) is a conceptual diagram illustrating how information is recorded in the hall call management data Dx when a chain of hold states occurs as shown in Fig. 8(C). As shown in this diagram, when a chain of hold states occurs, the status flag Pf is set to "1" for all assignment requests that have been placed on hold due to the chain.

[0064] In this modified example, the group management control device 2 releases all pending states only for the loop-shaped chain portion (the portion surrounded by the dashed line in Figure 8(C), i.e., the pending state for allocation requests for two robots H whose robot information Ph is "H-03" and "H-04") (see Figure 10(B)).

[0065] According to the second modification, it becomes possible to simultaneously move all of the robots H between floors in the loop-shaped chain portion. This allows the robots H to circulate along the loop, and as a result, it becomes possible to move the robots H between floors without creating a deadlock state on each floor.

[0066] [2-3] Third variant In any of the above-described embodiments and modifications, the control system may be modified as appropriate so that the timing of moving the robot H between floors is controlled by the robot management device 1. Specifically, the robot management device 1 may control the timing of sending an allocation request for the robot H (the timing of sending it to the group management control device 2) within the allocation request process, thereby controlling the timing of moving the robot H between floors. This will be explained in detail below.

[0067] <Overall elevator configuration> Fig. 11 is a conceptual diagram showing the overall configuration of an elevator according to the third modified example. In this modified example, the robot deployment data Dr (see Fig. 3(A)) is stored in the memory unit 11 of the robot management device 1. In addition, the assignment request management data Dq and the hall call management data Dx are changed as follows.

[0068] 12(A) is a conceptual diagram illustrating the allocation request management data Dq used in this modified example. In the allocation request management data Dq of this modified example, for each robot H (first robot Hk1) that has transmitted the destination floor Fy, the robot information Ph of that robot H, the departure floor Fc, the destination floor Fd, and the status flag Pw are recorded in a mutually associated state.

[0069] The status flag Pw associated with each first robot Hk1 is a flag indicating whether an allocation request for that first robot Hk1 should be sent to the group management control device 2, or whether the allocation request should be put on hold without being sent. In this embodiment, the status flag Pw associated with each first robot Hk1 is set to "0" if the allocation request should be sent (see FIGS. 12(A) and 14(D)), and is set to "1" if the allocation request should be put on hold without being sent (see FIG. 14(C)).

[0070] As a result, the robot management device 1 can refer to the allocation request management data Dq at any time to check which robot H is scheduled to move between floors at that time, which floors the robot H is scheduled to move from and to, and whether the allocation request for the robot H has already been sent or is on hold.

[0071] 12(B) is a conceptual diagram illustrating the hall call management data Dx used in this modified example. In the hall call management data Dx of this modified example, for each allocation request for a robot H received by the group management control device 2, the robot information Ph of that robot H, the departure floor Fc, the destination floor Fd, and the allocation destination information Py are recorded in a mutually associated state.

[0072] <Control process executed in elevator> Fig. 13 is a flowchart showing the allocation request process executed in this modified example. When the allocation request process is started in this modified example, the robot management device 1 first uses the robot information Ph in the received information Pr1 to create a recording location in the allocation request management data Dq in association with the robot information Ph so that various information (departure floor Fc, destination floor Fd, status flag Pw) about the robot H identified by that information (here, this robot H will be referred to as the "first robot Hk1") can be input (step S110; see Fig. 14(A)). Fig. 14(A) shows the state immediately after the recording location is created in step S110 (a state in which various information other than the robot information Ph has not yet been input).

[0073] Thereafter, the robot management device 1 uses the robot information Ph of the first robot Hk1 to extract the current floor Fx associated with the robot information Ph from the robot management data Dp, and records it as the departure floor Fc for the first robot Hk1 in the assignment request management data Dq (step S111, see FIG. 14(B)). In step S111, the robot management device 1 also records the destination floor Fy in the received information Pr1 in the assignment request management data Dq as the destination floor Fd for the first robot Hk1, and sets the status flag Pw for the first robot Hk1 to the initial state (Pw="0") (see FIG. 14(B)).

[0074] After step S111, the robot management device 1 determines whether a robot H (second robot Hk2) other than the first robot Hk1 is deployed at the destination floor Fy of the first robot Hk1 at that time (step S112). Specifically, the robot management device 1 determines whether robot information Ph is recorded in deployment information Pz associated with the same floor as the destination floor Fy by referring to the robot deployment data Dr (FIG. 3(B)).

[0075] If the robot management device 1 determines "deployed (Yes)" in step S112, it can determine that if the first robot Hk1 were to be moved to the destination floor Fy based on that determination, the number of robots H deployed on the destination floor Fy would be multiple (two or more). In this case, the robot management device 1 places the allocation request for the first robot Hk1 on hold without sending it to the group management control device 2 (step S120). Specifically, the group management control device 2 changes the setting of the status flag Pw for the first robot Hk1 in the allocation request management data Dq from Pw="0" to Pw="1" (see FIG. 14(C)) without sending an allocation request for the first robot Hk1. As a result, the first robot Hk1 is restricted from moving between floors and is placed in a standby state on the current floor Fx.

[0076] After step S120, the robot management device 1 determines whether the second robot Hk2 is no longer deployed on the destination floor Fy in order to time the inter-floor movement of the first robot Hk1 (step S121). Specifically, the robot management device 1 determines whether the record of robot information Ph (specifically, the robot information Ph of the second robot Hk2) has been deleted from the deployment information Pz associated with the same floor as the destination floor Fy by referring to the robot deployment data Dr. The robot management device 1 then repeatedly executes step S121 until it can determine "deployment is no longer available (Yes)" in step S121 (for example, until the deployment situation changes from FIG. 7(A) to FIG. 7(B)).

[0077] If the robot management device 1 determines in step S121 that "there are no more robots deployed (Yes)," then it can determine that even if the first robot Hk1 is moved to the destination floor Fy, there will no longer be multiple robots H deployed on the destination floor Fy (two or more robots). In this case, the robot management device 1 releases the hold state for the allocation request for the first robot Hk1 (step S122). Specifically, the robot management device 1 changes the setting of the status flag Pw for the first robot Hk1 back from Pw="1" to Pw="0" in the allocation request management data Dq (see FIG. 14(D)).

[0078] Then, the robot management device 1 makes an allocation request for the first robot Hk1 by transmitting the current floor Fx and destination floor Fy of the first robot Hk1, which are recorded as the departure floor Fc and destination floor Fd in the allocation request management data Dq, to ​​the group management control device 2 (step S130). At this time, the robot management device 1 also transmits the robot information Ph of the first robot Hk1 to the group management control device 2 so that the group management control device 2 knows which robot H the transmitted allocation request is for. Thereafter, the robot management device 1 ends the allocation request process.

[0079] On the other hand, if the robot management device 1 determines "not deployed (No)" in step S112, it can determine at that point that even if the first robot Hk1 is moved to the destination floor Fy, the number of robots H deployed on the destination floor Fy will not be multiple (two or more). In this case, the robot management device 1 proceeds to step S130 and transmits the allocation request without putting the allocation request for the first robot Hk1 on hold (without executing steps S120 to S122).

[0080] FIG. 15 is a flowchart showing the allocation process executed in this modified example. When the allocation process starts in this modified example, the group management control device 2 executes allocation in response to the allocation request transmitted from the robot management device 1 (step S230). Specifically, the group management control device 2 executes allocation to the car G by treating the departure floor Fc and destination floor Fd in the received information Pr2 as one hall call X. Furthermore, the group management control device 2 records the robot information Ph (robot information Ph in the received information Pr2) of the first robot Hk1 that performed the allocation, the departure floor Fc and destination floor Fd indicated by the hall call X of the first robot Hk1 at that time, and the car information Pg of the car G to which it is assigned in a mutually associated state in the hall call management data Dx (see FIG. 12(B)). Thereafter, the group management control device 2 terminates the allocation process.

[0081] According to the third modified example, it is also possible to control the timing of moving the first robot Hk1 between floors so that the number of robots H deployed on any floor of the elevator is not more than one (two or more) (so that the number of robots H deployed is at most one). As a result, it is possible to prevent the robots H from falling into a deadlock state on any floor of the elevator.

[0082] [2-4] Fourth Variation In any of the above-described embodiments and variants, if multiple robots H attempt to move to the same floor and as a result all allocation requests for those robots H are put on hold, the above-described control process may be controlled so that the hold state is released (so that the status flag Pf or Pw returns from "1" to "0") in the order in which the robots H request inter-floor movement to the robot management device 1 (the order in which the destination floors Fy are sent).

[0083] [2-5] Fifth variant In any of the above-described embodiments and modifications, the control processing executed by the control system (the allocation request processing performed by the robot management device 1 and the allocation processing performed by the group management control device 2) can also be applied to an elevator equipped with only one car G. In this case, the elevator control device that controls the one car G will perform the allocation processing in cooperation with the robot management device 1 instead of the group management control device 2.

[0084] [2-6] Sixth Variation In any of the above-described embodiments and modifications, each robot H may be appropriately modified to execute the control processing (including allocation request processing) performed by the robot management device 1 in place of the robot management device 1. In this case, each robot H will communicate with the group management control device 2 (or elevator control device) without going through the robot management device 1. This allows each robot H to use the elevator while autonomously cooperating with the group management control device 2 (or elevator control device), and to move between floors in the elevator without falling into a deadlock state at each floor.

[0085] The above-described embodiments and modifications should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined not by the above-described embodiments and modifications, but by the claims. Furthermore, the scope of the present invention is intended to include all modifications that are equivalent to the scope of the claims and fall within the scope thereof.

[0086] Furthermore, from the above-described embodiments and modifications, the subject matter of the invention is not limited to the elevator control system, but may also include the control processes executed by the control system (including the corresponding control methods), the devices constituting the control system (robot management device 1, group management control device 2, etc.), and even the control processes executed by each device (including the corresponding control methods) and programs, etc. Furthermore, part or all of the configuration of an elevator to which a control system is applied may also be extracted as the subject matter of the invention. [Explanation of symbols]

[0087] 1. Robot management device 2 Group management control device G car H Robot X Platform call 11, 21 Storage section 12, 22 Control section DP Robot Management Data Dq Allocation request management data Dr. Robot Deployment Data Dx Hall call management data Fc Departure Floor Fd Destination floor Fk target floor Fx current floor Fy Destination Floor Pf status flag Pg Basket Information Ph Robot Information Pw Status Flags Py assignee information Pz deployment information Hk1 1st Robot Hk2 2nd Robot Pr1, Pr2 received information

Claims

1. an elevator control device; a robot management device that, when a first robot is moved between floors using the elevator, issues an allocation request for the first robot by transmitting a departure floor and a destination floor of the first robot to the control device; Equipped with The control device When an allocation request for the first robot is received from the robot management device, the allocation request is treated as a target request, and the destination floor transmitted in the allocation request is treated as a target floor, and a determination (A) is made as to whether a second robot other than the first robot is deployed on the target floor; If it is determined in the determination (A) that the second robot is deployed, the target request is put on hold without executing the allocation according to the request, and then a determination (B) is made as to whether the second robot is no longer deployed on the target floor; When it is determined in the judgment (B) that the second robot is no longer deployed, the elevator control system releases the hold state for the target request and executes allocation according to the request.

2. 2. The elevator control system of claim 1, wherein in the judgment (B), the control device judges whether an allocation request for the second robot, in which the target floor is the departure floor, has been received from the robot management device, and if it is determined that such an allocation request for the second robot has been received, it determines that the second robot will no longer be deployed on the target floor.

3. 2. The elevator control system of claim 1, wherein, when the allocation request for the first robot is in a pending state, the robot management device makes an allocation request for the second robot as a new, separate first robot to the control device, and the control device must also put the allocation request for the new, separate first robot in a pending state, thereby causing a chain of pending states. Furthermore, if at least a part of the chain of pending states forms a loop, the control device releases all of the pending states for the part of the chain that forms the loop.

4. a control device for an elevator that can cooperate with a robot management device that, when using an elevator to move a first robot between floors, issues an allocation request for the first robot by transmitting a departure floor and a destination floor of the first robot; When an allocation request for the first robot is received from the robot management device, the allocation request is treated as a target request, and the destination floor transmitted in the allocation request is treated as a target floor, and a determination (A) is made as to whether a second robot other than the first robot is deployed on the target floor; If it is determined in the determination (A) that the second robot is deployed, the target request is put on hold without executing the allocation according to the request, and then a determination (B) is made as to whether the second robot is no longer deployed on the target floor; When it is determined in the judgment (B) that the second robot is no longer deployed, the elevator control device releases the hold state for the target request and executes allocation according to the request.

5. When a first robot is moved from a current floor to a destination floor using an elevator, a determination is made (A) as to whether a second robot other than the first robot is deployed on the destination floor; If it is determined in the determination (A) that the second robot is deployed, the allocation request for the first robot is put on hold without being sent to the elevator control device, and then a determination (B) is made as to whether the second robot is no longer deployed at the destination floor; A robot management method in which, if it is determined in the judgment (B) that the second robot is no longer deployed, the allocation request for the first robot is released from the pending state and sent to the elevator control device.

6. When using an elevator to move from a current floor to a destination floor, a determination is made as to whether or not a robot other than the robot itself is deployed on the destination floor (A); If it is determined in the determination (A) that the other robot is deployed, the allocation request for itself is put on hold without being sent to the elevator control device, and then a determination (B) is made as to whether the other robot is no longer deployed at the destination floor; If it is determined in the determination (B) that the deployment of the other robot has been eliminated, the robot releases the hold state of its own allocation request and transmits it to the elevator control device.

Images