WiseMove: A Framework for Safe Deep Reinforcement Learning for Autonomous Driving

TL;DR

WiseMove is a modular software framework designed to explore safe deep reinforcement learning techniques specifically for motion planning in autonomous driving, balancing safety, functionality, and scalability.

Contribution

The paper introduces WiseMove, a flexible, modular framework that facilitates research on safe deep reinforcement learning for autonomous vehicle motion planning.

Findings

Demonstrated WiseMove on a common traffic scenario

Showcased its adaptability to new technologies and research questions

Supported ongoing safe learning research in autonomous driving

Abstract

Machine learning can provide efficient solutions to the complex problems encountered in autonomous driving, but ensuring their safety remains a challenge. A number of authors have attempted to address this issue, but there are few publicly-available tools to adequately explore the trade-offs between functionality, scalability, and safety. We thus present WiseMove, a software framework to investigate safe deep reinforcement learning in the context of motion planning for autonomous driving. WiseMove adopts a modular learning architecture that suits our current research questions and can be adapted to new technologies and new questions. We present the details of WiseMove, demonstrate its use on a common traffic scenario, and describe how we use it in our ongoing safe learning research.

Figures

Tables

Table 1. Table 1: The options and examples of their preconditions.

Option	Description	Example LTL Precondition
KeepLane	keep lane while driving	-
Stop	stop at the stop region	G(not has_stopped_in_stop_region)
Wait	wait at the stop region then drive forward	G((has_stopped_in_stop_region and        in_stop_region) U highest_priority)
Follow	follow vehicle ahead	G(veh_ahead)
ChangeLane	change to other lane	G(not(in_intersection or in_stop_region)​)

Table 2. Table 2: Performance of low-level policies trained for 10 5 superscript 10 5 10^{5} steps, with and without additional LTL properties: mean (std) of the number of success in 100 episodes, averaged over 10 trials with independent retraining for each.

Add’l LTL	KeepLane	Stop	Wait	Follow	ChangeLane
Unused	15.8 (25.7)	45.7 (30.2)	0.00 (0.00)	58.2 (19.6)	52.2 (35.7)
Used	75.2 (37.9)	94.0 (10.6)	93.8 (6.12)	78.0 (17.9)	93.7 (15.7)

Table 3. Table 3: Performance of the high-level decision-making, without and with MCTS: mean (std) % of success/violation/collision rates in the experiment, averaged over 10 trials with 100 episodes. Without MCTS, each high-level policy for each trial is independently retrained for 2 × 10 5 2 superscript 10 5 2\times 10^{5} steps. With MCTS, all trials used a high-level policy that achieved 92% success. Both experiments were conducted with low-level policies pre-trained with 10 6 superscript 10 6 10^{6} steps, using additional properties to enhance training.

Without MCTS			With MCTS
success	violation	collision	success	violation	collision
89.7 (2.66)	4.24 (1.88)	4.41 (1.81)	98.0 (1.05)	0.60 (0.51)	1.40 (0.96)

Equations

$$\{\begin{array}{l}\begin{array}{rlrl}& {\dot{X}}_i=v_i\sin {\theta }_i& & {\dot{Y}}_i=v_i\cos {\theta }_i{\dot{\theta }}_i=v_i\tan ({\psi }_i/L)\\ & {\dot{v}}_i={\mathfrak{a}}_i(|{\mathfrak{a}}_i|\le {\mathfrak{a}}_{\max })& & {\dot{\psi }}_i={\rho }_i(|{\rho }_i|\le {\rho }_{\max },|{\psi }_i|\le {\psi }_{\max }).\end{array}\end{array}$$

$$z_i:=({has\_stopped\_in\_stop\_region}_i,{has\_entered\_stop\_region}_i,{waited}_i),$$

$$s^{\prime }=({\mathbf{x}}^{\prime },{\mathbf{z}}^{\prime }{)}^{⊺}=(f_{\mathsf{c}}(s,a),f_{\mathsf{d}}(s,a){)}^{⊺}:=f(s,a),$$

$$o:=(\mathbf{x},\mathbf{z},\mathbf{y},{\alpha }_1,{\alpha }_2,\cdots ,{\alpha }_N),$$

$$\phi =\text{F}\phi \mid \text{G}\phi \mid \text{X}\phi \mid \phi \text{=>}\phi \mid \phi \text{or}\phi \mid \phi \text{and}\phi \mid \text{not}\phi \mid \phi \text{U}\phi \mid \text{(}\phi \text{)}\mid \alpha$$

$${\phi }_1$$

$${\phi }_2$$

$${\phi }_3$$

$$V(s_{0:T},a_{0:T},m_{0:K}):=-\sum _{t=0}^{T-1}{\gamma }^t\cdot \mathsf{inst}(o_t,a_t,m_k)+{\gamma }^T\cdot \mathsf{term}(o_T),$$

Full text

We thus present \framework, a software framework to investigate safe deep reinforcement learning in the context of motion planning for autonomous driving. \framework adopts a modular learning architecture that suits our current research questions and can be adapted to new technologies and new questions. We present the details of \framework, demonstrate its use on a common traffic scenario, and describe how we use it in our ongoing safe learning research.

1 Introduction

Learned systems seem essential in autonomous driving, with machine learning providing performance that is difficult to replicate using other approaches. The safety of learned systems is, however, difficult to guarantee, creating a conflict of requirements.

Autonomous driving requires sophisticated perception and decision making, which is often most efficiently achieved by machine learning. The state space of the resulting complex functions is typically intractable to analysis, especially when considering the hybrid dynamics of autonomous driving. Safety is nevertheless essential, so a number of authors have already attempted to address the notion of safe learning in this context (e.g. [3, 2, 12, 10]). Many practical challenges remain, however, and we are not aware of any suitable software tools to investigate the complex trade-offs between safety and functionality.

Our group111uwaterloo.ca/waterloo-intelligent-systems-engineering-lab/ has developed an autonomous driving software stack that has already been used to drive autonomously for 100 km [11], so our interest in safety is more than just academic. Our pressing concern is the safety and scalability of motion planning, where safety can refer to both the learning and deployment phases, and scalability refers to both the creation and verification of a motion planning solution.

Our current stack employs deep neural networks for perception, but the rest of the motion planning architecture is more conventionally implemented. Governed by an overall mission planner, high-level decisions, such as slow down, turn left, etc., are made by a “behaviour planner” that resolves hand-coded logical constraints (rules) over a discrete abstraction of the environment (approaching the stop region, in the intersection, stopped, etc.). To implement the chosen high-level behaviour, a low-level reference trajectory is generated by a “local planner” that performs an optimization with respect to jerk and rate of progress, etc., over classes of smooth trajectories that avoid obstacles and pass through the current continuous state and future waypoints. A controller on the vehicle then actuates the reference trajectory.

The recent success of deep reinforcement learning (DRL) in playing Go [13, 14], and its success with other applications having intractable state space [7], suggests DRL as a scalable way to implement motion planning for autonomous vehicles. We have thus devised a hierarchical and modular DRL framework, \framework, to investigate the trade-offs between safety, performance and scalability. A DRL-based approach using a similar architecture to our own has recently been proposed in [10]. The work reports interesting results, but provides no software tool or other means to verify them. In what follows, having described \framework, we present results of experiments that can be reproduced by installing our publicly-available code222git.uwaterloo.ca/wise-lab/wise-move.

1.0.1 \framework

is an options-based modular safe DRL framework, written in Python. Its hierarchical structure is designed to mirror the architecture of our existing software stack, learning (approximately) safe high- and low-level decision-making policies that are then made safer using Monte Carlo tree search (MCTS [6, 5]). Options [15] model primitive manoeuvres, to which are associated low-level policies that implement them. These policies are learned separately, in advance, each using a deep neural network to encode the continuous action space. A learned high-level policy over options decides which option to take in any given situation. This high-level policy corresponds to the behaviour planner in our existing software stack; the low-level policies correspond to our “local” planner and controller. To define safe behaviour and option termination conditions, \framework uses runtime verification to validate simulation traces and assign rewards during both learning and planning with MCTS. MCTS is an expected-outcome algorithm [1], which \framework uses to perform a stochastic look-ahead, to choose the safest next option.

Fig. 2 gives a diagrammatic overview of \framework’s planning architecture. The current state is provided to the planner (MCTS) by the environment. MCTS explores and verifies hypothesized future trajectories, using the learned high-level policy over options as a baseline. MCTS chooses the best next option it discovers, which is then used to update the environment.

2 Dynamics

In this section we describe the dynamics of \framework, as used in the simple intersection scenario shown in Fig. 2. We first introduce the discrete and continuous dynamics, then use these to construct a partially-observable Markov decision process (POMDP) representing the full dynamics of the (simplified) driving task we consider in our experiments.

2.0.1 Continuous Dynamics.

Let $x_{i,\mathsf{veh}}:=(X_{i},Y_{i},\theta_{i},\,v_{i},\,\psi_{i})$ and $u_{i}:=(\mathfrak{a}_{i},\,\rho_{i})$ be the continuous state and control input, respectively, of vehicle $i$, with position $(X_{i},Y_{i})$, speed $v_{i}$, acceleration $\mathfrak{a}_{i}$, heading angle $\theta_{i}$, steering angle $\psi_{i}$, rate of change of steering angle $\rho_{i}$, and wheel base $L$. Then its continuous dynamics are

[TABLE]

The state is updated every $\Delta t$ (by numerical integration) according to state transition function ${x}_{i,\mathsf{veh}}^{\prime}=g_{\mathsf{veh}}(x_{i,\mathsf{veh}},u_{i})$. We use the previous input, $u_{i,\mathsf{prev}}:=(\mathfrak{a}_{i,\mathsf{prev}},\,{\rho}_{i,\mathsf{prev}})$, to approximate the jerk by ${\dot{\mathfrak{a}}}_{i}\approx(\mathfrak{a}_{i}-\mathfrak{a}_{i,\mathsf{prev}})/\Delta t$. Defining $x_{i}:=(x_{i,\mathsf{veh}},u_{i,\mathsf{prev}})$, the complete continuous dynamics of vehicle $i$ is $x_{i}^{\prime}=g_{\mathsf{c}}(x_{i},u_{i})$, where continuous transition function $g_{\mathsf{c}}(x_{i},u_{i}):=(g_{\mathsf{veh}}(x_{i,\mathsf{veh}},u_{i}),u_{i})$.

2.0.2 Discrete Dynamics.

Vehicle $i$ has discrete state

[TABLE]

where $waited_{i}\in\mathbb{Z}$ is initialised to $-1$, incremented every $\Delta t$ the vehicle remains in the stop region, and reset to $-1$ when it leaves. The discrete state is updated according to discrete transition function $z_{i}^{\prime}=g_{\mathsf{d}}(z_{i},y_{i,\mathsf{loc}}^{\prime})$, where $y_{i,\mathsf{loc}}$ is a local discrete abstraction of the continuous state $x_{i}$. The global hybrid state is given by $s:=(\mathbf{x},\mathbf{z})\in\mathscr{S}$, with $\mathbf{x}:=\{x_{i}\}^{\intercal}$ and $\mathbf{z}:=\{z_{i}\}^{\intercal}$, and where $\{\cdot\}^{\intercal}$ denotes the column vector formed by all the indexed elements. The global discrete output of vehicle $i$ is denoted $y_{i,\mathsf{glob}}$, comprising $s$ and $\{y_{i,\mathsf{loc}}\}^{\intercal}$. The complete discrete output of vehicle $i$ is $y_{i}:=(y_{i,\mathsf{loc}},y_{i,\mathsf{glob}})$, and $\mathbf{y}=\{y_{i}\}^{\intercal}$ denotes the global discrete output.

2.0.3 Complete POMDP.

The full update dynamics is given by

[TABLE]

where action $a\in\mathscr{A}=[-\mathfrak{a}_{\mathrm{max}},\mathfrak{a}_{\mathrm{max}}]\times[-\rho_{\mathrm{max}},\rho_{\mathrm{max}}]$ is the ego vehicle’s control input $u_{0}$, $f_{\mathsf{c}}(s,a):=\{g_{\mathsf{c}}(x_{i},u_{i})\}^{\intercal}$, and f_{\mathsf{d}}(s,a):=\{g_{\mathsf{d}}(z_{i},h_{\mathsf{loc}}\big{(}g_{\mathsf{c}}(x_{i},u_{i}))\big{)}\}^{\intercal}. Typically, we adopt a different policy, $\mu$, for the non-ego vehicles. E.g., the aggressive driving policy of [10]. Hence, $u_{i}=\mu(s)$ for all $i\neq 0$.

Omitting the index from any variable of the ego vehicle, the ego’s full observation $o\in\mathscr{O}$ is

[TABLE]

with $\alpha_{j}:=(X-X_{j},Y-Y_{j},v_{j},\mathfrak{a}_{j,\mathsf{prev}},\mathit{waited}_{j})$. The dynamics (2) and observation (3) induce a POMDP, $\mathscr{P}:=(\mathscr{S},\mathscr{S}^{0},\mathscr{A},f,\mathscr{O},h)$, where $\mathscr{S}^{0}\subseteq\mathscr{S}$ is the set of initial states and $h(s):=(\mathbf{x},\mathbf{z},\mathbf{y},\alpha_{1},\alpha_{2},\cdots,\alpha_{N})$ is the observation function. As (2) and (3) are deterministic, the only stochasticity, if any, is the randomly-chosen control action during training and/or planning.

3 Features and Architecture

\framework

comprises four high-level Python modules: verifier, the incremental verifier module; env, the environments module; options, the options module; and backends, the DRL module.

3.1 Incremental Verification

The verifier module provides methods for checking temporal logic property strings that are constructed according to the following LTL-like syntax:

[TABLE]

Literal symbols U, F, G and X are the standard until, eventually (finally), always (globally) and next-state temporal operators, respectively. The other literal symbols have their obvious meanings. Atomic propositions, $\alpha$, evaluate to true or false in each state and are represented by human readable strings. This syntax is compatible with the properties used by other logic-based safe learning approaches and is sufficiently expressive for our current needs. In what follows we refer to LTL properties, meaning properties written according to (4).

The verifier works as an efficient, incremental “learntime” or runtime monitor, constructed using the Coco/R compiler generator [9]. Efficiency of the verifier is important, since properties are checked in the innermost loops of learning the low-level and high-level policies, as well as within the MCTS.

In \framework, an episode continues while its termination conditions are all false. If one of the conditions becomes true, the episode terminates with a positive or negative terminal reward, depending on whether the termination represents success or failure, respectively. \framework also expresses traffic rules using temporal logic, e.g.,

[TABLE]

The result of verification at each time step determines whether to terminate the episode and, if so, the appropriate terminal reward. LTL expressions are also used to represent, if any, the preconditions and goal conditions of each option. Some options and preconditions are listed in Table 1.

3.2 Environments and Backends

The env module provides support for environments that adhere to the OpenAI Gym [4] interface, meaning they implement step, reset and render functions, which can respectively update, initialize and visualize the environment. The options module also adheres to this interface. This standardization allows for a plug-and-play functionality, such that we can plug in any gym-compliannt environment.

The backends module provides the architecture for control logic specification. Control logic for the environment, whether learned through optimization or programmed imperatively, have pre-defined abstract interfaces in backends that can be implemented as desired.

For the purpose of our experiments, we use DDPG [7], DQN [8] and MCTS for the different levels of our hierarchical architecture, which are all connected through the options module. The options module provides three modes of high level logic specification: rl, mcts and manual. While rl and mcts respectively use DQN and MCTS for high level logic, the manual mode provides support for a deterministic options graph, the transitions of which are manually defined. Our implementation currently use keras333http://keras.io and keras-rl444http://github.com/keras-rl/keras-rl for DRL training, and the training hierarchy can be specified through a json file. The configuration of the hierarchy can also be altered (via the json file) to use other options.

3.3 Options and Learning

The options module provides the hierarchical decision-making architecture for RL. An option is an elementary manoeuvre, hence we use the notation $m\in\mathscr{M}$ to denote elements of the set of options, and define $m:=(\mathscr{S}_{m}^{0},\pi_{m},\beta_{m})$ [15]. $\mathscr{S}_{m}^{0}\subseteq\mathscr{S}$ is the initiation set in which $m$ is available, $\pi_{m}:\mathscr{F}\to\mathscr{A}$ is a low-level policy—a map from the feature space $\mathscr{F}\ni\phi$ to the action space $\mathscr{A}\ni a$—and $\beta_{m}$ is the termination condition, which can evaluate to true or false.

In \framework, we learn the low-level policy $\pi_{m}$ for each option $m$ first, and then learn the high-level policy $\Pi:\mathscr{F}\to\mathscr{M}$, which determines the option $m=\Pi(\phi)$ at each decision instant. Only options whose preconditions are satisfied may be chosen. Table 1 shows examples of the logical preconditions.

If an option $m$ is chosen by the high-level decision maker, i.e., $\Pi$ or MCTS, at discrete time $t$, the agent generates a sequence of actions $a_{t}\,a_{t+\Delta{t}}\,a_{t+2\Delta{t}}\cdots$ according to $a_{\tau}=\pi_{m}(\phi_{\tau})$, for all $\tau\geq t$ until termination, and where $\phi_{\tau}$ is the feature vector at time $\tau$. An option $m$ terminates when the termination condition $\beta_{m}$ becomes true. In this case, the agent chooses the next option and executes it until it terminates. This process continues until the whole episode ends.

The options module defines the termination condition $\beta_{m}$ of each option as the disjunction of (i) a violation of an LTL requirement, (ii) successful completion, (iii) collision, and (iv) timeout.

3.3.1 Learning

The objective of DRL is to learn a set of low-level policies, $\{\pi_{m}^{*}:\mathscr{F}\to\mathscr{A}\}_{m\in\mathscr{M}}$, and a high-level policy, $\Pi^{*}:\mathscr{F}\to\mathscr{M}$, that jointly maximize the value function

[TABLE]

where: $\mathsf{inst}(\cdot)$ is the instantaneous reward; $\mathsf{term}(\cdot)$ is the terminal reward; $s_{0}\in\mathscr{S}^{0}$ is the initial state; $\gamma\in(0,1)$ is the discount rate; $T,K\in\mathbb{N}\cup\{\infty\}$ are the terminal time and decision instants of an episode, respectively; $s_{t}$ is the state at time $t$; $o_{t}$ is the ego’s observation at time $t$; $m_{k}=\Pi(\phi_{t_{k}})$ is the option chosen by the high-level policy at decision time $t_{k}$ of decision instant $k$, applied until its termination at the next decision time, $t_{k+1}$; and $a_{t}=\pi_{m_{k}}(\phi_{t})$ is the action given by the low-level policy at times $t=t_{k},t_{k}+\Delta t,t_{k}+2\Delta t,\cdots,t_{k+1}-\Delta t$.

Instantaneous reward $\mathsf{inst}(o_{t},a_{t},m_{k})$ is given at every time $t$, after observing $o_{t}$ and taking action $a_{t}$ under the option $m_{k}$. It is calculated as the weighted Euclidean norm of continuous features, such as the speed error (the difference between the reference speed and the actual speed) and the lateral position error (the distance from the lane centre line).

The terminal reward, $\mathsf{term}(o_{T})$, is given following the terminal observation, $o_{T}$, at terminal time $T$. In practice, we give a large positive reward for successfully reaching the goal of the option, or a large negative reward in the case of a collision or violation of an LTL requirement.

4 Experiments

We report here the results of experiments performed on the intersection environment illustrated in Fig. 2. The road scenario contains the ego vehicle, initially placed on the horizontal route, and up to $6$ other vehicles placed at random on either the horizontal or vertical routes. Vehicles are placed in either the left or right lane at random; they drive to the right on the horizontal route and drive down on the vertical route. Vehicles must stop completely in the stop region. No left or right turn is allowed, but vehicles can change lane within the same route. With this configuration, the goal of the ego vehicle is to arrive at the right end of the route without any collision or violation of the traffic rules, while respecting the speed limit. An episode terminates when any collision or violation occurs with the ego vehicle (failure), or if it reaches the goal region with its longitudinal speed less than or equal to the speed limit (success).

We first trained the low-level option-specific policies using DDPG, under various constraints. These include those that express preconditions (as given in Table 1), as well as additional properties used to enhance the training of low-level policies. The additional constraints include liveness conditions (e.g., G(not stopped_now)) for promoting exploration, and safety-related properties (e.g., G(not veh_ahead_too_close) in Follow). Table 2 shows the significant performance gains achieved when using the additional properties.

We next trained the low-level policy for each option using $10^{6}$ steps, in order to have a set of high performance base manoeuvres. We then trained high-level policies using DQN. The results in Table 3 show that without MCTS, the high-level policy achieves an average success rate of 89.7%, with a small number of collisions and traffic rule violations. With MCTS, the average success rate jumps to 98.0%, with even fewer violations and collisions.

The standard deviations of our results indicate that they are robust and repeatable. The full details of our experimental setups, along with scripts to reproduce the results, can be found in our repository2.

5 Conclusion and Prospects

Our early results with \framework have been successful in reproducing published results and revealing interesting phenomena and challenges that are not apparent in the literature. For example, the unpredictable interactions between different constraints and rewards. Having revealed these, however, we are confident that \framework is well equipped to help explore them.

Our ongoing research will use \framework with different scenarios and more complex vehicle dynamics. We will also exploit \framework’s modularity, using different types of non-ego vehicles (aggressive, passive, learned, programmed, etc.) and interleave learned components with programmed components from our autonomous driving software stack.

Acknowledgment

This work is partly supported by the Japanese Science and Technology agency (JST) ERATO project JPMJER1603: HASUO Metamathematics for Systems Design.