Until now, driving robots with a high mechanical component and corresponding installation and calibration costs had to be used to safeguard vehicle functions. Now e:fs TechHub has a much leaner yet powerful alternative: LeanDRA. It uses existing hardware and software in the vehicle to perform automated driving functions autonomously. In most cases, developers and testers of functions such as ADAS can thus dispense with the use of conventional driving robots.
AEEmobility: What is the idea behind the software-defined steering robot LeanDRA?
Niklas Jester: The question arose in the company as to how vehicle functions could be validated if future autonomous vehicles do not have a steering wheel and therefore the possibility of using a conventional steering robot is eliminated. We then investigated what we could already implement in this regard today with the existing hardware and software in the car, initially focusing purely on the steering function. The starting position was favorable for us because we were able to build up comprehensive and in-depth expertise as part of the numerous joint development projects with the VW Group.
Niklas Jester is Product Owner at e:fs TechHub GmbH, a joint venture between Akkodis Germany Solutions GmbH and CARIAD SE.
What were your findings?
It quickly became clear that we could do a lot with the car in terms of steering and beyond by accessing vehicle communication and manipulating sensors. We saw that we could replace the classic steering robot in many applications.
What does that mean in concrete terms?
For example, it is possible to use a software-defined robot in the validation of ESC systems and test scenarios to be covered there, such as corner braking. In this test, the vehicle must be driven in a circular path up to the dynamic limit and then braked sharply. The software-defined steering robot LeanDRA developed by us can perform this driving task without restriction. Connect our hardware to the vehicle bus, call up the prepared trajectory and press play, and the test drive runs automatically. A driver or an additional mechanical steering robot is not required for this.
However, part of this test scenario is also to find out how the ESC function behaves, how the vehicle continues to move after braking and where it comes to a standstill at the end. In our opinion, the processing required for this is far too short in many of the solutions available to date and testers are left to their own devices. In the case of corner braking, for example, we have seen testers drawing circular paths and measuring them with a ruler to determine the offset. That can’t be the solution.
The LeanDRA system does not require any modifications to the standard vehicle. The road approval can remain in place, making it particularly easy to change the proving ground. © e:fs
Which path are you taking?
We have GPS in the vehicles, with which we can precisely and automatically record the distance traveled with 2 cm accuracy during the test. We use this and then evaluate the data automatically. This means great added value for users.
This means that a classic solution for recording and analyzing the data is not required for specific test tasks!
Exactly. The idea was not to first record the data externally and then process it; with our approach, the data is generated and processed in the system anyway. Then we can also record it at the same time and, depending on what data is involved, analyze it live or afterwards and present the result to the tester.
But this is limited to the data required for the test, isn’t it?
Yes, we record and process the data selectively. Dedicated data acquisition systems, such as those used in vehicle development and validation, generally record much more data, so that very different analyses can be carried out afterwards. Of course, we are bound to what we have recorded. This means that we really concentrate on a specific, previously defined use case.
So you can do much more with LeanDRA than perform dynamic driving functions without a driver or steering robot?
Initially, we focused our concept on use in dynamic tests such as ESC applications. However, this is a very specific area that is the responsibility of the OEM and is also manageable from a market perspective. Things look very different when we look at ADAS driving functions and see the vehicle as a robot. Everything that can somehow be controlled in the vehicle can also be read out or manipulated by us.
This means that we not only focus on the classic testing and validation of ADAS driving functions, but also on all applications in which cars are moved and data needs to be evaluated. This ranges from the development and testing of vehicle components such as LiDARs and radar sensors to partial functions and complete ADAS solutions.
The LeaNDRA system is very compact. All the necessary components are integrated into one system. A single secure plug connection to the vehicle is sufficient for the test start. © e:fs
What does the LeanDRA solution look like today?
We have a basic system that takes over the robot function and is the same for all applications. In addition, there is a part with which we can adapt the solution to the specific requirements of the individual application. For example, with regard to the required control of trajectories, control of actuators or an additional option to visualize something to the driver via the instrument cluster.
Can you please explain this in more detail?
The basic system is the control unit with which we take over the vehicle in a safe, i.e. switched-off state, then start the engine, engage the gear, move the vehicle lengthways and crossways and can also operate additional functions such as indicators, horns and windshield wipers. At the end, we hand the vehicle back over in a safe state, i.e. with the engine switched off. This entire chain briefly summarizes the function of the basic system.
This module then forms the basis for a further module, which we use to adapt our solution to the various vehicle platforms. This is necessary because the vehicles follow different communication concepts. For example, the Audi Q8 we use as a demonstrator uses Flexray as its bus system, while the MEB-based vehicles use CAN/CAN FD. We are adapting the second component of our system accordingly, which in the case of VW covers many models at once. If future requirements come in the direction of Automotive Ethernet or other communication solutions, we can do this again by adapting the second component of our system without having to touch the basic system. This is also the reason why we chose to modularize LeanDRA.
For which vehicles is LeanDRA currently available?
As we control the vehicle systems, we are very deeply involved in vehicle networking. For this reason, we initially concentrated on vehicles from the VW Group for historical reasons. VW also has the advantage that the company has a huge range of vehicles – from small vehicles to electric vehicles and all-wheel drive vehicles through to commercial vehicles – so that users can test their products with a wide variety of vehicle types and classes.
However, we are now in the process of rolling out LeanDRA beyond VW Group vehicles. We are also relying on the support of OEMs in order to keep the development time required for integration to a manageable level by providing access to the relevant databases. Of course, this poses a certain challenge, as the databases are still the „holy grail“ for many German OEMs.
However, we are convinced that we will be successful because of the potential of our technology. This is also because we do not give out any vehicle data to the user that goes beyond the classic data that anyone could read out anyway – e.g. via the OBD interface or the vehicle’s displays.
Thanks to the two-stage safety concept, the driver can take control of the software-defined steering robot LeanDRA at any time. © e:fs
What requirements does your system place on a vehicle so that it can be used in principle?
For our system to be used to its full potential, the vehicle only needs to have two functions that can be found in almost every vehicle today: Cruise control, preferably an ACC function, and some kind of lateral function such as a parking assistant or lane center guidance. However, if the vehicle has a manual gearshift, there are limitations or the driver may have to change gear. If it is a vehicle with automatic transmission, we can automate this as well. If a test only requires a lateral function, for example, we naturally do not need ACC.
What are the limits of the system?
There are only a few limits. One point is that, unlike a steering robot, we don’t have the option of using our own motor to apply additional pressure to the system. We also have a solution for this that we have not yet shown publicly. Therefore, there are actually no dynamic limits. However, applications where this extremely high dynamic range is required are also absolutely marginal areas.
Another point is when the user wants to test the ACC in the vehicle itself and we use the ACC interface to control the vehicle at the same time. Generally speaking, we can test all systems in the vehicle, but not usually the ones we are currently using. But even here it is worth taking a closer look: in the case of the lane departure warning system, for example, we can drive into the test situation with our system, then deactivate it and hand over control to the vehicle and still continue to record and evaluate the vehicle’s reactions. In this case, we have to work with the customer to check exactly whether this type of control is permissible for the desired application. In the USA, for example, there are tests in the NCAP area in which a steering robot is described in order to drive this test. OEMs prefer to use this to be on the safe side.
If I understand you correctly, you can turn a standard vehicle into a robot-controlled vehicle with minimal effort?
That was always important to us. It was clear to us that if we didn’t have to install additional sensors, actuators and mechanics, it should also be possible to equip the vehicle with our system with minimal effort and convert it to robotic operation or start the planned test in just a few simple steps. As soon as our hardware is installed in the trunk or on the rear seat, the vehicle can be driven on public roads to the test site, as it is an unmodified production vehicle. As soon as the test is to be started, all that remains is to connect the hardware to the vehicle bus via a central connector on the system, switch on the hardware and then the test can begin.
e:fs TechHub GmbH
In the meantime, the company has significantly expanded its range of expertise with topics such as ADAS, AI and data management, and now sees itself as an independent partner to OEMs and suppliers and offers its own product solutions.
This is what the term TechHub stands for in the company name. Headquartered in Gaimersheim (Ingolstadt), the company also has sites in Erlangen and Wolfsburg.
How can users plan and carry out test drives?
We are deliberately holding back at this point. We didn’t want to launch the hundredth software on the market. There are already more than enough commercial software products for this. We have seen that most users install their own hardware with which they generate things such as perception, situation interpretation and the desired trajectories. These systems can connect to our system via CAN or Ethernet and send the driving commands. For demonstrations and simple applications, we offer a web server that can be used to make basic settings as well as perform simple tasks such as starting, following a GPS track and stopping. If you want, you can also control the vehicle via a wireless games console. We don’t want to go beyond that, but rather focus on providing the driving robot with access to all the vehicle’s movement and other functions.
Our strategy is therefore to be as compatible as possible and to support existing interfaces such as IMAR Navigation for scenario-based testing, which is also being transferred to ISO. Further interfaces are in the works.
To what extent will future vehicle architectures – keyword SDV – and increasing measures to ensure data security affect LeanDRA?
Of course, it will be a challenge because bus encryption and other cybersecurity issues come into play for security reasons. At the same time, at least the OEM must continue to have the possibility of access. In addition, various OEMs are thinking about interfaces that enable verified apps to connect the vehicle to the smart home, for example, so that it can park itself in the garage. We therefore assume that there will always be interfaces that we can use for our purposes. However, there is currently so much movement in this area and there are still so many uncertainties that we want to wait and see how things develop.
And above all for the current core area, i.e. the development of driver assistance functions, in which LeanDRA is currently primarily used, as well as in use in hare vehicles on the proving ground, it is not always necessary to automate the most advanced vehicle – often the previous generation, which causes no problems for LeanDRA, is sufficient.
If someone is interested in using your system, how does a project work?
As a rule, we first have to go through the prospective customer’s use case with them to clarify what we can already cover with our basic package and what adjustments we may need to make. The main aim here is to define the limits of the system together in such a way that the customer’s use case is not restricted and can be implemented safely at the same time.
If we do not have to make any major adjustments, we can provide a vehicle supplied by the customer and equipped and tested with our system within a few weeks.
The actual initial installation only takes about two hours. The system can be permanently mounted in the trunk – this is the most commonly chosen option – or on the rear seat if easy transfer between vehicles is required. In order for the system to be operational in both variants, it then only needs to be connected to the car’s vehicle bus, as mentioned above.
So simply setting up a vehicle for the test is much easier and faster with LeanDRA than when using a mechatronic steering robot, especially if I want to switch between several test vehicles?
The repeated physical installation of a conventional steering robot – usually additional robots are required, e.g. to actuate the pedals – is one thing that is definitely not necessary with us, as we only have to install it once. The other is the subsequent calibration effort for the mechatronic solutions. This requires trained personnel. With us, this step is also eliminated because the OEM has already ensured that the corresponding control command to turn to a certain steering angle is executed precisely.
To be fair, there are also interfaces that pose a challenge for both solutions. For example, the acceleration curve for the combustion engine is not linear and is therefore more difficult to control.
However, by accessing the vehicle bus, the scope of possible tests with LeanDRA should be significantly greater than with a mechatronic steering robot?
In any case, we can map a greater variety. Everything that is mapped in bus communication can be used for customer applications. For example, if I want to observe the vehicle’s reaction during and after emergency braking, we can simply simulate a virtual obstacle for the vehicle. This is not possible with a conventional steering robot. Other tasks are very difficult to address with a steering robot. These include setting the blinker or the windshield wiper – or even more complex due to the required 3D movement – switching on the high beam. For us, this is just a matter of setting a few bits.
That leaves the question of cost!
Compared to a steering robot, which offers the closest functionality to that of our base module, our solution requires fewer components. As mentioned, for example, we do not need a pedal robot and similar supporting auxiliary devices – with the possible exception of a gear-shift robot in the case of a purely mechanical gearbox. We also don’t need an additional battery to operate all the units. Compared to such a mechatronic driving robot, we are around a third of the cost. I also have significantly more space in the vehicle, the driver’s seat remains free and I can continue to use the vehicle as normal – even on public roads, and I also have a wider range of functions. The bottom line is that users get significantly more for their money.
Niklas Jester – Product Owner LeanDRA (Leitner ConnX customer system in the background) © e:fs
What else do you have in the pipeline for LeanDRA?
Our next goal is projects with other OEMs. We also see many applications for our system beyond classic road vehicles. The underlying logic, especially the safety mechanisms, can be applied to any movement platform.
For example, we have already implemented the urban mobility project ConnX with cable car manufacturer Leitner, which involved placing a cable car gondola that was previously suspended from a cable on a driving platform and moving it automatically to cover the last mile. Corresponding applications are conceivable in the port area to move containers autonomously, or autonomous vehicles in agriculture. Our concepts can actually be transferred one-to-one here. (jr)
