Autonomous vehicles are one of the greatest engineering challenges of our era. Since the first successful demonstrations in the late 80s [1
], great progress has been made in this field. However, achieving the highest level of autonomy (level 5 in the J3016 SAE document [3
]) involves overcoming many technical, social, and legal challenges [4
Driving decisions made by the vehicle control framework are based on the traffic situation and prior knowledge of the system. The traffic rules, street maps, and vehicle dynamics are among the prior knowledge of the system. The traffic situation is obtained by the perception system that includes observations from different on-board sensors (camera, sound navigation ranging (SONAR), Light Detection and Ranging (LIDAR), Global Positioning System (GPS), and odometry). The decisions can take the form of variables that control the vehicle’s motion.
These decision-making systems are usually implemented within four hierarchical components [5
Route planning: Computes the route through the road map to reach the goal.
Executive layer: Decides the high-level actions to follow the planned route according to the traffic rules. Since the driving process is a complex task that has to cope with many possible situations (stop, crosswalk, crossroad, overtaking, etc.), it is usually defined as a set of behaviors.
Motion planning: The actions commanded by the behaviors must be converted, in the end, into a trajectory that must serve as a reference to the vehicle control loop. The trajectory can be defined as a sequence of points or a sequence of motion controls, depending on the planner used.
Vehicle control: This controller selects the appropriate actuator inputs to carry out the planned trajectory. This module has to deal with the deviation errors when avoiding obstacles on the road.
The scope of this research takes in the executive layer and, in particular, the behavioral decision-making.
These systems are complex, so to support software development, the control framework will provide integration of loosely-coupled application software components to minimize covert interference [6
]. For example, the Robot Operating System (ROS) is one of the most popular open-source platforms providing a dynamic middleware with publisher/subscriber communication and a remote-procedure-call mechanism. The different modules in the control architecture implement the aforementioned functionalities. These modules implement basic actions and report events about their state by subscribing and publishing messages.
In this paper, we propose an implementation of the executive layer based on Petri nets (PNs) using the RoboGraph (RG) tool [7
]. PNs are a powerful tool to model, design, and analyze distributed, sequential, and concurrent systems [8
]. RG uses the middleware inter-process communication mechanisms to coordinate the actions in the rest of the modules to execute a behavior.
Using PNs provides several advantages when defining the traffic rules and building the executive layer in the autonomous car application. They include: Flexibility
, in which the traffic rules and behaviors are defined as PNs using the RG graphical user interface (GUI) [7
], and they can be modified without the need to change the code; Module abstraction
, which involves separating the modules interface with the PN from the implementation; Reduced development time
, in which behaviors are implemented as PNs; Easy maintenance
, which means tracing and debugging problems is easier when the system state can be seen by looking at the evolution of a PN rather than monitoring a set of variables; and Analysis and test
, in which PN properties also make them good candidates for qualitative (un-timed models) performance evaluation and quantitative (timed models) performance evaluation of the car behaviors. Significant research has been carried out in this area for industrial applications [8
] and also some in mobile robot tasks [10
The main contribution of this research is to provide a new approach to implement autonomous driving behaviors using a discrete event model framework. Unlike previous solutions, this approach integrates the model definition with the model verification, execution and monitoring using a framework based on PNs. The advantages of using this kind of framework include:
Behavior’s definition: A method to define the driving behaviors using message driving PNs. Traffic rules and behaviors are defined as PNs in a very intuitive and flexible way.
Formal verification: Using this PN model representation, the formal verification can be included as part of the normal software development cycle as described in [11
Monitoring: PNs include a graphical representation with tokens that model the state of the system. The inter-process communication messages can be used to update the tokens and to display the state of the system in real time.
Debugging: Many autonomous car software architectures, such as ROS, provide some way to store the inter-process communication messages. Those messages can be used later to represent the system state progress through the PNs.
The executive layer described here was implemented as part of the vehicle navigation system and applied to an autonomous car designed for elderly or disabled people described in [12
The rest of this paper is organized as follows. The next section introduces the work related to this research. Section 3
presents the control architecture used in our mobile robots. After an outline of the RoboGraph
tool in Section 4
, the description of the executive layer is summarized in Section 5
. Section 6
shows some examples of behaviors with the corresponding PNs. Results are presented in Section 7
. Section 8
concludes the paper.
2. Related Work
The behavioral decision-making system is the executive control layer that manages the sequence of actions and events that take place in each possible driving situation. The different driving situations or scenarios include overtaking, yield, stop, crosswalk, crossroad, and traffic lights. The decision-making module should include tools to define the traffic rules for each one of these scenarios. Furthermore, they should also provide a way to define the sequence of actions to execute in response to all possible events that can occur in each scenario. Different approaches have been proposed to implement the decision-making system. Some heuristic solutions [13
] are based on the concept of identifying the set of driving scenarios. To identify each one of these contexts, the vehicle will focus on a reduced set of environmental features.
One of the main challenges when implementing a decision-making system for autonomous driving is the complex interaction between the car and the environment. Even in the case of modeling all the possible states and situations, the uncertainty introduced by the perception system [14
] will include uncertainty to assess the current state of the vehicle and scenario. Furthermore, the presence of nearby external agents, such as other vehicles [15
] or pedestrians [16
], makes it especially challenging because their behavior is, in general, unpredictable.
Decision-making for autonomous driving is challenging due to uncertainty in the knowledge about the state of the vehicle and particularly the driving situation. This uncertainty comes from different sources, such as that introduced by the perception system [14
] and the observers. Especially challenging is to estimate the continuous state of nearby external agents, such as other vehicles [15
] or pedestrians [16
], since their behavior is, in general, unpredictable.
Research to improve decision performance can be focused on reduction of the uncertainty introduced by the observers or towards construction of a system that takes optimal decisions, assuming the noise information provided by the observers.
Improving the observers means providing accurate sensors and better detection and tracking methods. Much research has aimed to anticipate future intentions of other traffic agents [17
]. The solutions proposed range from deterministic models [18
] to different probabilistic models [19
], such as Kalman Filters (KF) [20
], Dynamic Bayesian Networks (DBN), and Hierarchical Dynamic Bayesian Networks (HDBN) [21
] or Gaussian Process (GP) regression [22
]. Most statistic observers provide observation with a probability value or a probability distribution. Modeling these distribution probabilities is not an easy task and many of the models mentioned use some kind of reinforcement to learn some parameters of the estimated model or even the driving styles of other vehicles.
To design an optimal decision system that takes into account uncertainty, Partially Observable Markov Decision Processes (POMDP) offer a theoretically grounded framework to capture the fact that the decision system does not know the underlying state of the system. Instead, the POMDP maintains a probability distribution over all of the states and makes the decision according to this distribution. The probability distribution is updated with the observations and the actions carried out according to the transition and observation probabilities that define the system model. Even though, in theory, the solution of a POMDP provides the optimal solution for the model given the previous observations and actions, solvers [23
] often have difficulty scaling computationally to real-world scenarios. Still, some approaches, such as that in [15
], consider only a finite set of a priori known policies to capture a different high-level behavior from the other traffic agents. POMDPs take into account both the uncertainty in observations and the uncertainty in the outcome of the actions. Building the POMDP model is not an easy task because it is necessary to define not only the states, actions, and transitions but also all the transition probabilities and rewards. Some of those parameters can be learned from experimental data using some reinforcement learning or deep learning techniques [24
]. A question remaining is to evaluate the performance of systems of this kind against other solutions, such as simpler finite state machines, where it is easier to model the traffic rules and change the model as the traffic rules are updated.
In theory, POMDP is a good framework for including uncertainty in the behavioral decision-making system. In practice, real-world scenarios are very complex with a large number of states, observations, and actions. Unfortunately, these kinds of POMDP models cannot scale to complex real-world scenarios. Instead, other approaches deal with uncertainty in the observers using some Bayesian model to estimate the state of the system and a simpler discrete event system to model the behaviors. Some popular solutions are hierarchical finite state machines [26
], finite state machines (FSM) [27
], and decision trees.
The Defense Advanced Research Projects Agency (DARPA) Urban Challenge [28
] contributed to the development of some of these technologies. The behavior generation component [29
] for the Tartan team (winning team) was implemented using a hierarchical finite-state machine. The main task (mission) is hierarchically decomposed into different behaviors. The top-level hierarchy behaviors are lane-driving, intersection handling, and achieving a pose [13
]. A similar hierarchical finite-state machine [27
] was used by the Standford University team that finished in second place. Thirteen states define the top-level hierarchy behaviors. The top-level behaviors of the California Institute of Technology include: road region, zone region, off-road, intersection, U-turn, failed, and paused. Ohio State University [30
] also chose an FSM for their car.
Even though FSMs can deal with relatively large problems, they need to explicitly define all states. In some situations, where it is necessary to define an action in small actions that can run in parallel or when a system can be divided in subsystems, the number of states grows exponentially. This is known as the state explosion problem, and that is one of the reasons why some researchers are considering Behaviors Trees (BT) instead [31
]. BTs provide a lot of flexibility and can be used to implement the behavioral layer architecture in autonomous driving [32
]. BTs are also easier to maintain and to expand [33
Another option to overcome the FSM state explosion problem is to use PNs. They have been used for different purposes in autonomous vehicles: evaluating the mission reliability [34
]; designing and modeling a cruise control system [35
]; modeling an intersection collision warning system [36
], and modeling the cooperation of a human driver and an automated system [37
]. On the other hand, in the approach presented in this paper, PNs are used to model the desired behavior of the vehicle in different traffic situations.
Several properties of PNs, such as concurrency, lead to simpler models that can deal with a large number of states compared with FSM. All of these properties come from the fact that the state of the system in a PN is represented by a set of tokens associated with places, while in a classical FSM every place represents a state. Therefore, in a PN using only a few places, a large number of states can be represented through a different combination of tokens. The problem of state-space explosion in PNs comes with the reachability analysis because somehow all the states need to be unfolded. To solve that problem, we use hierarchical PNs, as described in [11
]. The hierarchical interpreted PNs are used to model the behaviors for each driving situation or scenario. Additionally, a main PN defines the conditions to switch between the different behaviors. This main PN can start and stop other behaviors (PNs) whenever the driving situation changes. The PNs used here are binary, which means that the tokens associated with the places can only be one or zero. The hierarchy is used to break down the complexity of the model so that a PN can be started from another one. A full description of the reachability analysis of these hierarchical model is described in [11
Subsumption architecture has been extensively used at different levels in the autonomous robots field. The architecture focuses on sensing and reaction, and it builds small systems that could cope with uncertainty. For example, the research presented in [38
] provides an autonomous vehicle with the means to stay within the boundaries of a course, while avoiding obstacles. Developments in cognitive systems are also the base for some biologically-inspired layered control architecture for intelligent vehicles, such as in [39
shows the two main programs that form RoboGraph
. The GUI is a development tool that makes creating, editing, and monitoring of the different tasks possible, while the DISPATCH is in charge of executing those tasks.
This program is used to edit the PNs, monitor the execution of the PNs, and playback a finished execution of the system.
It includes a simple and intuitive PN graphical editor to create new tasks as a sequence of places and transitions. The PN is constructed by selecting and dragging different elements (places, transitions, arcs, and tokens). Afterwards, actions associated with places and transitions, as well as conditions associated with transitions, can be defined for the interpreted PN.
The actions associated with places and transitions can be commands implemented in any module in the control architecture shown in Figure 1
. The commands can be selected from a list automatically generated by the GUI. In a similar way, events can be part of the firing conditions of a transition. Some events are related to the arrival of a message from another module. The condition to fire the transition may only be the arrival of the message or a condition on some parameters of the message. For example, a condition can be that the event manager publishes a STOP signal detected
message or that the parameter distance of the STOP signal detected
message is less than ten meters. Figure 2
shows an example in which a transition is selected and the list of possible commands and events that can be associated with this transition is displayed. In Figure 2
, light pawns represent command messages that are executed when the transition is fired, and dark pawns represent events that integrate the condition associated with the transition.
There are other actions that can be associated with places and transitions besides commands, such as timers. A timer can be started in a place or transition for a limited period of time. The timeout can be part of the firing conditions of a transition.
Global variables are used to get starting data and store information to share conditions and events in different places and/or transitions. A condition to evolve the system might depend on the data coming from two or more messages.
Once the behavior is defined as a PN, the GUI includes an analyzer to test different problems and properties, such as possible deadlocks.
During the execution of the system, many independent modules (Figure 1
) are running in parallel. Debugging in these conditions is quite difficult. When the system crashes or does not work correctly, it is hard to identify the problems. The first step is to identify the module or modules that cause the problem. Sometimes the problem is not in a particular mode but in the synchronization between modes. The RG GUI can be very helpful for this task. While the system is running, the GUI in monitor mode connects to ROS and subscribes to different dispatch messages that show the status of the different running or waiting PNs. These messages are published by RG dispatch every time a PN starts, finishes, or evolves. The GUI shows every running PN in a different tab with the current marking. This way the status of the behavior can be identified in a snapshot, looking at the tokens in the PN. If the PN gets stuck in a particular marking, the problem can be easily identified by looking at the conditions of the enabled transitions. The typical situation is that a condition never holds because a module is not working the way it is supposed to work or the condition is not well defined. In either case, the module responsible for the problem can be easily identified.
When the autonomous car is operating in the real world, the number of PNs running in parallel and processes included in the system is huge. In this situation, debugging in real time becomes a hard task since many PNs can be evolving at the same time. In addition, some problems are hard to reproduce and it is useful to be able to playback a failed execution. In order to be able to deal with these problems, an XML log file with Dispatch ROS messages is created at runtime. Researchers can then run the GUI in playback mode, open the log file, play it at the same pace as in the real execution, and stop it at any time. It can also be traced step-by-step or jump to a defined place in the execution and look at the messages that arrive to RG.
Dispatch is the RG module that loads the PNs and executes them. In some way, dispatch coordinates the actions of the vehicle control modules (Figure 1
) according to the model defined in the PNs. The way RG dispatch interacts with the other modules in the control architecture is through messages. While executing a PN, the ROS messages associated with places are published every time the place gets a token (mark). A similar action takes place for the command ROS messages associated with transitions when the transition is fired. On the other hand, when RG starts the execution of a PN, it subscribes to all the the messages associated with transitions as events. Every time RG receives one of these messages, the conditions associated with the enabled transitions associated with the event are evaluated. Firing a transition results in execution of the commands associated with the transition, removing tokens from input places, and adding tokens to output places, according to the PN theory [47
]. It is important to notice that only the publish/subscribe paradigm is used to provide non-blocking communications. This way, even if some other module crashes, dispatch will not be blocked.
Dispatch is subscribed to the PN execution or cancellation ROS messages. Every requested message has an owner, priority, and execution mode (serial or parallel). Priority and owner define the execution precedence and the ability to stop or kill a PN. When a PN execution message arrives, dispatch loads the corresponding XML file and links the associated objects. Then, it starts the execution of the PN by setting the initial marking and subscribing to all messages associated with transition conditions.
For debugging purposes, this module publishes ROS messages reporting the state of all running PNs. Each change in the status of a PN (start, stop, evolve) is reported by issuing a new ROS message that is published and stored in a log file.
The RG tool was developed in Java because of its cross platform and its dynamic class loading features. The structure of each PN is stored in an XML file. The code associated with each place and transition is stored in a Java class that is dynamically loaded when the execution of a new PN is requested.
5. The Executive Layer
The executive layer implements different behaviors needed to drive the car autonomously. In the context of this work, a behavior corresponds to a traffic situation, such as a traffic light, a pedestrian crossing, an intersection with a yield, an intersection with a STOP, entering a highway, etc. Each of these behaviors is implemented in one or more PNs. In some way, the PNs that implement a behavior define the traffic rules to handle the corresponding traffic situation. The resulting system is very flexible since a modification in the traffic rules is easily implemented with minor changes in the corresponding PNs.
The role of the executive layer is to coordinate and synchronize other modules to carry out autonomous driving in different situations. Every behavior is modeled as a sequence of discrete events using the PNs. While running, other modules communicate events to this layer (pedestrian crossing, intersection ahead, etc.) through messages. According to the PN receptivity, in every situation, i.e., behavior, the executive module is subscribed to the messages that can evolve the state of the PN. At the same time, the executive module can request the execution of some commands (reduce speed, look for pedestrians, etc.) publishing messages to other modules that can carry out these commands.
5.1. Starting the System
There is a default PN running in the background all the time. This net is waiting for a message from the user requesting to execute some of the tasks the car can carry out. Figure 3
is a simplified version of that PN.
The foreground color of places and transitions (dark or clear) is used to represent different information about the execution of the PN. For example, transitions subscribed to a message are represented with dark foreground if the modules that publish those messages are already running in the system. In a similar way, places that are associated with messages will be represented with dark foreground when some module has already been registered as publisher of that message. For timed transitions, the black foreground represents timers that were used in the last execution.
When the RG dispatch module loads a PN, it subscribes to all the messages that take part in the events of the PN and registers publishers for all the messages that are included in the actions. All the PNs presented here have the same starting sequence: a first place (with the initial marking) and a transition. In the place, a timeout of 300 ms is started. The end of the timeout is the firing condition of the transition. This timeout has to be included to deal with ROS delays to avoid the use of messages before being registered. To simplify the figures, these first two items will be omitted in the rest of the paper.
As soon as the timeout concludes, the timeout transition will be fired, the token from the ini place will be removed and a new token will be added to wait place. In this situation, transitions manualDrive and goToPoint will be enabled. One of them can be fired whenever the condition associated with it shows as true. The condition associated with transition goToPoint is the reception of a message from the user GUI module selecting a destination. Upon reception of this message, the token from the wait place is removed and a new token is set in the wait start place. After the user selects the destination and a path is generated, the start button can be used to command the car to follow the path. In this case, the start message is published by the GUI and received by dispatch that fires the start transition. When the transition is fired, a token from wait start is removed and a new token is added to the RUN_start place.
The action associated with the RUN_start place is to send a message requesting to run the PN that starts one of the different behaviors (selector PN). The rest of the PN (left branch) deals with the selection between manual and autonomous drive. A transition with the STOP button event has been omitted for the sake of simplicity.
5.2. Monitoring the Behaviors
The selector PN decides which behavior to run, according to the traffic situation, and monitors the execution of the behaviors.
and Figure 5
represent the main parts of the selector
PN. The dangling arc coming from the right of Figure 4
is connected to the dangling arc leaving from the left of Figure 5
. The other dangling arc of Figure 5
is used to connect another part of the PN used for debugging purposes, but it has been omitted here for the sake of simplicity. Figure 4
represents the part that decides what behavior to execute and stores the name of the behavior in a global variable (mainBhvr
). A place labeled as wait
gets a token as soon as the PN is started and waits for the events that are relevant to make the decision. Whenever an event that is likely to change the traffic situation occurs, it should be detected by the corresponding module (event monitors
, map manager
, etc.) that will send the corresponding message. That message should trigger the related wait
output transition. Therefore, the token from the wait
place is removed and a new token is added to the calculateNewBehaviour
place. In this place, the main behavior is updated and stored in a PN global variable (mainBhvr
). It is important to note that standard PNs do not include variables, but they are an added feature in RG [7
] that simplifies the net in applications of this kind.
variable is used in the other part of the selector
PN (Figure 5
) to decide when to start or stop a behavior. As in the previous case, the selectBH
place gets a token as soon as the PN starts. When the mainBhvr
variable is set to one of the behaviors that matches the value associated with one of the selectBH
output transitions, that transition is fired. Therefore, the token from the selectBH
place will be removed, and a new token is added to one of the behavior places. The action associated with most of the behavior places is to start the corresponding PN. As soon as the traffic situation changes, the running PN that implements the current behavior should finish. Places labeled as wait_END_OK
in Figure 5
should get a token waiting for the message that is sent when the behavior PN finishes. If that message arrives before the timeout, the END_PN
transition will be fired and finally the selectBH
place will get a token, meaning that the system is ready to run the next behavior. If the timeout occurs while the wait_END_PN
place is marked with a token because the END_PN
message did not arrive, the timeout
transition will be fired and a message to kill the behavior PN will be issued, forcing the behavior to finish and popping up an error message for the user.
It is important to note that safe navigation is guaranteed at all times by the control loop on the local navigation
module. Any kind of obstacle should be detected by the range lasers and avoided by the local navigation
module, using a modified version of the CVM (Curvature Velocity Method) obstacle avoidance algorithm named CVM-Car [45
In the next section, we will describe some of the behaviors implemented in the autonomous driving system.
6.1. Pedestrian Crossing Behavior
A pedestrian crossing behavior is started when the vehicle approaches an area where the corresponding regulatory signs are displayed. This behavior is defined by the PN of Figure 6
After the starting sequence, the place watchForPedestrians gets a token, and the associated actions are executed. In this case, the actions consist of sending a message to the event monitor module to watch for pedestrians crossing on the crosswalk. There are three possible outcomes of this state regarding the event produced by the event monitor module: a message informing that so far no pedestrian has been detected (notPedestrian transition); a message reporting that a pedestrian has been detected (pedestrian transition); and no confirmation message has been received from the event monitor (timeout transition).
If no pedestrian is detected, transition notPedestrian is fired, removing the token from watchForPedestrians and adding a token to the followPath place. While in this place, the local navigation module will keep following the lane provided by the map manager module. The system in this state is receptive to two events: pedestrian and close2Crosswalk.
The first event (pedestrian) is a message published by the event monitor module; if this message is received, the pedestrian transition will be fired. According to the transition firing rules, a token is removed from the followPath place, and a token is added to the first stop place.
The event close2Crosswalk
occurs when the robot is closer than a threshold distance (D) to the crosswalk. The condition associated with transition close2Crosswalk
compares the current robot position with the crosswalk position. The vehicle position message is published by the localization
module (Figure 1
). The RG Dispatch
module that executes the PNs is subscribed to all messages used in the enabled transitions. Every time one of these messages arrives, RG Dispatch
evaluates the enabled transitions and fires the ones evaluated to true. On this occasion, the distance between the vehicle position (vehicle position message) and the crosswalk is obtained and compared with the threshold D.
When the transition close2Crosswalk
is fired, a token is added to the reduceVel transition (Figure 6
). The principal action associated with this transition is to command the local navigation module to reduce the speed. Still, the vehicle keeps following the path until the crosswalk is reached (crosswalkReached
transition) unless a pedestrian is detected (pedestrian
transition). If a pedestrian is detected, the pedestrian
transition will be fired upon the reception of the corresponding message published by the event monitor
module. A token will be added to the stop
, and a message commanding local navigation
module to stop in front of the crosswalk will be published. After the pedestrians cross and no pedestrians are detected, transition notPedestrian
is fired, and the vehicle starts moving again.
Finally, when the END
place is reached, RG Dispatch
will end the PN issuing an END_PN
message that will be used by the selector
PN (Section 5
6.2. Intersection Behaviors
Intersections pose many challenges as vehicles need to deal with many different maneuvers, such as merge, left turn, yield, and stops at certain road intersections. They include also a considerable number of different elements: traffic signals, traffic lights, turning lanes, merging lanes, and other vehicles entering the intersection.
shows the PN that represents the sequence of events and actions defining the behavior of the car in a traffic STOP situation. After the starting sequence, the stop
place will get a token. That will lead to publishing a couple of messages: the first one is addressed to the event monitor
module to check for vehicles at the intersection, and the second one is addressed to the local navigation
module to stop before the intersection. The firing condition associated with the stopped
transition is the reception of a car’s velocity message from the local navigation
module with velocity equal to zero. When this transition is fired, a timer of one second is started and the place labeled “wait 1s for safety
” gets a token. When the timer finishes, the timeout transition is fired, and place labeled “wait safe merge
” gets a token. This state is sensitive to two events associated with the corresponding transitions. The notSafeMerge
transition is fired if a an unsafe merge message is received from the event monitor
. The other event is that a safe merge message is received, in which case the SafeMerge
transition would be fired. The state of the system can move between these two states until the car is in the followPath
place long enough to enter the intersection. Once the car is in the intersection, it proceeds to cross the intersection since there is no point in stopping in the middle of the intersection. In any case, as aforementioned, safe navigation is guaranteed by the local navigator
The yield behavior is very similar to the STOP case, with the main difference that no stop is needed when it is safe to cross. That leads to a PN similar to the one in Figure 7
, removing the second and third places and transitions.
The sequence for the traffic light situation is defined by the PN in Figure 8
. After sending a message to the event monitor
to check for the traffic light at the intersection (checkTrafficLight
place), the car might need to stop (stop
place) sending a stop
message to the local navigation
module, or continue (followPath
place). The car will stop (stop
place) if one of these three different sequences occurs:
The traffic light is red (red transition).
A timeout expired before getting any traffic light reading from the event monitor module (timeout transition).
The traffic light is amber (amber transition), and it is safe to stop before the traffic light (safeStop transition).
The car will continue (followPath places) if one of these sequences occurs:
The traffic light is green (green transition).
The traffic light is amber (amber transition), but the car is already in the intersection, and it is not possible to stop in a safe place (notSafeStop transition).
There are other similar behaviors, such as entering a roundabout, entering a highway, etc., in which descriptions are not included here because the PNs that define their behaviors are very similar to some of those already depicted.
6.3. Overtaking Behavior
Overtaking is one of the most challenging maneuvers [48
] that involves the cooperation of several modules. The map manager
has the information to decide if in that part of the road the overtaking maneuver is allowed and for how long. The event monitor can decide whether it is safe to switch lanes according to the traffic. The vehicle needs to switch to the adjacent left lane and stay on that lane until the overtaken vehicle is left behind and there is a gap in the right line to return. Figure 9
represents the PN that models this maneuver. There are three main states: the first one is when the car is switching to the left lane (switchLeftLane
place), the second one is while the car remains in the left lane (overtaking
place), and the last one is when the car is switching back to the right lane (returnRight
While the behavior is in one of these states, it is sensitive to the messages that could change to a different state. For example, at the beginning (start place), the decision to start the overtaking maneuver (evaluateCond place) will depend on two messages reported by the event monitor module and one from the map manager. The event monitor reports when the adjacent left lane is clear for a sufficient distance (leftLaneInfo transition) and when there is a significant difference between the desired speed of the ego car and the speed of the car in front of it (frontCar transition). The map manager module knows the distance remaining in the current path where overtaking is allowed. Whenever one of these messages is received, the conditions are evaluated (evaluateCond place) and, depending on the outcome of this evaluation, the car might start switching to the left lane (switchLeft place) or keep waiting (start place).
Similar sequences are also defined while the car is returning to the right lane (returnRight place).
Both lane-change operations are depicted in Figure 10
. When the local navigator receives a switch2LeftLane
command together with the overtaking lane
message, it changes the left lane border to the far side of the overtaking lane. In Figure 10
a, the car is moving behind a slower car, and the executive module decides to overtake when it is legal to do so. The white circles on top of the lane borders are virtual obstacles generated by the CVM-Car obstacle avoidance method to keep the car in the lane. Figure 10
b shows that the left way has been switched and virtual obstacles appear on the left side of this lane. Now, CVM-Car will try to avoid the other car by moving to the opening area, which is in the left lane. Once the car has overtaken (Figure 10
c), it will return to the middle of the opening area, which is in the middle of the road. In order to return completely to the right lane, the left way progressively moves to the left way of the right lane.
By using a Petri-net-based programming environment to implement the executive layer of a car navigation framework, we have shown that it is possible to build and maintain the behavior system in a relatively fast and intuitive way. The programming environment, named RoboGraph
, allows the edition, execution, tracing, and maintenance of the PNs that implement the behaviors needed for different traffic scenarios. RG has been used before within the RIDE framework [44
] for several multirobot applications, such as on the hotel assistant BellBot [55
], the surveillance system WatchBot [56
], and a tour guide system GuideBot [57
]. For the work presented in this paper, the RG inter-process communication mechanism has been extended to communicate with ROS modules.
Unlike previous solutions, the approach presented in this paper integrates the model definition with the model verification, execution, and monitoring using the RG framework. Most of the vehicle control frameworks are based on a middleware layer with several independent modules. These modules are connected with different inter-process communication mechanisms using the message publish/subscribe paradigm. This use of messages instead of events (interpreted PNs) or signals (signal interpreted PNs) establishes a significant difference with previous models.
The solution proposed here can be implemented in any control framework that includes a functional layer with a set of components that provide access to sensor data, send commands to actuators, and execute different basic functionalities (localization, path planning, obstacle avoidance, etc.) or behaviors (follow wall, etc.). However, the use of frameworks provides several advantages when the modules are implemented as independent processes, communicating with each other and with the upper layers via some inter-process communication mechanism. These include, for example, module reusability, robustness because a failure in a module does not imply the whole system failing, and easier maintenance.
Even though the executive layer presented here does not explicitly deal with the uncertainty about the state of the system, it allows the monitoring system to deal with it. The motivation of this approach is that most of the uncertainty comes from the observers that are directly handled by monitors. Therefore, once the decision about the current situation is taken, the sequence of actions to deal with it are known and, in our case, defined using PNs.