EcoModder Forum Announcing a complete solution to mapping engine efficiency

Register Now
 Remember

 Submit Tools LinkBack Thread Tools
03-24-2010, 11:15 AM   #61 (permalink)
EcoModding Lurker

Join Date: Jan 2009
Location: Luxembourg
Posts: 29
Thanks: 2
Thanked 12 Times in 3 Posts
Quote:
 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.

Quote:
 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.

 Today Popular topics Other popular topics in this forum... View the most popular topics in this subforum by views or by posts
 03-24-2010, 11:21 AM #62 (permalink) EcoModding Lurker   Join Date: Jan 2009 Location: Luxembourg Posts: 29 Thanks: 2 Thanked 12 Times in 3 Posts 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?
03-24-2010, 11:31 AM   #63 (permalink)
EcoModding Lurker

Join Date: Jan 2009
Location: Luxembourg
Posts: 29
Thanks: 2
Thanked 12 Times in 3 Posts
Quote:
 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!

Quote:
 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...

03-24-2010, 11:35 AM   #64 (permalink)
EcoModding Lurker

Join Date: Jan 2009
Location: Luxembourg
Posts: 29
Thanks: 2
Thanked 12 Times in 3 Posts
Quote:
 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.

 03-24-2010, 12:25 PM #65 (permalink) EcoModding Lurker   Join Date: Jan 2009 Location: Luxembourg Posts: 29 Thanks: 2 Thanked 12 Times in 3 Posts (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?
03-24-2010, 02:59 PM   #66 (permalink)
Master EcoModder

Join Date: Jan 2008
Location: Mirabel, QC
Posts: 1,672

The Guzzler - '08 Hyundai Elantra GL
90 day: 33.12 mpg (US)

Got Soul? - '11 Kia Soul 2U
Thanks: 35
Thanked 86 Times in 57 Posts
Quote:
 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.

Quote:
 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.
__________________

www.HyperKilometreur.com - Quand chaque goutte compte...

03-25-2010, 12:46 PM   #67 (permalink)
Left Lane Ecodriver

Join Date: Aug 2008
Location: Buffalo, NY, USA
Posts: 2,257

Prius C - '12 Toyota Prius C
Thanks: 79
Thanked 286 Times in 199 Posts
Quote:
 Originally Posted by kubark42 Can I get a quick show of hands to see who is still interested?
Definitely still interested.
Quote:
 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.

03-25-2010, 01:20 PM   #68 (permalink)
EcoModding Lurker

Join Date: Jan 2009
Location: Luxembourg
Posts: 29
Thanks: 2
Thanked 12 Times in 3 Posts
Quote:
 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?

 03-25-2010, 11:23 PM #69 (permalink) Left Lane Ecodriver     Join Date: Aug 2008 Location: Buffalo, NY, USA Posts: 2,257 Prius C - '12 Toyota Prius C Thanks: 79 Thanked 286 Times in 199 Posts 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. Last edited by RobertSmalls; 03-25-2010 at 11:31 PM..
 03-29-2010, 01:51 AM #70 (permalink) Master EcoModder     Join Date: Jul 2009 Location: New York Posts: 513 no nickname , it's just a car - '04 volkswagen golf tdi Thanks: 2 Thanked 101 Times in 74 Posts 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

 Thread Tools

 Similar Threads Thread Thread Starter Forum Replies Last Post Lazarus General Efficiency Discussion 23 09-16-2015 02:27 AM bennelson EcoModding Central 43 08-12-2008 09:45 PM MetroMPG Hypermiling / EcoDriver's Ed 6 02-22-2008 08:38 AM Krieg EcoModding Central 31 01-02-2008 07:06 AM SVOboy Instrumentation 2 11-17-2007 11:38 AM

 -- EcoModder Skin -- Mobile / Lightweight skin Contact Us - EcoModder.com - Archive - Recent Posts - Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com