Traffic separation method for agents operating in shared areas

Abstract

The present disclosure relates to a computer-implemented method by a data-processing device for operating an agent within a fleet management environment. The method may comprise a step of receiving a request for entering a target region within the fleet management environment from the agent. The method may receive a step of determining whether a second agent is within the target region. The method may comprise a step of transmitting to the agent a grant for accessing the target region if no second agent is within the target region or a deny for accessing the target region if the second agent is within the target region. In addition, a computer-implemented method for operating an agent within a fleet management environment, a computer-implemented method for operating assistance within a fleet management environment, as well as corresponding data processing system(s) and computer program(s) are disclosed.

Description

[0001] Traffic separation method for agents operating in shared areas

[0002] Field of the invention

[0003] The present disclosure relates to a computer-implemented method by a data- processing device for operating an agent within a fleet management environment, to a computer-implemented method for operating an agent within a fleet management environment, to a computer-implemented method for operating assistance within a fleet management environment, and to corresponding data processing systems and computer programs.

[0004] Background

[0005] Nowadays, agents, such as autonomous mobile robots (AMRs), are commonly used for providing a variety of services. One use case are fulfillment centers or other industrial facilities in which the agent operates together with other agents or workers.

[0006] This collaboration requires specific mechanisms ensuring optimal traffic flow while avoiding congestions, accidents, hazards to the workers within the environment or other negative effects on their work.

[0007] For this purpose, known systems use a lock and release system. If an agent wants to enter a certain area within the environment, the agent requests the lock for the certain area from a central master unit. The central master unit is responsible for the entire fleet management. Upon receiving a corresponding request for a lock from an agent, the central master unit checks in a central database if the corresponding region is currently locked by another agent and decides whether the agent receives the lock for the region or whether it must wait until the region is no longer locked.

[0008] However, these centralized approaches suffer from several drawbacks. As the wireless connection in the mentioned environments is often not continuous, agent requests can get lost or can be delayed. The same applies to the corresponding response of the central master unit as well as to the central database updates. This results in suboptimal fleet management. Against this background, there is a need for providing improved methods and systems for operating an agent within a fleet management environment, which overcome the above-identified drawbacks.

[0009] Summary of the invention

[0010] The above-mentioned problem is at least partly solved by a computer-implemented method according to claims 1, 12 and 19, by an apparatus according to claim 26, and by a computer program according to claim 27.

[0011] An aspect of the present disclosure relates to a computer-implemented method by a data-processing device for operating an agent within a fleet management environment. The method may comprise a step of receiving a request for entering a target region within the fleet management environment from the agent. The method may further comprise a step of determining whether a second agent is within the target region. The method may further comprise a step of transmitting to the agent a grant for accessing the target region if no second agent is within the target region or a deny for accessing the target region if the second agent is within the target region.

[0012] This way operation within the fleet management environment is improved as agents are only able to enter certain target regions if they are accessible. The data-processing device may be remote (e.g., on a central server) or part of the agent (e.g., if a decentralized system is implemented). The agent maybe a human-operated vehicle or a robot. If the agent refers to a human-operated vehicle, the request may be triggered via a graphical user interface (GUI) input. If the agent refers to a robot, the request may relate to an application programming interface (API) request triggered based on path and / or task planning of the robot. In case of a grant, the target region (e.g., access to the target region) may be locked.

[0013] In another aspect, determining whether the second agent is within the target region may comprise a step of accessing a data source comprising information about an operating state of the target region, wherein the operating state indicates whether the second agent is within the target region or whether no second agent is within the target region. The method may further comprise a step of determining whether the second agent is within the target region according to the accessed information about the operating state of the target region.

[0014] The data source may relate to central database or a representation of the target region (e.g., comprising information about a state of the target region) stored on the data- processing device and / or or the agent. In another aspect, the method may further comprise a step of storing within the data source an updated operating state of the target region, wherein the updated operating state indicates whether the second agent or the agent is within the target region.

[0015] This way it is ensured that future decisions about whether access can be granted are made based on an updated data basis.

[0016] In another aspect, determining whether the second agent is within the target region may comprise a step of transmitting a first notification to a plurality of third agents about the request for entering the target region. The method may further comprise a step of receiving from at least a subset of the plurality of third agents information about an operating state of the target region. The method may further comprise a step of determining whether the second agent is within the target region according to the received information about the operating state of the target region.

[0017] In another aspect, the received information may comprise an indication from each third agent of the at least subset of the plurality of third agents, about the operating state of the target region. The operating state may indicate whether the second agent is within the target region or whether no second agent is within the target region. The method may further comprise a step of evaluating each indication about the operating state of the target region. The method may further comprise a step of determining whether the second agent is within the target region based on the evaluating.

[0018] This way, other agents within the environment are consulted whether the target region is accessible or not, resulting in increased reliability of the decision-making.

[0019] In another aspect, an agent within the subset of the plurality of third agents may fulfill one or more location conditions and / or one or more communication conditions.

[0020] In another aspect, the one or more location conditions may comprise at least a predefined distance to the target region and / or a predefined area around the target region.

[0021] In another aspect, the one or more communication conditions may comprise at least a latency of response associated with the first notification and / or a time of a latest heartbeat of the agent.

[0022] This way, only relevant agents (e.g., with respect to their position) or reliable agents (e.g., with stable communication conditions) are consulted for the decision-making. In another aspect, the method may further comprise a step of transmitting a second notification to the plurality of third agents about the grant or the deny transmitted to the agent.

[0023] This way, the other agents are kept informed about the state of the corresponding target region. This may allow the agents to update their respective data source comprising information about the operating state of the target region.

[0024] In another aspect in which the deny is transmitted, the method may further comprise a step of determining a queue position of the agent within a queue of agents, wherein each agent of the queue of agents requested access to the target region. The method may further comprise a step of transmitting the queue comprising the agent at the determined queue position to the agent.

[0025] This way, the agent requesting the access knows how long it may take for him to be able to access the target region. Accordingly, replanning (e.g., with respect to tasks) can be efficiently conducted.

[0026] In another aspect, determining the queue position of the agent may be based on at least one of: a type of the agent, a location of the agent within the fleet management environment, a size of the agent, a battery level of the agent or any combination thereof.

[0027] This way, prioritizing of agents within the queue based on these characteristics is enabled. For example, an agent with low battery level maybe prioritized (i.e., placed in a front position within the queue compared to an agent with a high battery level).

[0028] An aspect of the present disclosure relates to a computer-implemented method for operating an agent within a fleet management environment. The method may comprise a step of transmitting a request for entering a target region within the fleet management environment to a data-processing device. The method may comprise a step of receiving from the data processing device a grant for accessing the target region indicating that no second agent is within the target region or a deny for accessing the target region indicating that a second agent is within the target region. The method may comprise a step of operating the agent based on the grant or deny for accessing the target region.

[0029] This way operation within the fleet management environment is improved as agents are only able to enter certain target regions if they are accessible. In another aspect in which the grant is received, operating the agent based on the grant may comprise a step of entering the target region. The method may comprise a step of transmitting a signal indicating presence of the agent within the target region to the data-processing device. Additionally or alternatively, the method may comprise a step of transmitting a signal indicating leaving of the target region by the agent to the data- processing device.

[0030] This way, awareness of other entities within the environment (e.g., other agents or pedestrians) about the agent being within the target region is ensured.

[0031] In another aspect in which the deny is received, operating the agent based on the deny may comprise a step of receiving a queue comprising the agent at a determined queue position for the agent. The method may comprise a step of determining at least in part on the queue position for the agent, to queue for entering the target region or to move to another target region.

[0032] This way, the agent requesting the access knows how long it may take for him to be able to access the target region. Accordingly, replanning (e.g., with respect to tasks) can be efficiently conducted.

[0033] In another aspect, the method may further comprise a step of determining, prior to transmitting the request, that the target region is part of an intended trajectory of the agent. The method may further comprise a step of decreasing a movement speed of the agent.

[0034] This way, if the agents determines that he must pass through the target region, the request can be transmitted in advance such that no waiting (i.e., stopping) is required. In order to avoid stopping, the movement speed of the agent maybe decreased (e.g., if the request cannot be transmitted sufficiently in advance).

[0035] In another aspect, the target region as described herein may be a static region within the fleet management environment or a dynamic region within the fleet management environment.

[0036] This way, one the one hand static regions (e.g., intersections) can be modeled in which access needs to be controlled. On the other hand, traffic separation using dynamic target regions is enabled.

[0037] In another aspect in which the target region is a static region, the method may further comprise a step of determining, prior to transmitting the request, that a current position of the agent or a future position of the agent is within the target region. The method may further comprise a step of adjusting movement of the agent.

[0038] This way, if the agents determines that he must pass through the target region, the request can be transmitted in advance such that no waiting (i.e., stopping) is required. In order to avoid stopping, the movement of the agent maybe adjusted (e.g., increase or decrease the movement speed).

[0039] In another aspect in which the target region is a dynamic region, the method may further comprise a step of determining, prior to transmitting the request, that a current position of the agent or a future position of the agent is within the target region. The method may further comprise a stepof adjusting a movement speed of the agent such that a distance between a location of the agent and the target region stays constant.

[0040] This way, traffic separation can be efficiently implemented using the same concept of static target regions. Thus, computational overhead is reduced.

[0041] An aspect of the present disclosure relates to a computer-implemented method for operating assistance within a fleet management environment. The method may comprise a step of displaying on a graphical user interface (GUI) a current state of the fleet management environment and one or more target regions within the fleet management environment. Each target region may be associated with an operating state. The operating state may indicate whether an agent is within the target region or whether no agent is within the target region. Displaying of the target region may be based on the corresponding operating state. The method may comprise a step of receiving, via the GUI, an input command for modifying a target region and / or an operating state of the target region. The method may comprise a step of updating the GUI displaying the fleet management environment and the one or more target regions within the fleet management environment according to the input command.

[0042] This way, an intuitive way of assisting a user managing the fleet is provided.

[0043] In another aspect, the input command may comprise a request for modifying the operating state of the target region to indicate that an agent is within the target region and / or a request for modifying the operating state of the target region to indicate that no agent is within the target region.

[0044] This way, a user is able to, for example, reset an operating state of the target region or reserve the target region for himself. In another aspect, the input command may additionally or alternatively comprise a request for modifying a size, a location, a shape or any combination thereof of the target region, and / or a request for deleting the target region from the fleet management environment and / or a request for adding a new target region to the one or more target regions within the fleet management environment.

[0045] This way, the user is able to easily apply modifications within the fleet management environment. For example, if a target region does not longer exist it can be easily deleted via the corresponding input command.

[0046] In another aspect, the method may further comprise a step of displaying, on the GUI, agent information of the fleet management environment. The agent information may comprise for each agent of one or more agents a current location of the agent, a current task of the agent, a set of future tasks of the agent, an intended trajectory of the agent, one or more requests of the agent for entering one or more target region, a queue position of the agent within a queue for entering a target region, timing information associated with a heartbeat of the agent, information about a target region in which the agent is or any combination thereof.

[0047] This way, an overview of all agents within the environment is presented which provides for an efficient way of identifying potential issues with respect to the fleet management.

[0048] In another aspect, the method may further comprise a step of displaying, on the GUI, for each target region of the one or more target regions, a queue of agents waiting for entering the target region.

[0049] This way, an overview of all target regions within the environment is presented which provides for an efficient way of identifying potential issues with respect to the fleet management.

[0050] In another aspect, the input command may further comprise at least for one target region of the one or more target regions, a reordered queue of agents waiting for entering the at least one target region.

[0051] This way, the user has the option to intervene and reorder the queue according to the user’s desire. For example, if the user him- or herself wants to enter a target region, the user might reorder the queue such that the user’s position is up front.

[0052] In another aspect, the method may further comprise a step of obtaining information about a new state of the fleet management environment. The method may further comprise a step of updating the GUI displaying the current state of the fleet management environment and the one or more target regions within the fleet management environment according to the information about the new state of the fleet management environment.

[0053] This way, the overview given by the GUI is kept updated which avoids delays in the fleet management.

[0054] An aspect of the present disclosure relates to a data-processing system or apparatus comprising means for performing the one or more methods of any one of the aspects described herein.

[0055] An aspect of the present disclosure relates a computer program comprising instructions, which when executed by a computer, cause the computer to perform the one or more methods of any one of the aspects described herein.

[0056] Brief description of the drawings

[0057] Various aspects of the present invention are described in more detail in the following by reference to the accompanying figures without the present invention being limited to the embodiments of these figures.

[0058] Fig. i illustrates an exemplaiy overview of a fleet management environment comprising a plurality of target regions according to aspects of the present disclosure.

[0059] Fig. 2 illustrates an exemplaiy graphical user interface according to aspects of the present disclosure.

[0060] Fig. 3a and Fig. 3b illustrate an exemplary overview of static and dynamic target regions according to aspects of the present disclosure.

[0061] Fig. 4 illustrates an exemplary graphical user interface according to aspects of the present disclosure.

[0062] Detailed description

[0063] In the following, aspects of the present invention are described in more detail. Fig. 1 illustrates an exemplary overview of a fleet management environment 100 comprising a plurality of target regions iO5a-c according to aspects of the present disclosure. In the illustrated example, a fleet management environment is presented in which target regions are implemented as mutex areas. The lines no represent agent paths and path constraints. When argents are forced to use such paths, dynamic mutex areas around agents (i.e. , dynamic target regions) may help to create traffic separation. The rectangles and triangles are polygons representing static mutex areas (i.e., static target regions). When agents follow a path and are about to intersect with a Static mutex area, they request permission from the fleet management system to get exclusive access to these areas. They may ask during movement (e.g., before entering the target region, which may be determined based on whether a future position of the agent is within the target region) and receive it in time in order not to have to stop. The presented color scheme may represent a state or a type of the target region (e.g., the mutex area).

[0064] In an example, fleet traffic management works by enforcing certain traffic patterns such as fixed trajectories in corridors, traffic separation in highways, and controlled areas of potential traffic conflict. Traffic conflict occurs in certain areas such as junctions, charging stations, pickup / drop off areas, doors, corridors and queues. These are areas where agents may come from different directions but where only one is allowed to operate at a given moment. There are several ways of controlling agent behavior around these areas of contention, for example, a city traffic light, an airplane runway or railway lane-change or a shared shower with a single key.

[0065] The concept underlying the method(s) of the present disclosure may assume that agents rely on data communication protocols for traffic management. When an agent reaches a traffic-controlled area (i.e., a target region such as a mutex area), the agent needs to request permission in order to get exclusive right to pass through or operate- within the area. If permission is not granted then the agent needs to stop and wait until it is granted, possibly entering a queue.

[0066] A mutual exclusion object (mutex) is a program object that allows multiple programs on one computer or across a network to share the same resource, such as file write access, but not simultaneously. A mutex is created with a unique name and any program or thread that needs the resource must lock the mutex to ensure no one else is using that resource at the same time. The mutex is unlocked when the program doesn’t need that resource any more. In some cases, the locking program also sets an autounlock timeout so that if it dies prematurely, the mutex is unlocked automatically after a period of time. In some cases, the mutex provides a queue of pending lock requests and is able to prioritize these requests and assign the lock to the next entity on the queue.

[0067] There are two main frameworks for ensuring that exclusive access is granted: Centralized (master) and decentralized (master-less). The master framework typically requires a central database, whereas the master-less doesn’t. The method(s) of the present disclosure may be implemented in a centralized or, preferably, in a decentralized manner. In the centralized manner, the computer-implemented method by a data-processing device for operating an agent within a fleet management environment according to the aspects of the present disclosure may be executed by the data-processing device, which is part of a central master. In the centralized manner, the computer-implemented method for operating an agent within a fleet management environment may be executed by the agent. In the decentralized manner, the computer-implemented method by a data-processing device for operating an agent within a fleet management environment according to the aspects of the present disclosure maybe executed by the data-processing device which is part of an agent. This way no central master system is required. In the decentralized manner, the computer-implemented method for operating an agent within a fleet management environment may be executed by the agent.

[0068] Distributed / decentralized traffic management requires the state of all mutexes to be synchronized by all / multiple agents in the fleet. Better resilience to outages in wireless communication is achieved when synchronizing the states using “consensus” algorithms such as Paxos and Raft for synchronizing mutexes, queues and priorities.

[0069] The decentralized fleet management methodology allows the agent to be more independent and less frequently reliant on WiFi (or other wireless communication technology) to make motion planning decisions. All state information from fleet members is broadcast to all fleet members who maintain a copy of the state of the entire fleet. As a result, every fleet member can calculate their own optimal plan. It also has the advantage that as the fleet grows, there is no need to scale the central master database computer because all intense calculations are made on every agent individually. Exclusive access is granted through a communication protocol over WiFi (or based on other wireless communication technology) and all agents must abide by expected behavior (in some cases, the framework can tolerate human agents that misbehave and don’t follow the rules all the time).

[0070] Mutex area geometry

[0071] Fig. 1 showing the map and in turn in the physical world, whereas polygons describe the mutex areas. These polygons can also be associated with a moving agent. The agent continuously checks if its position is on definitive collision course with all mutex areas or has penetrated or exited one. This methodology facilitates two distinct use-cases: static mutex area is predefined (e.g., using a GUI as illustrated in Figs. 2 and 4), representing an area on the map and in a physical location. It serves to define exclusive use areas. When an agent approaches or penetrates a mutex area, it first tries to lock the mutex to ensure there are no other agents operating there. If the mutex area is not available, the agent will stop and wait. It may enter a queue of agents waiting to get the exclusive use or may decide to go somewhere else. Static mutex areas may overlap. This usually happens when editing the polygons with different use-cases, in close proximity. This overlapping does not have any adverse effect or demands special considerations for the various mechanisms discussed herein.

[0072] A dynamic mutex area is an area around a mobile robot / agent that helps create queues. As with static mutex areas, when an agent discovers that it is on collision course or has penetrated a dynamic mutex area, it asks permission to enter. However, unlike static mutex areas, the agent will never be granted the lock. It will never be allowed to enter a dynamic mutex area. Since the dynamic mutex area moves where the agent moves, a second agent that was denied permission to enter, will suddenly discover that the mutex area is no longer where it was and therefore does not have to stop. When agents follow a specified path, they move one behind the other at potentially different speeds. Through the mechanism of exclusive area around the agent, that is always denied entrance, another agent can never get any closer than the predefined polygon, and since both agents are on the same trajectory, this creates the effect of highway separation and waiting queues. Another advantage of the dynamic mutex area mechanism is that it helps agents to know that they are supposed to queue behind another agent rather than attempt obstacle bypass or that they are blocked by an unsurpassable obstacle for too long. When an agent encounters an obstacle, it usually stops or attempts to bypass it. It can also create an alert for human intervention or decide to go somewhere else. In any case, there needs to be a way for a robot to know that an obstacle blocking its path is another agent because the consequent behavior should be different. For example, if it is another robot waiting for a mutex or stuck, then the agent should not execute an obstacle bypass maneuver and should queue up on a given path and wait

[0073] Inside the agent’s / robot’s computer during operations, an algorithm cross-checks these mutex areas against the robot's own position. When the robot realizes it is about to penetrate the area or has already penetrated the area, by matching his own coordinate with the polygon’s contour coordinates, it will attempt to lock the associated mutex.

[0074] Mutex areas mechanism

[0075] The mutex areas mechanism can be realized by requesting (acquiring) the mutex lock from the remote central server (master - typically some kind of database). If the lock is successful, the master will keep time and identification (ID) of the robot that locked the given mutex area. The database must ensure through techniques such as having a single threaded change-request queue, that parallel change requests can’t cause race conditions and ambiguity. There are several issues with having a central database. For example, if the WiFi network is not continuous along the path of the agent, when it requests the mutex lock, the software can wait for a long time for a response, not knowing if the reason for the untimely response is bad WiFi or a server failure. In turn it can’t decide whether to enter the mutex area or not and the agent will typically wait until it gets a definitive answer.

[0076] The mutex areas mechanism can be done by requesting (acquiring) the mutex lock in a master-less framework. It requires consensus consent of the majority of fleet members. There are several known algorithms to manage the consensus edge cases. Each agent keeps a copy of the state of the mutex areas that gets updated by requests and consents of all members of the fleet. All requests and replies are broadcast for everyone to hear. The distributed consensus state replication algorithms guarantee that each robot has an updated state of all mutexes and all participating agents when it needs to make relevant decisions. Consensus implies that the majority of robots approve the locking of the mutex areas.

[0077] An inventive improvement on standard consensus algorithms is that each robot continuously gets position updates (part of the State of the agents) from the robot fleet members every few seconds, therefore it can dismiss automatically the risk of mutex infringement by robots that are not likely to be in the vicinity of a target mutex area.

[0078] Mutex area queue and priority

[0079] When multiple fleet members request exclusive access to a static mutex area such as a traffic junction, these requests can be entered into a queue. The optional queue is implemented as part of the mutex mechanism. Usually, the request for the mutex exclusive right-of-use will be queued on a first-come first-served (same as FIFO; first in first out). When several fleet members are in the queue, one of them automatically gets assigned the mutex once it is released by the locking agent. The next agent in the queue that receives the lock can be according to the FIFO sequence or can be the one with the highest priority. Priority within a queue is defined either by a score function that regards parameters of the fleet member such as vehicle type, its location, size, batteiy level or it can be prioritized manually by the operator.

[0080] The requesting agent enters the queue and can inspect the queue. This can be helpful in decision making because if the queue is too big then maybe the agent can do something else rather than waiting in the queue. Alternatively, the operator can see that the queue is growing in the user interface (UI) and intervene to find out why this is happening and potentially identify an agent that has been too long inside the mutex area or change the paths and mutex areas using the UI to make the fleet more efficient.

[0081] Agent behavior as it approaches a mutex area

[0082] Agents typically follow a prescribed trajectory, usually overlaid and editable in the UI map. They may also dynamically compute their own navigation path to reach their destination, while avoiding obstacles. Agents continuously match their position and planned path against all mutex area polygons.

[0083] When an agent's planned path intersects with a mutex area, the agent adheres to the following behavior as it approaches mutex areas: - The agent can send the mutex request to the fleet management system before or as it enters the mutex area.

[0084] - Typically, it sends the request before entering, while moving, in order to not stop moving because every time the agent stops, it is inefficient for the fleet operation.

[0085] - If it doesn't get an answer in time before entering the mutex area, or gets a negative answer, then it stops.

[0086] - In such cases it should stop before entering the area or it should ensure it enters the area with minimal penetration depth. Typically, the agent’s estimation of its own location on the map (localization), may carry an error, so the extent of the possible localization error is considered in order to ensure it doesn’t actually enter the mutex area that could potentially interfere with another agent’s operation inside it.

[0087] - If the localization of individual agents is known to have imprecision, another approach is to increase the mutex area in order to prevent agents from accidentally penetrating them.

[0088] - If the mutex response doesn't come in time, the agent may slow down before its trajectory intersects with the mutex area - because slowing the agent’s motion is more efficient than stopping it.

[0089] Similarly, when an agent exists a mutex area, it must ensure that it is outside the area before informing the fleet that the area is available (unlocking the mutex)

[0090] Mutex area timeouts agents regularly send their state condition to the fleet management system (heartbeat). The purpose of this is to allow the operator to know if an agent has some fault that is preventing it from broadcasting.

[0091] The agent waits till it gets the lock. If the lock is not acquired by a given time, then the operator, using the UI can be notified and intervene. In such a case, if the operator knows that an agent had some malfunction in the mutex area and was moved away manually, the mutex may still remain locked although no other agent is operating in the mutex area. Therefore, the operator can manually release the mutex and allow another agent to gain exclusive access.

[0092] Another heuristics mechanism is having the lock automatically released after a given time. When this happens, another agent may lock the mutex area and operate within it. The agent who owns the lock, must therefore regularly refresh the lock time before it times-out. This operation requires the fleet management system to acknowledge and yield a positive reply. This is part of the heartbeat framework whereby each agent regularly informs the fleet management of its status. If the agent loses wireless communication while operating inside the mutex area, it will realize that it can not refresh the lock and therefore must evacuate the area because some other agent may have already locked it. In such a case, the operator will be notified in the UI about this event and may want to intervene and find the reason why an agent is not communicating. If a locking agent stops functioning and is stuck in the mutex area, there can be a case where a second agent will acquire the lock and enter the mutex area while the malfunctioning agent is still inside. The working agent may be blocked by the malfunctioning agent and this will appear in the UI as an error condition which may require human intervention.

[0093] In any case of mutex area lock timeouts or general agent heartbeat irregularity, there is usually human intervention to check what happened physically to the robot in order to verify that the robot is not stuck and there is no safety or operational efficiency risk.

[0094] Fig. 2GUI may allow operators of the automation flows and human drivers to work among the robots. The UI has the following features:

[0095] - Map 210 in 2D, 2.5D or 3D of the fleet management environment (e.g., a facility) showing the corridors of where the agents navigate surrounded by static fixtures such as walls.

[0096] - Curves 220 representing agent static path constraints: these must be followed to within certain precision by agents. They can intersect or pass through with mutex area polygons.

[0097] - The location of the fleet members / agents: They can be represented by icons 230 or animations of the actual machines. Their color and blinking can represent their heartbeat status or if they have been immobile for too long. Their dynamic mutex areas can be depicted by polygons that follow their locations.

[0098] - Static mutex areas 240: polygons representing the physical shape of that area. They can be edited and refined in the UI scene editor. Their colors, types of contour lines, and blinking can represent their state. Additional text information can show who is locking them, the queue of agents waiting to lock them. - Alerts: Issues concerning traffic can be seen in the UI with indication of how to mitigate the potential fault. For example, agents whose heart beat has stopped broadcasting can be seen in different colors than healthy agents (e.g., green for healthy and red for heartbeat has stopped), mutex locks that have not been refreshed and were timed-out recently can generate a text alert.

[0099] - The user can manually release a lock if the robot got stuck inside a mutex area or it is unresponsive. Usually this is done once the operator verifies that a robot is not stuck inside the mutex area and that there is no safety risk.

[0100] Mutex interaction for human forklift / vehicle driver

[0101] The GUI 200 can be used by forklifts or other human vehicle drivers for them to see where the robots / agents are on the map as well as interact with the system as they have to co-exist with the robots and share the same space and trajectories.

[0102] The UI for the human driver can have the following elements:

[0103] - A map of the facility showing where the robots are located including where they are inside mutex areas.

[0104] - Ability to notify the system if the forklift driver is available for work.

[0105] - The driver follows the same paths as the robots and stops before entering mutex areas.

[0106] - Ability to signal a request to enter mutex areas so that the Fleet Manager will give that exclusive right to the human or wait till the another agent is done in that area.

[0107] - The human driver signals in the UI when exiting the mutex area unless the vehicle has self-localization capabilities and the exit can be signaled automatically.

[0108] - The human driver indicates that the payload was successfully picked and dropped in addition to error conditions such as getting stuck.

[0109] Fig. 3a and Fig. 3b illustrate an exemplary overview 300 of static and dynamic target regions according to aspects of the present disclosure.

[0110] The dynamic mutex area 3ioa-b around an agent changes its position with the agent as it moves. The agent is not moving because the mutex area 33oa-b before him is locked. Pedestrian agents 32oa-b queueing up together with vehicle agents to enter the busy junction. Static mutex area 33oa-b at the junction. Only one fleet member can enter this area at a time. Traffic separation 34oa-b between agents queueing up is enforced with dynamic mutex areas 3ioa-b. Traffic separation 350a-b between vehicle agents along the highway path is enforced with dynamic mutex areas.

[0111] Fig. 4 illustrates an exemplary graphical user interface 400 according to aspects of the present disclosure. The GUI 400 maybe used by a human (e.g., a pallet truck driver) and shows what the agents / robots are doing. This way the human or operator can see if for example when an agent has stopped sending heartbeat messages (e.g., the icon representing the agent may change color or blink). The GUI 400 may also show information about the state of a mutex area (e.g., either continuously or on-demand by the operator). The operator may also intervene and change the queue priority for a given mutex area.

[0112] The GUI 400 shows a target region (e.g., mutex area) 410, a pallet robot 420 diagonally entering the (static) mutex area 410 where a platter resides. Only the robot 420 can engage with that pallet thanks to the mutex area mechanism. The GUI 400 also shows a robot with a corresponding dynamic target region 430 used for traffic separation. In addition, a robot / agent 440 is illustrated following a path moving away from a currently residing area and entering a new target region for maneuvering towards a pallet-drop area. The GUI 400 may allow a human / user to select a mutex area 410 (e.g., a spot where a pallet may have to be placed by the human) and to manually request locking of the corresponding mutex area to ensure that no robots / agents enter at the same time or request release of the lock (e.g., once the user is finished or if the user identified a robot without heartbeat locking the corresponding target region). The GUI 400 also ensures that a user can identify or see a robot pallet mover (e.g., the pallet robot 420 which is about to exit the corresponding target region and is thus locking adjacent mutex areas (e.g., the area 410) when moving out with the pallet payload. This way, the human driver knows that entering the area 410 is not allowed while it is indicated or highlighted as locked.

[0113] Terminology

[0114] Agent / fleet member - Collective term referring to AMR, AGV, pedestrians, human guided vehicles and other entities operating in the same facility while abiding more or less to traffic rules defined by the fleet management system. AGV - autonomous guided vehicle. Similar to AMR except that it follows prescribed paths.

[0115] AMR - autonomous mobile robot. It can follow paths that are not predetermined.

[0116] Centralized fleet management - A framework for fleet management system that runs on one or few computers. They consolidate all the share data by the fleet members and make all traffic decisions. They run a central database that maintains the state of the agents, mutexes and policy configuration.

[0117] Decentralized / distributed fleet management - A framework for fleet management that runs on all / most agents. They all broadcast and receive all shared data and each have a synchronized copy of the database containing agent state, mutexes and policy configuration.

[0118] Fleet management - A system that prescribes the activities of the fleet. In this context it refers to traffic optimization through the use of mutex areas, queues and priorities. Agents typically use wireless data communication to share relevant traffic information and act in accordance with the policies of the fleet management system.

[0119] Mutex area / target region - A physical space that should only be used by one fleet member or a limited group thereof, is represented by a mutex which is a software construct designed to enforce exclusive access through the concept of a lock whereby the key is only given to one entity can open it at any time. The mutex can provide a mechanism to manage a queue of pending lock requests. Which agent, if any, has exclusive use of that area is referred to as the operating state of the target region. A static region is a physical area in the operating environment, visible in the UI map. A dynamic region is an area around an agent that may move over time.

[0120] Operator - people working in the facility where the fleet is deployed who are in charge of monitoring, intervening and optimizing the fleet management system.

[0121] Priority - When multiple fleet members are in a queue, the queue can reflect a priority algorithm. Queue - When multiple fleet members request exclusive access to an area via mutex, they enter a queue (software construct extending the mutex).

[0122] Shared data / heartbeat / agent state - Agents regularly send information to the fleet management about their current state such as their position in the facility, velocity, intended path, mutex requests and releases. If an agent is currently locking a mutex area, they must regularly refresh the lock. This information is transmitted regularly and is kept up to date by receiving entities. The shared data acts as a heartbeat for the fleet manager and other agents to know when and where was the last time any agent broadcast its state data in the event that it suddenly stops sending data (erroneous situation requiring usually human intervention). The latest state data is sent by all agents and maintained in a centralized database or broadcast by all agents and maintained by all agents in a database.

[0123] UI / GUI - Graphical User Interface - allows human operators and humans driving vehicles working among the robots, to see the map of the facility, the location of the fleet members, the mutex areas, and alerts. Issues concerning traffic can be seen in the UI with indication of how to mitigate the fault. The policies and configuration of the fleet management system can be viewed and modified in the UI. This data and any changes reside in the fleet management database (centralized or distributed)

[0124] The methods according to the present invention may be implemented in terms of a computer program which may be executed on any suitable data processing device comprising means (e.g., a memory and one or more processors operatively coupled to the memoiy) being configured accordingly. The computer program may be stored as computer-executable instructions on a non-transitory computer-readable medium.

[0125] Embodiments of the present disclosure may be realized in any of various forms. For example, in some embodiments, the present invention may be realized as a computer- implemented method, a computer-readable memory medium, or a computer system.

[0126] In some embodiments, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, e.g., any of the method embodiments described herein, or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets. In some embodiments, a computing device may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memoiy medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets). The device may be realized in any of various forms.

[0127] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

[0128] The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. In particular, with reference to the appended claims, features from dependent claims maybe combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

Claims

Claims1. A computer-implemented method by a data-processing device for operating an agent within a fleet management environment, comprising: receiving a request for entering a target region within the fleet management environment from the agent; determining whether a second agent is within the target region; and transmitting to the agent: a grant for accessing the target region if no second agent is within the target region; or a deny for accessing the target region if the second agent is within the target region.

2. The method of claim 1, wherein determining whether the second agent is within the target region comprises: accessing a data source comprising information about an operating state of the target region, wherein the operating state indicates whether the second agent is within the target region or whether no second agent is within the target region and determining whether the second agent is within the target region according to the accessed information about the operating state of the target region.

3. The method of claim 2, further comprising: storing within the data source an updated operating state of the target region; wherein the updated operating state indicates whether the second agent or the agent is within the target region.

4. The method of claim 1, wherein determining whether the second agent is within the target region comprises: transmitting a first notification to a plurality of third agents about the request for entering the target region; receiving from at least a subset of the plurality of third agents information about an operating state of the target region; and determining whether the second agent is within the target region according to the received information about the operating state of the target region.

5. The method of claim 4, wherein the received information comprises an indication from each third agent of the at least a subset of the plurality of third agents about the operating state of the target region, wherein the operating state indicates whether the second agent is within the target region or whether no second agent is within the target region; and wherein the method further comprises: evaluating each indication about the operating state of the target region; and determining whether the second agent is within the target region based on the evaluating.

6. The method of claims 4-5, wherein an agent within the subset of the plurality of third agents fulfills one or more location conditions and / or one or more communication conditions.

7. The method of claim 6, wherein the one or more location conditions comprise at least: a predefined distance to the target region; and / ora predefined area around the target region.

8. The method of claims 6-7 wherein the one or more communication conditions comprise at least: a latency of response associated with the first notification; and / or a time of a latest heartbeat of the agent.

9. The method of claims 4-8, further comprising: transmitting a second notification to the plurality of third agents about the grant or the deny transmitted to the agent.

10. The method of claims 1-9, wherein the deny is transmitted and the method further comprises: determining a queue position of the agent within a queue of agents, wherein each agent of the queue of agents requested access to the target region; and transmitting the queue comprising the agent at the determined queue position to the agent.

11. The method of claim 10, wherein determining the queue position of the agent is based on at least one of: a type of the agent, a location of the agent within the fleet management environment, a size of the agent, a battery level of the agent or any combination thereof.

12. A computer-implemented method for operating an agent within a fleet management environment, comprising:transmitting a request for entering a target region within the fleet management environment to a data-processing device; receiving from the data processing device: a grant for accessing the target region indicating that no second agent is within the target region; or a deny for accessing the target region indicating that a second agent is within the target region; and operating the agent based on the grant or deny for accessing the target region.

13. The method of claim 12, wherein the grant is received and wherein operating the agent based on the grant comprises: entering the target region; transmitting a signal indicating presence of the agent within the target region to the data-processing device; and / or transmitting a signal indicating leaving of the target region by the agent to the data-processing device.

14. The method of claims 12-13, wherein the deny is received and wherein operating the agent based on the deny comprises: receiving a queue comprising the agent at a determined queue position for the agent; and determining at least in part on the queue position for the agent, to queue for entering the target region or to move to another target region.

15. The method of any one of the claims 12-14, further comprising: determining, prior to transmitting the request, that the target region is part of an intended trajectory of the agent; anddecreasing a movement speed of the agent.

16. The method of claims 1-15, wherein the target region is a static region within the fleet management environment; or a dynamic region within the fleet management environment.

17. The method of any one of the claim 16, wherein the target region is a static region and the method further comprising: determining, prior to transmitting the request, that a current position of the agent or a future position of the agent is within the target region; and adjusting movement of the agent.

18. The method of claim 16, wherein the target region is a dynamic region and the method further comprising: determining, prior to transmitting the request, that a current position of the agent or a future position of the agent is within the target region; and adjusting a movement speed of the agent such that a distance between a location of the agent and the target region stays constant.

19. A computer-implemented method for operating assistance within a fleet management environment, comprising: displaying on a graphical user interface, GUI, a current state of the fleet management environment and one or more target regions within the fleet management environment; wherein each target region is associated with an operating state, wherein the operating state indicates whether an agent is within the target region orwhether no agent is within the target region; wherein displaying of the target region is based on the corresponding operating state; receiving, via the GUI, an input command for modifying a target region and / or an operating state of the target region; and updating the GUI displaying the fleet management environment and the one or more target regions within the fleet management environment according to the input command.

20. The method of any one of the claim 19, wherein the input command comprises: a request for modifying the operating state of the target region to indicate that an agent is within the target region; or a request for modifying the operating state of the target region to indicate that no agent is within the target region.

21. The method of any one of the claims 19-20, wherein the input command comprises: a request for modifying a size, a location, a shape or any combination thereof of the target region; a request for deleting the target region from the fleet management environment; and / or a request for adding a new target region to the one or more target regions within the fleet management environment.

22. The method of any one of the claims 19-21 further comprising: displaying, on the GUI, agent information of the fleet management environment; wherein the agent information comprises for each agent of one or more agents: a current location of the agent, a current task of the agent, a set of future tasks of the agent, an intended trajectory of the agent, one or more requests of the agentfor entering one or more target region, a queue position of the agent within a queue for entering a target region, timing information associated with a heartbeat of the agent, information about a target region in which the agent is or any combination thereof.

23. The method of any one of the claims 19-22, further comprising: displaying, on the GUI, for each target region of the one or more target regions, a queue of agents waiting for entering the target region.

24. The method of claim 23, wherein the input command further comprises: at least for one target region of the one or more target regions, a reordered queue of agents waiting for entering the at least one target region.

25. The method of any one of the claims 19-24, further comprising: obtaining information about a new state of the fleet management environment; and updating the GUI displaying the current state of the fleet management environment and the one or more target regions within the fleet management environment according to the information about the new state of the fleet management environment.

26. A data-processing system comprising means for performing the one or more methods of any one of the claims 1-11, 12-18 and / or 19-25.

27. A computer program comprising instructions, which when executed by a computer, cause the computer to perform the one or more methods of any one of the claims 1-25.

Images