Adaptive Cruise Control

1
Adaptive Cruise Control
Gurulingesh R. KReSIT, IIT Bombay

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

2
Overview

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

3
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
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
5
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
Overview

• Introduction
• Components
• Design
• Implementation
• Results and Observations
• Further Work
• References

7
Components of ACC
Sensors Four Wheel Sensors, Brake Pedal Sensor,
Throttle Pedal Senor, Radar Actuators Brake
Actuator, Throttle Actuator. Controllers High
level Low level controller. Communication
Medium
USER INTERFACE
SENSOR FUSION
SENSOR
TAC
TA
CONTROL UNIT
TARGET DETECTION
TARGET TRACKING
RADAR
BAC
BA
8
Overview

• Introduction
• Components
• Design
• Implementation
• Results and Observations
• Further Work
• References

9
Functionality and Data Flow
10
Controller State Diagram

• State Variables
• Current speed
• Cruise Status
• Brake
• Throttle
• Leading Vehicle
• Driver Intervention

Possible Events Curr-speed gt 25 km/h Radar
contact found Driver intervention Lead-distance gt
safe-dist and so on.
11
State Switching Issue

• When to switch state?
• S-to-D Curr_Dist lt TimeGap Host_Vel ?
• D-to-S (Host_Vel gt Des_Vel)
• (Curr_Dist TimeGap Host_Vel ?)
• Chattering
• S-to-D Curr_Dist lt TimeGap Host_Vel ? - hyst
• D-to-S (Host_Vel gt Des_Vel)
• (Curr_Dist TimeGap Host_Vel ? hyst

RoD 0
RoD 0)
where RoD is Rate of change of Distance
12
Task and Data Items

• Tasks
• WheelTi(1i4), SpeedT, RadarT, DriverT,
  SwitchT, ExceptionT, AdjLaneT, FrictionT, AdaptT,
  ModeSwT.
• Data Items
• WheelSpeedwi, HostVel, LeadVel, LeadDist,
  RoadType, LeftLanevi, di, RightLanevi, di,
  DesAcc, DesSpeed.

13
Issues

• Dynamically varying data

Prepare for the Worst
Over-Sampling
14
Issues (cont)

• When to Update

Unnecessary Updates
15
Issues (cont)

• 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
16
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
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
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
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.

20
Solution to mode-change

• What triggers mode change?

LeadDist
OR
RoD
OR
LeadDist RoD
21
Solution to mode-change

• Chattering
• In SC Mode
• (Safe_Dist lt Curr_Dist Follow_Dist-)
• (Follow_Dist lt Curr_Dist Radar_Dist RoD
  DECR-FAST)
• (Follow_Dist- lt Curr_Dist Follow_Dist
  Curr_Mode SC)
• In NC Mode
• (Follow_Dist lt Curr_Dist Radar_Dist RoD ?
  DECR-FAST)
• (Follow_Dist- lt Curr_Dist Follow_Dist
  Curr_Mode NC)

22
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
Solution to Data Repository

• When to update

First-Level Continous Second-Level On-Demand
based on R(d)
24
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
Overview

• Introduction
• Components
• Design
• Implementation
• Results and Observations
• Further Work
• References

26
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
27
Follower Version-2
Front view
Side View

• UDM
• Range 2m, Accuracy 1cm, Sampling Rate 10
  per sec
• Shaft Encoder
• Resolution 0.4cm

28
Software Implementation

• Two-Level Repository Approach

• CBS Scheduling

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

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

31
Software Implementation

• Data Logging
• RT-FIFO

RTLinux Architecture
32
Overview

• Introduction
• Components
• Design
• Implementation
• Results and Observations
• Further Work
• References

33
Results Observations

• Cruise Control Operation
• Set speed 35 m/s2

• Open-loop lower controller
• Shaft encoder error

34
Results Observations

• Constant Leading Distance
• LeadDist 63 cm
• Timegap 1.8 s

35
Results Observations

• Linear Increase-Decrease
• Timegap 1.5 s

36
Results Observations

• Two-Level Repository
• Tested for UDM_RD Task
• Lead Dist 69 cm

37
Overview

• Introduction
• Components
• Design
• Implementation
• Results and Observations
• Further Work
• References

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

40
Goals Revisited

• Study the ACC application and to identify
• Components
• Algorithms
• Real-Time Issues
• Real-Time approach to Design
• Setup a basic platform

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

42
Video Clip
43
THANK YOU