Embedded Controller Testing

Integral to this project and its wireless capability is the SBC that interfaces with all the sensor hardware, communicates with the user-control-station, and runs the collision avoidance algorithms. Implementing a real-time controller with an embedded Linux platform presents many challenges as it is not a real-time operating system. In

145

addition, the SBC has limited resources such as processing power and memory. The processing power and memory being used while running the open-loop and closed-loop controller consists of many tasks, as described in chapter 3. Instead of many distributed electronic control units (ECUs) running concurrently that share data on the vehicle’s data bus, as is commonly found in modern automobiles, this system uses one ECU with many distributed FSMs running concurrently in separate threads that share data by utilizing a shared memory model. This is an advantage for scaled research as the footprint and power requirements are greatly reduced as well as the complexities of the hardware connections, integration, and synchronization of many different ECUs; although, this configuration does rely more heavily on the processor to perform all the tasks. Thus it is important that the SBC is adequately capable of performing all the required tasks without maxing out the processor or memory use as this could cause important real-time tasks to miss their deadlines and could degrade controller performance. The CPU load and memory use while operating the open-loop and closed-loop controller is shown in Figure 66. These figures show that the SBC is perfectly capable of running the controller’s software without maxing out processor or incurring high memory use. A load average of 1.0 shows that the processor is fully utilized and processes do not have to wait to be scheduled. The load on the processor while running the open-loop controller is minimal; no task has to wait to be executed, as shown by the load average, and the processor is idle 95.6 percent of the time. For the closed-loop software, the average load on the processor shows that the software matches the processor’s capability and is fully utilized without overloading it. The percentage of processing time is spent where anticipated, processing the point-cloud and determining the threat of a collision and a safe path to navigate. The

146

memory usage is also quite small and remains relatively constant for both the open and closed loop software, which helps show that the program does not contain any memory leaks. While the SBC is well suited to run the full system’s software there is not as much room for further expansion of the software. For instance, addidtional features that use the same data could likely be incorporated without affecting the processor’s ability to address the needs of each task; however, integration of new sensors, such as a camera for obstacle recognition and lane detection through image processing, would likely need additional hardware to avoid overloading the processor. There is also a significant opportunity to offload the load on the processor by utilizing the programmable real-time units and the enhanced quarture encoder package within the SoC. This and other possible

147

Figure 66. Controller's open and closed-loop CPU load and memory use As Brennan states, the primary focus of using an automated controller to drive a vehicle during an emergency is to reduce the response time to an impending collision or instability. Often, the delay of a driver’s response during an emergency situation is the biggest distinction between a poor and an expert driver. For an automated controller to be effective it must provide an appropriate response to avoid an impending collision, allow time to actuate the avoidance response, and allow enough time for the dynamic forces to develop. A semi-autonomous steering-based collision avoidance system’s performance may be determined by the ability of the controller to safely steer a vehicle around an imminent threat in a variety of situations. In regards to the semi-autonomous aspect of the

148

controller, the switch between computer and user control has a dramatic influence on the driver’s perception of this technology, especially if the switch is jarring and/or

frightening to the driver. The switch must be fluent and seamless.

Determining the imminent threat to a vehicle is a complicated matter, especially when this threat determination dictates whether the driver or the vehicle controller is in control of the vehicle. There are many unknowns that could influence the threat to a vehicle involving the environment, road surfaces, other vehicles, and other driver’s behavior that can be extremely difficult to model and predict. To compound the

complications of quantifying a threat level, the vehicle’s hardware has limited processing power, sensor range, and must perform within strict time constraints. Properly identifying a threat is imperative as failure to do so within time may put the driver, by-standers, and the vehicle’s hardware at great risk. Failure to determine a valid threat may result in injury or death. Conversely, falsely identifying a threat may result in oscillating between driver and computer control, which could be jarring to the driver and could be just as dangerous as missing a valid threat altogether. There are many obstacles that a vehicle may be presented with, such as: moving & stationary vehicles, people, animals, roadway barriers, and road surface conditions. The focus of this project was narrowed by only differentiating road boundaries from other obstacles. A numerical quantification of each obstacle’s threat metric was compared with a threshold threat metric to determine if this obstacle should be added to the threatening obstacle set for consideration during path- planning. Future development could account for varying obstacle types, pedestrians, and their behaviors.

149

This chapter showed the results from the hardware in the loop simulator and the implementation of a Linux based embedded controller on the vehicle platform. The wireless implementation of the controller greatly expanded the vehicle’s capacity to study and develop collision avoidance software and to research human factors. The SBC

implemented as the vehicle controller that runs the collision avoidance software in real- time in a multithreaded FSM configuration was shown to have adequate resources. This showed that an SBC running Linux is a viable option for a semi-autonomous collision avoidance system. This chapter presented some the usefulness of hardware in the loop simulation for identifying issues in the collision avoidance software as well as further developing the underlying algorithms. Specifically, the issue of switching between driver and computer control through the determination of a threat metric was investigated and refined. The reasons behind path-planning algorithms oscillatory behavior were also examined. In the next chapter, recommendations are suggested to improve system

150