Reutlingen University: AGL Based Driving Simulator

By May 8, 2020Blog, Infotainment, Use Cases
Guest post by: Prof. Dr. Marcus Schöller and Thomas Walzer, Reutlingen University

Introduction

At Reutlingen University, we have been working on the topic of automotive services and driver assist systems for several years. For this purpose, a driving simulator has been built. On that time we worked on a concept of a InVehicle Infotainment system based on OSGI. The implementation proved to be hard, but the idea of flexibly installing services and applications into a car has been driving our work ever since. Two years ago, we evaluated and chose AGL as a replacement for our base system; AGL being an open source and industry standard platform with an active community were important factors for our decision. We became an AGL member last year and have started to migrate our driving simulators since then. We are using the AGL-based instances in our research projects as well as for education purposes.

CAN bus integration

First we had to integrate AGL into the driving simulator by connecting the AGL instrument cluster to the existing CAN bus. The steering wheel and pedals send control commands via the CAN bus messages to the driving simulator where they are translated into movements of the virtual car. One value calculated is the speed of the car. To display that information on the AGL instrument cluster, this information is sent via the CAN bus again. Moreover, we also use the CAN bus to connect car sensors, e.g., temperature sensors which we want to visualize on the AGL IVI, and actors, e.g. power windows that are controlled from there.

The base of our driving simulator is our CAN bus gateway. They are derived from a real car architecture adopted for research. Therefore, we have built the following setup which is easily extensible with new systems attached to the respective bus channels:

To handle the messages from different sources we have a tool that is a broker (PySim2CAN) between the OpenDS driving simulation software and the different CAN bus gateways. OpenDS usually uses a TCP connection to send and receive data. To better mimic a real car, our broker terminates this TCP connection and receives values like speed and gear from OpenDS. It translates motor and gear values into CAN bus messages that are sent to the powertrain gateway and distance sensor values to the car or obstacle in front to the body gateway. Hence, the broker simultaneously attaches itself to both channels (see figure above). We also use the TCP connection to send data from the CAN chassi gateway to the driving simulation to transmit the steering wheel angle and the pedal values. All the components that are used for the interior like fans are connected to the interior gateway. In the current planing the IVI system is connected to that CAN bus, too. A second CAN bus that is used by AGL systems is the telematics gateway to get e.g. the speed values forwarded from the powertrain in the instrument cluster.

To get the whole system working, we are defining the CAN bus messages in a database that is parsed by our broker. These messages were developed in previous work. As an example, we have developed messages for window controllers to open and close the window of our simulated car. In order to keep the driving simulator vendor independent, we are using relative values, e.g., percentage of a totally closed window, where possible.

With our experience from previous work and the knowledge of socketcan, the integration of AGL into our simulator was really straight forward. We were quickly able to receive and send messages in AGL to communicate with other nodes. Finally, one of our students built an HTML5 AGL app to control functionality on a microcontroller attached to the CAN bus.

Our next goal is to setup a pipeline to automatically convert the CAN bus messages for usage in AGL instrument cluster and IVI and make them known to the agl-service-can-low-level. We use XML to define CAN bus messages with all their parameters including value ranges. An example CAN bus message definition file can be found here: CAN example. Thereby, our students will be able to quickly attach sensors or actuators as CAN bus nodes, describe the required messages for this peripheral and make it accessible via the AGL IVI. A short tutorial on how to configure the CAN bus devices and how to setup AGL is available on our getting started page.

The way ahead

Our Future Mobility Lab allows us to rapidly develop and evaluate new types of Human Car Interactions for future automotive services and applications. The simulator enables the analysis of user distraction and unsafe driving while interacting with applications under development.

At the moment, we are developing a carpooling application for our university. This application uses big data analysis to identify people that regularly travel similar routes to and from the university at roughly the same times. Obviously, these persons could share a ride but do not do so at the moment because they just don’t know each other, e.g., working in different departments, and hence do not realize that the take similar routes. When two or more people pick up in the suggestion to share the ride, the university rewards this behaviour. Our incentive model defines benefits for the driver as well as for the passengers. Passengers log into the ride by registering themselves with the car using a bluetooth connection from their mobiles. Drivers can define a maximum acceptable detour for their ride and the systems matches drivers to passengers.

For us in the faculty of computer science the possibility to develop HTML5 apps is a function that allow us to integrate AGL in early steps in the studies.

Another research direction is in the area of interactive bio-based surfaces. We use so called smart textile surfaces that could be used as buttons or interaction areas in the car. This is a collaborative effort with researchers and students from the School of Textiles & Design at Reutlingen University. In their bachelor programme on “Automotive Interior Design” new design concepts for future cars are developed. It is our intend to use the AGL based driving simulator to take these design concepts one step further by implementing some of them into our system for real world evaluations.

About the Authors

Prof. Dr. Marcus Schöller is a professor for cloud computing at Reutlingen University. His research interests are on resilient distributed systems and future mobility services. The results of his research have been published in several articles and books and he is a frequent member in conference committees. Moreover, he has been contributing to standardization activities and has been leading standardization working groups.  He is co-leading the Future Mobility laboratory at Reutlingen University with a focus on value added automotive services where in-car systems and car-external systems cooperate to improve the driving experience and mobility in general.

 

Thomas Walzer is a Researcher (M.Sc.) at Reutlingen University. He has been dealing with the topic of making through his hobby (amateur radio) since he was young. After one semester electrical engineering, he started to study media and communication informatics for his bachelor’s and master’s degree. In his bachelor thesis, he developed a concept for an in-vehicle infotainment system based on OSGi. He also developed a CAN-bus network for the driving simulator at Reutlingen University.