Intelligent cruise-control applications - Real-time ... - IEEE Xplore

Intelligent Cruise-Control Applications Real-Time, Embedded Hybrid Control Software

R

eal-time embedded systems have become prevalent in our everyday life. Cell phones, PDAs, televisions, washing machines, microwave ovens, and calculators all contain embedded processors. An embedded system is a special-purpose computer system built into a larger device [3]. Since many embedded systems are produced in the tensof-thousands- to millions-ofunits range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor clock speed and small memory size to cut costs. Programs on an embedded system often must run with real-time constraints; i.e., a late answer is considered a wrong answer. Often there is no disk drive, operating system, keyboard, or screen. Demands placed on the functionality, complexity, and critical nature of embedded systems are ever increasing. Modern automobiles now contain many different processors that perform functions ranging from engine control to automatic braking and vehicle stability and traction control to electronic control of power windows, mirrors, and driverseat settings. Aircraft control systems can be several orders of magnitude more complicated, due in part to a greater need for system reconfiguration from mission to mission and to fault tolerance and redundancy requirements that include having several “back-up” copies of critical sensing and actuation systems. As expectations abound for increasingly complicated embedded systems, organized real-time, embedded software development processes are needed. Current industry standards

fall short of providing reusable code which can be used with a a high degree of confidence. Our interactions with automotive partners indicate that the typical embedded software development process is as shown in Figure 1. A large pitfall of the current state of the art is that most bugs are caught in the final phases of the process, at system integration and testing time. Cor recting the problem often involves modifying the system requirements, specification, or design, and such changes are costly as they imply a signifiE: cant reworking of the system. G A IM The model-based process we present AR C , SC in this article, shown in Figure 2, places DI IA O R OT IN PH TE strong emphasis on performing as much testing © U E: TIT AG S and verification in “tight-loops’’ as possible. Thus, IM IN N CH I A M REN we hope to catch bugs early on in the development F process and minimize costs associated with fixing the problems. We choose to frame our models and controllers in the context of hybrid automata. The use of a model with wellunderstood mathematical properties allows the formal verification of the controller, and additional information about the experimental platform allows us to verify timing properties of the software. This gives us a high degree of confidence in the performance of the generated code. A hybrid verification of the controller and an analysis of timing properties are conducted through the use of third-party tools. This development process was conceived in a joint effort between the University of California at Berkeley, Ford Scientific Research Laboratories, and General Motors. We start with hybrid system models of the plant and controller,

BY ANOUCK R. GIRARD, STEPHEN SPRY, AND J. KARL HEDRICK 22

IEEE Robotics & Automation Magazine

1070-9932/05/$20.00©2005 IEEE

MARCH 2005

which allow formal verification, simulation, and automatic The CACC system can be designed code generation. Timing properties of the generated code can be checked. The approach is applied to adaptive cruise to have proven string stability, control (ACC) and cooperative ACC systems. so it could contribute to dampening While regular cruise-control (CC) systems track a desired vehicle speed, ACC systems adapt their behavior if there is a shock waves in the freeway vehicle ahead on the roadway and follow the leader vehicle at a driver-requested time gap using line-of-sight sensors such as traffic stream. radar and/or lidar. When there is no “leader’’ vehicle present, ACC defaults to conventional CC and reverts to the driver-set speed. ACC systems are now available on several production cars, including the Nissan Q45 and FX45, the Mercedes SThe vehicle and controller models are presented. Impleclass, the Lexus 330 and 430, the Audi A8, and select Jaguar mentation of the controllers on automated cars is disand Cadillac models. These production ACC systems obtain cussed—in terms of sensing issues, experimental platform their distance and closing rate information about the leading capabilities, and software implementation—and experimenvehicle through the use of forward-looking sensors. These tal results are shown. sensors are typically subject to noise, interference, false alarms, and drop-outs, and their use requires heavy filtering. This, in Vehicle Model and Controller Design turn, introduces delays into the system and limits the ability of The vehicle model used for controller development is an 11the ACC-equipped vehicles to closely follow the leader vehi- state model, which includes vehicle state dynamics, throttle cle or respond quickly to a change in its speed. A variant is cooperative ACC (CACC), where the forward-looking sensor is complemented by a wireless communication link that provides hop-by-hop, leader-to-follower updates of critical inforSystem Requirement mation. Such a system can be designed to follow vehicles with Delivery Specification higher accuracy and faster response than traditional ACC systems and should allow for freeway throughput capacity System System Specification Test increases. In addition, the CACC system can be designed to have proven string stability, so it could contribute to dampenSystem System ing shock waves in the freeway traffic stream. Design Integration This application domain makes use of several robotic technologies that are applied to intelligent transportation sysModule Module tems. Measurement systems are used to keep track of the tarDesign Test get vehicle. In particular, microwave and Doppler radars and a lidar were considered in this project. In addition, to supImplementation plement information obtained from the forward-looking sensors, wireless communications were used to provide frequent updates of key information. Automotive vehicles can Figure 1. A typical embedded software development process [1]. be very nonlinear, and the control of such systems is of paramount interest to the robotics community, as comQNX Simulation Low-Level C Code mon nonlinearities such as actuator Device Drivers saturation affect both worlds. The P/S Database intelligent CC has multiple modes and must deal with switching C++ Car, Pentiums QNX Machine between CC, ACC, and CACC in a Plant Library CA CC safe and smooth manner, a problem Code that is currently a topic of research for robotic vehicles as well as automotive applications. Finally, the software development process that we Hybrid System Schedulability Until HSIF present is equally applicable to the Verification Analysis Matures development of robot mission softThird-Party Third-Party ware. The generated code has been Tools Tools run and tested as a prototype on automated vehicles. Figure 2. The intelligent cruise-control software development process. MARCH 2005


23

Throttle

Vehicle State Dynamics

• One Continuous Time State Representing Throttle Dynamics.

• Two Continuous Time States: Position, Velocity. • Includes Vehicle Mass, Air Drag, Rolling Resistance, etc.

Spark Ignition Engine

50 0 100

60

Pm

40

20

500 600 300400 0 0 100 200 e

50 Pm

• No Continuous Time States. Two Hybrid States: Coupled & Uncoupled Transmission • Discrete Transitions Are Taken During Gear Changes Based on Vehicle Speed. • Abrupt Gear Changes Cause Abrupt Gear Ratio Changes—A Filter Is Added That Includes One Continuous Time State.

300 200 100 0 -100 -200 100

150 100

• One Continuous Time State Representing Time Response Lag

Torque Converter

• Uses Two-State Continuous Time . Nonlinear Model: ω, m a • Three External Data Maps Are Used Which Require Both One- and TwoDimensional Interpolation.

200

Brakes

400 0 0 200 e

Wheel Slip Model • Models the Tire Slip Dynamics. • Requires Four Continuous Time States—One Per Wheel.

600

Figure 3. The vehicle model (courtesy of Michael Drew [2]).

and brake system dynamics, a two-state model for the sparkignition engine (as presented in [4], including external data maps, which require interpolation) and models of the torque converter, transmission, and wheel slip, as shown in Figure 3. The vehicle state dynamics have two continuous states, vehicle position and velocity, and consider vehicle mass, air drag, and rolling resistance. The throttle and brake dynamics are both first-order, with one continuous state for each, representing actuator dynamics for the throttle and time response lag for the brakes. Complete details of the model are available in [2]. The controller design process stems from system requirements. We consider only the longitudinal control of passenger vehicles (no automatic steering). Vehicles may be heterogeneous, that is of different types, makes, and models. In our experiments, we limit ourselves to the utilization of two automated cars. This excludes cut-in scenarios for the experiments (they were considered in simulation). The automated cars are 1996 and 1997 model-year Buick LeSabres. The maximum acceleration recorded on the test track (zero to full throttle as a step) is on the order of 4m/s2 , and the maximum deceleration obtained during this project on the track is on the order of −4m/s2 , obtained manually. Dynamic capabilities of the vehicles must also be considered. Environmental limitations include wanting to avoid stationary 24


objects, such as trees and a fence that runs the length of the test track. The desired behavior for the automated vehicle is to perform CC if the road is clear. Otherwise, it is to follow the vehicle in front at a predetermined time gap. The controller was split hierarchically between an upper level controller that has several modes, namely CC, ACC, and CACC. In ACC mode, we use only information from the host vehicle’s forward-looking sensors, and in CACC mode, we supplement this information with data from the wireless communication system. The upper control generates a desired host-vehicle acceleration, which is sent to the lower level controller. The lower level controller converts this desired acceleration to a desired torque, then chooses whether to apply the brakes or throttle and in what amount [5]. The desired throttle angle is computed using an engine map. The brake control controls the master cylinder pressure. A pressure regulator valve controls the pressure applied on the hydraulic actuator. Seal friction exists in the master cylinder and the actuator, and a small amount of hysteresis is present in the pressure regulation valve. The friction is modeled as hyperbolas from various points in the hysteresis loop and can be written as MARCH 2005

Pmc = g(u).

Feed-forward plus proportional feedback control is used, as developed in [6]. The control law can be written as ub = g −1 (Pmc ) + kb (Pmc

des

The control law was designed using sliding control, where a surface is usually defined as a function of the error, derivatives of the error, and/or integrals of the error. The surface is defined so the state will exponentially decay along the surface to the desired point. The input is chosen to guarantee that the state will converge and stay on the sliding surface. We define the error e as

− Pmc ), e = R − Rd ,

where ub is the applied command input to the brake solenoid valve, Pmc des the desired master cylinder pressure, Pmc where the range R is defined as R = x1 − x2 , R˙ = x˙ 1 − x˙ 2 , the measured master cylinder pressure, and kb > 0 a feed- and R¨ = x¨ 1 − x¨ 2 = a 1 − a 2 . Let a 2 = a 1 − v. Then R¨ = v. back gain. Let v = R¨ d − k d e˙ − k p e . Then e¨ + k d e˙ + k p e = 0. Figure 5 shows data taken during an acceleration-tracking The control law obtained by feedback linearization is run on the test car, using the low-level control law. The a 2 = a 1 − Rd + kd e˙ + kp e. desired acceleration is a square pattern. On the first line, the velocity, acceleration, and desired acceleration are shown versus time. Low-Level Control High-Level Control The second line has the desired Desired Acceleration State of Car and actual brake pressure and throttle angle versus time. DB1

DB2

Acceleration to Torque Cruise-Control Law OFF The purpose of cruise control is to Switching Law maintain a desired velocity. A vehiCC ACC cle may be in cruise-control mode if Throttle Brake it is not equipped with ACC or CACC, has no vehicle immediately Throttle, Brake, State of Car Desired Acceleration in front of it, has at least 100 m of clearance to the preceding vehicle, Figure 4. The decomposition of the vehicle-control system in modes. or as decided by the human driver. The controller uses a feedback and feed-forward control law of the form: 15

where a d is the desired acceleration of the vehicle, v is the speed of the vehicle, v d is the desired speed of the vehicle, and k is a gain set to 0.75.

10

ACC and CACC Law The control law for ACC and CACC is identical. The main difference between both modes is in the sensor fusion and in the quality of the state information. Also, the operating logic is different in both modes. The purpose of an ACC or CACC law is to regulate the range between vehicles to a user-selected value and to adjust the vehicle speed to the speed of downstream traffic. Velocity dependent (headway) control is used, with

Acceleration (m/s2)

Velocity (m/s)

a d = v˙d − k(v − v d ),

CACC

2 1 0

5

−1

0 0

20

40

60

Brake Pressure (psi)

600

−2 0

20

40

60

Throttle Angle, Desired and Measured (°)

15 10

400

5 200 0 0

0

20

40

60

−5

0

20

40

60

Rdes = λv + µ. Typical values for headway time range are 1.8–0.7 s. MARCH 2005

Figure 5. The results of an acceleration tracking run on a test track. Green quantities are actual, red are measured, and blue are filtered.


25

Automotive vehicles can be very nonlinear, and the control of such systems is of paramount interest to the robotics community, The first two terms in the control law are feed forward, and the last two are feedback.

Software Development Process

COURTESY OF PATH PUBLICATIONS

We used a model-based approach throughout the control and software development. We phrased the vehicle models as hybrid automata and used the TEJA [7] language to simulate and exercise the models. We designed our controllers and also phrased them as hybrid automata in TEJA. This allowed us to perform simulation over a wide range of conditions. In particular, switching conditions from one mode to the next (for example, ACC to CACC) were designed by hand and were tested carefully. In addition, hybrid system verification was conducted to answer questions such as “will the distance between the two vehicles ever become less than zero?’’ (an undesirable circumstance). Results were obtained by several different groups and can be found in [8]. TEJA allows true control and software architecture codesign; the programmer can organize his/her hybrid automata into tasks, allocate tasks to processors (manually), and select communication mechanisms between distributed processors or between separate tasks. The chosen architecture can then be simulated, and C or C++ code can be generated for each task independently. This allows us to maintain a single model containing all of our control and software information. The code generated from TEJA for the controllers interfaces with legacy code, such as device drivers, driver display units, etc. through the use of a shared-memory database on the “publish-and-subscribe’’ model. On the experimental test vehicles, all of the software is run on Pentium computers with the QNX4 .25 real-time operating system. After experimental testing, calibrations may be made to the controller by modifying the original TEJA automata, then regenerating the TEJA code.

Figure 6. The experimental test vehicle. 26


Implementation and Experimental Results The TEJA-generated software for CC, ACC, and CACC was run on experimental test vehicles operated by California PATH. Sensor Issues In the TEJA simulation, we considered that we had range and closing rate information available (for ACC, supplemented by communicated acceleration and maximum braking rates for CACC) for a target vehicle located ahead of the host vehicle. We considered noise models for the range, closing rate, and lead-vehicle acceleration and dropped packets and bandwidth limitations for the communicated data. However, the sensors that were mounted on the test vehicles did not have such simple outputs. We used two different types of radar and a lidar, in addition to the wireless communications (conducted over 802.11b). The first radar we considered is a microwave radar that was custom made by Delco for vehicle platooning operations. It operates in the millimeter-wave region at 76–77 GHz and has a narrow beam and a range of approximately 40 m. The short range made this radar useless for highway-speed type ACC, but very useful for slow-speed, stop-and-go type ACC and CACC that were also developed as part of this project. The second radar we considered is a Doppler (monopulse) radar, part of the EVT300 collision warning system (EatonVorad Technologies), with a 12° beam width. It provides range, derivative of range, and azimuth information for up to seven targets; has a range of approximately 100 m; and, due to its operating principles, provides no information on objects having zero relative velocity. The lidar we used is a Mitsubishi unit with a field of view of 12° (±6°) in the horizontal plane. It provides distance and intensity values for each of 80 equal segments over the 12° of field of view. Due to the nature of the sensors, the raw sensor data must be processed to provide fused information about a single target vehicle—ahead of the host vehicle and in the same lane— that is used by the control algorithm. Several strategies were evaluated for processing the radar and lidar data, including limiting potential targets to those in a target zone, which can be shaped to accommodate for curves in the road using information from a gyro, placing thresholds, target locking based on persistence over time, and eliminating nonfeasible objects. In addition, the algorithms were developed to function both in highway conditions (high speeds, low curvature) and in stop-and-go conditions (low speeds, and obstacles such as parked cars and pedestrians on the road). This presented an additional level of difficulty. Details about the sensor processing and fusion algorithms can be found in [5]. Experimental Platform The experimental vehicles are 1996 and 1997 model-year Buick LeSabres. They are equipped with throttle, brake and steering actuating systems, as well as with numerous sensors, including accelerometers, wheel speed sensors, engine speed MARCH 2005

and manifold pressure sensors, and magnetometers used as part of the lateral control. In addition, for our project, both radars and the lidar previously described were mounted to the the vehicles’ front bumpers. There are two control computers located in the trunk. Both run the QNX 4.25 operating system and communicate over serial port connections. The computers run a host of tasks necessary for automated control of the vehicles, including reading sensor data and writing to actuators, performing control computations such as those described earlier for the ACC/CACC system and low-level controllers, and conducting tasks pertaining to driver display information. There are about 30 different tasks running on the most heavily loaded of the control computers. Tim15 ing is fairly critical as human test drivers are in the cars during runs and their safety is paramount. Conse10 quently, we teamed up with another Model-Based Integration of Embedded Systems (MoBIES) team at 5 Carnegie Mellon University to perform schedulability analysis of all tasks, using rate monotonic scheduling 0 algorithms [9]. Execution times for the different tasks 0 were measured on the control computer, and a choice of priorities to set the tasks in QNX was found that 800 guarantees that timing properties are not violated.

The algorithms were developed to function both in highway conditions and in stop-andgo conditions

Velocity (m/s)

Acceleration (m/s2)

3 2 1 0 −1

20

40

−2

80

60

Brake Pressure (psi)

0

15

600

20

40

60

80

Throttle Angle, Desired and Measured (°)

10

Experimental Results Figure 7 shows a velocity-tracking run on the test car 5 400 using the cruise controller. The vehicle is tracking a 0 200 half-sine wave in velocity, as shown in the top-left portion of the figure. 0 −5 0 20 40 60 80 0 20 40 60 80 The speed limit on the Berkeley test track is 25 mph. Higher-speed testing is done regularly at a remote facility. Results for a CACC run on the Figure 7. The results of the velocity-tracking cruise control run on the test track. The green quantities are actual, the red are measured, and Berkeley test track are presented in Figure 8. the blue are filtered. The vehicle speeds match well, especially when the discontinuous nature of the speed profile is taken into consideration. A constant-range policy was used for this particular low-speed test, and the range between the vehicles CACC–Velocities of Leader and Follower Cars was maintained at 15 m throughout the test. 12 10

This article presents the use of a model-based approach to the development of real-time, embedded, hybrid control software. The concepts are illustrated with a scenario involving speed-profile tracking and vehicle following applications for passenger vehicles. The model-based approach was developed in partnership between the University of California at Berkeley, Ford Research Labs, and GM. An ACC and CACC system has been tested in prototype phase, both at highway speeds and in stop-and-go situations (such as driving in congested traffic). Robotic technologies, such as range, velocity, and acceleration measurements, and their processing and fusion were used as part of the system. In addition, vehicles can present very nonlinear behavior, especially at low speeds, and their control presents a formidable challenge. MARCH 2005

Speed (m/s)

Conclusions

8 6 4 2 0 –2

0

10

20

30

40 50 Time (s)

60

70

80

90

Figure 8. The results of the CACC cruise control run on the test track. The green line indicates the velocity of the lead car, the red lines the velocity of the follower car, the blue lines indicate relative velocity as obtained from the communications and radar filtering. IEEE Robotics & Automation Magazine

27

The problem domain of intelligent cruise-control applications has been described in detail, along with control and software development methodologies. We are currently working on applying the same model-based approach to the development of intelligent cruise-control systems for automated transit buses.

Acknowledgments This work was supported by DARPA/ITO in the MoBIES project under Grant F33615-00-C-1698. The authors would like to acknowledge the assistance of the Experimental Group at California PATH, in particular, Dan Empey and Paul Kretz for their assistance with vehicle instrumentation, testing and data collection and Adam Howell and Mike Drew with TEJA model development and testing. Figure 6 is courtesy of PATH publications. Special thanks to Hayley Sudeith for her help with formatting.

Keywords Intelligent cruise control, hybrid control software, real-time embedded systems, speed-profile tracking, vehicle following, model-based approach.

References [1] K. Henry, GM Research, private communication, Mar. 2001. [2] M. Drew and J.K. Hedrick, “A discussion of vehicle modeling for control,’’ Vehicle Dynamics Lab Tech. Rep., Mechanical Engineering Department, Univ. California, Berkeley, CA, Tech. Rep. 2002-102. [3] Wikipedia, the Free Encyclopedia. [Online] Available: http://www. wikipedia.org/wiki/Embedded_system [4] D. Cho and J.K. Hedrick, “Automotive engine modeling for control,’’ ASME J. Dyna. Syst., Measure. Contr., vol. 111, pp. 568–576, Dec. 1989. [5] A.R. Girard, S.C. Spry, P.R. Kretz, S.R. Dickey, D.M. Empey, J.A. Misener, P.P Variaya, and J.K. Hedrick, “Vehicle-to-vehicle open experimental platform reference manual,’’ Report to DARPA on the MoBIES Project. [Online] Available: http://robotics.eecs.berkeley. edu/~anouck/v2v_report.pdf [6] D.B. Maciuca and J.K. Hedrick, “Advanced nonlinear brake system control for vehicle platooning,’’ in Proc. 3rd European Control Conf., Rome, Italy, 1995, vol. 3, pp. 2402–2407. [7] Teja. [Online] Available: http://www.teja.com [8] Franjo Ivancic, “Report on verification of the MoBIES vehicle-vehicle automotive OEP problem,” Univ. Pennsylvania, Philadelphia, Tech. Rep. MS-CIS-02-02, Mar. 2002. [9] TimeSys Corp. [Online]. Available: http://www.timesys.com

Anouck R. Girard received her M.Sc. in ocean engineering from Florida Atlantic University in 1998 and her Ph.D. in engineering from the University of California (UC) Berkeley in 2002. She is an assistant professor of mechanical engineering at Columbia University. She teaches classes related to control systems and engineering design. She was a postdoctoral researcher and lecturer at UC Berkeley from 2002–2004. Her

28


research interests include control and optimization; systems engineering; marine robotics and autonomous vehicles; realtime control systems, tools, and algorithms; distributed control of hybrid systems; networked multivehicle systems; and Webbased control systems education. Stephen Spry received his Ph.D. in mechanical engineering from the University of California (UC) Berkeley in 2002. He is a postdoctoral researcher at UC Berkeley. His research interests are in coordinated vehicle control. J. Karl Hedrick received his B.S. in engineering mechanics from the University of Michigan in 1966. He received an M.S. in aerospace and astronautics engineering and a Ph.D. in aerospace and astronautics engineering from Stanford University in 1970 and 1971, respectively. He is the James Marshall Wells Professor and Chairman of Mechanical Engineering at the University of California (UC) Berkeley. He teaches graduate and undergraduate courses in automatic control theory and vehicle dynamics. The active suspension laboratory at UC Berkeley is the only full-scale, half car test facility in the United States. Before coming to Berkeley, he was a professor of mechanical engineering at MIT from 1974–1988, where he served as director of the Vehicle Dynamics Laboratory. His research has concentrated on the development of advanced control theory and on its application to a broad variety of transportation systems, including automated highway systems, collision warning systems, collision avoidance systems, and ACC systems. His work has also included brake control and electronic suspension systems. He has also worked in the power train control area, including engine and transmission control. He has served on many national committees, including the Transportation Research Board, the American National Standards Institute, International Standards Organization (ISO), and the National Cooperative Highway Research Program (NCHRP). He is currently a member of the board of directors and vice president of the International Association of Vehicle System Dynamics (IAVSD) and is the editor of the Vehicle Systems Dynamics Journal. He is a Fellow of the American Society of Mechanical Engineers (ASME), where he has served as chair of the Dynamic Systems and Controls Division and as chair of the Honors Committee. He is a member of the Society of Automotive Engineers (SAE). Address for Correspondence: Anouck Girard, Mechanical Engineering Department, Columbia University, 228 SW Mudd Building, Room 228, MC 4703, 500 West 120th St, New York, NY 10027 USA. Phone: +1 212 854 2962. Fax: +1 212 854 3304. E-mail: [email protected].

MARCH 2005