Adaptive Cruise Control(1)

8/3/2019 Adaptive Cruise Control(1)

1/43

Adaptive Cruise Control

Advisor(s):

Prof. Krithi Ramamritham

Prof. S. RameshProf. Kavi Arya

Gurulingesh R.

KReSIT, IIT Bombay


2/43

Overview

Introduction

Components

Design Implementation

Results and Observations

Further Work

References

Demo/Video


3/43

Goals of the Project

Study the ACC application and to identify

Components

Algorithms Real-Time Issues

Real-Time approach to Design

Setup a basic platform


4/43

Introduction to ACC

Extension ofCruiseControl.

Operates either in

DistanceControlstate

SpeedControlstate

Des_Dist = Host_Vel * Timegap + where

Host_Vel is Host Vehicle velocity

TimeGap is set by the driver

for additional safety


5/43

Requirements

Functional: Detect leading vehicle.

Maintain desired speed.

Maintain desired timegap.

Communicate actions to User Interface

Non-Functional (timing constraints):

Response Time

Data update rate and so on

ISO Limitations:

mean dec 3.0 m/s2 (over 2 s),

acceleration 2 m/s2


6/43

Overview

Introduction

Components

Design

Implementation


Further Work

References


7/43

Components of ACC

CONTROL

UNIT

SENSOR

FUSIONSENSOR

RADAR

TARGET

DETECTION

TARGET

TRACKING

USER

INTERFACE

BAC

TAC TA

BA

Sensors:

Four Wheel

Sensors, Brake

Pedal Sensor,

Throttle Pedal

Senor, Radar

Actuators:

Brake Actuator,

Throttle Actuator.

Controllers:

High level & Low

level controller.

Communication

Medium


8/43

Overview

Introduction

Components

Design

Implementation


Further Work

References


9/43

Functionality and Data Flow


10/43

Controller State Diagram

State Variab

les1. Current speed

2. Cruise Status

3. Brake

4. Throttle

5. Leading Vehicle

6. Driver Intervention

Possible Events:Curr-speed > 25 km/h

Radar contact found

Driver intervention

Lead-distance > safe-dist and so on.


11/43

State Switching Issue

When to switch state?S-to-D: Curr_Dist < TimeGap * Host_Vel +

D-to-S: (Host_Vel > Des_Vel) ||

(Curr_Dist TimeGap * Host_Vel + )

Chattering

S-to-D: Curr_Dist < TimeGap * Host_Vel + - hyst

D-to-S: (Host_Vel > Des_Vel) ||

(Curr_Dist TimeGap * Host_Vel + + hyst

&& RoD 0

&& RoD 0)

where RoD is Rate of change of Distance


12/43

Task and Data Items

Tasks:

WheelTi(1i4), SpeedT, RadarT, DriverT, SwitchT,

ExceptionT, AdjLaneT, FrictionT, AdaptT, ModeSwT.

Data Items:

WheelSpeed[wi], HostVel, LeadVel, LeadDist, RoadType,

LeftLane[vi, di], RightLane[vi, di], DesAcc, DesSpeed.


13/43

Issues

1. Dynamically varying data

Prepare for the Worst

Over-Sampling

Dist

Time


14/43

Issues (cont)

2. When to Update

Unnecessary Updates


15/43

Issues (cont)

3. All Tasks and Data throughout the

system operation??

Poor CPU utilization

Not modular

Scheduling Overhead

AdaptT when lead car is near

AdjLaneT, TimeLeftT when car is far


16/43

Approach

Mode-Change System Exclusive modes of operation

Mode change leads to:

Addition of a task Change in frequency of execution

Deletion of a task

Data Repository (Neera Sharma)

updates in response to changes in the data

items (on-demand update).


17/43

Approach (cont)

Mode-Change System Dynamically varying data

All Tasks and Data throughout the system

operation

Data Repository

Dynamically varying data Derived Data Items


18/43

Issues

With mode-changes: How many modes

What triggers mode change

When to switch mode

Chattering

Mode-change delay

Schedulability

With Data Repository

How many levels

When to update


19/43

Solution to mode-change

How many?

Two: Safety-Critical(SC), Non-Safety Critical(NC)

When to switch? Finish task execution.

Mode-change delay

Boundedby longest periodicity task.

Schedulability

Static checking.


20/43


What triggers modechange?LeadDist RoD Mode

FAR DECR-FAST SC

FAR INCR-FAST NC

FAR DECR-SLOW NC

FAR INCR-SLOW NC

CLOSE ---- SC

FOLLOW ---- RETAINLeadDist & RoD

LeadDist OR

RoDO

R


21/43


Chattering

In SC Mode:

(Safe_Dist+

< Curr_Dist Follow_Dist-

) ||(Follow_Dist+ < Curr_Dist Radar_Dist && RoD = DECR-FAST) ||

(Follow_Dist- < Curr_Dist Follow_Dist+ && Curr_Mode = SC)

In NC Mode:

(Follow_Dist+ < Curr_Dist Radar_Dist && RoD DECR-FAST) ||

(Follow_Dist- < Curr_Dist Follow_Dist+ && Curr_Mode = NC)


22/43

Solution to Data Repository

How many levels

Example:

First-Level: Raw data from radar, wheel sensor, etc

Second-Level: Host Velocity, Lead Distance, etc


23/43

Solution to Data Repository

When to update

First-Level: Continous

Second-Level: On-Demand based on R(d)


24/43

Scheduling

Mode-Change approach

All Tasks are identified in advance.

All tasks are periodic. RMS

Data Repository approach

Aperiodic tasks.

Guarantee to aperiodic tasks.

CBS


25/43

Overview

Introduction

Components



Further Work

References


26/43

Implementation

Hardware

Ultra-sonic Distance Meter (UDM)

Purpose: leading vehicle

distance

Range: 1.3m

Accuracy: 2.5cm

Sampling Rate: 1 per sec

Shaft Encoder (ENC)

Purpose: Host Velocity

Resolution: 1 cm per step

Communication (PC Robot)

Printer Port Ver 1: Leader and Follower

Hardware Expert: SachitanandMalewar


27/43

Follower Version-2

Front view Side View

UDM

Range: 2m, Accuracy: 1cm, Sampling Rate: 10 per sec

Shaft Encoder

Resolution: 0.4cm


28/43

Software Implementation

Two-Level Repository Approach

CBS Scheduling


29/43


Mode-Change Approach

Same task structure with:

dummy tasks in each mode.

Mode-switch task.

All Tasks are periodic.

RMS Scheduling

Mode change after the completion of least

priority task.

Delay bounded by its periodicity.


30/43


Mode-Change Approach (cont)

Task Periodicity (in seconds):

UDM_WR: 0.2 ENC_WR: 0.3

UDM_RD, UDM_VEL: 0.4

ENC_RD: 0.6

CTRL_TASK: 0.7

MODE_SW: 0.4 ( = UDM_RD)


31/43


Data Logging:

RT-FIFO RTLinux Architecture


32/43

Overview

Introduction

Components


Results andObservations

Further Work

References


33/43

Results & Observations

Cruise Control Operation

Set speed = 35 m/s2

Open-loop lowercontroller

Shaft encoder

error


34/43


Constant Leading Distance

LeadDist = 63 cm

Timegap = 1.8 s


35/43


Linear Increase-Decrease Timegap = 1.5 s


36/43


Two-Level Repository

Tested for UDM_RD Task

Lead Dist = 69 cm


37/43

Overview

Introduction

Components



FurtherWork

References


38/43

More Experiments

Effect of mode-change delay

Improve in CPU utilization

LeadDist, RoD values

Periodicity of tasks, data update rate

Chattering b/w SC-NC Mode Switching

BETTER VEHICLE


39/43

Further Work

More experiments to evaluate the design.

Implementing two-level repository on Real-

Time Data Base.

Is printer port good enough or need forRT-

Communication (TTP/TTCAN/CAN).

Merging with Lane Changing.

Inter-Vehicle communication.

Formal modeling using UPPAAL/KRONOS.


40/43

Goals Revisited

Study the ACC application and to identify

Components

Algorithms

Real-Time Issues

Real-Time approach to Design

Setup a basic platform


41/43

References

Petros Ioannou; Cheng-Chih Chien. Autonomous IntelligentCruise Control. IEEE Trans. On Vehicular Technology,42(4):657-672, 1993.

Thomas Gustafsson; Jrgen Hansson. Dynamic on-demand

updating of data in real-time database systems.In Proceedings of ACM SAC 2004.

Gerhard Fohler; Flexibility in Statically Scheduling Real-TimeSystems. PhD Thesis, Technischen Universitat Wien Austria,

Apr. 1994.

L. Sha; R. Rajkumar; J. Lehoczky; K. Ramamritham. ModeChange Protocols forPriority-Driven Preemptive Scheduling.Technical Report: UM-CS-1989-060, University of

Massachusetts Amherst, MA, USA.


42/43

Video Clip


43/43

THANK YOU

Adaptive Cruise Control(1)

Documents

Transcript of Adaptive Cruise Control(1)