Successful NCAP tests are the result of careful planning and execution, and of course, good measurement data. Whether a test involves multiple vehicles, vulnerable road users or simply being able to maintain a speed accurately, there are two parts to a successful test from a measurement point of view. First, there is the need to capture the required data while meeting all the test criteria and second, the data must be extracted and passed on in a way that allows it to be analysed as required. In this blog, we wanted to look at some of the features of RT-Range and how they’re helping automotive manufacturers, test houses and Tier 1 suppliers around the world capture good measurement data in NCAP tests.
All NCAP protocols specify the minimum accuracy with which measurements should be made. When paired with one of our RT inertial navigation systems, RT-Range meets the requirements laid down in all NCAP protocols worldwide and exceeds them in many areas. But there’s more to accuracy than simply achieving a number. In order to be useable, it’s important that a measurement system can sustain that accuracy, so you don’t lose any data due to changing conditions. Our RT products deliver this by combining both inertial measurements and GNSS measurements. In this way, the system isn’t wholly dependant on one, and can use the best aspects of both to deliver an accurate, reliable and most importantly, repeatable set of measurements with a relative accuracy of 3 cm.
Data Logging (selective test)
As well as accurately measuring the vehicle under test (VUT) and other test elements, one of the strengths of the RT-Range is how the software can be configured to automatically extract portions of the data based on user-defined parameters in real-time and post-process. As the test parameters can be saved, this is a powerful and time-saving tool, as it allows the measurements required for a given NCAP test to be automatically extracted.
For example, for AEB testing, the software can be configured to save files whenever the time to collision drops below four seconds. Or for lane-keep-assist tests, a virtual start line can be configured so data is output as soon as the VUT crosses the line. Of course, the measurements included in all CSV data files can be configured, and an absolute GNSS timestamp is included in the file so it can be synchronised with other data sets. Alternatively, trigger channels can also be fed into the hardware, and files can be generated in response to that.
Regardless of which solution is used, our software has evolved over the years to include the tools that ADAS test engineers have asked for, to enable them to accomplish their tasks as easily and quickly as possible.
Steering robot output
Some NCAP tests, such as lane support and AEB-VRU, require the vehicle under test to be driven in a very precise and repeatable fashion or require certain actions to be triggered at specific times depending on the speed and position of the test vehicle. In tests like this, a driving robot is often the preferred option because they deliver repeatable and predictable results. However, to do so, the steering and pedal robot needs to not only know where it is, but also how it’s moving—measurements that the RT is already supplying to the RT-Range inside the car. Using a standard Ethernet interface, it’s easy to pass the required measurements to driving robots in the VUT. Real-time measurements of the test vehicle can also be passed wirelessly up to 1 km using the RT-XLAN, if they need to be made available to other equipment being used in the test scenario.
While the statistical analysis of NCAP results are handled back at base, there is always a need to field-check that all the equipment is working correctly on the day. The easy way to do this is via our NAVdisplay software, which is supplied free of charge with all RT and RT-Range systems. This software takes measurements and information being output via Ethernet and allows the user to display the information along with conditional formats. For example, RTK integer position accuracy is required in nearly all NCAP protocols, so NAVdisplay allows you to monitor the GNSS mode and display it as, say, a button. As the driver has a lot to concentrate on, the button might be formatted so that it’s green when the system is in RTK integer, but red at all other times. By configuring all the important measurements in this way, the vehicle driver can glance across and know they are still getting valid data as long as all the buttons are green.
ADAS technology has changed a lot over the last 10 years, and it looks set to keep doing so. While the aims of the technology will undoubtedly change a lot, the need to accurately test and validate such systems will not. From OxTS’s point of view, we’ll continue to add new features, such as the recently release Multiple Sensor Point functionality, to the RT-Range so that it can remain at the cutting edge of ADAS measurement for both existing and developing systems. This is perhaps especially important at the current time as the industry (and public) grapples with the balance between ADAS and full autonomy.