Adaptive Cruise Control

Gurulingesh R. KReSIT, IIT Bombay

Advisor(s): Prof. Krithi Ramamritham Prof. S. Ramesh Prof. Kavi Arya

Overview
Introduction Components Design Implementation Results and Observations Further Work References Demo/Video

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

Introduction to ACC

Extension of Cruise Control. Operates either in Distance Control state

Speed Control state

Des_Dist = Host_Vel * Timegap +

Host_Vel TimeGap

where

is Host Vehicle velocity is set by the driver for additional safety

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

Overview
Introduction Components Design Implementation Results and Observations Further Work References

Components of ACC
USER INTERFACE SENSOR SENSOR FUSION TAC TA

Sensors: Four Wheel Sensors, Brake Pedal Sensor, Throttle Pedal Senor, Radar Actuators: Brake Actuator, Throttle Actuator. Controllers: High level & Low level controller. Communication Medium

CONTROL UNIT
TARGET DETECTION TARGET TRACKING

BAC

BA

RADAR

Overview
Introduction Components Design Implementation Results and Observations Further Work References

Functionality and Data Flow

Controller State Diagram

State Variables
1. 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.

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 && RoD 0 D-to-S: (Host_Vel > Des_Vel) || (Curr_Dist TimeGap * Host_Vel + + hyst && RoD 0)

where RoD

is Rate of change of Distance

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.

Issues
1. Dynamically varying data
Dist

Time

Prepare for the Worst Over-Sampling

Issues (cont)
2. When to Update

Unnecessary Updates

Issues (cont)
3. All Tasks and Data throughout the system operation??
AdaptT when lead car is near

AdjLaneT, TimeLeftT when car is far

Poor CPU utilization Scheduling Overhead Not modular

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).

Approach (cont)
Mode-Change System
Dynamically varying data All Tasks and Data throughout the system operation

Data Repository
Dynamically varying data Derived Data Items

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

Solution to mode-change
How many?
Two: Safety-Critical(SC), Non-Safety Critical(NC)

When to switch?
Finish task execution.

Mode-change delay
Bounded by longest periodicity task.

Schedulability
Static checking.

Solution to mode-change
What triggers mode change?
LeadDist RoD OR OR
LeadDist FAR RoD DECR-FAST Mode SC

FAR
FAR FAR CLOSE

INCR-FAST
DECR-SLOW INCR-SLOW ----

NC
NC NC SC

LeadDist & RoD

FOLLOW

----

RETAIN

Solution to mode-change
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) ||

Solution to Data Repository

How many levels

Example:
First-Level: Raw data from radar, wheel sensor, etc Second-Level: Host Velocity, Lead Distance, etc

Solution to Data Repository

When to update

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

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

Overview
Introduction Components Design Implementation Results and Observations Further Work References

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
Printer Port

Robot)

Ver 1: Leader and Follower

Hardware Expert: Sachitanand Malewar

Follower Version-2

Front view UDM Shaft Encoder

Side View

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

Resolution: 0.4cm

Software Implementation
Two-Level Repository Approach

CBS Scheduling

Software Implementation
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.

Software Implementation
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)

Software Implementation
Data Logging:
RT-FIFO

RTLinux Architecture

Overview
Introduction Components Design Implementation Results and Observations Further Work References

Results & Observations

Cruise Control Operation Set speed = 35 m/s2

Open-loop lower controller Shaft encoder error

Results & Observations

Constant Leading Distance LeadDist = 63 cm Timegap = 1.8 s

Results & Observations

Linear Increase-Decrease Timegap = 1.5 s

Results & Observations

Two-Level Repository Tested for UDM_RD Task

Lead Dist = 69 cm

Overview
Introduction Components Design Implementation Results and Observations Further Work References

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

Further Work
More experiments to evaluate the design.

Implementing two-level repository on RealTime Data Base.

Is printer port good enough or need for RTCommunication (TTP/TTCAN/CAN). Merging with Lane Changing.

Inter-Vehicle communication.
Formal modeling using UPPAAL/KRONOS.

Goals Revisited
Study the ACC application and to identify
Components Algorithms Real-Time Issues

Real-Time approach to Design Setup a basic platform

References
Petros Ioannou; Cheng-Chih Chien. Autonomous Intelligent Cruise 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-Time Systems. PhD Thesis, Technischen Universitat Wien Austria, Apr. 1994. L. Sha; R. Rajkumar; J. Lehoczky; K. Ramamritham. Mode Change Protocols for Priority-Driven Preemptive Scheduling. Technical Report: UM-CS-1989-060, University of Massachusetts Amherst, MA, USA.

Video Clip

THANK YOU