Universal Safety Distance Alert Device for Road Vehicles

Abstract

Driving with too short of a safety distance is a common problem in road traffic, often with traffic accidents as a consequence. Research has identified a lack of vehicle-mountable devices for alerting the drivers of trailing vehicles about keeping a sufficient safe distance. The principal requirements for such a device were defined. A conceptual study was performed in order to select the components for the integration of the device. Based on the results of this study, a working prototype of a flexible, self-contained device was designed, built and tested. The device is intended to be mounted on the rear of a vehicle. It uses radar as the primary distance sensor, assisted with a GPS receiver for velocity measurement. A Raspberry Pi single-board computer is used for data acquisition and processing. The alerts are shown on an LED-matrix display mounted on the rear of the host vehicle. The device software is written in Python and provides automatic operation without requiring any user intervention. The tests have shown that the device is usable on almost any motor vehicle and performs reliably in simulated and real traffic. The open issues and possibilities for future improvements are presented in the Discussion.

1. Introduction

Driving at a too short of a safety distance is a common problem in road traffic and presents one of the principal causes of traffic accidents. From 1994 to 2012 in Slovenia, about 15% of all traffic accidents were due to ignoring the safety distance [1,2,3]. The drivers often tend to drive too close to the leading vehicle, because they are unaware of the distance required to stop the vehicle at the given velocity and because they inadvertently wish to increase the traffic throughput and, thus, shorten the trip time. On the other hand, the commonly-known scenario involves impatient drivers on multi-lane motorways who try to force the vehicles in front of them off the fast lane by intentional “tailgating”. The constant improvement of road vehicle performance and the inclusion of driver-assistance systems may increase the problem even further, as it gives the drivers a false confidence in their vehicle’s abilities to stop and prevent the impact consequences [4,5,6,7]. This leads to frequent rear-end collisions, often with devastating consequences and even fatal injuries [3].

The regulations regarding the required safety distance on roads in most countries include the so-called “two-second-rule” [8,9]. This defines the safety distance to be at least as long as the distance travelled by the vehicle at its current velocity in two seconds. Enforcement of this rule in everyday traffic can be achieved with different measures. In many countries, the safety distance is measured by the police at strategic spots by hand-held radar detectors [10] or by employment of in-vehicle surveillance systems [11]. On selected spots on the highways, there are also test fields that allow the drivers to self-evaluate their safety distance [12]. These test fields are sometimes combined with variable-content traffic signs for visually alerting the drivers about their safety distance. All of those measures are passive and can only be carried out on discrete spots on the road network. A survey of available active measures for continuous monitoring of the safety distance reveals that there is a serious lack of devices for continuous safety distance monitoring. Many of those devices are not easily installable into existing vehicles and are not able to alert the drivers of the trailing vehicles about keeping the required safety distance. Most of those devices are integral parts of the equipment of higher-priced vehicles [13,14,15] and are mostly designed to communicate the safety distance to the driver of the vehicle carrying the device [16] rather than those behind it and violating the safety distance.

The work described in this paper was initiated to fill this void and to develop a device for continuous safety distance monitoring and visually alerting the drivers of the trailing vehicles whenever their safety distance decreases below a safe level. The result of the research and development is a working prototype of a low-cost device that is almost universally applicable in any road vehicle and reliably performs this task automatically with no required human intervention. Its flexibility allows the device to be installed on different positions of the vehicle and to alert either the driver of the vehicle carrying the device or the drivers of other vehicles about their insufficient safety distance.

2. Materials and Methods

2.1. Defining the Functional Requirements and Conceptual Design

Prior to starting the development of the concepts, the functional requirements of the system were set. For the sake of brevity, the “vehicle carrying the safety distance measuring device” is henceforth referred to as the “host vehicle” and the vehicle driving behind the host vehicle in the same direction as the “trailing vehicle”. The functional requirements for the device are as follows:

• The device has to be able to measure the distance from the rear end of the host vehicle with sufficient range and sufficient accuracy to be able to operate at motorway speed limits (130 km/h).
• The device has to be able to measure the instant velocity of the host vehicle with sufficient accuracy to calculate the required safety distance.
• The device has to visually alert the driver(s) of the trailing vehicle(s) whenever their safety distance to the host vehicle is too short.
• The device has to alert the driver of the host vehicle of a possible or inevitable rear-end collision.
• The device has to be able to record all of the ride parameters (time, location, velocity, acceleration) for the last 1000 km of travel.
• The concept of the device must be such that a realization of a working prototype with the basic subset of functions will be possible by integrating components that are either readily available or can be made using the existing workshop equipment.
• The device must be installable into any motor vehicle with on-board electrical power without requiring any permanent changes to the vehicle or its systems.
• The previous seven requirements shall be fully fulfilled while minimizing the cost of the components.

Following these requirements, five concept solutions were synthesized and evaluated. The morphological matrix of the available options for providing the required functions is presented in

Table 1. The morphological matrix.

Function		Available Options
		1	2	3	4	5	6	7
a	Distance measurement	LIDAR	RADAR	LASER	image analysis	ultrasound	active infrared	passive infrared
b	Host vehicle velocity measurement	GPS	vehicle Hall sensor	optical sensor
c	Data processing	microcontroller	embedded computer	desktop computer	laptop computer
d	Alerting the other vehicle’s driver	LED matrix display	transparent LED net	projection on glass	strobe flash	vehicle rear lights	LCD screen
e	Power supply	vehicle on-board power	independent battery	solar cells	dynamo
f	Attachment to any vehicle	suction cups	adhesive	bolts	snap-in joints
g	Acceleration measurement	digital 3-axial accmtr.	analogue 3-axial accmtr.
h	Automatic distress alert	GSM voice call	GSM text message	GSM data	Wi-Fi to mobile phone	Bluetooth
i	Alerting the host vehicle driver	audible: beep	audible: speech	visible: light	tactile: vibration
j	Parameter recording	hard disk	memory card	tachograph
k	Recording locations with frequent violations	hard disk	memory card	tachograph
l	Data transfer from the device for analysis	wired USB	wired serial	wired Ethernet	wireless Bluetooth	wireless Wi-Fi

.

The morphological matrix was used to propose the following feasible design concepts:

• C-1 = a2 + b1 + c2 + d1 + e1 + e2 + f1 + g1 + h2 + i1 + j2 + k2 + l3
• C-2 = a3 + b1 + c2 + d1 + e1 + e2 + f1 + g1 + h2 + i1 + j2 + k2 + l3
• C-3 = a2 + b3 + c2 + d2 + e1 + e2 + f1 + g1 + h2 + i1 + j2 + k2 + l3
• C-4 = a4 + b1 + c2 + d4 + e1 + e2 + f1 + g1 + h4 + i1 + j2 + k2 + l1 + l5
• C-5 = a2 + b2 + c2 + d5 + e1 + f3 + f4 + g1 + h2 + i1 + j1 + k1 + l1 + l3

The proposed concepts were evaluated using functional value analysis from the technical and economical point of view. The set of technical criteria contained the following: distance measurement accuracy, velocity measurement accuracy, alert display visibility, power consumption, ease of maintenance, required mounting effort, mounting versatility and aesthetics. The set of economic criteria contained the following: development cost, homologation cost, component acquisition cost, manufacturing cost and marketability. In both cases, the utility function was unweighted. The results of the evaluation are shown in Figure 1.

Based on the evaluation results, the concept C-1 was chosen for implementation as the highest ranked among the proposed concepts. The evaluation results also indicate the importance of the evaluation process, since the value difference between the concepts is relatively small.

2.2. Design and Adaptation of the Selected Concept

The selected concept of the device is based on an embedded computer and includes an LED-matrix display for visual alert, a radar sensor for distance measurement, a digital accelerometer, a GPS module for velocity measurement, a GSM module for sending distress alerts as text messages and a speaker for host vehicle warnings. It is powered either from the vehicle on-board power system or from a separate battery; it records the data on the built-in memory card and is attached to the vehicle with a suction cup mount. Figure 2 shows the required components and their connections used in the concept.

2.3. Selection of the Components

The first component that had to be selected carefully was the radar distance sensor, because it represents a significant cost. The tests were started with a radar sensor as is used in vehicles with adaptive cruise control [17]. Although conveniently sized and available at an attractive price, this sensor soon had to be rejected as unsuitable due to the unavailability of data transfer protocol documentation and a lack of resources for reverse-engineering. The next option was a purpose-built radar sensor. A K-MC3 Doppler radar sensor by RFbeam Microwave GmbH [18] was chosen. It is used, among other applications, in adaptive traffic signage. The sensor comes with a configurable DSP board that communicates with its host via a UART serial interface. The preliminary tests have shown that the sensor system largely fulfils the requirements regarding the measurement range and response time.

After deciding upon the distance sensor, the decision was made about the processing unit. Based on its versatility, low power consumption and largely positive experience from other projects, we opted for the Raspberry Pi Model B single-board computer [19]. Since it runs a standard Linux-based OS and provides a large set of on-board communication interfaces, it was a natural choice for use in the prototype development.

Other components were selected mainly from what was available in the lab equipment pool, so that they were connectable to and supported by software on the Raspberry Pi. Due to their unavailability at the time of the prototype construction, the GSM module, the accelerometer and the speaker were left out from the final version of the prototype. This, however, did in no regard hinder its principal functions. The list of the actual components used in the final version of the prototype together with a conservative cost estimate is presented in

Table 2. The components used in the final prototype.

Component	Manufacturer and Type	Cost Estimate (€)
Radar sensor with DSP board	RFbeam Microwave GmbH K-MC3	560
Single-board computer	Raspberry Pi Foundation Model B	30
SDHC memory card	SanDisk Ultra (8 GB Class 10)	8
GPS module	u-blox AG Antaris 4 AEK-4T	200
Power supply voltage regulator + accessories (capacitors and heat sink)	Generic 7805-TO 220	4
LED-matrix display (including a driver MC)	Olimex Shield-LOL-10 mm-Green	25
polypropylene (PP) enclosure	TRACON Electric Co. 200 × 150 × 75 mm	6
Suction cup mount	Bohle AG Veribor	35
Mounting accessories	various	4
Cables, connectors, adapters	various	18
Total		890

.

2.4. Prototype Assembly

The acquired components were electrically connected and assembled inside a protective plastic enclosure with an attached suction cup for mounting on a vehicle rear window or panel. Research and testing was carried out [20,21] in order to find the correct enclosure material that does not hinder the radar function. It was found out that the 4 mm-thick polypropylene shell of the enclosure is transparent to the RF waves as long as the radar antenna is mounted 6.2 mm from the inner surface of the shell. This distance was achieved by inserting suitable spacers. A 3D model of the prototype device assembly was created for studying and optimization of the component layout within the enclosure. The model, together with the actual assembly of the components in the enclosure and its mounting on a vehicle rear window, is shown in Figure 3.

The electrical connections for the purpose of the prototype were made using readily-available cables and connectors in order to avoid physical alterations to the components. The connection diagram of the prototype system is shown in Figure 4.

Once assembled, the system was preliminary tested for power requirements and physical suitability for attaching to a vehicle.

2.5. Software Setup and Development

The first step of the software setup was getting and installing the operating system for the Raspberry Pi computer. We opted for the ready-made disk image of Raspbian Jessie [22], provided by the Raspberry Pi Foundation [23]. The image was transferred to the SDHC memory card. The system was configured for its specific purpose. The most important steps in this process were maximizing the storage space by purging the unneeded software packages, disabling the unnecessary services, enabling the SSH server and setting up a static IP address for the on-board Ethernet adapter. Only the following services are configured to start at boot: systemd-udevd, ifplugd, cron, dbus-daemon, samba (nmbd, smbd), getty (with only two virtual consoles) and sshd. The debug output to the serial console was disabled in /boot/cmdline.txt to free the Raspberry Pi on-board serial interface for communication with the radar sensor DSP board. The allocated GPU memory was reduced to 16 MB by editing /boot/config.txt. The configured Raspberry Pi is accessible over Ethernet from another computer using a SSH connection, eliminating the need for a separate display and keyboard. Running ifplugd ensures automatic network interface configuration on cable connection. Running samba provides access to the recorded data files on the Raspberry Pi from a computer running MS Windows without additional software.

The bi-directional serial connection to the radar sensor DSP board was tested by sending command strings and receiving the response. The bi-directional USB-to-serial connection to the GPS module was tested by sending the command to initiate continuous operation and receiving the NMEA 0183-compliant output. The transmit-only serial connection to the display microcontroller using a Prolific PL-2303 USB-to-UART converter chip was tested by sending command strings and observing the display.

The core function software was developed in Python 2.7. The main reason for this was the extensive support for various communication protocols, ease of debugging and the amount of available documentation with code examples. The user software consists of separate routines for getting the data from sensors. This enables isolated testing of the individual protocols and the use of the developed routines for thorough testing of each individual sensor. After the data manipulation routines were tested and proven working, the routines for user alerts were written and tested, and once the results were satisfactory, the main program subroutine was written. In normal device operation, this subroutine is run in an endless loop, which is automatically started at system boot as a cron job. Figure 5 shows a simplified flow chart of the main subroutine.

To determine the actual safety distance SD_a, a list of detected targets in the measuring range is acquired from the radar sensor. This is accomplished by sending a command to the DSP board over serial connection. Upon receiving this command, the DSP board returns a text string, including the positions and velocities of all of the detected targets. From these targets, the one closest to the sensor (and thus, to the host vehicle) is determined, and its required safety distance d_s,req is calculated as follows:

$$d_{s,\text{req}}=v_2\times t_{\mathrm{R}}+\frac{v_2^2-v_1^2}{2·a},$$

(1)

where v₁ is the longitudinal velocity of the host vehicle, v₂ is the longitudinal velocity of the trailing vehicle, t_R is the reaction time (constant at t_R = 2 s) and a the achievable braking deceleration in wet conditions (a = 4 m/s²). The host vehicle velocity v₁ is acquired from the GPS sensor by continually receiving and processing its output in the form of NMEA 0183 strings.

The distance to the closest target, d_s,closest is continuously compared to the calculated required safety distance. The alert on the LED-matrix display is initiated whenever the following condition is true:

$$d_{s,\text{closest}}<d_{s,\text{req}},$$

(2)

The alert is sent as a command string over the serial connection and interpreted by the matrix display controller firmware. An animated double-arrow (Figure 6) is shown followed by the scrolling “KEEP DISTANCE!” message. This sequence runs in a continuous loop until the condition in Equation (2) becomes false again.

2.6. Testing the Finished Prototype

Once the operating system and the initial version of the main program on the Raspberry Pi were ready and running, the power consumption of the entire system under load was again tested connected to a laboratory power supply. It was found out that the steady electrical current draw of the entire system (including the Raspberry Pi) on the 5-V DC output of the regulator never exceeded 0.8 A, which is why we decided to keep the 7805 linear voltage regulator rather than replacing it with a switching type regulator. The prototype was tested on a vehicle in a controlled environment. For this purpose, the following test protocol comprising several Pass/Fail criteria was developed:

• The allowed relative measurement error of the host vehicle velocity (from the GPS module) in the 30–200-km/h range is below 5%.
• The allowed relative measurement error of the host vehicle velocity (from the radar sensor) in the 30–200-km/h range is below 10%.
• The allowed relative measurement error of the trailing vehicle velocity (from the radar sensor) in the 30–200-km/h range is below 10%.
• The measurement range of the radar sensor when measuring the distance to target is within the 5–70-m range.
• The allowed relative measurement error of the measured distance from the rear-most point of the host vehicle to the front-most point of the trailing vehicle on the same traffic lane within the 5–110-m range is below 10%.
• The reliability of the alert activation when the measured safety distance of the trailing vehicle is too short must not be below 95%; in other words, the alert shall activate in at least 19 of 20 cases of safety distance rules violations.
• The radar sensor must always provide reliable distance-to-target measurement without any disturbances in the form of unexplained values or significant oscillations.
• The radar sensor must be able to sense a vehicle abruptly cutting in onto the traffic lane on which the host vehicle is driving.
• The radar sensor must not sense objects outside the roadway or vehicles driving on other traffic lanes as a trailing vehicle.

To test the criteria, several test scenarios were devised and carried out. All of the tests were performed using one or two passenger cars on a closed road. The tests included measurements of velocity (Criteria 1–3), distance (Criteria 4 and 5) and combined tests in simulated and real traffic (Criteria 6–9).

3. Results

In the first test, the host vehicle velocity was simultaneously measured with the radar sensor and the GPS. Figure 7 shows an excerpt from one of the measurements, where it can be observed that the agreement between the two curves is generally very good. The slight time shift occurs due to the GPS velocity being sampled only twice per second due to a limitation imposed by the GPS receiver used in the prototype. The mean values of magnitude (excluding the radar sensor noise) follow each other with an average relative error of 3.12%, which is well within the required 10% relative error margin.

In the second test, the distance from the host vehicle to several different stationary objects (a flat wall, a shipping container, a car) was measured in order to determine the radar sensor range and accuracy. The example measurement was performed with the device attached to a car slowly driving away from a steel shipping container approximately 6 m wide and 2.6 m high. The points at 20, 30 and 50 m from the container were marked by using a calibrated measuring wheel. The car was stopped at these points during the test in order to test the stability and accuracy of the measurement. Figure 8 shows that the measured distance is stable and accurate. All of the measurements are well within the required 10% relative error; statistics for all of the tests are shown in

Table 3. Distance-to-object measurement test statistics.

Measuring Wheel Distance (m)	Average Radar Measurement (m)	Average Absolute Error (m)	Average Relative Error (%)
20.00	20.65	0.72	3.49
30.00	29.79	1.08	3.62
60.00	59.59	0.95	1.59

. It is also obvious that the maximum reliable range of the measured distance is approximately 75 m. It is possible to increase this value by adjusting the radar target sensing amplitude level, albeit at the expense of lower distance measurement accuracy.

Similar measurements were done with a stationary passenger car as the target object. In those measurements, the upper limit of the maximum reliable measurement range was also between 70 and 80 m.

One of the requirements was also a reliable, disturbance-free distance measurement throughout the whole measuring range of the radar sensor. To test this, the device was mounted on the host vehicle driving in a straight line at 30–40 km/h while the trailing vehicle was approaching it from behind with a constant relative velocity of approximately 0.8 m/s. During the test, the distance of the trailing vehicle to the host vehicle has thus approximately linearly decreased from 75 m down to 15 m. The time vs. distance curve is shown in Figure 9. It can be observed that the otherwise prevailingly straight curve contains three significant anomalies at approximately 71 m (reading 0 m), at approximately 46 m (reading 23 m) and at approximately 23 m (reading 0 m). After some research and discussion with the radar sensor manufacturer, it was determined that the interference most likely comes from the MAX232 RS-232-to-TTL converter chip on the sensor DSP board. To remedy this, the known false readings of 23, 46 and 71 m were filtered out in the final version of the device software and substituted by interpolating the adjacent readings. This does not significantly hinder the device performance, as the distance between vehicles in normal traffic is dynamic and, thus, the probability of remaining at exactly the filtered-out values for any prolonged time is fairly low.

The same test setup was also used to determine the influence of the driving surface itself on the distance measurement. Due to the shape of the microwave propagation field of the radar transceiver [18], it was expected that the nature of its mounting on the host vehicle may cause the detection of the driving surface as one of the targets, thus causing false alert triggering. To determine this, the signal amplitude vs. distance chart was drawn. Figure 10 shows an example where two vehicles were located at distances of 12 m and 37 m from the radar sensor. The target sensing amplitude threshold in this case was set to 3500 in order to reliably sense the targets, but this setting almost always returned a target at the distance of just over 1 m, determined to be the reflection of the driving surface. To overcome this, the targets closer than 3 m were subsequently programmed to be filtered out in the final version of the device software.

The next test was performed in order to test the reliability of the alert message activation on the LED-matrix display. To satisfy the sixth Pass/Fail criterion, a drive of two test vehicles on a closed road in simulated traffic was performed. The device was mounted on the host vehicle, and the trailing vehicle was driving behind it with varying velocity and distance. During the test, the driver of the trailing vehicle intentionally initiated a series of 20 obvious safety distance violations with different severity (an example video is available as a supplement). The results of this test show that the alert on the display was successfully activated in all 20 instances and that there were no false activations. It was observed that the alert activated with slight delay whenever the trailing vehicle approached the host vehicle very rapidly due to the low sampling rate of the GPS velocity readings. This test was repeated on an open road with normal traffic and objects along the roadsides (an example video is also available as a supplement). There, it was determined that in curves with a very small radius, it a false alert can be triggered. Therefore, we had to declare the ninth criterion as a Fail, although the false alerts triggered by the roadside stationary objects usually do not seriously affect the function of the device in slow city traffic or on a motorway with large curve radii.

Table 4. Summary of Pass/Fail criteria and their fulfilment.

Criterion Description		Pass	Fail	Remark
1	GPS host vehicle velocity measurement error under 5%	-	-	not checked, GPS used as the reference
2	Radar host vehicle velocity measurement error under 10%	√
3	Radar trailing vehicle velocity measurement error under 10%	-	-	not checked, assumed OK due to fulfilled Criterion 2
4	Radar measuring range 5–70 m	√
5	Radar distance measurement error under 10%	√
6	Alert activation rate over 95%	√
7	Radar provides reliable, disturbance-free distance measurement		x	false targets due to electrical interference
8	Radar senses trailing vehicle cutting in onto the host vehicle lane	√
9	Radar must not sense objects outside the roadway or vehicles on other lanes		x	false alerts in tight curves

shows the summary of the Pass/Fail criteria and their fulfilment. It is obvious that the prototype device fulfils five out of nine test criteria; two criteria were not tested; and the device fails two of the test criteria. We were not able to adequately test Criteria 1 and 3 due to the lack of a reference measurement device for velocity and due to limited testing space not allowing vehicle velocities over 50 km/h. It was assumed, based on previous research [24,25,26], that the GPS velocity measurements are sufficiently accurate to be used as the velocity reference. For the criteria that had to be declared as Fail (7 and 9), the cause of failure was determined and, in the case of Criterion 7, corrected programmatically or, in the case of Criterion 9, found as not being heavily detrimental to the function of the device.

4. Discussion

The research of the traffic accident statistics, on the one hand, and of the state-of-the-art devices, on the other, yielded the conclusion that there is the need for a device for alerting the motor vehicle drivers about following a particular vehicle on a too short of a safety distance. The market survey revealed that a universal low cost device that would be suitable for the task does not yet exist. The analysis of the traffic legislation proved that such a device can be made compliant with existing regulations. These findings were the basis for the development of a self-contained device that can be attached to almost any motor vehicle and automatically provide visual alert to the drivers of the trailing vehicles violating the two-second safety distance rule.

The development started by setting out the functional requirements of the system. In the early stages of the development, several concepts were synthesized. A morphological matrix was compiled to define them, and the functional value analysis was carried out to evaluate the concepts and to select the most appropriate one regarding their technical and economic value. The highest priority evaluation criterion was the optimization of the cost while still satisfying the functional requirements.

After some initial considerations, the principal measurement method was selected to be a radar sensor. The rationale behind this decision is the relative insensitivity to environment parameter variations and sensors with suitable characteristics available at a relatively modest cost. In the beginning of the actual sensor selection process, there were considerations whether to use a readily-available adaptive cruise control sensor. While this is an attractive option as far as its price and mounting possibilities are concerned, the lack of documentation describing electrical connections and data transfer protocols prevented its implementation for the time being. Instead, a Doppler radar, as found in adaptive traffic signage, was used.

From the beginning of the design process, a single-board computer was intended to be used for sensor control, data processing and alert activation. Based on the research of the market and previous positive experience, the Raspberry Pi Model B was chosen for the task. Throughout the design process, from the initial data transfer tests to testing the finished prototype in real traffic, the Raspberry Pi has continuously proven itself exactly the right choice. It owes its suitability mostly to the excellent balance between the processing power and the flexibility of a Linux-running system, on the one hand, and its small form factor and modest power requirements, on the other. This is the balance that was almost impossible to achieve as recently as a few years ago when the gap between “classic” microcontroller-based embedded systems and small PCs was still wide open. An added bonus of the Raspberry Pi is its on-board interfaces, which eliminate the need for overly-complicated connection interfaces required for communication with the system components.

The chosen components were integrated into a working prototype of the device. As per the functional requirements, the device can be used on any vehicle, as long as it can provide on-board electricity and a suitable surface to mount the sensor enclosure and the LED-matrix display.

The control software is written in Python 2.x. In its basic version, the software consists of modules for sensor data acquisition, data processing and comparison and for activating the visual alert. These modules are called from the endless main loop, providing continuous operation without the need for user intervention. Should additional functionality ever be required, the existing routines can be altered and new ones added to the existing code. For debugging and service purposes, an SSH connection over Ethernet can be used to connect an external computer to monitor the operation and/or adjust the operating parameters.

The finished prototype was extensively tested. The first tests were performed in laboratory conditions in order to test the compatibility and performance of sensors. After reviewing the preliminary results, a series of Pass/Fail criteria was set out to test the function of the device in expected conditions in traffic. A test protocol was devised to test these criteria. Generally, the test results were satisfactory, passing five out of nine criteria. As expected, some of the tests yielded results that required adjustments to the system. These were all implemented by software changes only and included only minor additions to the data processing algorithms. With those adjustments, the system proved itself reliable and robust in daily traffic. The cost of the components used in the final version of the prototype was kept significantly under 1000 €, which is within the desired target budget, as well. To display the alerts on the prototype device, a relatively small (150 × 100 mm) 14 × 9 LED-matrix display was used as a proof-of-concept. To increase the visibility, a new, larger, transparent LED-matrix display (Figure 11) has been designed and is currently awaiting prototype production.

The prototype device as described is currently used on a road surveying vehicle during various continuous measurements to keep the trailing vehicles at a safe distance in order to not disturb the measurement. The direct benefit of this use is a reduced need for road closures, since the measurements can now take place on the roads open for traffic even without employing a separate distance-keeping vehicle.

Although the device has proven to perform soundly, there is, of course, always room for improvement. The most apparent challenge is false alert triggering due to roadside objects in tight curves. While it does not really affect the robustness and reliability of the operation on straight roads, it is nevertheless an inconvenience that has to be considered and possibly addressed. The possibilities of including target angle sensing are currently being studied, either from the existing vehicle steering wheel sensors or by implementing lateral distance sensing by the radar. Before the device is ready for wider implementation, its operation in unfavorable conditions will also have to be tested more thoroughly. This includes tests in extreme weather, such as rain and fog, and under the influence of other radar devices (vehicles with adaptive cruise control, police speed guns, etc.). None of these tests have yet been conducted, but are planned in the near future. Using the Raspberry Pi as the processing unit makes the design of the prototype device ready for future functionality expansion by employing additional sensors or by implementing additional software algorithms if the need arises. The replacement of the originally-used Model B Raspberry Pi with one of the newly-available models also opens new possibilities. By using a quad-core Raspberry Pi 2 or Raspberry Pi 3, it may be possible to eliminate the radar DSP board by relegating the signal processing to the Raspberry Pi itself; by using a Raspberry Pi zero, it is possible to minimize the physical dimensions and the power requirements of the device. The design of the Raspberry Pi ensures the compatibility of the operating system and the user software across the model range.