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 > 25 km/h Radar contact found Driver intervention Lead-distance > safe-dist and so on.

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

13. Dist … … … Time 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+ < 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. 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. 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 …

30. 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 …

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