For his PhD at the University of Michigan, [Adam] designed a Raspberry Pi-based system that controls an HCCI engine, a type of engine which combines the merits of both diesel and gasoline engines. These engines exhibit near-chaotic behavior and are very challenging to model, so he developed a machine learning algorithm on a Raspberry Pi that adaptively learns how to control the engine.
[Adam]’s algorithm needs real-time readings of cylinder pressures and the crankshaft angle to run. To measure this data on a Raspberry Pi, [Adam] designed a daughterboard that takes readings from pressure sensors in each cylinder and measures the crankshaft angle with an encoder. The Pi is also equipped with a CAN transceiver that communicates with a low-level engine control unit.
[Adam]’s algorithm calculates engine control parameters in real-time on the Pi based on the pressure readings and crankshaft position. The control values are sent over CAN to the low-level engine controller. The Pi monitors changes in the engine’s performance with the new values, and makes changes to its control values to optimize the combustion cycle as the engine runs. The Pi also serves up a webpage with graphs of the crankshaft position and cylinder pressure that update in real-time to give some user feedback.
For all the juicy details, take a look at [Adam]’s paper we linked above. For a more visual breakdown, check out the video after the break where [Adam] walks you through his setup and the awesome lab he gets to work in.
Can somebody give me an idea whicht software is used for the web interface? Looks pretty neat.
Looks like he rolled his own with d3.js. He has another video with slides that show the platform running on the RasPi: https://www.youtube.com/watch?v=_yrLWFffP_Q#t=401
My initial thoughts were around the R-pi not being ideally suited to realtime operations and the likes of a beagle bone with PRU’s (or even a MCU) would be better. The thesis states that the average computational time is 66 microseconds, and the combustion cycle is 50 milliseconds, so unless something goes very wrong, I guess it isn’t an issue.
The project looks really good. If the thesis were done in LaTek/Tek colour me impressed, it looks great.
Same thought here. But I guess he spend a few minutes evaluating his choice. I have not done this jet, but with the underlaying linux you should be able to force a rather determinisic realtime behaviour of a “simple” process. And “realtime” is just a question of definition ;-)
Anyway, leraned something new today about HCCI :)
I think the key bit is “The Pi is also equipped with a CAN transceiver that communicates with a low-level engine control unit.” so it’s more like the beagle-bone in that sense (with the ARM11 in the Pi being the same as the A8 in the Beagle-bone and the “low-level control unit” doing the hard-real-time as one would have got the PRU to do).
Also it’s not the average that’s critical – it’s the worst case which could be quite a lot higher than the average (you may only need one “miss” situation to destroy a cylinder) but he doesn’t mention that (it could be that, as the average was so much lower than the needed, that even the worst cases were well ‘safe’).
Oh, I think the 66us was in relation to a i7 860 @2.8GHz which also did the off-line processing (in 1.1us) – he simply added at the end of the text that, as the on-line process was so computationally simple, it was possible to do it on a Pi (still impressive but possibly a bit closer to the required time!)
The video description says:
Pressure data acquisition is recording 240k 18-bit samples per second (total, all channels) with assembly code in an FIQ. Control commands must be calculated with less than ~300 microseconds of latency to maintain control. I have the control algorithm running in PREEMPT_RT Linux user space and streaming processed data to a d3.js web-based UI over a WebSocket.
Hook this up to a car and get a big raspberry from the EPA. Or get a big federal grant to apply to further deployment.
This is insanely impressive from a Pi. Linux is not Real time and doing this with an arduino would be a lot easier.
I really hope he releases it all so I can dig in and see what the heck he did to make it that responsive. Although I dont see any runs up to redline and holding it there, having a Pi handle 900rpm-1200rpm is easy. 10,000 rpm and I am thinking it will fall down.
He mentions in his other video that he uses RT PREEMPT, which I believe is a real time version of the linux kernel. Similar to what linuxcnc does (use a RT kernel, though I’m not sure which one they use).
@ timgray1 RT on Pi, try Xenomai. 10,000 rpm on a gasoline/diesel engine? Conventional car engines typically redline at 5500-7000 rpm and deisel engines typically around 3500rpm. Given the described ‘chaotic’ nature of the engine in the article, I would guess that 10,000rpm while not outside the realm of possible is well beyond practical.
Typical car maybe but petrol engines are frequently built higher (look up bike engines – there’s quite a lot in the 10k+rpm region) and are still very practical.
Why? my motor cycle has a 10k redline.
It is all about the piston speed. A short stroke engine can rev very high without damage. Of course you have the have the valve are to support it and the higher you rev the more friction you have to deal with.
My Triumph S4 redlines at a screeching 13.5k RPM.
Swap it with a gas turbine to increase your redline to 200K, so your small motor isn´t diesel nor is it running in HCCI mode. Rather out of the topic? Looks like you haven´t payed attention what the post is about. On regular diesel engine its not practical to get them rev high not to mention this HCCI mode, where the proper ignition timing of fuel mixture is really hard, seems lot of work to see it running stable at all. The commertial HCCI engines change the fuel to petrol or use regular diesel direct injection when they are under acceleration, so you suppose the PhD just this engine up to 13K or what?
>The Pi is also equipped with a CAN transceiver that communicates with a low-level engine control unit
i.e. There is something that takes care of the real time low level stuff. RPi is there to look at the “bigger picture” for fine tuning the engine via the low level controller. So the “real time” RPi dealing with might be much more relax.
I’m sorry, but I’m going to reject his paper strictly on the basis of wire and cable management.
And can somebody buy this wonderfully appointed lab a computer cart instead of the chair?
Otherwise incredible work. I’ve worked with the Megasquirt ECU, and was always amazed that a simple 8-bit microcontroller was capable of what it was doing. My limited playing around with the RasPi tells me that whatever he did to get that far is incredible.
One thing to note. He is using the ecotec 2.0L engine. Typically that engine has a forged rotating assembly from the factory. However the problem with HCCI is the limited rpm range as well as high loads being able to kill them. They esencialy run in lean mode all the time. The other issue is timing. He is using VVT on that engine to get the engine to run properly at certain rpm’s however that is not fast enough nor flexible enough to make that engine viable. He really needs solenoid actuated valves with air springs on them. That could reduce the adaptation timing as well as allov for virtual compression ratio change on the fly from high load to low load.
With all of this being said, I am impressed he was able to get the PI to compute the data, color me excited that he was able to predict combustion events 1 cycle ahead. I am sure he has to be running RT linux kernel or at least tweaked the normal linux kernel to do the calculations at such low latency. I wonder what he could do if he used a 32bit micro controller and some solenoid valves on that engine. Running ultra lean is what modern engines should do, mazda has the right idea, it just needs to spread. Now to figure out a way to reduce the heat absorption into the cylinder walls and head/pistons for increased efficiency.