Slashdot Mirror
Linux Controls a Gasoline Engine With Machine Learning
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 am not familiar with combustion engine computation. Does this make the engine more or less efficient? And if it is more effiecent, how does it compare with commercial offerings of comparable use?
Restore the madness of youth's lechery
"I don't hear the engine running, so I highly doubt that this video is legit."
Oh! ... well everyone stand back then!
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.
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.
Wow. I'm going to have to consider these profound insights.
There are after market ECUs available It's not that extremely hard, that people couldn't reproduce them without an engine manufacturer.
Computationally, running a car engine is trivial for a raspberry pi. Early EFI used processors in the KHz range and even current ECUs like Megasquirt use 16 bit 50 or 100 MHz processors.
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 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).
The expensive part of an ECU isn't the processor. It is supporting circuitry to tolerate lots of EMI noise, varying supply voltages, and lastly, driving fuel injectors (they're actually a PITA because of voltage / current / pulsing).
If they really want to get ambitious, their system will learn the exact intake geometry effects(intake asymmetry) , individual injector flow characteristics, and cylinder geometry (build up, hot spots) and thermal trends just by watching I/O.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I know right?
I'd be far more impressed if they managed to do this with Brainfuck or something.
Linux is just painfully obtuse to get it to do things.
Brainfuck? Hoooo boy you'll be putting holes in walls.
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 the pulse timing per injector when measured against the cam and crank sensors. Even the TBI injectors that came up in the late 80's through 90's before MPFI became the mainstream used only a crank sensor.
Om, nomnomnom...
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 between genuine ECU and your own custom one. The ECU isn't doing much, it's just doing it fast enough that simple engineering on its own couldn't manage. But even a couple of MHz is way within the range of a viable "homebrew" ECU for almost any vehicle if you want to spend the time on it.
Even if ECU's were dirt cheap (and they already are), the car industry isn't going collapse because of it (proof - they're still here). Few people would ever replace an ECU, replacing an ECU voids your warranty, and garages aren't going to start voiding your warranty for you to save a pittance. Even if you could, what do you think you'll gain? A handful of stats and you'd burn a lot more fuel.
ECU's are LIMITING your engine to legal emission levels. That's their primary purpose and the reason they exist. They are not necessary to build a working car, just one that meets the emission requirements. And they do it by being more efficient about how much fuel you actually end up burning.
You can get better performance by replacing the ECU (which is why there are kits to do so and people doing it every day, and ECU switches so you can pass the emission tests and then put your car back into illegal "boy-racer" mode), you can't spend less on fuel (in fact, the opposite).
Put the car companies out of business? What a ridiculous statement. And ECU's used to not exist for many decades of the automobile industry.
The year of Linux on the dash board!
... and we reduce a huge number of moving parts & weight. whether its linux or qnx doesn't really matter, of course.
Probably because a lockup in the fuel-metering system would not cause the engine to explode.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
The goal is always to make it more efficient wherever possible.
There are other factors to optimize the combustion for.
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 the physics and solve the equations for a complete solution.
BOOM!
Do we really want a computer program to learn from its mistakes at running a nuclear power plant?
Does not work that way.
HCCI relies on compression ignition. The thing runs on chaos, with multiple ignition point in an overall lean mixture with rich pockets around the injection spray.
Turbulence, chaos, past cycle conditions, current load, etc.. These are what you need to model... Nobody cares (to a point) about exact intake headers length at this point...
What you are suggesting requires solving the Navier-Stokes equations with mass transfer, energy equillibirum, mass-momentum equillibirum, chemical kinetics reactions (lots of them BTW) and what not. In real time? With sensors and a supercomputer thrown in there randomly? Oh boy...
This must be the year of Linux on deskt....gas pumps.
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?
The video desciption says "Data acquisition is running at 240k samples per second and control commands must be calculated within ~300 microseconds to maintain control." That's kinda fast for Linux, and it's also streaming this data to a web browser.
Look at the math in the arXiv link. It's also not a trivial O(1) lookup table for control. Lookup tables used in most engine controllers don't work well with HCCI engines because there's no direct control knob over combustion. There's no spark, combustion is controlled by complex chemistry.
Yes, if everything is measured and everything is consistent, this is true. But what about things that are not very precisely controlled? External air temperature? The exact octane rating of the gasoline? Air pressure (elevation)? Engine temperature? Oil viscosity? etc., etc. To measure all of these things would be prohibitively expensive. Better to create a control system that learns the current state and adapts to it.
He's not running the engine with a Pi, Linux, or Windows of any kind. He's using the Pi to collect data from a cylinder pressure and crank angle sensor on one cylinder (of a 4-cylinder engine) and then sending tuning parameter adjustments to the engine computer over CAN. His objective is to increase the RPM range where a gasoline engine can operate reliably using compression ignition (like a diesel).
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 have real-world practical use (the whole Rasberry Pi/Linux angle is a side note in the paper just to show that the algorithm is fast enough for real-world application). A possible 30% fuel efficiency increase in all/some new cars? Car makers would certainly be interested.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
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.
If you don't understand any of my sayings, come to me in private and I shall take you in my German mouth.
Not really. When racing production vehicles, one big step towards improving performance is taking the engine apart and "blueprinting" it.
How do you know? Are you the creator?
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 problem with compression ignition is that using it induces more vibration, a serious problem on any engine without opposed cylinders which is usually solved by throwing more mass at the problem. The only benefit is being able to run lean all the time, and while that is not inconsiderable, GDIs are headed in the direction where they'll be able to run lean much of the time anyway.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 certain engine cycles. It became ubiquitous when it was seized upon as a means of improving emissions, and developed to the point of general usefulness, and now we even have fuel injected small engines.
Saying that we got ECUs for emissions is like saying we got electronic ignition for emissions, it just ain't so. But electronic ignition became a way that emissions control was implemented.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Well, not the Creator. Mostly I just do the fjords.
That's what humans are doing now. ;)
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.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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 the cylinder head and variations in the mold that forms the chambers of the cylinder head. There are doubtless many more.
All of the above have a range of acceptable tolerances. These stack up in an assembled engine; each of the above can conspire to make a given cylinder have a compression ratio on the limit of the high side while a cylinder in a different bank of the SAME ENGINE will have a stack up that puts the ratio on the low limit.
All of this is perfectly normal and manufacturers employ engineers to compute tolerance stackups in engine designs to arrive at cost effective yields of working parts. In other words, how much can they get away with and still make engines that are acceptable in a market filled with competitive rivals.
Besides what can vary in manufacture you have what will vary over the life cycle of an engine. Just off the top of my shade tree mechanics head, what can vary in a traditional internal combustion engine that cannot be controlled through precision manufacture;
Cylinders and pistons wear. A high mileage engine will be several thousands out of spec due to wear, and the wear is not uniform, due to minute differences in material hardness, the slightly different forces encountered by different cylinders, non-uniform lubrication and temperature gradients due to non-uniform cooling. The combined effect of both the cylinder and piston wear can get rather large with enough miles; .008-.010" in is not unusual, with each cylinder having different rates of wear in the same engine.
Cylinders and chambers become contaminated by carbon deposits over time, changing the shape of the chamber, the volume of the chamber and temperature gradients on the chamber surface. This effect is dynamic; a cylinder will have more or less carbon deposit over time due to driving habits, air temp, fuel and a host of other factors. This is a big reason knock sensors are used to correct ignition timing in real time.
Wear on rod bearings and piston pins or pin holes change cylinder volume over time.
Piston rings wear and accumulate damage with time, reducing sealing effectiveness which changes cylinder compression. This is non-uniform due again to minute differences in materials and randomly accumulated damage. On the other hand, new piston rings improve sealing as an engine breaks in.
Heat expansion changes the behavior of an engine dramatically and in non-uniform ways while operating.
Then you have repairs.
Replacement parts are frequently not identical to original parts. The things that will vary a chamber during repairs include replacement pistons, gasket thickness and milling cylinder deck or head surfaces. Some of these are not common with modern passenger car engines any longer, but they remain common with industrial engines and probably always will.
Finally, there are ordinary run time variables that affect engine operation.
Fuel is a big one here. Fuel has become a plaything of government regulators as they mandate difference mixtures for different regions and prevailing weather. Fuel can change significantly long after an engine is manufactured in ways the manufacturer did not anticipate (or deliberately ignored); higher alcohol percentages and new additives are examples of this.
Air varies in myriad ways. Density, variations in molecular ratios (humidity, oxygen ratio, etc.) particulates including w
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Or learn from the human mistakes?!
And then decides to fix the "bug" in the system, by removing humans....!?!?
I only know of one HCCI engine that went to production, and strangely that was a 2-stroke Honda off-road bike; the CRM250 AR back in 1997.
The RPi seems like a rather eccentric choice of platform for this application, there are plenty of hard-realtime platforms with the engine-control hardware already in place.
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, which claim to incorporate more inherent safety, and I think the fact that there are millions cars driving around with humans behind the wheel, some of them carrying large quantities of hazardous or explosive materials, some of them drunk, some of them insane or asleep, is a scary as hell, compared to the more benign idea, that a machine-learning system would be controlling some industrial processes....
You don't even have to replace the ECU for better performance in many cars, nowadays. Especially the Mitsubishi Evo and Subaru WRX, in which you can reprogram the factory ECU with either the Cobb AccessPort or numerous open source tools using the Tactrix Openport.