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 + ∆ where

Host_Vel is Host Vehicle velocity
TimeGap 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
Sensors:
Four Wheel
USER
Sensors, Brake
SENSOR
INTERFACE Pedal Sensor,
SENSOR FUSION Throttle Pedal
TAC TA Senor, Radar …

CONTROL Actuators:
UNIT
Brake Actuator,
Throttle Actuator.
DETECTION

TRACKING
TARGET

TARGET

BAC BA
RADAR

Controllers:
High level & Low
level controller.

Communication
Medium
 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(1≤i≤4), 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

…
t si D

… … 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 LeadDist RoD Mode
change? FAR DECR-FAST SC
FAR INCR-FAST NC
LeadDist OR FAR DECR-SLOW NC
FAR INCR-SLOW NC
RoD OR
CLOSE ---- 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 Robot)
• Printer Port Ver – 1: Leader and Follower

Hardware Expert: Sachitanand Malewar

 Follower Version-2

Front view Side View

• UDM
• Range: 2m, Accuracy: ± 1cm, Sampling Rate: 10 per sec
• Shaft Encoder
• 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 Real-
Time Data Base.
• Is printer port good enough or need for RT-
Communication (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; Jörgen 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