Student Projects
Contact Information
Country: Denmark
Year Submitted: 2017
University: Technical University of Denmark
List of Team Members (with year of graduation):
Andreas Ulrich Møbius (2019)
Benjamin Lucas Lewis Karlson (2017)
Faculty Advisers:
Overall responsible of the ecocar project: Jesper Schramm: js@mek.dtu.dk
LabVIEW adviser: Rasmus Frausing: rasfra@mek.dtu.dk
Main Contact Email Address: s114648@student.dtu.dk
Project Information
Title: Control and Test of DTU Roadrunners Ecocar
Description: DTU Roadrunners is a team of engaged students at the Technical University of Denmark who build and optimize highly efficient cars for use in the Shell Eco Marathon. The Shell Eco Marathon is a competition in driving with the best fuel economy with 2 types of cars and different means of propulsion resulting in 8 different classes.
We are using our cRIO as an Engine Control Unit which is shown in figure 1. The encoder is sending a signal with information about where the piston is at the moment. The cRIO is then using this to calculate when to send a signal to the spark plug and the fuel injection. From the exhaust, a signal from the fuel/air sensor is send back to the cRIO.
Figure 1 - Block diagram of the ECU setup
With this configuration DTU Roadrunners competed in the Urban Concept Combustion engine class and placed second with a run of 449 km/L.
Products:
- Software
- http://www.ni.com/labview/
- http://www.ni.com/labview/realtime/
- cRIO-device drivers
- FPGA-target
- Hardware
- cRIO
- Chassis 4/8-slot
- Module NI 9411
- Module NI 9211
- Module NI 9205
- Module NI 9403
The Challenge:
Our challenge was to make our existing labVIEW code simpler and more effective. Because of the development of a new test rack, we had to implement a new way to test our engine. Implementation of Closed Loop in our Engine code and a better interface for the user.
The Solution
ECU-Rework
Our engine code has been developed over several years. This year we focused on changing all our FGV’s with channels. This was done to make our code more beginner friendly for the new students starting the ecocar project with little experience to LabVIEW every year.
New interface
A new interface host was made this year to make the program and the controlling of the car easier. In the new interface, you have a bigger overview of how the car perform. We can from the interface choose if we want to control the car from the computer or from the steering wheel.
Video of the car idling using the interface
We can also change the calibration parameters of the engine in our Interface window (fig. 2, 3 and 4).
Figure 2 - User Interface with test control used to control the DTU Roadrunners Ecocar
Figure 2 shows our user interface. Here we can see and control the different engine temperatures. On the right side of our user interface it is possible to toogle between the test section and the different calibration segments of the engine which can be seen in figure 3. If something goes wrong in our VI we have a troupleshooting section which can be seen in figure 4.
Figure 3 - User Interface Calibration control
Figure 4 - User Interface Troubleshooting control
Closed Loop
One of the main reasons for our high mileage is our possibility to run with a high air-fuel ratio, lambda. Because lambda is calculated on air, it is therefore highly demanding on eg. the temperature of the air taken in or the temperature of the engine. These conditions change during a race. We wanted to make a VI which was able to change the fuel injection while racing. The closed loop is using the parameters shown in the circle on figure 1. The lambda sensor is sending a lambda signal to the cRIO which it compares to the original set lambda. Then it uses the NI PID control to figure out the error. The cRIO then sends a correction to the fuel injection corresponding to the error. This way the equipment can make a closed loop around the injection control without any user interference. The system would then be able to use the optimal injection, getting the most effective setup for our engine at any time.
We succeeded in making a VI with a closed loop application. We only had time to test it with computer connected to the car and were therefore not able to use it in the race. It was a success in the way that it drastically reduced the time needed to calibrate the engine before a race.
Further testing of the VI is needed before it can be implemented for the races.
Automatic Test
During the year we wanted to be able to test our engine dynamically. Before 2017 we had only been able to make static test of the engine where it was mounted to an electric engine. A new test rack was developed in 2017 where the cars weight and rolling friction as well as the drag against the car were simulated. With this new test rack, we could therefore get more realistic tests of how the engine would perform in the race. Because of the test rack we had to make a new way to test.
This was done by making VI’s for automatic testing. The automatic test is done by first choosing how many burns you want and second choosing the velocity the engine should act at. Eg. the first burn goes to 34 km/h and the second burn should be initialized when the velocity reaches 18 km/h and go to 34 km/h again. The engine then accelerates to 34 km/h using the automatic gear, decelerates to 18 km/h and then accelerates to 34 km/h again. We are then able to choose the length of the track we run and get a value of fuel consumption (km/L) at the end of a test. This was how we chose which lambda calibration we should run with and which of our crankshafts that was the most effective.
Datalogging
Our datalogging is an important part of our LabVIEW code. We have an USB in the cRIO, on which all the data from the engine was logged. Afterwards we can plot the data to see how our engine is performing.
Problems – Home
We had a few problems with LabVIEW before we went to London.
After a few changes in our LabVIEW code our Windows 10 computers couldn’t run the code with our engine. We were still able to run the code with a Windows 7 computer. This made a big nuisance for the people who were trying to test the engine. We have yet to solve this problem.
We created an application of the code to our cRIO so it was apple to run in the car. After a few changes to our code we couldn’t make a new application, since it crashed every time we tried to make a new. This was a major problem not being able to access the application to solve the challenges we faced.
Problems – In London
In London, we started having a lot of signal noise in our velocity measurements of our wheels. This caused problems for our automatic gear because it changed gear when a spike in the velocity happened. This was first thought to be an instability caused be the wheels leaning away from the velocity sensor during a race or a test. We tried to mount the engine on our test rack instead to see if the problem occurred here too. Sadly, it was the case for the test rack too. In this situation, the issue of not being able to make a new application to the car became a big problem. A fix could have been made to the LabVIEW code if we had been able to access it. No viably fix was made and we ended up using a bicycle computer for the velocity of the car and changing gears manually.
During one of our runs LabVIEW crashed. This ended up being due to the high temperature in our engine area. It could be seen in the datasheet of the cRIO that it only is capable of function below 55 degrees Celsius. It was a very hot week in London reaching temperatures of 30 degrees Celsius. We ended up drilling a hole in the bottom of the car and mounting a tube to make an air flow towards the cRIO to cool it down during a race.
Why LabVIEW
LabVIEW is highly flexible and easy to program. Most students do not have an electrical or software engineering background but using the National Instruments online training you are able to learn how to use and program the LabVIEW hardware regardless of educational background.
Conclusion
Even though we had some setbacks and problems with our LabVIEW code we ended up with a good result. We got a second place in the Shell Eco Marathon Europe Urban Concept Class. This was only possible because of the calibration and design of our LabVIEW code. We had one of the most advanced engine codes at the Shell Eco Marathon and because of this also one of the most effective engines.
In 2015 we set the world record of 665 km/L using the National Instruments hardware and software. The record was beaten this year, but we are ready to set a new one in the future.
