Collision Avoidance of Autonomous Driving at Low Speed in the Near Field of Vehicle

— This paper aims to propose a new idea for realizing low-power-consumption, real-time, microcontroller-based, redundant embedded collision avoidance systems in autonomous driving applications. When operating a fully automated vehicle, the vehicle generates a driving trajectory based on the global route to the destination. The car must follow the generated driving path. It is essential to ensure the safety of this path by checking that it is collision-free. The goal of our low-level embedded collision avoidance system is to guarantee the safety of the path. After defining the driving path area associated with the generating path and the safe monitoring distance, the system can monitor the vehicle's defined Keep-Out-Area (KOA) by using 3D Light Detection and Ranging (LiDAR) sensor. Considering the relatively limited computing power of the microcontroller, the KOA is calculated offline and stored in a look-up table (LUT). This paper also introduces an experimental hardware platform based on the proposed system concept. This platform can facilitate the testing of various collision avoidance algorithms. Moreover, we also identify the challenges, such as false positives and deviation from the actual driving path.


I. INTRODUCTION
ITH the rapid development of autonomous driving technology, it is gradually possible to transport goods and people without or with less driver intervention.Autonomous driving can reduce the number of road accidents due to driver factors in specific complex traffic environments.For example, suppose a child or a dog suddenly runs into the vehicle's roadway.In that case, an unskilled driver may take longer to react to such an unexpected scenario or even accidentally step on the accelerator instead of the brake.Either of these can lead to accidents.
A study by the U.S. Department of Transportation, after collecting and evaluating 2,189,000 crashes, reveals that the critical cause of an estimated 94 % of crashes is attributed to drivers [1].The top three reasons of driver-related causes are recognition error, decision error, and performance error.Therefore, one of the main goals of introducing driverless cars is to reduce the number of road traffic accidents caused by drivers.However, this can also be a big challenge to ensure the safety of autonomous driving from all aspects, as various unexpected driving scenarios must be faced, and the vehicle needs to respond appropriately to each scenario.
Traditional vehicles come equipped with passive safety systems such as airbags and seat belts, which help reduce the risk of injury or death in a traffic accident.While these measures are essential for the driver's and passengers' safety, they are ineffective in avoiding collisions.To prevent accidents, an active approach is necessary.
In contrast to passive safety, active safety systems in the form of Advanced Driving Assistance Systems (ADAS) are widely used in semi-autonomous vehicles, such as Adaptive Cruise Control, Lane Departure Warning, Anti-lock Braking Systems, City Safety, and Autonomous Emergency Braking Systems (AEBS) [2][3] [4] With the help of ADAS, a collision could be effectively avoided in advance by steering and braking maneuvers.
One way to achieve avoidance of rear-end collision is to use the City Safety system, which is now available in Volvo models [3].A Light Detection and Ranging (LiDAR) sensor in front of the vehicle can capture the traffic environment ahead.Threat assessment is based on the speed and acceleration of the target vehicle in front and the host vehicle and the distance between the two cars.An indicator for City Safety intervention is the calculated deceleration for safe braking.If the deceleration exceeds a certain level, City Safety becomes active to brake the vehicle.However, this system must process a lot of LiDAR point cloud data.It relies heavily on the vehicle's computer, which may not be suitable as a separate redundant braking system for fully autonomous driving applications.
Another alternative approach to rear-end collision avoidance is AEBS [4].The main feature of AEBS is that it does not immediately apply the emergency brake.By utilizing risk assessment, the autonomous braking process can be implemented in multiple stages [5].In the pre-warning stage, the driver is warned visually or audibly.If the driver ignores the warning, the risk of a collision may increase, in which case AEBS enters the second stage.Partial braking is applied gradually to reduce the vehicle's speed.If the collision W probability or risk is high, and the AEBS enters the final stage of full car braking.Risk assessment can use different risk indicators, such as Time to Collision (TTC), Safe Distance, and Predicted Minimum Distance.However, there is still a limitation of application scenarios, for example, the AEBS is applied when the target vehicle runs in front of the host vehicle [5].
Distinguished from semi-autonomous driving, a fully automated vehicle needs to generate a driving trajectory after it has obtained a global route to the destination and then follow the generated driving path.The safety of the following path needs to check whether the path is collision-free.A common approach is reachability analysis [6] [7].The reachability analysis focuses mainly on the control problem of finding all of the reachable sets for a given initial state.Analyzing reachability requires significant calculations to arrive at a mathematical solution.As a result, it can be time-consuming in terms of computational requirements.
The main goal of this paper is to propose an embedded collision avoidance system that can operate independently as a redundant system in autonomous driving.In addition, we propose a hardware platform for experimentation based on the proposed system concept.This will allow the testing of various algorithms for collision avoidance within the scope of the Munich Mobility Research Campus (MORE) project.In addition, the redundant collision avoidance system should have a low power consumption.
The remainder of the paper can be structured as follows: Section II overviews the system concept and presents some typical driving scenarios.Section III presents the hardware implementation of our collision avoidance system, while Section IV describes the monitoring strategy.In Sections V and VI, we propose challenges we may face in the project and the future working point we investigate.

II. SYSTEM CONCEPT
This paper proposes a low-level embedded near-field monitoring system MORE (NeFiMMORE) for autonomous vehicles in low-speed applications.
An autonomous vehicle usually uses multiple sensing technologies, such as LiDAR, radar, and visual sensors, to perceive the vehicle's environment.The sensors mounted behind the windshield or on the vehicle's roof have the advantage of an extended sensing range.This could be more advantageous when the vehicle travels at high speeds on the highway.However, when it comes to low-speed scenarios, such as city driving, additional near-field scenarios need to be considered, such as tight turns and obstacles in the blind spot vision of the sensors.A possible blind spot of the roof-mounted sensor with a limited vertical field of view (FOV) is shown in Fig 1 .Although the roof-mounted sensor will see pedestrians at a distance, the dog outside FOV will not be detected.Therefore, placing a sensor in front of the bumper would be feasible to compensate for the detection area in low-speed applications.As mentioned in Section I, it is necessary to ensure that the planned path is collision-free, and there are approaches to verify the collision-free path.Nevertheless, a low-level near-field monitoring system is still needed as a redundant system to improve the robustness of autonomous driving.
This system should, on the one hand, have the ability to monitor the driving path that the path planner generates.On the other hand, it should be as independent as possible from the high-level system.An emergency brake is immediately applied if an obstacle is detected in the monitored area.There is no obstacle avoidance by steering maneuvers since steering to avoid collisions is less effective than braking at low speeds [3].As long as the high-level automated driving system is functioning properly and no objects obstruct the vehicle's blind spot, the redundant system should never activate the emergency brake.As a result, it is essential, and also a significant challenge, to avoid false positives in automatic emergency braking.
Typical driving scenarios are shown in Instead of using a high-performance computer, the monitoring and data processing is carried out by a microcontroller system.This deeply embedded system is attached to an autonomous driving system to accomplish the specific collision avoidance task, and 3D LiDAR is used to perceive the surrounding environment.Considering the relatively limited computing power of the microcontroller, we compute the monitoring KOA offline and build a look-up table (LUT).The dedicated computing microcontroller can retrieve the needed KOA from the LUT anytime.It can also process large amounts of raw 3D LiDAR data.The KOA selection algorithm is another important factor affecting the performance of this collision avoidance system.The LiDAR data processing is separated from the algorithm implementation.A dedicated microcontroller handles this process.The system architecture and hardware implementation are described in the following subsection.

III. SYSTEM IMPLEMENTATION
In this section, we will introduce our experimental hardware test platform that allows the implementation and testing of algorithms.
The NeFiMMORE mainly consists of four controllers (one master controller and three sensor controllers).The number of sensor controllers depends on how many LiDAR sensors are used to sense the vehicle's environment.For the current application design, one bumper-mounted LiDAR monitors the vehicle's front view, and two LiDARs are mounted on the rear corners of the car's bumper.The two corner-mounted LiDARs can monitor the left and right sides as well as the back of the vehicle.They cover the nearby area around the vehicle.A tower-shaped system structure is designed to save space, as shown in Fig 4 (c).All interfaces for internal data communication are mounted on the same side to simplify wiring.Instead of using a high-performance computer, we use microcontrollers to complete the specific collision avoidance task, which could reduce power consumption.Specifically, we rely on the STM32H743ZIT6 microcontroller, which serves as the control unit for both the master controller and sensor controllers.This ARM Cortex-M7-based microcontroller unit (MCU) offers high performance with a double precision FPU, L1 caches, memory protection unit, controller area network flexible data rate (CANFD) peripheral, quad serial peripheral interface (QSPI) peripheral and up to 480 MHz core frequency [8].These advanced features and capabilities make it suitable for this embedded application.To avoid excessive computational load on a central controller, data processing and evaluation of 3D LiDAR perception data is performed in the sensor controllers, and each LiDAR has a dedicated MCU for data processing.
Two external components (SD memory card and QSPI NOR flash) are provided for each control system (master controller and sensor controllers) to expand the system's memory capacity.With the additional memory options, the system is able to realize more functions without limiting the usability of the system due to the lack of memory on the microcontroller.Since the reading speed of the SD card is slower than QSPI, the SD card is more suitable for storing the event log data for the event evaluation application.We keep our LUT for KOA in the dedicated QSPI memory.The KOA variables can therefore be quickly accessed as comparison values during data processing.It should be noted that the allocated QSPI flash serves as readonly memory.
To realize a better user interaction with the master controller and the sensor controller, we provide an interface board on the top level of the tower-shaped structure, see  The main components of the system and its data communication are shown inFig 5. CAN protocol is used to exchange data between the central controller and the three sensor control subsystems.In the figure, an additional sensor controller is presented as an optional component for using an extra LiDAR.The data exchange between the central controller and the high-level system (HLS) is implemented using the User Datagram Protocol (UDP).The main task of the master controller is to act as an interface between the HLS and NeFiMMORE to respond to each event.The HLS delivers a new path to NeFiMMORE.The master Controller can use algorithms to determine the KOA and notify each distributed system of its newly monitored KOA.If one of the distributed sensor systems detects that a collision is about to occur, it can send a CAN message with a high-priority identifier to the master controller.An emergency signal is then immediately sent to MicroAutoBox II MABX.We use bare-metal programming to implement embedded software without using a general-purpose operating system like Linux.This allows us to maximize the performance on a resource-constrained hardware platform.In the autonomous application, the response time of the system is essential.Therefore, with the support of the Real-Time Operation System (RTOS) on the hardware platform, the time-critical tasks can be executed strictly within the deterministic response time.

A. Drive path area
The primary objective of the near-field monitoring system in autonomous driving is to ensure that the predicted area is free of collisions.It is not necessary to decide whether this collision will occur or not.If the HLS of the autonomous vehicle does not react to this obstacle and provide an escape path in time, or worse, does not see the obstacle, our system must be active and enabled to respond.
Definition: The driving path area associated with the predicted trajectory within a specific planning horizon is defined as an area where the autonomous vehicle is going to travel.

B. Monitoring distance
The risk assessment strategy for AEBS is the system's judgment of the crash probability and severity under the current working situation [5].It is not the task of the NeFiMMORE system to determine the collision possibility and severity because it does not perform multi-stage collision avoidance operations.However, we use the safe monitoring distance as a collision indicator to gauge collision risks.The monitoring area of the front sensor is restricted within a safe distance.Definition: The Safe monitoring distance D !"# is defined as the sum of system reaction distanceD $ , vehicle braking distance D % and safety marginD & .
A normal untrained driver takes less than 1 s to brake in response to the road situation [9].Automated emergency braking systems may have a shorter response time compared to human drivers.Equation ( 2) is used to determine the vehicle braking distance.It considers impact factors such as weather, vehicle geometric dimension, and vehicle weight [10].
Where  '( = -: The weight of the vehicle g: Gravitational acceleration v: Velocity of vehicle  % : Brake factor µ: Frictional coefficient : Road slop  $ : Roll factor p: Air density  + : Vehicle windward projection area  , : Air drag factor The sum of the system reaction distance and the vehicle braking distance denotes the vehicle's stopping distance.The monitoring distance must at least satisfy the following hard condition: Emergency braking cannot prevent a collision if an obstacle is within the stopping distance.However, it can reduce the severity of the crash.Therefore, to avoid the collision, we add safety margin  & , which is able to extend the monitoring distance.It is important to note that the current monitoring distance strategy is unsuitable for a car-following scenario.

V. CHALLENGES
This section aims to emphasize the various challenges that may arise in our future work.Identifying these potential hurdles allows us to understand the problems we may face in practice.
One of the biggest challenges for collision avoidance systems is the problem of false positives.False positives can lead to unwanted and uncomfortable emergency braking.The cause of false positives can be the consequence of the algorithm's limitation in addressing a narrow range of traffic scenarios or simplifications of road scenarios.For example, the simplified approximated road model is used to simplify the calculation.In addition, the cause of false positives can also result from overreaction due to the detection of non-hazardous obstacles, such as floating plastic bags or leaves, in a special driving scenario.As a low-level collision avoidance system, it can only detect whether there are obstacles in the detection area.The overreaction problem will be investigated in future work by applying the appropriate algorithm.
Another challenge for collision avoidance systems in autonomous driving systems is a premature reaction to obstacles.This is also undesirable for a reliable system.HLS can avoid this collision at an early stage by slowing down the autonomous vehicle or generating an escape path.A safe monitoring area must be clearly defined.
Another major challenge in the practical problem is the derivation of the actual trajectory from the planned trajectory.This is because the path-following controller in the autonomous vehicle must adjust the vehicle's present position to match the intended path, given the path's derivation.The challenge of trajectory derivation is not a major problem at very low speeds, such as walking speed.However, the derivation of the trajectory along the designed path cannot be neglected when the vehicle is driving, for example, on a wet road at a relatively high speed.This is because the orientation of the vehicle changes significantly under such conditions.Therefore, the collision avoidance system cannot follow the normal monitoring strategy in such a special scenario.Considering this special situation, we may need to take the current steering angle as an additional input to the system.

VI. CONCLUSIONS AND FUTURE WORK
In this paper, we have introduced a collision avoidance system in the near-field area of autonomous vehicles.This proposed system aims to build a redundant embedded low-level collision avoidance system based on high-performance microcontrollers.We also define the driving path area and the safe monitoring distance to determine the monitoring area.
In our future work, we will investigate the type of path generated by the path planner and develop an algorithm to identify the type of path because the type of path has a significant impact on the selection of KOA.The decisionmaking process and system intervention in different situations will also be investigated in further work.After testing generic scenarios, such as car-following and overtaking, we will consider complex driving scenarios.In addition, the challenges mentioned in the last section will also be addressed as research points in the future.

Fig 1 .Fig 3 .
Fig 1.The obstacle in the blind spot area of the roof-mounted sensor Fig 2. and Fig 3.The Keep Out Area (KOA) is highlighted in red and limits the system monitoring area.Fig 2 illustrates a situation where the vehicle enters a trafficcontrolled area such as a kindergarten, residential area, and canteen area on campus.In this scenario, it is essential to monitor the traffic around the vehicle.In Fig 3 (a), when a target vehicle attempts to overtake a host vehicle on a straight road, the applied KOA shrinks to avoid false positives.In Fig 3 (b), the KOA must remain within the host vehicle's lane to avoid capturing the target vehicle from the opposite direction.

Fig 4 .
Fig 4. Hardware realization of the NeFiMMORE system Fig 4 (c) and a graphical user interface, see Fig (a).In this project, the STM32F769IDISCOVERY board is used as the display.The 3D LiDAR we use for near-field detection is the Velodyne VLP-16 see Fig 4 (b).It uses 16 laser beams to perform a realtime, 360-degree horizontal and 30-degree vertical scan of the environment.

Fig 5 .
Fig 5. Overview of system structure block diagram

Fig 6 .
Illustration of the driving path area, driving lane (blue), driving path area (orange), and predicted path (blue dashed line).(a) Curve driving scenario (b) straight driving scenario The driving path area in Fig 6 (a) consists of paths of the vehicle's diagonal vertices.When the predicted path is straight, the driving path is the path of the vehicle vertices, as shown in Fig 6 (b).The area of interest for obstacle monitoring is constrained in the defined driving path area.