rusefi.com

TL,DR: everything works as of 2020ish



Would anyone be available to implement electronic throttle body control code?

Currently there is a skeleton available at electronic_throttle.cpp but I simply do not have time to play with it.

This is somewhat related to dual-potentiometer TPS - see https://sourceforge.net/p/rusefi/tickets/29/

For ETB hardware see http://rusefi.com/forum/viewtopic.php?f=4&t=316

December 15, 2018 status:
ETB is good enough to drive around the block. At the moment @russian is waiting for more VNH2SP30 eBay boards to rebuild test rig
@mck1117 and @russian to merge codebases together

December 30, 2019 status:
dual ETB tested on a bench, very limited documentation added to https://github.com/rusefi/rusefi_documentation/wiki/HOWTO_electronic_throttle_body - this really needs a lot of improvement

Good way to kill a lot of people. You can always install a normal throttle body on any engine. This should be the very last thing implemented, after the code is very mature, stable, and proven.

UnaClocker wrote:You can always install a normal throttle body on any engine.

Have you seen where the TB of mini cooper is located?

UnaClocker wrote:This should be the very last thing implemented, after the code is very mature, stable, and proven.

But yes, you have a point here. My idea for reliability was to have a dedicated chip running just the ETB firmware. Anyway, before this happens we need some ETB firmware to run on a bench

Hows my snow blower going to kill people?

I think there is some myth to this safety concern. When you do ETB, you're not just putting a motor on the right pedal, your algos have to change quite a bit. The ETB can control the engine, but shouldn't. If you don't squirt fuel, you don't get HP. Basically the Right Pedal Sensor (RPS) commands X KW of energy, which then basically commands a fuel pulse width of up to X mS. The ECU can generally adjust that pulse width to something smaller than the x mS commanded by the pedal, but does not allow for more fuel. Then the ETB adjusts to get that power with optimal efficiency. If you have a turbo, I would expect the ETB to be WOT, then you control the O2's/AFR via turbo controls. If the ETB erroneously goes WOT, then you end up lean and don't get the proper HP. I would use a very different set of algos than what people often think of for MAP and MAF sensors. Don't let the manifold pressure or flow directly determine the fuel pulse. Let the MAP / MAF sensor be used to decrease the fuel pulse when the RPM/turbo doesn't allow the commanded power.

First I will agree, throttle by wire/drive by wire, whatever you want to call it, should be last. On today’s cars throttle pedal position does not equal throttle blade position… and to assume so is far from reality.

Some examples;
* An 87mm TB (throttle body) can be found on engines ranging from 4.8L to 6.3L supercharged 650 HP on new 2015 ZO6.
* Above example illustrates that an oversized TB can be used on many engine sizes if correct governing is used.
* Above TB size is also used with displacement on demand, or where 4 cylinders are turned off (intake/exhaust valves deactivated) of 8. As engine displacement is effectively cut in half, TB must be opened more to maintain same power (more pumping losses and half available mass flow), this must be transparent to driver, so pedal position does not = throttle blade position.
* The desire to reduce pumping losses (increase VE or volumetric efficiency) will push any engineer to a very large TB, after all this is an easy/cheap solution… Less pressure drop across it, the better an engine breathes.

Downside of large TB;
* A certain minimum port/runner velocity must be maintained. If in doubt look at 10 year old motorcycle engines in which driver had control over main TB or butterfly valve via cable, but ECU controlled a downstream butterfly valve. The reason for this was to keep consumers happy with the perception that they had control not some computer, little did they know LOL.
* Large TB is much harder to get to idle correctly vs. small one with dedicated idle circuit.

Some things to consider;
* Most if not all modern TBs are “limp” or high idle biased… What this means is they must be driven closed to get normal idle. Spring return is too much air.
* Above was done due to regulations in which driver could pull off to side of the road, but at low speed in the event of a controls failure.
* There is no such thing as stepper TB, or have never seen one.
* Most TBs use an engine torque model as control method - far from simple…
* The days of separate TB control module are long gone, it’s in ECU with multiple levels of redundancy.

Safety concerns;
* No it’s not a myth, OEMs have paid out millions in settlements…
* You have apposite slope analog inputs for both throttle and pedal position feedback for a reason… This should also go to different ADC units… hence why input MUX on certain automotive MPUs is shared amongst units. It’s not a downside, but intentional.
* A simple MPU watchdog is not acceptable, with a secondary required that will disable appropriate devices.
* Memory error checking was put in for a reason.
* Many sanity checks are required i.e. calculated mass flow vs. throttle position.
* This is a VERY short list and not even close to complete.

Electric motor is not a gasoline engine;
* You cannot limit fuel in the same manner as current.
* If AFR is lean you will detonate/knock an engine to death.
* AFR can be so lean that engine will fall on it’s face - true, but you’ll transition through lean knock zone.

So in closing, I said I’d help push topics forward and am doing so.

But will not supply equations or control algorithms to be published on web… I have hundreds of hours in research alone… Never mind rest of it (theory to code w/testing)…

I think I might need to add some more to this comment of mine.

kb1gtt wrote:If the ETB erroneously goes WOT, then you end up lean and don't get the proper HP.

If you erroneously go WOT, the engine will knock and do some nasty stuff, but it will not generate excessive power. This is not like an electric motor, you are not instantaneously limiting power via limiting fuel. You are limiting stead state power by limiting fuel. Many people have the perception that if the ETB goes wide open the engine will run away, that's not the case with ETB algo's. Also note, the by wire stuff has been a problem for many years, and for many reasons. For example, the Magnium PI heli used a sensor that included a magnet, some metal filings got near the pedal / magnet and caused a crash. I seem to recall that crash was used as part of the intro, but cut short of the crash, to make it look like a crazy pilot doing a fast take off. Here's a video of the crash, they eventually start talking English. Just like with a broken TB cable, you can have problems. I've seen far less hazardous failure with ETB than with mechanical cables. This is why I consider ETB safety to be more myth than reality. Anyone can make a poorly designed system. However when people don't understand how the system works, they get scared, which is why we see such concerns with ETB. Much like the people with horses, who didn't like car's, it turned out that cars are better. ETB is also better and will win in the long term. Also the algo's are completely different, so the idea of doing it later when things are stable, isn't quite correct. It's completely different, and very little of the fuel code can be re-used with ETB algos. It's lower priority as there are less people out there with this newer technology.

Any how, primary point being If the ETB messes up some how, you will not run away with excess power. You will either choke air, and remove power, or you will go lean and remove power.

About multiplexing ADC's, beware the multiplexers tendency to charge pump. I've seen 24bit ADC's only perform at 12 bit accuracy because of this charge pumping issue. I don't like sharing DAC's as the internal capacitance can be a bugger. It's very common that it will skew your readings by a couple bits.

With ETB I am focusing on the fact that a lot of cars are using ETB already. For us to be able to control these engines somehow, we need some bare bones implementation. All we need now is a plain "electrical cable" implementation, the one the the pedal is directly linked to ETB position.

Anything smarter then that is in fact pretty far from now.

With ETB I am focusing on the fact that a lot of cars are using ETB already. For us to be able to control these engines somehow, we need some bare bones implementation. All we need now is a plain "electrical cable" implementation, the one the the pedal is directly linked to ETB position.

Anything smarter then that is in fact pretty far from now.

That’s a really bad idea… You need to decouple pedal from ETB for many reasons, some of which I explained above.

The pedal is a “Request” scaled 0-100%. The request is then conditioned to generate a “commanded” ETB position.

Some conditioning/reasons below;
* Most ETBs will idle at 1500+ RPM if not driven closed… This is where a negative bias comes into play.
* A max ETB position vs. RPM clamp should be employed. Simple lookup and interpolation is sufficient.
* Cruise control needs decoupled pedal - positive bias.
* Traction control needs decoupled pedal - negative bias.
* Rev limiter (this can be glass smooth if done correctly) needs decoupled pedal.

The first 2 bullet items can be written in under an hour… As I mentioned before, stop writing code and define this stuff so not stuck in perpetual re-write/modification mode, if you intend on early implementation.

EDIT
Above is oversimplified but used to illustrate why pedal should not = ETB or be a direct link...

Nobody wrote:As I mentioned before, stop writing code and define this stuff so not stuck in perpetual re-write/modification mode, if you intend on early implementation.

I think if we would agree to split ETB firmware into two pieces:
#1) ETB hardware driver. Assuming ETB position is defined by a value between 0 and 1, the responsibility of the driver is to move & hold throttle to the requested position
#2) ETB logic - the logic which is in charge of deciding where we want the throttle to be.

I believe that the driver could and should be implemented independently from the logic. So far I am only focusing on the ETB driver.

This is with BTS7960B which is only available from China but not from digikey.

Next step would be trying same with VNH2SP30 which I also have somewhere.

This time it's VNH2SP30-E - mine is http://www.ebay.com/itm//321530606386
[video][/video]

Not rusEfi, not mine - just to save the cool links:

What's so cool about it? Btw, what is the practical use of all those modes? (progressive, non-linear)
p.s. One thing I like about it is it doesn't produce that buzzing noise
p.p.s. Tuning software is really nice!

Sliding mode control as presented here: http://www.actc-control.com/events/meetings/ACTC_ET.pdf looks promising. All the maths looked difficult to start with until I realised it was summing the output position, the inverse of the required position and the last position acceleration multiplied by a factor gamma. Just need to get a suitable H-bridge FET driver built and I can give it a try.

Phil

Perhaps this would work for a proto-type.

http://www.ebay.com/itm/1Pcs-BTN7971-Motor-Driver-Module-7-2-20V-High-Performance-New-/281782870915?hash=item419b916383:g:jfMAAOSwkNZUeTsg

I have drawn a schematic for it. Well at least one channel of it.

I was planning on something rather simpler. And for a prototype I'll swap out the Dual P-N FETs for separate P & N channel ones.

I've ordered 2 N and 2 P channel FETs [TO220] along with 2 TC4427s this evening.

Apologies in advance for stupid software questions. They'll be along the lines of "where should I put the code?", "where and how should I store config parameters?" and "please help with I/O setup"

I have neither worked with ChibiOS nor with collaborative software projects in general so I expect to get flamed but would appreciate a gentle roasting.

Phil

I would use a dedicated H-Bridge driver with protection and diagnostics, something like this:

http://www.infineon.com/cms/en/product/power/motor-control-and-gate-driver-ics/intelligent-motor-control-ics/integrated-full-bridge-driver/TLE5205-2G/productType.html?productType=db3a304414ce7fd301153da68ca22af2

I agree with using a chip similar to the TLE5205.

I don't see how doing something that can be purchased in 1 chip but doing it in multiple chips is simpler. As well the circuit I referenced has an optocoupler. This is because these chips have a tendency to send higher frequency RF from inductive snubbing events up stream on your digital lines. The opto allows you galvanic isolation, which is commonly important for higher power inductive drivers. This suggested TLE5205-2G is almost identical to the BTN7971 found on the e-bay board. Datasheet for the BTN7971 found here.

http://www.infineon.com/cms/en/product/power/motor-control-and-gate-driver-ics/intelligent-motor-control-ics/single-half-bridge-driver/BTN7971B/productType.html?productType=db3a304414ce7fd301156bffc7c946b0

Cheers for the pointers. I'll still be testing with my solution as it's all available through-hole rather than SMT. Can't find a source for BTN7971 in the UK and the TLE5205-2G is very expensive. I'm going to plan on using the BTN8982.

PhilTheGeek wrote:Apologies in advance for stupid software questions. They'll be along the lines of "where should I put the code?", "where and how should I store config parameters?" and "please help with I/O setup"

Give me a couple of days to respond with more details but you can start @ http://rusefi.com/forum/viewtopic.php?f=5&t=9 & http://rusefi.com/forum/viewtopic.php?f=5&t=10

PhilTheGeek wrote:They'll be along the lines of "where should I put the code?"

https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/electronic_throttle.cpp is probably the file to add the new code into. We technically have some naive one-way PID implementation, I guess the first step before adding a better implementation would be figuring a way to objectively measure performance so that we can compare the existing implementation to the future one.

I'd suggest the best way of objectively assessing performance is to apply a synthesised throttle pedal input that performs a normally impossible instant step change from 0 to ~50%. Then log the throttle plate position and look for the speed of response along with minimisation of overshoot and oscillation at setpoint. If this looks good then it's probably also worth looking at a 100% to 50% step change as the response due to the return spring will be different.

After that I'm not sure if it's worth checking other smaller and larger steps and then some slower rises.

http://publications.lib.chalmers.se/records/fulltext/184355/184355.pdf
Design and implementation of a central
control unit in an automotive
drive-by-wire system
Master of Science Thesis in Embedded Electronic System Design

and they've used TMS570

I think this snippet summarizes that article well.

Because the objective of this project was to reconfigure the existing system architecture, no new functionality was added to the wheel and engine control units.

I've managed to skim most sections, there are lots of works about how they choose the TMS570, and they detail lots of things like how can bus work, or how drive by wire works, and other such high level content. They mention the "prior prototype" many times. It appears the ECU control algorithms would be part of what ever they did in that prototype. This paper appears to be all about combining 2 boards into one board and adding an LCD display. I wonder if they did a write up on that prior prototype.

Here come my not-very-heavy 2 cents:

have aHyundai Genesis Coupe with an EThrottle from the factory, where I'm running a certain afterrmarket company's PnP product for it.

From my personal experience, the best way to get things working at last somewhat is implementing it, and basically every car has a e-throttle nowadayss,
anywh, their product has hd (and stll has) ETC issues, but I've been driving on it for 2 and a half years no without dying. The few times I've had total ETC failure, one of two things happened:
1) The throttle would jut come to a hardcoded "rest" position, and the car would come to a stop.
2) The engine would shut down.

My point here is, it seems that making a "you're not going to die" piece of code is simple enoughm and this project, b virtue of bin open source,,,,,,,, a lot more potential to develop a "safe" ETC algorithm than a closed company of 2-3 working on one specific portion of code where all the testing comes from some guy in the other side of the world through Teamviewer.

I really don't think anyone will die from using an "experimental" version of a code as long as basic bases are covered, since from what I've seen, aftermarket options basically use their clients as test sujbects, and at least I can't report any fatalities of me or my clients (which by ladder, are clients of the aftermarket). I'm willing to test code as soon as I get everything Frankenso-related up and running.

I don't think the ETB progress has been hindered by safety concerns. There are lots of reasons why an engine can run away, a loose bolt, broken cable, loose screw on your butterfly, cracked gasket, etc can all cause an engine to run away. An ETB generally has reduced the run away risks significantly. As well you should have extra safeties, including a clutch or shift to neutral, and ignition key which can all be used to prevent a run away problem. As well this is of course only for track and closed circuits, not for roads which regulate safety or pollution

I think the key obstacles are getting a functional system that the software developer can develop against, and having a solid understanding of how the ETB should function. There is quite a bit of algorithm behind how an ETB should function. Generally it's not just a TPS to butterfly conversion. As well there seems to be like 10 different electrical typologies in how ETB's are handled. Some are powered open and spring closed, others are powered open and closed, some are steppers, other are PWM solenoids, etc. Then there is the feedback, with the two POT's, so there is a bunch of algorithm used there. I suspect that if @russian had a functional system which he could touch and could develop against personally, he'd probably make a bunch more progress. However attempting to develop with out something to touch makes it very hard to make progress.

Stepper for ETB? Aren't most ETB's a spring loaded PWM DC motor? Is your really a stepper ETB?