Linux Controls a Gasoline Engine With Machine Learning 89
An anonymous reader writes: Here's a short (2 min) video of PREEMPT_RT Linux controlling a gasoline engine from one burn to the next using a Raspberry Pi. It's using an adaptive machine learning algorithm that can predict near chaotic combustion in real-time. A paper about the algorithm is available at the arXiv.
I didn't see any mention of efficiency. (Score:2)
Re:I didn't see any mention of efficiency. (Score:4, Informative)
Here the goal is to make the engine spend as much fuel as possible, hence the term "chaotic combustion". The system can maintain the engine in a "chaotic combustion" state in real time ;-)
Re: (Score:2)
As much fuel as possible ? Hardly.
The conclusion says "the broader objective of this new modeling approach is to enable a new class of cycle-to-cycle predictive control strategies that could potentially bring HCCI’s low engine-out NOx and high fuel efficiency to production feasible gasoline engines."
Re: (Score:1)
by burn as much fuel as possible he probably meant
"get the most energy out of the fuel in the chamber"
not
"use the most fuel"
Re: I didn't see any mention of efficiency. (Score:1)
That's because you read the summary, not the paper...
tl;dr?
Re:I didn't see any mention of efficiency. (Score:5, Informative)
In HCCI, you operate the engine *without* the throttle (for practical purpose, they probably left the throttle in but operated at WOT: pedal to the metal). This improves the efficiency for sure right there.
HCCI *is* about efficiency: without the throttle in the way, things go much better thermally in the machine. Torque output (thus power) is then controlled by fuel injection and the motor autoignites (like a diesel).
Combustion at every cycle starts according to current conditions (pressure and temperature). This means that earlier cycles are essentially what determines the current combustion... You only get to control fuel timming and quantity supply...
This is hard people...
The article is about a *control* strategy. It is normal to seek worst case conditions (hence the chaos, variability, etc) and to try to demonstrate robustness... Efficiency will certainly be evaluated next, once robustness is set. Given the article was written in october 2013, they probably have this figured-out by now ;-)
I don't get why you would need this in production (Score:2)
On a production engine, the specs of every unit will be identical (to machining tolerances .001 in). So once you solve the problem just encode the parameters in the controller and you can use something much less powerful (and more reliable). For solving the problem, use whatever high-power equipment you'd like. Attach a hundred sensors and throw a supercomputer at it. Even better, rather than "machine learning" (aka, we don't understand it, we will let the computer tweak it until it gets better), simulate t
Re: (Score:1)
On a production engine, the specs of every unit will be identical
Wow. That is fabulously naive.
Manufacturers deal in tolerances. They do NOT make "identical" engines. There is a range of acceptable tolerances for everything. Then there is tolerance stack up, sort of a second derivative of a simple tolerance. A cylinder volume at top-dead-center will vary due to the sum of; the rod journal and pin clearance, the distance between the rod journal and piston pin holes, the position of the pin hole in the piston, the milling height of the cylinder deck, the milling of th
Re: (Score:3)
Don't worry. It's not going to be in cars anytime soon.
I think a Pi running realtime Linux with machine learning looks much more interesting as a possible candidate for replacement of legacy control systems in nuclear fission-based power plants with a much more modern less-expensive system based on current generation commodity off-the-shelf hardware.
Re:Oh no, Linux Lockup Bug strikes again! (Score:4, Funny)
Do we really want a computer program to learn from its mistakes at running a nuclear power plant?
Re: (Score:2)
Shouldn't matter. Even non-nuclear plants tend to have a "physical" layer of security beneath the computer. If, for example, a reactor vessel becomes overly full, it triggers a switch which directly closes all the feed valves, overriding the computer in the process. The computer only has control when processes are running within safe parameters.
Re: (Score:2)
Shouldn't matter. Even non-nuclear plants tend to have a "physical" layer of security beneath the computer. If, for example, a reactor vessel becomes overly full, it triggers a switch which directly closes all the feed valves
Yup. They have extra layers of safety in power plants you won't find in microcontroller-controlled mechanical devices designed for the consumer.
Then look at one of the more modern fast breeder or molten salt reactor concepts such as ThorCon [thorconpower.com], which claim to incorporate more inherent
Re: (Score:2)
Probably because a lockup in the fuel-metering system would not cause the engine to explode.
Re: (Score:2)
No, but I have built a fuel injection computer. I've burned out injectors by using them over their duty cycle and leaned out an engine to the point of failure. But sorry, no explosions.
Re: (Score:2)
"I don't hear the engine running, so I highly doubt that this video is legit."
Oh! ... well everyone stand back then!
Re: Is that engine even running? (Score:3)
Fuel injection and spark events only occur at the 10s of Hz scale (topping out at around 60 each per second). Even if you handle cam phasing and MAF sampling at 100 times that interval, you're still within the computational work load of a couple dozen MHz of instructions.
The research is only interesting because they are tak
Re: (Score:2)
The research is only interesting because they are taking advantage of way overspecced processing power to approach combustion more granularly per event and trying to learn from each one and control the next.
I only wish the abstract had been informative, and I'm not going to bother to read the whole paper. What are they claiming that sampling the process at more points is buying them? Because we already monitor each and every combustion event, and in some cases we will take action on it before the next combustion event already, and have been doing that approximately since the late eighties when we implemented knock detection.
Re: (Score:2)
I can't say there's much of anything interesting at all. Since a lot of the stuff, except what's covered in your last sentence has been done by the old ECU's since the 90's. Even varying supply voltage has been under control since around 1996, the variation of voltage for ECU connected components was down to 0.03v, it's 0.01v these days. It doesn't *have* to be any better than that when the tolerance is +/- 0.04v per sensor. There isn't really a problem with injectors though. It's not hard to figure out
Re: (Score:2)
Fuel injection and spark events only occur at the 10s of Hz scale (topping out at around 60 each per second). Even if you handle cam phasing and MAF sampling at 100 times that interval, you're still within the computational work load of a couple dozen MHz of instructions.
Aye. Now try controlling the engine and fuel injection system, and achieving combustion, without using a spark plug. Because that's what the story is actually about. They're using compression-based ignition (like a diesel engine) rather than spark based ignition (like a conventional gasoline engine), which requires a detailed knowledge of the state of the engine at each cycle.
The research is only interesting because they are taking advantage of way overspecced processing power to approach combustion more granularly per event and trying to learn from each one and control the next. It only got press here because they used Linux (anything production grade would use QNX or similar).
Nah, it's interesting because it's an application of machine learning algorithms applied to an actual physical problem that might ha
Re: (Score:2)
A possible 30% fuel efficiency increase in all/some new cars? Car makers would certainly be interested.
They would, but you don't get those kinds of gains over GDI+Spark, only over traditional IDI+Spark injection/ignition systems. The only advantage is eliminating the spark. Problem is, having the spark gives you more control over combustion! Being able to vary both injection and ignition timing is still superior to having your ignition timing dependent on your injection timing, which is why GDIs will eventually equal diesels for efficiency. They do have all the same drawbacks, but less of most of them. The p
Re: (Score:2)
Why would it put car companies out of business?
What a ridiculous statement.
Cars ran for decades without ECUs at all, all due to proper engineering. ECU have been around for decades too. The first were literally nothing more than simple circuits on a PCB. Modern ones are not that much more complicated. The ECU in your car can be interfaced and controlled with by a £5 bluetooth adaptor and a free app.
You can get ECU replacement chips for almost any model of car, and even switches to switch bet
Re: (Score:2)
ECU's are LIMITING your engine to legal emission levels. That's their primary purpose and the reason they exist.
It's the reason why they came into being when they did, perhaps, but we would have had computerized engine management eventually whether there was an emissions-related motivation or not. It offers superior efficiency, which means more power and/or range, so it's desirable anyway. The self-tuning aspect is justification enough. Fuel injection wasn't invented because of emissions, it was invented because it was thought to be a better way to deliver fuel. It became popular because it was a necessity for certai
'Linux?' (Score:5, Insightful)
Oh come on - I like Linux and use it for my servers and even some RTOS... but 'Linux' has almost nothing to do with that. It'd work just as well on any RTOS. Would you give credit to Windows for every single freaking program that can run on it?
Something like 'Raspberry Pi Controls a Gasoline Engine With Machine Learning Using Eigen
C++ Matrix Library' would be far more descriptive.
Re: (Score:2)
Dell XYZ controls sound levels for my DJ show
What operating system ?
Re: (Score:2)
BSD
Re: (Score:2)
I thought BSD died?
Re: (Score:3)
Re: (Score:2)
Windows Vista - not somehting it could do
WIndows 7 - not something it could do
WindowsXP - can do
Windows2000 - can do
That's part of the answer why winnt5/5.1 are actually widley used, they are used in realtime equipment, along with their low memory and cpu footprint (winxp can be tuned very good).
And hopefully nobody dares to connect Win2ksp4 or winxpsp3 on these appliances to the pure-internet nor to any intranet consisting of more than one not connected computer.
But WinXP and 2k are very good & smooth
Re: (Score:2)
Re: (Score:2)
And I'm sure that you are just funny, go back to sleep kid.
Re: (Score:3)
>> That's part of the answer why winnt5/5.1 are actually widley used, they are used in realtime equipment
BS. No hard real time system uses any Windows variant. There are RT packages for Windows, but all the RT functionality is in the package kernel - Windows rides along as an preemptable process on top of the RT nanokernel. Tenasys and other vendors IIRC.
RT_PREMPT is alive and well - however AFAIK most folks leverage it through Xenomai.
Re: (Score:2)
Linux is the kernel. Windows is a full operating system.
You take the NT kernel and strip out the extra stuff like the gui then it could run on the pi as well
GNU/Windows (Score:2)
Who wrote the compiler that the Linux kernel was is compiled with?
If I use MinGW (GCC for Windows) and MSYS (GNU Make, Bash, and Coreutils) to compile applications for Windows, am I using GNU/Windows?
Re: (Score:2)
It is a cool implementation to be sure, but we are talking timing deadlines of about 8-9 Hz per cylinder at (2000RPM). Not very much of a test of a RTOS or the HW it is running on.
Re: (Score:2)
It is a cool implementation to be sure, but we are talking timing deadlines of about 8-9 Hz per cylinder at (2000RPM). Not very much of a test of a RTOS or the HW it is running on.
They claim they're sampling combustion at multiple points during the cycle per cylinder, so it's probably in the tens of Hz. Which is still not much of a test.
Re: (Score:1)
Re: (Score:1)
The first time a program runs reliably and securely on Windows, I will give all the credit it is due.
Re: (Score:1)
I agree. I am as much a content user of Linux as the next guy here, but it could easily have been any decent OS doing the same thing. Even the Raspberry PI has alternatives here. There is no need to glorify Linux as something special in this regard, it's just a completely typical (for Tannenbaum fans, completely atypical, of course) run-of-the-mill half-modern (monolithic kernel debate again) operating system. There is no magic involved in Linux other than the fact that it is essentially the largest crowdso
Re: (Score:2)
Checkout Xenomai - you can get hard realtime determinism at microsecond level.
Re: (Score:2)
That video showed a whole lot of Windows, BTW.
HCCI are efficient like diesel (Score:5, Informative)
HCCI engines are a really cool technology, but very hard to do.
Efficiency of internal combustion engines is related to the compression ratio - the ratio of the combustion chamber from largest to smallest capacity.
Gasoline engines usually have a compression ratio around 9:1. Higher, and the compressional heating combined with the heat off of the walls can cause "knocking," which detonation of pockets of fuel/air away from the flame front from the spark plug. Engines with premium gas can run higher compression ratios. Higher-octane fuels can be compressed more without burning, but of course there is no benefit to running it on engines rated for regular.
Diesel engines run ratios of around 17:1, resulting in much greater efficiency. Diesel engines of course don't have spark plugs. The fuel is injected just before top dead center, where the air is compressed maximally. This is in contrast to a gasoline engine, where it is well mixed with air before entering the combustion chamber. Due to compressional heating, it spontaneously combusts very quickly, much faster than the combustion in a spark-plug-ignited gas engine.
HCCI well-mixes the air and gas upon intake, but ignites by compression like diesel. This gives diesel efficiency. In addition to the better compression ratio, HCCI controls power by the amount of fuel injected, like a diesel. Gasoline engines use a throttle to choke off the air supply, which induces losses because the engine has to work harder to pull air at lower power. That's how engine braking works, and also why diesel trucks use a separate "jake brake" to use the engine to brake.
It must run under a leaner mixture. It's really hard to have complete burning of fuel, and avoid knocking. That's why it has to be very carefully computer controlled based on temperature and such.
Re: (Score:2)
Most gasoline engines have a compression even below 9:1, but now compression ratios over 10:1 are starting to become common because gasoline engines are now going direct injection. Direct-injection diesels run ratios of around 17:1, the old IDIs ran more like 21 or 22:1 which makes them much better in non-turbocharged applications. However, nobody is really making naturally aspirated diesels any more, because they stink on ice. However however, we can expect the same trend to happen for gasoline engines as
Re: (Score:2)
Direct-injection diesels run ratios of around 17:1, the old IDIs ran more like 21 or 22:1 which makes them much better in non-turbocharged applications.
That's mostly a function of turbocharged vs. NA, not IDI vs DI. E.g. 2005 VW 1900cc PD SDI ran 21.3:1
2005? You're off by over a decade from the vehicles I'm talking about. I'm talking about the IDI days. The NA and turbocharged pre-powerstroke 7.3 liter fords have the same compression, around 21.5:1. Same for the turbocharged and non-turbocharged Mercedes. Everyone who could manage to build a high compression engine and have it be reliable did that, and so did International. Actually, the 6.9 was a rock, but when they bored it out to 7.3 they made the walls too thin. I have a 7.3 in my yard which has died