Announcing a complete solution to mapping engine efficiency

[kubark42]

Originally Posted by tasdrouille

Building on Robert's idea, of letting it start backwards with the clutch disengaged. You now have two scenarios. 1- The car reachs a speed at the bottom of the wave at which the engine would rev past its efficiency island. 2- The car never makes it to the most efficient speed just rocking back and forth from it's innitial potential energy.

Scenario 1: You let it rock backwards up the left hand side of the wave. From there going down it will cross the most efficient rpm somewhere before the bottom of the wave. It will also cross it back while slowing down somewhere on its way back up the wave to the car's original starting point. Assuming your new "starting position" is now on the left hand side of the wave pointing down, you then calculate and subsequently execute two pulses, both as close to the efficiency island load and rpm as they can be, one on the way down and one on the way up, that will give you the energy needed to get over the first wave.

Scenario 2: You let it rock backwards so your new starting position is on the left hand side of the wave pointing down and you do one single pulse starting at the very bottom of the wave, where you're speed will be the greatest.

Edit: Thinking about it, for scenario 1 the car should be rocking back and forth in the starting wave while applying infinitesimal bursts each time the sweet spot speed is crossed when the car is going forward, the amplitude of the movement increasing all the way untill the car can go over the first wave.

That is indeed correct. I think an easier way to look at it is like this:

You need a certain amount of additional energy to climb over the first hill. The maximum efficiency will come by buying that energy the cheapest possible.

Since the car can rock back and forth for free, you have only to let it oscillate back and forth, applying thrust only at the moment when the energy is cheapest to buy, that is to say at the highest efficiency.

So to be mathematically precise, you have the following cases:

1) While coasting up and down, you never reach the maximum efficiency speed. At this moment, you apply an infinitely short blip of throttle in the very bottom, buying your energy at the maximum efficiency point, even if it is not the absolute maximum efficiency.

2) While coasting up and down, you reach the maximum efficiency speed. You can do this once (in the critical case), twice, or perhaps an infinite number of times.

2a) Once: The maximum efficiency speed arrives at the very bottom of the curve. This is an arbitrary distinction from the multiple peak crossings, so there's nothing interesting here.

2b) Multiple times: depending on how strong your torque input is versus the slope, you could actually add energy sufficiently quickly that the car accelerates. Therefore you get to repeat this strategy as many times as possible during the cycle.

In any case, the strategy is always to add energy at the very moment when it costs you the least. And an earlier comment was right, once you have just enough energy to crest the first hill, the other hills require no more energy, but you WILL grow tired of this after a few eons and decide that maybe a tiny bit of wasted energy might be nice in order to finish the trip before the universe dies a heat death.

I have long been suspecting the definitive answer is lying in an unpractical particularity of the excercise, mostly irrelevant to the real world.

That's not correct. It is, perhaps, not immediately relevant to driving. However, it is most certainly not irrelevant to the real world.

One of the challenges in the world of controls and mathematics is to find analogs between systems. For instance, you have developed a new controller and would to apply it to nuclear reactors. Obviously, no one is going to let you do it without years of experience with the controller. So how do you do it? You look for systems with similar dynamics. For instance, the ball and plate is analogous to certain nuclear controls problems, so by demonstrating stability in a fun, harmless experiment, we can at the same time make the case for a far more serious application.

So, to come back to the point, what is interesting is that there is a point at which the system "tips", at which it is no longer interesting to go backwards an infinite number of times before we finally arrive at our forward target.

So while this might not work in a real-world car, something similar might work on metal rails (with perhaps one or two rocking motions before the final "push"), certainly works for spacecraft (that's where the "intersteller highway" comes from), and probably has some interesting applications in chemical systems.

Anyway, all that over and done with, I thought it was an interesting problem when I encountered it, and it highlights the problems with correctly posing problems in optimal control.

[kubark42]

And a quick afterword, sorry to have been away for so long. Life (and a paper deadline) got the better of me for a couple weeks. We've got some very new and interesting results from a real car (none of this ideal clutch, frictionless, etc...), not only for observation but also optimal control.

That being said, I owe Tasdrouille an AVR Dragon (which I have sitting right next to me. Just PM me where I should send it and I'll drop it in the mail ASAP). In fact, thinking of sending out circuits, there are a number of you who said they'd like modules and I've got ones sitting here, in various states of readiness. Three of them have the hard parts soldered on them and can go out the door immediately. I'd rather send these to people who don't have any way to solder SMD devices. I won't have time to complete them, but they ARE tested so I know that everything works. What hasn't been soldered on yet is some resistors, capacitors, an opto-isolator, an LED, etc... All DIP parts, so this is 15-30 minutes of work, not more.

Can I get a quick show of hands to see who is still interested?

[kubark42]

Originally Posted by RobertSmalls

Ah, yes, I think Martin has it with the well-timed infinitesimal pulses. The only way to improve upon it without cheating too blatantly would be to use the above method, but stop a few hundred Joules short of being able to crest the hill. Then have the driver get on the roof of the car, and run off the back of the car as fast as he can.

There are a few variations on this theme that involve the driver removing noncritical components (the interior, bodywork, exhaust, whatever) and vigorously ejecting them rearward while the car is at rest or traveling forward. But these are all examples of human power, and if that's allowed, then you may as well just push the car faster little by little, as you would push a child on a swingset.

Hilarious!

While commuting today, I was thinking about what the data would look like in MATLAB. If you look at my TPS readings (or using fuel injector pulsewidth as a surrogate), you'd think I'm an indecisive driver. Maybe I am, but traffic can be unpredictable.

Do you automatically discard unusable data by running the observer only across timescales where the fuel injectors are active? Perhaps you could record the position of the neutral safety switch (or manually select timescales where you were coasting) to allow you to include data for neutral coasting. I'm sure engine efficiency is one of the most unpredictable parameters, so being able to set engine torque to zero some of the time would improve your ability to estimate all of the parameters, right?

Your project is as interesting to me for its ability to estimate CdA despite gravitational and rolling resistance effects, as for its ability to measure BSFC.

I run the observer at all times, but without throttle and brake position sensors, it is difficult to see the transitions. Thus I only create the efficiency graph for times when I can be sure that the engine is pushing the car. This isn't hard to find. Pretty much anything where the car is over 10km/hr and the car is experiencing a forward thrust is a case where the engine is certainly pushing. There are also cases which we miss, for instance when slowing enough that it's tough to tell the difference between engine in neutral and giving it a teensy-bit of gas, but that's really 1% of the time you spend driving in the car. (Driving in the sense of rolling forward, not time spent idling while stopped.)

It is trivial (in the engineering sense) to detect when the car is in neutral. We have only to look for when the engine speed is strongly different from the possible engine vs. car speed. So you can get loads of good data on estimating CdA, Crr, etc...

[kubark42]

Originally Posted by tasdrouille

This is only 5 days worth of driving for my wife in her Elantra. 17000 unfiltered raw data points and 150000 individual values logged on my CAN OBDuino. Things are starting to look interesting. I just need to take the car and spin it in RPM/loads regions it's not usually used to get a better picture.

XYZ you have RPM, BMEP in kPa and BSFC in g/kWh

Fuel flow was calculated from the MAF sensor reading corrected with the equivalence ratio from the stock wideband sensor.
Brake torque was estimated from the Calculated engine load % (airflow/peak theorical airflow. I need to figure out if peak airflow is adjusted from baro pressure or not in the Elantra.) mapped against the max engine torque curve from the manufacturer.

What I like about this method is that fuel flow does not depend on the repeatablity of fillups and calibration of external sensors, but it assumes the MAF and WB02 sensors are accurate. Even though torque is grossly estimated, I kind of like the fact this method does not care about the car's mass, rolling resistance or air drag, all of which can greatly vary in time.

Hey, that's quite neat. How did you find the CAN codes for the Elantra? I'd be quite interested to know how that stacks up against my predictions. It'd certainly be a good way to improve the model. At what speed are the samples coming?

For calculating torque, are you just multiplying the normalized airflow times peak engine power? I'm not sure how much you can trust the torque measured that way. If you could put it on a dynamometer once you could calibrate it, though, and that'd be quite nice.

[kubark42]

(Ooof, 5 posts in 60 minutes. Who has time to read them all?)

Slight change of plans. I was just asked by some researchers to use my logging module to log traffic flow in Luxembourg, so I'm going to redesign the board for the XMEGA. If anyone has specific requests on what could/should be in a newly designed logging module, I'll be happy to build them in. I need to have the design ready by Monday, so if you've got an idea don't hesitate.

Here are my upgrades so far:

1) Provide a pad for CAN/LIN.
2) People have mentioned wide-band O2 sensors. What, beyond a 0-3.3V ADC would this need in order to measure it? (This is your moment, jfitzpat, tell me what goes here and I'll build it in.)

What else would you like to have?

[tasdrouille]

Originally Posted by kubark42

Hey, that's quite neat. How did you find the CAN codes for the Elantra? I'd be quite interested to know how that stacks up against my predictions. It'd certainly be a good way to improve the model. At what speed are the samples coming?

The CAN OBDuino was designed by member Magister here. He'd have the answers about the CAN codes. Samples are coming in at roughly one PID every 25 ms. There is some error inherent to receiving PIDs asynchronously and using them to computes instantaneous values. I don't know if this is significant or not, but I believe I'll be able to easily throw out errors from rapidly changing conditions so everything averages out in te end.

Originally Posted by kubark42

For calculating torque, are you just multiplying the normalized airflow times peak engine power? I'm not sure how much you can trust the torque measured that way. If you could put it on a dynamometer once you could calibrate it, though, and that'd be quite nice.

Yes, I generated a torque/rpm table from peak torque curves of stock elantras dyno runs, and I estimate torque from airflow/peak airflow. This is based on the fact that torque is proportional to MAF/RPM*Lambda. I have not considered lambda in the torque estimation yet as I'm more ot less at 1 all the time, but I have the data at hand. I have not verified if peak airflow in the elantra is adjusted for barometric pressure or intake air temperature, but again I have the data logged to account for that too. Ignition timing is the other factor I did not account for that affect torque production when estimating from MAF. I will have to investigate that. My car does not have EGR so this is at least one thing I don't need to worry about when estimating torque.

[RobertSmalls]

Originally Posted by kubark42

Can I get a quick show of hands to see who is still interested?

Definitely still interested.

Originally Posted by kubark42

What else would you like to have?

Traction battery current. Otherwise my logs will be peppered with enormous increases in driving torque accompanied by modest increases in fuel consumption. Logging that channel would also allow me to study exactly how much energy I recover through regenerative braking, and how much I waste with friction braking.

The Insight's current sensor outputs about 25mA per amp of battery current. Battery voltage varies from ~140V to ~168V at rest, and probably varies more under load. If you log both channels and consult a motor + inverter efficiency map (efficiency is a function of RPM and torque), it should be possible to estimate electric drive torque. Whether that estimate will be accurate enough to be useful, I don't know.

[kubark42]

Originally Posted by RobertSmalls

Traction battery current. Otherwise my logs will be peppered with enormous increases in driving torque accompanied by modest increases in fuel consumption. Logging that channel would also allow me to study exactly how much energy I recover through regenerative braking, and how much I waste with friction braking.

The Insight's current sensor outputs about 25mA per amp of battery current. Battery voltage varies from ~140V to ~168V at rest, and probably varies more under load. If you log both channels and consult a motor + inverter efficiency map (efficiency is a function of RPM and torque), it should be possible to estimate electric drive torque. Whether that estimate will be accurate enough to be useful, I don't know.

So what this will need is a resistor bridge, followed perhaps by an op-amp in order to have the full range in the ADC.

For safety reasons, the resistor bridge needs to be by the pack, no ifs and or buts. However, I will try to design a pad for an op-amp into the circuit-board so that this kind of voltage can be measured.

Anything else?

[RobertSmalls]

For my purposes, it would probably be sufficient to log only current, and just make educated guesses about voltage. But if you need more accuracy, such as if you wanted to find the optimal control scheme for a hybrid whose electric motor can't be switched off like mine, then you'd want to log voltage and perhaps current at the battery and on the U, V, W phase cables between the inverter and motor.

I'm pretty confident that the optimal scheme for my hybrid is to use assist as seldom as possible, because energy drawn from the battery has to be paid back at ~70% efficiency.

[mwebb]

Unfortunately, we cannot directly measure the difference between rough roads and smooth ones. This is within the capability of the observer, but in order to have that level of precision you would have to have much more accurate sensors. Specifically, you'd need a danged good elevation profile for your road. Also, a throttle position sensor would help.
the TPS value will NOT help.
the MAF or MAP (on speed density systems) value will
and
better still (as stated already in this thread )
the calculated load PID will
==============================
with the mpguino Can
they are using OBD2 data to make the calculations

on many systems using AFR sensors ;
you can not use an analogue connection to measure all AFR sensors
some use changes in current flow , very small changes and there is no easy way to break into the harness to get an accurate measurement .
but
you can use the STFT or EQ ratio value in OBD2 generic data as the output of the AFR sensor is directly reflected in
STFT and EQ ratio -
if your scan tool has a fast enough update rate and can graph the data
you can get some really neat graphs going after only 1 or 2 PIDs at a time

and
you can flag a biased AFR sensor IF it does NOT center on ZERO trim or Lambda on most systems

you can get a basic idea if your MAF sensor is reporting correctly by
comparing calculated load at WOT over 4k rpm in 2nd gear uphill
calculated load should be very close to 100%
do not use the absolute calculated load PID , values will always reach 100% and they will not be correct

If there is a BARO calculation (ford) it better be accurate for local ambient BARO pressure at the time , other wise suspect incorrectly reporting MAF .

if calculated load is less than 100% under WOT as described above
and the system is still in fuel control and NOT open loop , look at fuel trim
IF SUM of fuel trim s is adding more than 10%
expect an underreporting MAF or restriction to fuel flow