Announcing a complete solution to mapping engine efficiency

[kubark42]

(Acknowledgement: This project was inspired and made possible by the MPGuino.)

As part of an extensive research project in optimal control, we have developed a sensor suite that we think can be used to map the engine efficiency of YOUR particular car. The engine efficiency is derived from logging data under normal driving conditions for any individual car. In fact, engine efficiency is probably a misnomer, as we are actually calculating complete system efficiency, including drivetrain losses, etc...

While similar to the MPGuino, this project has some notable differences: 1) no screen, 2) GPS logging, 3) accelerometer, and 4) saving data to an SD card.

The principle and application is described in short here:

http://www.eissq.com/ponthy/preprint.pdf (I had to resort to the obscuring the HTML because of the anti-spam features. I'll delete them as soon as the website says I have enough posts to have the right to post links.[Thanks MetroMPG for fixing it.])

As indicated in the above pdf, the solution is comprised of two parts: a hardware logger (shortly described above, with more details later) and a software package based on an Extended Kalman Filter.

The software package is complete, and is more or less in fire-and-forget state. It’s in alpha because documentation is lacking and it would take a few back-and-forths with me to properly set up your Matlab environment.

The software outputs the engine fuel efficiency, and gives you some other nifty outputs, such as the included Google Earth trip tracking (where color indicates speed).

I have full hardware schematics available, and will distribute the originals on demand. I am providing the jpgs for those curious.

In continuing this research, I would like to extend this project to cars outside the few we are already following. We are looking for people who would like to help us out. We are giving away the Eagle schematic and AVR code base in hopes that some of you will be motivated to build your own, with technical assistance from us. In theory, anyone can build one of these, although in reality the two SMC components (ATMega chip and accelerometer chip) are much easier with an oven. The overall parts cost, not including the GPS and board, can be brought in at well under $20. The GPS can be anything that can output NMEA sentences over a serial port. (I use a FV-M8 at 5Hz.)

As of this moment, I have ~10 circuit boards that are completed and tested, and another two for an upgraded model that awaits soldering. I will give these away for free to anyone interested in installing these units. I will include the AVR, the accelerometer, and the SD Card adaptor, as these might be hard to find. The rest are OTS components: resistors, capacitors, etc… I ask only that people pay shipping.

I also have a new version already written and debugged for the XMEGA, which solves some of the limitations of earlier models. It simply remains to finish the circuit schematic and fabricate the boards. If someone were to complete the circuit schematic for the XMEGA, I would be able to run off 10 or so boards, and then distribute them for free.

This could also be ported to the Primer2 or STM8S-Discovery platforms, if someone were so inclined. Thus you have the convenience of the MPGuino with the power of the Kalman Filter. I can offer a bit of assistance on these projects, but not as much as for the Primer2.

For those of you who have a CAN bus, I also have code for a $75 CAN reader, one where you have nothing to solder but one single 8-pin chip.

If it happens that any of you are in Luxembourg, Luxembourg or Auxerre, France, then I can give you a free working model and help you install it.

If anyone in the community is interested in the programming side of this project, the biggest help would come from converting some of the matlab files into C, Python, or some other language that can run on anyone's computer, without having a multi-thousand dollar software license.

I am interested in any and all comments that can help us improve this. (Notably, I am struggling to explain why I get a fuel efficiency that is globally too high, even if the shape of the curve seems to be spot-on. Which in the end is all that is important, as relative efficiency between engines and engine operating points is far more useful than absolute efficiency.)

As I get an idea of the community and internet’s reaction to this project, I will make a website that explains it a bit better. I admit that this post is a bit disorganized, but alas such is the limitation of forums. Unfortunately, as a result of having spent years on this project, I suffer from being too close to the problem and thus am likely assuming that things are clear when they are anything but. Don't be shy, let us know what you're thinking!

[gone-ot]

...wow!

[McTimson]

http://www.eissq.com/ponthy/On_Mappi...y-preprint.pdf is the link

This is some very impressive work! You've clearly put a lot of effort into this, and it looks very interesting. After reading through the report, I have a few questions about it:

In its' current state, the microprocessor stores the data on an SD card, and then you have to plug the SD card into a computer so Matlab can read it, correct? Would it be possible to output the data directly to a PC/laptop via Matlab rather than storing it on an SD card, in order to have real-time display of the data?

What exactly are the torque and efficiency being mapped against in figures 2 and 3 of the pdf?

Since the data for the different methods is so consistent, why is it still preferred to keep the GPS in the system? Was the data with GPS and DEM considered more accurate?

Do you have a source for the GPS units? I took a quick look for the FV-M8, but only found one for around $100.

[MetroMPG]

Hi Kenn -

Welcome, and thanks for posting. I just had a quick look through your research... fantastic! I'm sure you'll have more than a few members of the Instrumentation forum excited by your work.

I know that the topic of building specific fuel consumption maps has been brought up before in the context of the MPGuino, but this is the first (that I've seen) of it being done.

And verified against a dynamometer ... I'm envious of the tools you have available!

Originally Posted by kubark42

(I had to resort to the silly DOTs because of the anti-spam features.

I reformatted your URL to make it active.

(Trust me: with the number of spammers who register here daily simply to hi-jack the site's popularity by posting useless links, the restriction is needed, if annoying to legit new members. Feel free to post & delete 5 total messages to bypass the filter if you want to post more URL's.)

Darin

[gone-ot]

...anybody got one in USA and playing with results yet?

[kubark42]

Originally Posted by McTimson

In its' current state, the microprocessor stores the data on an SD card, and then you have to plug the SD card into a computer so Matlab can read it, correct? Would it be possible to output the data directly to a PC/laptop via Matlab rather than storing it on an SD card, in order to have real-time display of the data?

Absolutely. That's one of the eventual goals in the optimal control problem. With this model, we can estimate parameters online, such as mass changes (passengers getting in/out), air resistance changes (windows open/closed), rolling resistance changes (tire pressure a little low), etc...

What we're missing right now is the time to program the observer. A 17x17 matrix is not chump change for a microcontroller, especially without floating point. Even on my i7 processor, the Matlab calculations only go 10 times faster than real time. There's a lot of optimizing that can be done, though, so I'm guessing that a small DSP (or even FPGA) could do the work. It's certain, though, that the 8MHz AVR can't at that sample rate.

Originally Posted by McTimson

What exactly are the torque and efficiency being mapped against in figures 2 and 3 of the pdf?

Time. You're the second person to ask that, so clearly I need to do a better job of presenting those graphs. I'll update the caption once I'm back at work.

Originally Posted by McTimson

Since the data for the different methods is so consistent, why is it still preferred to keep the GPS in the system? Was the data with GPS and DEM considered more accurate?

Do you have a source for the GPS units? I took a quick look for the FV-M8, but only found one for around $100.

Multiple reasons: 1) For the highest precision results, we want to use as much data as possible. 2) With the GPS, we can continually update the estimation of road elevation and grade, improving past and future results as we converge toward the true road parameter values. 3) We need the GPS anyway for optimal control. Of course, that being said, it bears repeating that you don't strictly need the GPS and DEM if you want to apply the observer. In fact, the observer becomes much simpler, and might even become small enough to be practical in real-time on a 8MHz AVR. 4) Most importantly, the GPS gives us a very good time fix. Otherwise, you're kind of guessing in the dark when you try to fuse the various asynchronous data, and that is NOT good.

For the FV-M8, I have a source in Germany for less than 50E, and I remember seeing a few in America for under $60. Anyway, I wouldn't use that particular model anymore. The u-blox line of GPSes are far more interesting. For instance, the Falcom FSA03 is cheap, and has a host of features that are good for these kind of embedded applications (For instance, the FSA03 has very advanced firmware support for energy savings, while the FV-M8 has nothing at all.)

[kubark42]

Originally Posted by MetroMPG

I know that the topic of building specific fuel consumption maps has been brought up before in the context of the MPGuino, but this is the first (that I've seen) of it being done.

The math behind performing all the observability tests is widely understood. It's not complicated once you know what you're getting into, but if you're looking at it for the first time it can be overwhelming. The observer is key to getting good results. Without that, your data will be so noisy as to be totally inconclusive.

Originally Posted by MetroMPG

And verified against a dynamometer ... I'm envious of the tools you have available!

Even better, I got to verify against a dynamometer at the Grand Prix racetrack at Spa-Francorchamps. And they said I can come back and put the roadster on the race track once spring comes. "For scientific purposes".

To tell the truth, the dynamometer was kind of scary. It took a long time (around 1 hour) to get a very dense data grid. Since this was my personal car, if something blows up it's not my research budget that pays! But it was a lot of fun, and we'll definitely be going back with some other cars where I've installed the logging unit.

Originally Posted by MetroMPG

(Trust me: with the number of spammers who register here daily simply to hi-jack the site's popularity by posting useless links, the restriction is needed, if annoying to legit new members. Feel free to post & delete 5 total messages to bypass the filter if you want to post more URL's.)

Darin

Oh, I believe it! Thanks a lot for fixing it for me. And I'm guessing that I'll get to 5 pretty quickly, anyway.

[Weather Spotter]

what exactly would I need to buy in order to use my car as a test car? As a collage student money is tight bit I do drive a consistent route on a regular basis.

[kubark42]

Originally Posted by Weather Spotter

what exactly would I need to buy in order to use my car as a test car? As a collage student money is tight bit I do drive a consistent route on a regular basis.

Good question. While the exact cost will depend on what you have and what kind of a car you've got, overall it should be quite cheap. I have sitting next to me a number of 1st gen. boards that are completely ready, and tested. Only... they're first generation. The results are as accurate, but there's no automatic shutdown module for the GPS, so either you find an alternate way not losing the GPS fix whenever you turn off the car, or you run the risk of killing the battery if your car is parked for extended periods of time.

I have one additional second gen board, which uses a transistor to turn on the GPS every 30 minutes so that you always have a hot fix whenever you jump in your car. However, for this board it turns out that I don't even have the processors anymore, nor the accelerometer, so you'd have to spend about $20 on chips. Not a lot, but not free either.

So, to answer your question:

1. You should get a GPS. Any kind that outputs NMEA over a serial port AND has a pulse-per-second (PPS) signal will do, but as mentioned in an earlier post, I strongly favor something based on the u-blox chipset. Otherwise, I bet you can find something used on eBay for <$15.
   
2. You'll need to have some way of splicing into the fuel injection signal, so I suggest spending $5 to buy a short extension cord, (just like you would with the MPGuino.)
   
3. Again, just like the MPGuino, you'll need a Vss signal. I've seen cars where this is quick and easy, cars where I found it with a bit of effort online, and, for instance my car, cars where there is no Vss and you have to find some other solution (I used the CAN bus).
   
4. You'll also need an SD card, maximum of 2GB. (>2GB cards won't work.) If you don't have an old one lying around, I just bought a handful for 2€/ea. so they can only be cheaper back in the States.
   
5. If it's a first generation board, depending on the GPS you might need a battery to keep the GPS alive. I used lithium watch batteries, but those are a little pricey (~$5)
   
6. Add in assorted wires and connectors to get everything connected, and you're set for installation.
   
7. You'll also need a computer. If you don't have Matlab at school, you might find a copy that "fell off the back of the internet".

Oh, yeah, and don't forget to factor in a couple bucks in postage. The Luxembourgish post office says 2€ to send it anywhere in the world.

[McTimson]

I'd definitely be interested in installing one of these, the only problem for me would be finding the GPS unit. I don't know anything about them, so I'm not really sure what to look for in buying one. I already have an MPGuino set up, so those wires are already tapped, and I have access to Matlab.

Do you know the typical power draw of the GPS units?