From 8:00 PM Friday, July 23 - 7:00 PM CDT Saturday, July 24, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Designing an Electric Racecar With NI LabVIEW and NI Single-Board RIO

David Möller, Technical University Dresden

"The data analysis in DIAdem and the return of real data in the multibody simulation also refines the concept-finding process for the next vehicle and increases the understanding of the actual racing car."

- David Möller, Technical University Dresden

The Challenge:

Developing telemetry and motor control systems for an electric racecar with highly modular, scalable hardware and software.

The Solution:

Using the NI Single-Board RIO platform, a high-resolution NI 9219 analog module, and an NI 9853 controller area network (CAN) module to measure sensor values, perform motor control, and communicate with the inverters.

Author(s):

David Möller - Technical University Dresden
Rick Weiß - Technical University Dresden
Stefan Weser - Technical University Dresden

 

Overall Concept and Hardware Setup

The formula student racing team Elbflorace e.V. produces one race car annually. The team designed and built this year’s car, Areus, in less than eight months. Areus is the first racing car developed by the Technical University (TU) Dresden that is powered solely by electricity and complies with the Formula Student regulations. The car is driven by two electric motors that are permanently erected and synchronous. The motors are powered by two battery containers consisting of 462 cells each. Two inverters take care of the torque control for each motor, which is parameterized via CAN.

 

 

To usefully transfer power to the road, comprehensive engine control is necessary and requires various sensor data. Digital and analog sensors are connected in various ways to the single board. Most are directly connected. A vehicle dynamics module delivers additional data through the NI 9853 CAN module. The inverters and battery management system send sensor data through the CAN bus.

 

Several temperatures are recorded within the cooling circuit and battery to power down the vehicle in case there is danger of overheating. Front and rear break pressure is also recorded. For a detailed vehicle analysis, four wheel speed sensors, a steering angle sensor, and the already mentioned CAN module evaluate the acceleration of all three axles as well as the rates of roll, pitch, and yaw.

 

Mistakes often occur when evaluating analog sensors because the cable length is about 2 m. For this reason, steering angle and break pressures need to be measured differentially. The NI 9219 analog module innately provides this option. The NI sbRIO-9642 also has the capability for differential measurement. However, beside the first analog module we used a second one, because an additional connection is required for the temperature sensors, as the analog module NI 9219 only has four entries.

 

To recognize the pedal position and measure the driver’s desired momentum, we mounted a quadruple redundant system consisting of angle sensors with pulse-width modulation (PWM) to the “power pedal.” Aside from the cell temperatures, the BMS delivers voltage and current for each of the cell modules in the form of a CAN message and outputs its own status. The inverters output values such as current torque, momentum, electricity flow rate, and temperature.

 

All sensor data and CAN messages are recorded in the field-programmable gate array of the NI Single-Board RIO device. The FPGA VI files this data in the direct memory access (DMA). The FPGA and the real-time processor can write on and read this part of the RAM memory using the first-in, first-out (FIFO) procedure.

 

The real-time processor reads the DMA FIFO data, calculates for the various controls, and monitors the threshold values. If one of the threshold values is exceeded, the NI Single-Board RIO module can break the safety circuit. This interlock switch provides the accumulator insulation relay (AIR) with electricity.

 

The data is logged on a separate board ROM that we can analyze later using NI DIAdem data analysis software. For dynamic monitoring, a VI runs on a Windows processor and displays the live status of the vehicle.

 

Data Acquisition and Preprocessing With the FPGA Target

All I/O modules used for the project are connected to the FPGA target. For maximum parallelism, we implemented several While Loops in parallel to prevent the applications from thwarting each other. The right frequency and prioritization of the loops is essential. Additionally, the pipelining procedure executes the respective loop content in parallel to achieve maximum performance.

 

All of the elected values are now preprocessed in the FPGA. Frequencies are calculated from the PWM signals and some of the values are smoothed if necessary for subsequent processing on the real-time processor. At times, even raw data is transferred to the real-time processor. For example, conversion of voltage values to temperature values is too complex and resource intensive for the FPGA.

 

Aside from data collection, two of the vehicle’s independent CAN buses converge in the CAN module. The messages the board receives are filtered by IDs and transferred to the respective VIs. To transfer the CAN messages to and from the real-time target, a FIFO is initially applied as well, which allows the FPGA to independently take care of the CAN communication in both directions. The autonomy of the individual program parts by parallel implementation allows for a solid system design and contributes heavily to the clarity.

 

Further Data Processing and Distribution With the Real-Time Target

The contents of the DATA-FIFOs are selected in the real-time target. This is where further data processing and control of the engines occurs as well as the cooling. Furthermore, error handlers monitor various threshold values, which can open the battery protection of the 435 V battery. This is how the NI Single-Board RIO module monitors the vehicle and guarantees the safety of the driver and crew.

 

After initialization of the real-time VIs, the FPGA VI is retrieved and the AIR interlock-circuit is closed. The FIFOs are cleared and activated to allow for a constant flow of data between the two VIs. The real-time controller extracts elements from the DMA-FIFO for the sensor data and translates this information into usable data with real units such as Bar U/min for pressure and torque.

 

A mean value of the smoothed signal from the FPGA’s angle sensors is calculated and transferred to the engine control. If one of the sensors fails, the vehicle can continue the high redundancy. When three of the four built-in sensors are no longer connected or if they show very different values, the driver’s desired momentum is rejected and the engines are switched to idling. This is the error handler’s responsibility.

 

The desired momentum and the vehicle dynamic data are used in the engine control to calculate momentum distribution. This is realized by the drive concept of using two independent engines. It allows for weight savings in the form of differentials. By implementing the differential alternative, the decreasing of the momentum for the inner wheel is already part of the engine control.

 

The engine control performed in NI LabVIEW software translates the input values into the two targeted momentums for the inverters. Out of those, CAN messages are created together with the threshold torque and other parameters according to the inverters’ CAN protocol. To send the messages through the bus, the engine control VI writes its message contents on the CAN_OUT-FIFO. It’s the FPGA VIs’ responsibility to send the message.

 

All sensor values are saved in the Technical Data Management Streaming (TDMS) format on the board’s ROM. At the same time, this data is sent to a host computer through a WLAN connection. The order of the data is stored in an enum-type definition, which permits the same order when writing or reading.

 

Monitoring VI

Accessing the NI Single-Board RIO device with a computer is possible with TCP/IP through a LAN wire. The vehicle’s built-in WLAN router provides wireless access to the board and use of the monitoring VI. This VI selects the shared variables array and tries for a clear display of the stored sensor values. It also makes it possible for different members of the team to monitor the sensor data independently.

 

 

In this case, the shared variable is the most practical implementation. The shared variable is independent from any data type, so it is perfectly suitable for a distributed system and includes a FIFO mechanism to prevent losing data in case WLAN connection is temporarily interrupted. For a smaller data volume, the accessible data transfer rate of 25 kb/s is sufficient.

 

An overview tab displays significant data in a front panel that looks like a dashboard. It shows the current vehicle speed on a circular instrument, critical error messages and status information through LEDs, and the state of charge (SOC) in a slide control—all within one front panel element. Next to this element, the steering angle is displayed as a rotating steering wheel. The manipulated image is a CAD photograph of the Areus steering wheel. It mimics the angle that the driver turns the real steering wheel. We can also view the speed, steering angle, and SOC in the time course as a diagram.

 

 

For cooling, the temperatures are displayed as thermometers. Additionally, LEDs are positioned using a CAD image of the cooling circuit at exactly the positions that the sensors are located in the car. The LEDs are green by default and turn red as soon as the respective sensor exceeds a threshold value. Unconnected sensors are black LEDs. This simplifies analysis and speeds up troubleshooting the cooler circuit.

 

 Rear and front break pressure is located in the vehicle’s lateral view in their respective positions. The X- and Y-acceleration is shown on its own front panel element using a XY graph that also shows the yaw rate.

 

All the displays are for a quick live view of the vehicle status during the drive and not intended for scientific analysis. For scientific analysis, we evaluate the logged data with NI DIAdem software.

 

Data Acquisition, Processing, and Analysis With DIAdem

DIAdem provides us with a multipurpose tool for data administration and analysis. A clear separation in the different data sets is critical. The separation occurs when storing the values in TDMS format on the NI Single-Board RIO module. All of the recorded raw data is combined in individual groups with respective channels.

 

 

 

For comparison, we calculated the required values and functions that served the multibody simulation for parameterization using the DIAdem analysis. This includes mean values of the wheel speed sensors and the speed or ratio factors that were calculated using those mean values.

 

With the DIAdem view, we can easily compare and layer the obtained and calculated values. We can see the origin of important interrelations to evaluate and take into account for the next year’s vehicle, helping to get it closer to its limits.

 

The data analysis in DIAdem and the return of real data in the multibody simulation also refines the concept-finding process for the next vehicle and increases the understanding of the actual racing car. In vehicle evolution, continuous data acquisition and evaluation are the most important factors.

 

Conclusion

NI technology simplified the system design. The NI LabVIEW Real-Time and LabVIEW FPGA modules and DIAdem software helped us achieve major successes. The complete package of NI products simplified the hardware setup. Existing signal conditioning expedited software development with intuitive usability. It also simplified the data administration and analysis with powerful DIAdem software and add-ons. The first season using NI technology helped our team take a big leap in terms of data acquisition, analysis, and processing. It also offers a promising prospect for the upcoming seasons because we can rely on real data when we develop our concept.

 

Author Information:

David Möller
Technical University Dresden

Figure 3: Monitoring VI Overview
Figure 4: Monitoring VI - Cooling
Figure 5: Monitoring VI Driving Dynamics