Active safety and autonomous collisions avoidance systems are very complex to say the least. With dynamic, hardware, computing, and sensory considerations these systems cover a broad range of engineering disciplines and exhibit non-linear behaviors that make them difficult to design and evaluate. Interesting results often only appear after complete immersion and hours of testing. The primary purpose of this project’s crash avoidance system is to serve as a research platform to ascertain how drivers interact and perceive this technology and to further develop the collision avoidance algorithms to better coincide with driver’s expectations. It is important that driver’s perception of this technology does not hinge on the specific implementation or algorithms but rather on the technology as a whole. The simulator and analysis toolchain created for this project help to facilitate development of the system to help ensure that this is the case. Active safety systems and vehicle automation has the potential to save thousands of lives and billions of dollars. The degree to which drivers are ready to embrace this technology in their own vehicles is a significant factor in achieving widespread implementation and hinges on how well the controller performs.
Through testing it was seen that the threat determination, and thus the switch between driver and computer control, plays a crucial role in determining the performance and behavior of a semi-autonomous collision avoidance system. For example, a very aggressively tuned threat leads the vehicle to exude more fully autonomous behavior where the driver’s steer inputs are largely ignored. A lightly tuned threat yields a system with functionality that more closely resembles driver assistance behavior where the controller’s effect may only be realized by the driver if they completely take their hands
151
off of the wheel. A lightly tuned threat keeps the vehicle in the center of the roadway; however, the driver inputs can win out forcing the vehicle to exit the roadway. Both of these threat behaviors can be traced back to the binary switch between computer and driver control and the frequency at which this switch occurs. The more constrained the threat is, the more fully autonomous behavior is observed with less frequent switching of control back-and-forth between the driver and the computer and vice-versa. Hence, there is a balance with respect to the sensitivity of the threat when tuning the controller, which depends on the desired performance. As described in (Anderson, Peters, Pilutti, Tseng, & Iagnemma), alternative controller schemes exist that simultaneously consider the
computer and driver steer inputs. Instead of a binary switch between computer and driver control, a proportion of control is given to both by weighting the computer and driver control commands depending on the threat level. For each iteration of the control-loop, the wheel sideslip is converted into a scalar threat metric that is used in a piecewise-linear intervention function to blend the driver and controller inputs as shown in Equation 36.
𝒖𝒗𝒆𝒉𝒊𝒄𝒍𝒆= 𝑲(∅)𝒖𝑪𝒐𝒏𝒕𝒓𝒐𝒍𝒍𝒆𝒓+ (𝟏 − 𝑲(∅))𝒖𝒅𝒓𝒊𝒗𝒆𝒓 ( 36 ) As implemented, this steering-based collision avoidance system does not consider the throttle as a control parameter. This greatly complicates the use of the calculated steering commands necessary to follow the same path planned by the RRT algorithm between control-loop iterations. These steering commands are calculated based on the current speed of the vehicle. If the vehicle’s speed changes the required steering command to follow the same path must also change, as is reflected in the pure-pursuit control law discussed in chapter 2. For now, only the first steer command is used since it is calculated using the current vehicle speed. A new safe path is calculated every time the
152
control-loop runs regardless of whether the previous path is still valid. While this allows the driver to be in control of the throttle and speed of the vehicle at all times, it is
inefficient in terms of processing. Furthermore, if the throttle and speed is not held constant while performing an autonomous maneuver the dynamic region in which the controller operates may change. This can greatly affect the necessary controller output and the vehicle’s dynamic response. A controller used to avoid imminent collisions with static and moving obstacles would likely be the most effective if all control inputs were considered including braking, throttle, and steering. While this consideration is out of the scope of this project, there is great potential in using all control signals to optimize the avoidance maneuver for safety and comfort. From analysis of the paths generated by the RRT path-planning algorithm, it is apparent that it is not an optimal path-planning algorithm. The RRT can only perform so many iterations in a given amount of time and does not perform consistently with the same constraint data due to the random nature of the algorithm. Several iterations may look in the same area to place the next node despite having already failed to place a node in that area. In addition, the driver’s input has no influence on the generated path, which may be jarring to the driver if they maneuver one way to avoid an obstacle and the controller overrides the driver with a maneuver in the other direction to avoid the same obstacle. The hardware-in-the-loop simulator could be used to conduct a study to improve components of the RRT algorithm as well as
investigate the viability of alternative path-planning algorithms. Updating the RRT path- planning algorithm to follow the same path or biasing the generated path to consider the user’s input and previously searched regions could dramatically improve the controller’s ability to avoid collisions. Alternatively, implementation of an efficient and optimal path-
153
planning algorithm, such as artificial potential fields (APF) seen in Figure 67, may provide more consistent results and improve performance. As discussed in (Michielsen, 2013), APF methods have been studied extensively and are extremely powerful and applicable for autonomous vehicle path-planning applications. With little computational overhead, APF path-planning algorithms have great potential for use in real-time semi- autonomous collision avoidance systems.
Figure 67. Path-planning with artificial potential fields
As discussed in chapter 3, an interrupt driven approach was taken in order to measure the speed of the vehicle with the wheel encoders. While this method is adequate at low speeds, it becomes increasing difficult to keep an accurate count of the wheel encoder ticks as the wheel speeds increase. With interrupts, a portion of the processor’s CPU cycles must be used to monitor the wheel encoder interrupts and count the encoder ticks, which detracts from the main program running the collision avoidance software. An alternative and more efficient approach could be taken by utilizing the three enhanced quadrature encoder package (eQEP) hardware blocks within the SoC. This would help reduce the load on the main processor while enabling higher wheel encoder resolutions without sacrificing CPU cycles. Unfortunately, this does not circumvent the use of
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 -0.5 0 0.5 X Direction Y D ir e c ti o n
154
interrupts altogether as there are only a limited number of these modules within the AM335x processor; only three wheel encoders may be monitored with this method. An even better solution would be to use one of the programmable real-time units (PRU) to completely void the main processor of monitoring the wheel encoders. The BeagleBone has two PRUs which are completely separate 200MHz cores within the processor that offer hard real-time determinism and have the great potential for further development. These cores both have their own memory for data and instructions and also share memory with the main processor to facilitate communication. The PRUs may be used to
incorporate other sensors with a high degree of resolution or to handle the serial communication with the user control station. While the PRUs are programmed in assembly, an optimized C/C++ compiler was recently released by Texas Instruments to generate the assembly code.
This system uses the LiDAR sensor to obtain point-clouds of data that represent the surrounding environment. These point-clouds are segmented and obstacles are parsed out. The obstacle properties are searched in order to differentiate between hazardous obstacles and cone obstacles that mark the road boundaries. The CMOS camera is merely used to feed a visual driver perspective to the user control station’s monitor. Future development of this system could incorporate the camera for use in image processing based algorithms to enhance system performance and functionality. With image processing, the detected obstacles could be classified and the road edges could be detected with lane markings. This could also help to track the different obstacles and to better estimate their speeds and headings. A recent FPGA cape for the BeagleBone could be used to facilitate the incorporation of a camera and to run the image processing
155
algorithms. Another interesting cape designed for the BeagleBone, called the Interacto, uses one of the PRUs to capture images from a small camera at thirty frames per second and stores the results in data shared with the main processor. This allows hard real-time image capture without any load on the main CPU. Needless to say, the BeagleBone is a very capable SBC with great opportunity for further expansion.
As mentioned above, investigation of the system’s performance around a curved roadway or oval track would be an interesting study. The vehicle’s yaw rate could be measured and used to estimate the curvature of the detected roadway. The hardware-in- the-loop simulator could be used to develop and simulate these features and also has great potential for expansion. For instance, multiple controllers could be used in the simulation while simulating multiple vehicles with the same system to observe how fleets of
vehicles with the same technology would behave. With respect to the vehicle hardware, there is significant capacity to improve the scaled vehicle’s dynamic similarity to a full size vehicle. By reconfiguring the hardware, adding weights in appropriate locations, and changing the tires on the vehicle better similarity could be achieved by matching the pi groups between a full size vehicle and the scaled vehicle platform for better dynamic similarity, as described by Brennan.
While moving obstacles are not explicitly considered in the current
implementation, this is still an effective system with the potential to greatly reduce fatalities and injuries resulting from distracted drivers. Nothing prevents this system from avoiding moving obstacles; however, the path-planning algorithm does not consider the velocity of each obstacle as the segmentation algorithm does not adequately estimate each obstacle’s velocity. The effectiveness of this algorithm to avoid moving obstacle is
156
degraded by the reduction in time available to react and no consideration of the obstacle’s speed relative to the vehicle. Even without consideration of moving obstacles, avoiding collision with static obstacles is an effective active safety technology. To put this into perspective, in 1988 44.73% of fatalities occurred from vehicles colliding with inanimate, stationary objects not found on the road (Brennan, 1997).
Automation plays a massive role in society as airplanes, vehicles, manufacturing processes, and repetitive tasks are being continuously replaced with electronic control systems that offer increases in efficiency, throughput, and safety. The way in which people interact and perceive automated systems is greatly important, especially in regards to the automation of vehicles and their navigation. Car companies are continually
improving vehicle’s safety by releasing innovative products that sense, react, and automate the operation of a vehicle. One of the most complicated aspects of active vehicle safety systems, especially semi-autonomous systems, is blending them with humans. If these systems are implemented in such ways that the driver sees them as irritating or as not controlling the vehicle as a human would they may disable these systems altogether or opt for vehicles that do not have them equipped. An described in (Richtel & Dougherty, 2015), an example of this is lane departure warning systems where some drivers found the acoustic beeping as being irritating when they purposefully
changed lanes without a turn signal. The blending of robot and human drivers also presents some interesting challenges. For example, drivers tend to look at each other at intersections, pedestrians tend to look to see if drivers are paying attention to them before crossing the street, and robot cars don’t possess eyes. Despite these hurdles, active safety systems are already available in vehicles and fully automated vehicles are soon to follow.
157
Active safety systems will likely become increasingly prevalent as the progress to fully autonomous vehicles continues. This is certainly a very exciting and active area of research that is already helping to save lives with the potential to save many more. Vehicle collisions, especially those that cause severe injuries and fatalities, will soon go the way of the dinosaur.
158
BIBLIOGRAPHY
Ahmad, S. (2013, May 31). Using PWM on the BeagleBone Black. Retrieved from http://www.saadahmad.ca/using-pwm-on-the-beaglebone-black/
Anderson, S. J., Peters, S. C., Pilutti, T. E., Tseng, H., & Iagnemma, K. (n.d.). Semi- Autonomous Avoidance of Moving Hazards for Passenger Vehicles.
Brennan, S. N. (1997). Modeling and Control Issues Associated with Scaled Vehicles. Urbana, Illinois.
CarSim. (n.d.). CarSim Mechanical Simulation. Retrieved from https://www.carsim.com/products/carsim/
Columbia University. (n.d.). Linux Scheduler. Retrieved from https://www.cs.columbia.edu/~smb/classes/s06-4118/l13.pdf
Daimler. (n.d.). PRE-SAFE Brake: The Anticipatory Brake. Retrieved from
http://www.daimler.com/dccom/0-5-1210220-1-1210348-1-0-0-1210338-0-0- 135-0-0-0-0-0-0-0-0.html
Dash, N. P., Dasgupta, R., Chepada, J., & Halder, A. (2011). Event Driven Programming for Embedded Systems - A Finite State Machine Based Approach. Kolkata, India: Innovation Lab.
Davies, A. (2014, June). Infiniti's New Steering System Is a Big Step Forward - Unless You Love Cars. Retrieved from http://www.wired.com/2014/06/infiniti-q50-steer- by-wire/
Dixon, J. C. (1996). Tires, Suspension, and Handling (2nd ed.).
Free Electrons. (2015, January). Linux Kernel and Driver Development Training. Retrieved from http://free-electrons.com/doc/training/linux-kernel
Free Electrons. (n.d.). Embedded Linux system development. Retrieved from Free Electrons Web site: http://free-electrons.com/doc/training/embedded-linux Gillespie, T. D. (n.d.). Fundamentals of Vehicle Dynamics. Society of Automotive
Engineers, Inc.
Lipari, G. (2009, May 12). Programming RT systems with pthreads. Retrieved from http://www.feanor.sssup.it/~lipari
Michielsen, J. (2013). Crash Avoidance Path Planning using Artificial Potential Fields. M.S. Thesis, California Polytechnic State Univ.
159
Milgram, J. (2003). Numerical Integration of Differential Equations. Retrieved from http://www.myoops.org/cocw/mit/NR/rdonlyres/Ocean-Engineering/13- 024Spring2003/09A5CF66-2BA1-48D4-92E6- 70EF1F26A809/0/differential_eqs.pdf: http://www.myoops.org/cocw/mit/NR/rdonlyres/Ocean-Engineering/13- 024Spring2003/09A5CF66-2BA1-48D4-92E6- 70EF1F26A809/0/differential_eqs.pdf
Miller, J., Ujiie, B., & Woods, G. (2011). Autonomous Crash Avoidance System. Senior Project Report, California Polytechnic State University, San Luis Obispo. Milliken, W. F., & Milliken, D. L. (1995). Race Car Vehicle Dynamics. Society of
Automotive Engineers.
Monster, M. (2003, November). Car Physics for Games. Retrieved from
http://www.asawicki.info/Mirror/Car%20Physics%20for%20Games/Car%20Phys ics%20for%20Games.html
MSC Software. (n.d.). Adams/Car: Real Dynamics for Vehicle Design and Testing. Retrieved from http://www.mscsoftware.com/sites/default/files/ds_adams- car_ltr_w_0.pdf
National Highway Traffic Safety Administration. (2000). Economic Impact of Motor Vehicle Crashes 2000. U.S. Department of Transportation, Washington, D.C. National Highway Traffic Safety Administration. (2007). Federal Motor Vehicle Safety
Standards; Electronic Stability Control Systems; Controls and Displays - Final Ruling. U.S. Department of Transportation, Washington, D.C.
National Highway Traffic Safety Administration. (2009). Fatalities in Frontal Crashes Despite Seat Belts and Air Bags. Washington, D.C.: U.S. Department of
Transportation.
National Highway Traffic Safety Administration. (2010). Traffic Safety Facts 2010. U.S. Department of Transportation, Washington, D.C.
Nise, N. S. (2011). Control Systems Engineering (6 ed.). John Wiley & Sons, Inc. Noxon, N. (2012). A Model Predictive Control Approach to Roll Stability of a Scaled
Crash Avoidance Vehicle. M.S. Thesis, California Polytechnic State Univ., Dept. Mech. Eng., San Luis Obispo.
Ohio University. (2008, October). Ohio University driving simulation lab to improve traffic, construction zone safety. Retrieved from
160
Oracle. (2014). The Java Tutorials: Double Buffering and Page Flipping. Retrieved from http://docs.oracle.com/javase/tutorial/extra/fullscreen/doublebuf.html
Pacejka, H. B. (2002). Tire and Vehicle Dynamics.
Palm |||, W. J. (2007). Mechanical Vibration. Hoboken, NJ: John Wiley & Sons, Inc. Palopoli, L. (n.d.). Real-Time Embedded Control. Retrieved from
http://www.disi.unitn.it/~palopoli/hycon2_slides.pdf
Richtel, M., & Dougherty, C. (2015, September 1). Google's Driverless Cars Run Into Problem; Cars With Drivers. The NY Times.
Snider, J. M. (2009). Automatic Steering Methods for Autonomous Automobile Path Tracking. Carnegie Mellon University, Pittsburgh.
Sparkfun. (n.d.). Bluetooth Basics. Retrieved from Sparkfun: https://learn.sparkfun.com/tutorials/bluetooth-
basics?_ga=1.228314781.1047042560.1418342781
Stan, A., Botezatu, N., Panduru, L., & Lupu, R. G. (2009). A Finite State Machine Model Used in Embedded Systems Software Development. Universitatea Tehnica,
Gheorghe Asachi din Iasi.
Steele, J. (1955). Motion Sickness. Shock and Vibration Bulletin(22).
Stevens, T., Birdsong, D., Painter, I., & Carlson, E. (2013). Overview of a Student Semi- Autonomous 1/10th Scale Vehicle Collision Avoidance Platform. California Polytechnic State University San Luis Obispo, San Luis Obispo.
Stevens, T., Carlson, E., & Painter, I. (2013). Autonomous Collision Avoidance Final Design Report. Senior Project Report, California Polytechnic State University, San Luis Obispo.
Tass International. (n.d.). PreScan Overview. Retrieved from https://www.tassinternational.com/prescan-overview
Taylor, P., Funk, C., & Craighill, P. (n.d.). Americans and Their Cars: Is the Romanace on the Skids? A Social Trend Report, Pew Research Center.
Texas Instruments. (2011). AM335x ARM Cortex-A8 Microprocessors (MPUs): Technical Reference Manual.
The Cooper Firm. (2014, March). How Can Electronic Stability Control Save Your Life? Retrieved from http://thecooperfirm.com/can-electronic-stability-control-esc- save-life/
161
Vahid, F., & Givargis, T. (1999). Embedded System Design: A Unified
Hardware/Software Approach. University of California Riverside, Riverside. Weilkes, M., Burkle, L., Rentschler, T., & Scherl, M. (2005, January). Future vehicle
guidance assistance - combined longitudinal and lateral control. Automatisierungstechnik, 42, 4-10.
Wymann, B. (n.d.). About TORCS. Retrieved from
http://torcs.sourceforge.net/index.php?name=Sections&op=viewarticle&artid=1 Yang, J. (n.d.). W4118 Operating Systems. Retrieved from
162 APPENDICES
Appendix A Hardware-in-the-Loop Simulation Controls
163
Appendix B Embedded System Code
boot/uboot/uEnv.txt
##Video: Uncomment to override: ##see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/fb/moded b.txt #kms_force_mode=video=HDMI-A-1:1024x768@60e ##Enable systemd systemd=quiet init=/lib/systemd/systemd ##BeagleBone Cape Overrides
##BeagleBone Black: ##Disable HDMI/eMMC #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT- HDMIN,BB-BONE-EMMC-2G ##Disable HDMI cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN ##Audio Cape (needs HDMI Audio disabled)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02 ##AVOIDANCE CAPE cape_enable=capemgr.enable_partno=BB-UART4 ##Example #cape_disable=capemgr.disable_partno= #cape_enable=capemgr.enable_partno= ##WIP: v3.14+ capes.. #cape=ttyO1 #cape=
##note: the eMMC flasher script relies on the next line mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait fixrtc
##These are needed to be compliant with Angstrom's 2013.06.20 u-boot. console=ttyO0,115200n8
kernel_file=zImage initrd_file=initrd.img
164 loadaddr=0x82000000 initrd_addr=0x88080000 fdtaddr=0x88000000 initrd_high=0xffffffff fdt_high=0xffffffff
loadkernel=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} ${initrd_addr} ${initrd_file}; setenv initrd_size ${filesize}
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile} loadfiles=run loadkernel; run loadinitrd; run loadfdt
mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${cape_disable} ${cape_enable} ${kms_force_mode} root=${mmcroot} rootfstype=${mmcrootfstype}