Feeler thread: Looking to create our own engine management system
DavidZemon
Posts: 2,973
In the posts below you will find thoughts on a new engine management system running on a Propeller chip. The core idea that will differentiate this EMS from every other one out there is the auto-tuning. With so much parallel processing power, we will use two cogs to automatically tune the engine as it drives, with 3 modes available (economy, mixed, sport).
This originally started because I needed something on my resume. I wanted to compete in some national competition but have since decided to do this project as my Senior Design class. I will take care of the majority of all low-level programming (reading the maps and controlling spark/fuel) while my good friend Nathan will take care of all high-level programming (writing the algorithms to tune the engine). If we're lucky, we'll find a third person to take care of the GUI, but that is proving difficult.
---Original first post---
Hey all,
This is my first post here. I'm a computer engineer at Missouri S&T (Rolla) looking to partake in the Cornell Cup Competition next year. My team has a couple ideas - the main one being that we want to build our own engine management system, like MegaSquirt (www.megasquirt.info).
I'll post details on this later, once we get some more concrete plans. But, just for starters, do you guys think the Propeller is a good choice for a microcontroller, or would it be overkill?
Thanks,
David
This originally started because I needed something on my resume. I wanted to compete in some national competition but have since decided to do this project as my Senior Design class. I will take care of the majority of all low-level programming (reading the maps and controlling spark/fuel) while my good friend Nathan will take care of all high-level programming (writing the algorithms to tune the engine). If we're lucky, we'll find a third person to take care of the GUI, but that is proving difficult.
---Original first post---
Hey all,
This is my first post here. I'm a computer engineer at Missouri S&T (Rolla) looking to partake in the Cornell Cup Competition next year. My team has a couple ideas - the main one being that we want to build our own engine management system, like MegaSquirt (www.megasquirt.info).
I'll post details on this later, once we get some more concrete plans. But, just for starters, do you guys think the Propeller is a good choice for a microcontroller, or would it be overkill?
Thanks,
David
Comments
We think the Propeller is a good choice for all applications involving ambiguous questions.
Are you familiar with engine management systems and what designing one entails? If you are, then I don't think the question is actually all too ambiguous.
Actually, SRLM's answer wasn't too far off base. Do you know what micro controller designs entail and what the capabilities of the Propeller are? If you are, then the Answer isn't too cheeky!
Do you plan on monitoring and controlling basic engine functions? There are 8 cores and 32 general I/O pins to start with. Do you need to display data on an LCD? Might your requirements change so that a bigger/better display is needed? How abou VGA or composite video? PWM control of some peripheral? Data logging to a SD? ???? Ambiguous requirements at this point? Ambiguous, general purpose micro controller as a solution.
Come back with more specific needs and an attitude to TEAM with a bunch of professionals and eager, clever amateurs and you'll be amazed at the results!
- Listen to various engine sensors such as: engine temp, water temp, knock sensor, air pressure, O2 sensor
- Control fuel injection
- Control spark timing
- adjust fuel and spark as the dependent variables on two 3d curves with air pressure and RPM being independent
- output all of the above engine functions to an LCD
And the one thing that will make our system stand out from every other built today:
- adjust the fuel and timing maps automatically, during run-time, therefore auto-tuning the engine as you drive
I'm going to use this post as an outline for the requirements of the project as prof_braino suggested.
In fact, What would you do with the leftover Cogs?, Maybe output to a dash mounted TV monitor,
Much data could be logged, and then sent out thru XBee or even to your Smart Phone...
Check out the Parallax store, I see some stuff from your list that they might have for your team..
Keep us posted, This sounds like a cool project.
-Tommy
One problem.... I just read up on the Cornell Cup Competition rules... we have to use the Intel Atom Tunnel Creek. Not that it's a bad design, but I was really hoping to use the Propeller lol. Anyone know of other competitions that would fit this project?
-Phil
One key to success is any project is to start with clear requirements, and translate these into functions you can implement, and test that verify the functions are present and work as required. Another key to success is to do the coding/implementeation LAST, after you have written the requirements, completely described the functions, and established the tests. Most folks don't know this, I don't think its taught in school yet.
You have a cool project, and have some interesting highest-level requirements. Decompose these into systems, functions, and decide how to test them, this increases the likelihood of success.
Thanks, that's a really good idea. I do a bit of that already, but hadn't defined the process quite so thoroughly. I'll make sure to follow your suggestions though.
And again, if anyone hears of or finds a competition that would fit this project, let me know. I want to dominate it =D
Uh... yea! Thanks for the link
A problem connecting the chip to my computer postponed this project for a long time. With that now out of the way though, I'm finally ready to start coding.
I found a library not too long ago to drive an character LCD display, so I think my first project is going to be to get that working and try multi-threaded stuff. I'll have a timer on one cog and the LCD display driver on another. Then I will display the time from cog1 with the display driver on cog0. That should give me some practice with shared data.
I've decided to use post #5 as the outlined requirements for the project as prof_braino suggested. Should keep the project nice and easy to follow and comment on I hope.
I'm actually planning to make my own EFI system, but based on a servo motor driving a CIS distributor rather than pintle injectors.
We're going to first build this on Nathan's (my friend helping me with the project) Toyota MR2. I'd love to do this to my '91 900 Turbo, but it's my only car. Nathan is pretty sure he will have a second car by the time we're ready to actually hook anything up, so if something goes horribly wrong, one of us isn't screwed out of transportation.
Once it's up and running, it WILL be moved/copied onto my car
The 900t should have a B202L. Biggest difference from a 202 to a 204 is that the 204 is straight up an down, and the 202 is tilted. My dad has a B234 in his '99 9-3, and gets over 400hp out of it.
See what you can do in your '91. I've heard of >300HP without mechanical changes to the engine. Search SaabLink.net for some projects by "Palmer".
Anyway, I actually have no intentions of replacing the APC - it works beautifully (well... not in my car... but the design is great and some day it'll work in my car again). First step is to replace fuel-injection. When we have that working, we'll move onto spark. Probably won't ever replace the APC.
4800000000/delay
where delay is a register with the calculated delay between engine revolutions. Is there an awesome bit-shifty way to do this? I don't need to keep anywhere near 32 bits of precision. 10 bits would give me 10,000 rpm down to 250 rpm in intervals of 10
Given the horsepower of the propeller, if a project of this scale were to be undertaken, I think it would be good in the long run to start out with a base code running on one or two cogs, that was designed from the onset to allow features to be added without massive changes to the base code. I think one of the most important things to start with would be a generic wheel decoder to establish high precision timing events for the rest of the code to use, this would be one area where we could learn from the MS development. It started with a simple interupt (tach event) that had to be choped up, modified, and constantly updated to account for new users with oddball crank or cam or crank/cam triggers.
if we could come up with an elegant general purpose wheel decoder to start off with, then it might be all the easier to customize later versions of code for different engines.
I also think it would be cool to use the $25 P8X32A board as the "core", and build a few DIY duaghter boards that it could be bought and built by the end user depending on the feature set they required, the P8X32a could then just plug onto the daughter board with minimal fuss.
As for a base feature set, that is another area where a propeller based system could really shine with a rich set of periferals that would seem to be easy to implement;
1, SD card data logging with remote button(s) to mark datalogs for events. MS does this with a laptop and the space bar
2, A display! either a cheep monochrome or full color touch screen whiz bang, or both, would be a huge plus. The diplay could be plugged in to allow monitoring and possibly tuning. The MS has several options for this, but most if not all of them are driven by the serial port, are fairly basic, and usually cost as much or more than the MS itself. If this was added into the code from the onset, then the cost could be kept way down.
3, A standard, multi-pin automotive grade sealed connector(s). I like the simplicity of the MS DB37 connector(s), but its just dated, and its not very well suited to automotive conditions, although it seems to have worked well. But there are several afordable high quality, high pin count connectors out there. I have used a few of them and find them much easier to use.
4,Onboard wideband O2 sensor driver(s), If this thing is to be auto tuned, then a wideband O2 is simply a must.
5, on board RTC battery powered
6, input for or onboard accelorometer
7,A generic transmission controller?
lets see, what else
minimum of 8 injector driver pins with PWM if needed
minimum of 8 ignition coil pins
stepper motor controll for IAC valve
as many additional digital I/Os as possible, fuel pump, fan relay, fault lamp indicator, boost solinoid, 3-5+trans solinoids, shift lights, etc
many additional analog I/Os as possible, MAPand orMAF, BARO, TPS, O2(s), BattV,CTS,IAT,
give it a dedicated serial interface so that all crutial code variables could be transmitted to a second propeller.
for a start,
It looks like we would be pin limmited, but many of the digital and analog I/O's are not terribly timing sensitive, so they might be multiplexed or controlled via SPI or I2C to save pins for timing crucial events.
Something else that came to mind, though I dont know how hard it would be or how much overhead it might take, would be a "SetUp" mode.
This might be extreamly compilcated, but would be a HUGE benifit to the end user;
Since most engines this would be used on are alread fuel injected, if the gearhead could tie into the crank/cam signal, an injector(#1), coil signal, and load sensor, then put the propeller in "SetUp" mode, it could monitor all these signals and set itself up for 90% of the engine variables, as well as build rough fueling and timing curves. I Realise this would most likely be even more complicated than than the main code, but it would sure make it marketable to the average gearhead.
Don't forget, it's ok to connect two or more propellers to communicate with each other,
I bet that would help with some of the more crucial timing events..
Tommy
Thanks for showing your interest! This much feedback and suggestions is a great help. Unfortunately, I only got about half-way through before slapping myself for not doing homework. I'm completely bogged down by school this week & weekend, but I'll get back to you with comments and an update on progress soon as I can.
Cheers,
David
-Mike
Mike, those are my thought exactly. wheel (crank) angle determination and ignition timing would seem to me to be the single most crucial part to get right. The injector control would be next on the list, but the timing of the injector signal would not be terribly crucial to overall performance. What I mean by this is that if the injection event is off or moves around a few crank degrees I doubt it would make a noticeable difference in how the engine runs. The control over how long the injector is open needs to be tightly controlled, obviously. But my guess is, that if a robust code could be written to accurately read and predict wheel angle to a high precision, the ignition timing, coil dwell, injector timing and injector pulse control would be tied to that peripheral and have all the precision needed.
Also, my friend is likely picking himself up an old VW Rabbit to play around with as a rally car, so there's a very good chance that will be our test-bed.
Joey:
I finally got around to reading your post. lol. That took long enough. There are many many good ideas that I *will* be using. The automotive-quality connector isn't something I'd ever thought of, but I'll make sure that ends up in requirements section. I also love the idea for an on-board accelerometer - could give some fun little outputs to the screen (which was already part of the plan). Why the battery-powered RTC btw? It's certainly not out of the question but I can't imagine why you'd want one in your ECU.
The "SetUp" mode is something I'd already thought of and would love to implement. We'll see if it happens...
I think a lot of features will depend entirely on two things: how much my group and I are able to get done during this coming academic year, and how motivated I'll be to continue adding features when I graduate.
I promise this though - when I graduate, I will do at least one of two things: 1) continue adding features and making it more robust, 2) open-source the software and hardware (of course, this may happen earlier out of necessity when I get stuck on something lol)
1) Hardware and software are 100% reliable with some sort of fail-safe in event of failure. Priorities:
2) Engine reliability (if engine failure is possible, anything will be done to prevent it that does not harm the engine)
3) Performance/Economy (better-than-stock performance and economy are the overall goal of the software)
3) Setup of the software on any car is easy and straight-forward without in-depth knowledge of engine tuning. (Your on your own for automotive hardware compatibility - look to megasquirt users for help converting your car)
4) Full kit is as cheap as possible (while still adhering to Goal #1)
Because of goal #4, I do not plan to use a Parallax dev board. If I find that using a dev board is cheaper in the long run, I'll do that, but I suspect building my own PCB and buying only the parts necessary will be cheaper than using a dev board. I would rather have the above-listed core functionality and a very inexpensive product than a crazy wizbang board with hundreds of additional features and three times the cost.
-dan