Following the Same Path between Iterations of the RRT

141

especially when faced with a single obstacle in the center of the roadway. The oscillatory steer commands produce no net change in direction of the vehicle when avoiding an obstacle. This oscillatory behavior results from calculation of a new safe path every time the control-loop and RRT algorithm runs. This is especially apparent when the constraint data does not adequately force a general corridor in which to navigate through when planning a safe path. For instance, when an obstacle is in the center of the roadway the path-planning algorithm may plan a safe path left around the obstacle then subsequently plan a safe path right around the obstacle between control-loop iterations. This is shown in Figure 65. An effort to improve the RRT algorithm focused on reducing the resulting steer oscillations by only calculating a new safe path when the previously calculated safe path was deemed no longer safe to follow or the goal of the previous path was reached. While implementing this update, it was quickly realized that in order to follow the same path between controller iterations the change in vehicle position and heading must be considered and the previously calculated path must be compensated for by bringing it to the current frame of reference. This has to be considered as the LiDAR and obstacle data is seen in the current vehicle frame while the last calculated safe path is in the previous vehicle frame. The previous path must be checked for validity in the current frame for collisions with obstacles and to stay within the road boundaries. In order to bring the previous path to the current vehicle frame, the change in the vehicle’s position and

heading must be determined since the last iteration of the control-loop. Without the use of additional sensors, such as a GPS or IMU, the only way to estimate this is to use the available speed, elapsed time, and the detected yaw angle to dead-reckon the vehicle’s position. Dead-reckoning is the process of determining the current position through

142

knowledge of the previous position and advancing it based upon the estimated speed over the elapsed time. This method is subject to cumulative error that increases with the distance from the original location. This method also assumes that the safe path is very closely followed. In addition, by using the same path between iterations and relying on dead-reckoning, the effectiveness of the closed-loop controller to correct for the oversimplified steer angle estimation to follow the path is greatly reduced. With additional sensors, a much more accurate and reliable way to determine the vehicle’s position can be used to follow the previously calculated path if it is still safe to follow. In addition, a closed-loop controller that minimizes the error between the vehicle’s actual path and the safe path could be implemented to better steer the vehicle. A vehicle tracking system could be simulated with the simulation tool described in chapter 4 to verify and develop these improvements before selecting, purchasing, and implementing any hardware components.

Figure 65. Subsequently planned paths around an obstacle showing cause of oscillatory steer commands

Another issue associated with following the same path is that the calculated path depends on the vehicle speed, which is assumed to be constant while planning the path. The path is stored as a lookup table with time values that indicate when the vehicle

143

should issue the next steer command in the table. With future updates, the time indexed steer lookup table may be compensated to allow for varying speeds while following the same path. This would allow the driver to control the throttle at all times during the autonomous maneuver while following the same path. The previous implementation of the system kept the throttle constant once a threat was detected and the system engaged. In addition, a completely new path is calculated for each iteration of the control-loop and only the first steer command in the look-up table is used. The wireless system also calculates a new path for every iteration of the control loop; since only the first steer command in the look-up table is used, no constant speed constraint or table compensation is required and the user remains in control of the vehicle’s speed throughout the

autonomous maneuver. This allows the driver to alter the speed at all times during system operation to better realize semi-autonomous operation; however, this feature can be disabled to mimic the previous tethered implementation.

With the current tuning of the threat determination, the system’s behavior may be best described as a lane-keep assist system with steer-based collision avoidance. If the driver tries to go off of the roadway, the controller will attempt to fight the driver to bring the vehicle back to the center of the roadway; in the end, the driver can overpower the controller off of the roadway if the road boundary is approached with a speed and yaw angle. However, if the driver drives down the roadway with their hands completely off the steering wheel, the system easily maintains a central position in the roadway. This system behavior can be changed by tuning the distances to the road edge before controller performs a maneuver to stay on the roadway. Higher values will trigger a reaction from the controller sooner and a high enough value will essentially ignore all driver commands

144

in order to stay in the center of the roadway even if the driver pushes the steering wheel in an attempt to overpower the controller. If the threat to the vehicle is deemed imminent, then the controller takes over control and the haptic steering wheel effects merely provide feedback to the driver. In the event of a controller override the driver has no control over the vehicle even if they push the steering wheel with more force. The steering wheel angle may be used to implement a driver override feature if the driver’s steering wheel angle greatly differs from that of the controller. One pitfall of this system is that if no road boundaries can be detected than the system cannot plan a safe path and therefore cannot avoid any collisions. A future test track may involve creation of a circular or oval track with evenly spaced road cones to prevent the road from ending. This scenario was simulated in the hardware in the loop simulator. As the road bounds are drawn as straight lines, some cones will appear in the center of the roadway as an obstacle while in a curve. This could be avoided by reducing the distance that an obstacle is considered threatening and curving the detected road lines in proportion to the yaw rate. The yaw rate may also be incorporated in determining the threat of a collision with particular object by

extrapolating the vehicle’s future path to see if the obstacle would be in its path. This could help provide a confidence metric within the threat determination algorithm with respect to each detected obstacle. The simulator can be used to investigate this further.