adaptive cruise control with sensor fusion -凯发k8网页登录

introduction

an adaptive cruise control system is a control system that modifies the speed of the ego vehicle in response to conditions on the road. as in regular cruise control, the driver sets a desired speed for the car; in addition, the adaptive cruise control system can slow the ego vehicle down if there is another vehicle moving slower in the lane in front of it.

for the acc to work correctly, the ego vehicle must determine how the lane in front of it curves, and which car is the 'lead car', that is, in front of the ego vehicle in the lane. a typical scenario from the viewpoint of the ego vehicle is shown in the following figure. the ego vehicle (blue) travels along a curved road. at the beginning, the lead car is the pink car. then the purple car cuts into the lane of the ego vehicle and becomes the lead car. after a while, the purple car changes to another lane, and the pink car becomes the lead car again. the pink car remains the lead car afterward. the acc design must react to the change in the lead car on the road.

current acc designs rely mostly on range and range rate measurements obtained from radar, and are designed to work best along straight roads. an example of such a system is given in (model predictive control toolbox) and in (radar toolbox). moving from advanced driver-assistance system (adas) designs to more autonomous systems, the acc must address the following challenges:

this example demonstrates two main additions to existing acc designs that meet these challenges: adding a sensor fusion system and updating the controller design based on model predictive control (mpc). a sensor fusion and tracking system that uses both vision and radar sensors provides the following benefits:

an advanced mpc controller adds the ability to react to more aggressive maneuvers by other vehicles in the environment. in contrast to a classical controller that uses a pid design with constant gains, the mpc controller regulates the velocity of the ego vehicle while maintaining a strict safe distance constraint. therefore, the controller can apply more aggressive maneuvers when the environment changes quickly in a similar way to what a human driver would do.

overview of test bench model and simulation results

get a list of systems that are open now so any systems opened during this example can be closed at the end, then open the main simulink model.

startingopensystems = find_system('matchfilter', @simulink.match.allvariants);
open_system('acctestbenchexample')

the model contains two main subsystems:

to run the associated initialization script before running the model, in the simulink model, click run setup script or, at the command prompt, type the following:

helperaccsetup

the script loads certain constants needed by the simulink model, such as the scenario object, vehicle parameters, and acc design parameters. the default acc is the classical controller. the script also creates buses that are required for defining the inputs into and outputs for the control system referenced model. these buses must be defined in the workspace before model compilation. when the model compiles, additional simulink buses are automatically generated by their respective blocks.

to plot the results of the simulation and depict the surroundings of the ego vehicle, including the tracked objects, use the . the bird's-eye scope is a model-level visualization tool that you can open from the simulink toolstrip. on the simulation tab, under review results, click bird's-eye scope. after opening the scope, click find signals to set up the signals. the following commands run the simulation to 15 seconds to get a mid-simulation picture and run again all the way to end of the simulation to gather results.

sim('acctestbenchexample','stoptime','15') %simulate 15 seconds
sim('acctestbenchexample') %simulate to end of scenario

ans = 
  simulink.simulationoutput:
                logsout: [1x1 simulink.simulationdata.dataset] 
                   tout: [151x1 double] 
     simulationmetadata: [1x1 simulink.simulationmetadata] 
           errormessage: [0x0 char] 

the bird's-eye scope shows the results of the sensor fusion. it shows how the radar and vision sensors detect the vehicles within their sensors coverage areas. it also shows the tracks maintained by the multi-object tracker block. the yellow track shows the most important object (mio): the closest track in front of the ego vehicle in its lane. we see that at the beginning of the scenario, the most important object is the fast-moving car ahead of the ego vehicle. when the passing car gets closer to the slow-moving car, it crosses to the left lane, and the sensor fusion system recognizes it to be the mio. this car is much closer to the ego vehicle and much slower than it. thus, the acc must slow the ego vehicle.

in the following results for the classical acc system, the:

in this example, the raw data from the tracking and sensor fusion system is used for acc design without post-processing. you can expect to see some 'spikes' (middle plot) due to the uncertainties in the sensor model especially when another car cuts into or leaves the ego vehicle lane.

to view the simulation results, use the following command.

helperplotaccresults(logsout,default_spacing,time_gap)

in the mpc-based acc design, the underlying optimization problem is formulated by tracking the driver-set velocity subject to enforcing a safe distance from the lead car. the mpc controller design is described in the adaptive cruise controller section. to run the model with the mpc design, first activate the mpc variant, and then run the following commands. this step requires model predictive control toolbox software. you can check the existence of this license using the following code. if no code exists, a sample of similar results is depicted.

hasmpclicense = license('checkout','mpc_toolbox');
if hasmpclicense
    controller_type = 2;
    sim('acctestbenchexample','stoptime','15') %simulate 15 seconds
    sim('acctestbenchexample') %simulate to end of scenario
else
    load data_mpc
end

-->converting model to discrete time.
-->assuming output disturbance added to measured output #2 is integrated white noise.
   assuming no disturbance added to measured output #1.
-->"model.noise" is empty. assuming white noise on each measured output.
ans = 
  simulink.simulationoutput:
                logsout: [1x1 simulink.simulationdata.dataset] 
                   tout: [151x1 double] 
     simulationmetadata: [1x1 simulink.simulationmetadata] 
           errormessage: [0x0 char] 
-->converting model to discrete time.
-->assuming output disturbance added to measured output #2 is integrated white noise.
   assuming no disturbance added to measured output #1.
-->"model.noise" is empty. assuming white noise on each measured output.

in the simulation results for the mpc-based acc, similar to the classical acc design, the objectives of speed and spacing control are achieved. compared to the classical acc design, the mpc-based acc is more aggressive as it uses full throttle or braking for acceleration or deceleration. this behavior is due to the explicit constraint on the relative distance. the aggressive behavior may be preferred when sudden changes on the road occur, such as when the lead car changes to be a slow car. to make the controller less aggressive, open the mask of the adaptive cruise control system block, and reduce the value of the controller behavior parameter. as previously noted, the spikes in the middle plot are due to the uncertainties in the sensor model.

to view the results of the simulation with the mpc-based acc, use the following command.

helperplotaccresults(logsout,default_spacing,time_gap)

in the following, the functions of each subsystem in the test bench model are described in more detail. the adaptive cruise controller with sensor fusion subsystem contains two main components:

open_system('acctestbenchexample/acc with sensor fusion')

tracking and sensor fusion

the tracking and sensor fusion subsystem processes vision and radar detections coming from the vehicle and environment subsystem and generates a comprehensive situation picture of the environment around the ego vehicle. also, it provides the acc with an estimate of the closest car in the lane in front of the ego vehicle.

open_system('accwithsensorfusionmdlref/tracking and sensor fusion')

the main block of the tracking and sensor fusion subsystem is the block, whose inputs are the combined list of all the sensor detections and the prediction time. the output from the multi-object tracker block is a list of confirmed tracks.

the block concatenates the vision and radar detections. the prediction time is driven by a clock in the vehicle and environment subsystem.

the detection clustering block clusters multiple radar detections, since the tracker expects at most one detection per object per sensor.

the findleadcar matlab function block finds which car is closest to the ego vehicle and ahead of it in same the lane using the list of confirmed tracks and the curvature of the road. this car is referred to as the lead car, and may change when cars move into and out of the lane in front of the ego vehicle. the function provides the position and velocity of the lead car relative to the ego vehicle and an index to the most important object (mio) track.

adaptive cruise controller

the adaptive cruise controller has two variants: a classical design (default) and an mpc-based design. for both designs, the following design principles are applied. an acc equipped vehicle (ego vehicle) uses sensor fusion to estimate the relative distance and relative velocity to the lead car. the acc makes the ego vehicle travel at a driver-set velocity while maintaining a safe distance from the lead car. the safe distance between lead car and ego vehicle is defined as

where the default spacing , and time gap are design parameters and is the longitudinal velocity of the ego vehicle. the acc generates the longitudinal acceleration for the ego vehicle based on the following inputs:

considering the physical limitations of the ego vehicle, the longitudinal acceleration is constrained to the range [-3,2] .

in the classical acc design, if the relative distance is less than the safe distance, then the primary goal is to slow down and maintain a safe distance. if the relative distance is greater than the safe distance, then the primary goal is to reach driver-set velocity while maintaining a safe distance. these design principles are achieved through the min and switch blocks.

open_system('accwithsensorfusionmdlref/adaptive cruise controller/acc classical')

in the mpc-based acc design, the underlying optimization problem is formulated by tracking the driver-set velocity subject to a constraint. the constraint enforces that relative distance is always greater than the safe distance.

to configure the adaptive cruise control system block, use the parameters defined in the helperaccsetup file. for example, the linear model for acc design , and is obtained from vehicle dynamics. the two switch blocks implement simple logic to handle large numbers from the sensor (for example, the sensor may return inf when it does not detect an mio).

open_system('accwithsensorfusionmdlref/adaptive cruise controller/acc model predictive control')

for more information on mpc design for acc, see (model predictive control toolbox).

vehicle and environment

the vehicle and environment subsystem is composed of two parts:

open_system('acctestbenchexample/vehicle and environment')

the vehicle dynamics subsystem models the vehicle dynamics with the bicycle model - force input block from the automated driving toolbox. the vehicle dynamics, with input (longitudinal acceleration) and front steering angle , are approximated by:

in the state vector, denotes the lateral velocity, denotes the longitudinal velocity and denotes the yaw angle. the vehicle parameters are provided in the helperaccsetup file.

the outputs from the vehicle dynamics (such as longitudinal velocity and lateral velocity ) are based on body fixed coordinates. to obtain the trajectory traversed by the vehicle, the body fixed coordinates are converted into global coordinates through the following relations:

the yaw angle and yaw angle rate are also converted into the units of degrees.

the goal for the driver steering model is to keep the vehicle in its lane and follow the curved road by controlling the front steering angle . this goal is achieved by driving the yaw angle error and lateral displacement error to zero (see the following figure), where

the desired yaw angle rate is given by ( denotes the radius for the road curvature).

the actors and sensor simulation subsystem generates the synthetic sensor data required for tracking and sensor fusion. before running this example, the driving scenario designer app was used to create a scenario with a curved road and multiple actors moving on the road. the roads and actors from this scenario were then exported to the matlab function acctestbenchscenario.m. to see how you can define the scenario, see the scenario creation section.

open_system('acctestbenchexample/vehicle and environment/actors and sensor simulation')

the motion of the ego vehicle is controlled by the control system and is not read from the scenario file. instead, the ego vehicle position, velocity, yaw angle, and yaw rate are received as inputs from the vehicle dynamics block and are packed into a single actor pose structure using the packego matlab function block.

the block reads the actor pose data from the scenario variable loaded in the workspace. the model runs acctestbenchscenario.m to load the scenario into the workspace at the start of simulation. you can also load the scenario by clicking the run scenario script button in the model. the block converts the actor poses from the world coordinates of the scenario into ego vehicle coordinates. the actor poses are streamed on a bus generated by the block. in this example, you use a block and block. both sensors are long-range and forward-looking, and provide good coverage of the front of the ego vehicle, as needed for acc. the sensors use the actor poses in ego vehicle coordinates to generate lists of vehicle detections in front of the ego vehicle. finally, a clock block is used as an example of how the vehicle would have a centralized time source. the time is used by the multi-object tracker block.

scenario creation

the driving scenario designer app allows you to define roads and vehicles moving on the roads. for this example, you define two parallel roads of constant curvature. to define the road, you define the road centers, the road width, and banking angle (if needed). the road centers were chosen by sampling points along a circular arc, spanning a turn of 60 degrees of constant radius of curvature.

you define all the vehicles in the scenario. to define the motion of the vehicles, you define their trajectory by a set of waypoints and speeds. a quick way to define the waypoints is by choosing a subset of the road centers defined earlier, with an offset to the left or right of the road centers to control the lane in which the vehicles travel.

this example shows four vehicles: a fast-moving car in the left lane, a slow-moving car in the right lane, a car approaching on the opposite side of the road, and a car that starts on the right lane, but then moves to the left lane to pass the slow-moving car.

the scenario can be modified using the driving scenario designer app and exported and saved to the same scenario file acctestbenchscenario.m. the scenario reader block automatically picks up the changes when simulation is rerun. to build the scenario programmatically, you can use the helperscenarioauthoring function.

plotaccscenario

generating code for the control algorithm

although the entire model does not support code generation, the accwithsensorfusionmdlref model is configured to support generating c code using embedded coder software. to check if you have access to embedded coder, run:

hasembeddedcoderlicense = license('checkout','rtw_embedded_coder')

you can generate a c function for the model and explore the code generation report by running:

if hasembeddedcoderlicense
    rtwbuild('accwithsensorfusionmdlref')
end

you can verify that the compiled c code behaves as expected using software-in-the-loop (sil) simulation. to simulate the accwithsensorfusionmdlref referenced model in sil mode, use:

if hasembeddedcoderlicense
    set_param('acctestbenchexample/acc with sensor fusion',...
        'simulationmode','software-in-the-loop (sil)')
end

when you run the acctestbenchexample model, code is generated, compiled, and executed for the accwithsensorfusionmdlref model. this enables you to test the behavior of the compiled code through simulation.

conclusions

this example shows how to implement an integrated adaptive cruise controller (acc) on a curved road with sensor fusion, test it in simulink using synthetic data generated by the automated driving toolbox, componentize it, and automatically generate code for it.

% close any systems opened during execution of this example.
endingopensystems = find_system('matchfilter', @simulink.match.allvariants);
bdclose(setdiff(endingopensystems,startingopensystems))