Wednesday, February 1, 2023 · 0 min read
Vehicle Dynamics Testing Based on ISO Standards
This story tells how we, LEANE and Dewesoft, helped some friends, working in different departments of a large car maker, to implement new solutions to improve their daily vehicle testing job - introducing the Dewesoft R2DB data acquisition system and the Vehicle Test Suite software application.
With the main headquarters in Parma and offices in Turin, Milan, and Rome, LEANE International is a company oriented toward the marketing of sensors and electronic instrumentation for industry and research.
If initially the techniques available were based on analog, over the years, following technological improvements, we have extended our skills in various sectors that allow us to offer complete solutions in the field of data acquisition systems and electrical engineering.
We operate with passion, are attentive to technological innovation, and are strongly oriented to the needs of our customers. The technical-commercial structure, thanks to the main headquarters in Parma and offices in Turin, Milan, and Rome allows you to operate throughout the Italian territory, both for sales and for assistance.
Our friend, Gianni, works in the Chassis and Vehicle Dynamics lab of a big car manufacturer group. Gianni and his team have to deal with a number of different standard applications for benchmarking and development of the handling, ride, and braking performance.
Their daily job is to measure the vehicle dynamics performance and to analyze the behavior of the related subsystems, based on both ISO standard test procedures and legacy test protocols developed in the company. Sometimes, the lab has “special” test requests that need a multi-disciplinary approach or the development of new testing methodologies.
On the measurement side, a typical setup for objective handling or braking objective analysis includes:
an optical sensor for speed and sideslip angle, with analog or CAN output,
a sensor for measurement of the steering wheel angle and torque,
an Inertial Measurement Unit (IMU),
Pedal force and position sensors,
Hydraulic pressure sensors,
several thermocouples,
A GPS receiver, with the differential correction to achieve centimeter-level accuracy on the absolute position, and
Vehicle CAN bus data.
In many cases, they have to use additional accelerometers, strain gauges, ride height sensors, and cameras or they need to measure electrical power.
Figure 1. An optical sensor (left) is used for the measurement of the speed and sideslip angle, and a laser ride height sensor (right) for the precise measurement of roll and pitch relative to the ground.
The list of wishes
So, Gianni came to us looking for a new data acquisition (DAQ) hardware solution with just a few requirements:
16 analog inputs,
with the possibility to manage potentiometers
strain gauge sensors,
additional counter inputs,
a couple of CAN ports for vehicle CAN bus data,
and maybe integrated GPS receiver too,
and (why not?) RTK correction,
and a battery for being independent of the car power supply,
better would be a pair of hot-swappable batteries,
and, sometimes, I need to add a bunch of thermocouple inputs,
and a remote controller to start and stop recording, for the convenience of the test driver, and
easily expandable with additional analog channels.
Indeed, aside from Gianni's department, his friend Enrico is leading the testing lab of the Vehicle Performance and Fuel Economy department, so in the end, we collected the requirements of both. Finally, the R2DB data acquisition system was born, because we wanted to make Gianni and Enrico happy with the right instrument.
Our custom-made remote controller with a display allows the test driver to navigate a predefined test menu and to look at the most important parameters without turning his eyes off the road.
Tricky test driving
On the testing procedure side, the job consists of applying those test protocols mentioned above. It means that the test driver has to drive the car following predefined steering, accelerator, and braking actuation profiles. The task may appear not so difficult, at least for some types of tests, but even the simplest test maneuver must be executed complying with precise requirements and tight tolerance boundaries on several measured variables, in order to guarantee repeatable and accurate results.
For example, performing a sinusoidal steer input on a 2km long, 15m wide straight, the test driver has to keep under control:
the speed,
the amplitude of the steering wheel angle required to achieve the desired level of lateral acceleration, and
the steering frequency.
Of course, he also needs to have a look at the road, just to avoid going on the grass, crashing into a barrier, or into another car.
In the case of sinusoidal input, the focus is on precise actuation at a low steering angle and low g. Other tests, e.g. step steer, require fast and precise actuation at higher steering wheel angle values, with high steering velocity, low overshoot, and constant steering wheel angle (within a 1-degree tolerance) in the steady-state.
Several test protocols require performing the same test maneuver varying one parameter at a time, e.g. increasing the vehicle speed from one run to another, or the steering angle. Then you need to have a look at aggregate data in order to see how the test sequence is proceeding after each test run.
Here we come to another important point: having efficient vehicle testing is a matter of both good hardware and the right companion software.
Gianni’s team has a long tradition of very skilled objective test drivers. But, even the best objective test driver in the world needs to see how well he performed, and if a test run has a small imperfection, he needs to do it again in order to make his performance engineer happy (besides showing that he can do it the perfect way).
In the past, a performance engineer had to check the test data in order to provide the test driver with feedback about the quality of the test run, to tell him if he failed the execution due to any variable out of range, and eventually, to repeat the test.
Check out:
Improved software
So, Gianni’s team needed a good software to take home objective test results, without having to send a performance engineer on the track with his test driver all the time. But it can’t just be software for engineers - it must be software suited for track engineers, with:
a lot of buttons,
a lot of functions,
to manage any configuration of all the existing sensors,
to do a lot of complex calculations,
a lot of plots, and
a lot of numbers.
All the things that vehicle engineers like so much. But, at the same time, it must be software for the test driver:
as simple as possible,
only a few large buttons,
just a few simple plots,
just a few simple and large numbers, and
possibly with red/green flags,
so that you (the test driver) can immediately understand if the test runs you just finished are as good as your track engineer would expect or if you can / should do it a little better.
Vehicle test suite software
So, we started another piece of work in order to make both the engineers and test drivers in Gianni’s team happy. After thinking for a while, we agreed that we had to:
put all the stuff that most engineers like inside Dewesoft, and
put all the features that a test driver needs in an external application running on top of Dewesoft.
This is how the Vehicle Test Suite (VTS) was born - an application for the DewesoftX Vehicle Dynamics plugin.
Actually, in Gianni’s team, there are some quite demanding guys, so they asked for a number of custom features and a fully customized version of VTS with exclusive content.
At the end of the day, we learned that it is not so difficult to make engineers happy, while it is by far more difficult to make a test driver happy about the software.
Anyway, now the performance engineers can stay in their office to analyze data and improve vehicle performance, while their test drivers can go on the track without their supervision. Definitely, everyone can focus on his main job.
Driving robots
In spite of this, the professional objective test driver tradition is still going, there comes a time when they, the “human” drivers, have to turn their minds to share their job and the proving ground with driving robots.
In the beginning, the use of driving robots was limited to some specific homologation test protocols, where extremely high actuation rates and amplitudes must be achieved with small errors and high repeatability.
But also, other test maneuvers are really frustrating for a human driver. Think about actuating a linear increasing steering angle at 5deg/s or less, up to 1m/s2 lateral acceleration, with a ridiculous tolerance boundary on the steering movement. Even the most experienced and proud objective driver would be happy to let a robot execute this kind of test.
Our friends Demetrio and Paolo pushed to promote the use of the robots for some testing activities in the vehicle dynamics area, getting advantages in terms of efficiency and accuracy of the test results. What is the impact of this choice on the measurement system?
The setup of a driving robot for vehicle dynamics and brake testing includes:
a real-time controller,
a user interface software,
a couple of devices to trigger the robot actuation and to safely abort the test
steering and/or pedal actuators,
embedded steering and pedal sensors (angle and torque, position and force)
IMU with integrated GNSS receiver, and
with differential correction for centimeter-level position accuracy (RTK2).
The real-time robot controller manages the actuators based on the selected combination of steer, brake, and accelerator actuation profiles, or based on a path profile. The IMU+GNSS device feeds data to the controller via CAN or Ethernet. The controller may use these data to:
follow a predefined path, including the speed profile,
follow a profile of desired acceleration/deceleration,
trigger an actuation based on a given condition related to a given variable e.g. absolute position, roll rate threshold, etc…
From the point of view of the data acquisition, the AB Dynamics robot system itself can be used as a data logger, or it can be seen as a “sensor cluster” able to output data on the CAN bus: data output includes the steering and pedal inputs, the inertial data, the geo-localization data.
This solution is well-suitable when we have a complex sensor setup for special experimental investigations, with a number of analog channels that can be easily conditioned by Dewesoft data acquisition systems. This - see figures x, x, and x below - is a nice application with a steering robot, a combination of SIRIUS DAQ systems and distributed KRYPTON DAQ modules.
This way they take advantage of the accuracy and reproducibility of the AB Dynamics robot system on one hand and the extreme flexibility of the Dewesoft DAQ system, on the other hand, getting the most effective solution for their needs.
Conclusion
To sum up, I have tried to explain how our friends got advantages from our solutions and improved their job, increasing quality, and efficiency:
optimize the time and competence of the people on the team,
reduce the vehicle setup time in the workshop,
reduce the test time on the track, and
increase the reproducibility of the test data.