FreeEMS firmware feature wishlist! (out of date)

[GartnerProspect]

You lost me at Fuzzy.

But I'm dying to learn!

[AbeFM]

It's not that it's confusing, I'm wondering where the advantage is. Easier to tune? Or would this be self adapting?

[thebigmacd]

It's not that it's confusing, I'm wondering where the advantage is. Easier to tune? Or would this be self adapting?

Not self-adapting really, just easier to learn. More along the lines of model-based, but the math is done in terms of "fast" "slow" and "stopped" rather than "7000 rpm", "1200 rpm" and "0 rpm". Of course, you define fast, slow and stopped to be these numbers, but once they are defined, the abstract logic ignores the actual numbers as far as the operator is concerned.

I think the "self adapting" part is the biggest misunderstanding about fuzzy logic. Countless companies market fuzzy-this and fuzzy-that as "Self-adapting" but in actual fact no logic is modified at run time. The only adaptation part is during the design of the fuzzy statements, the designers used logic that will account for any possible anomaly in the operating conditions.

The whole point of fuzzy is easy setup and tuning while providing very good control of non-linear and multi-variable problems. For example, a PID controller can be set up to balance a given weight on top of a stick of a given length, but (physical limits notwithstanding) a simple fuzzy controller can balance ANY weight on ANY length, even if both parameters are varying in real time, without tuning during runtime. The fuzzy controller can even start with the weight hanging down and swing it up before balancing it. And all you need is a 7x7 logic table (7 ranges for rotation angle and 7 ranges for rate of change of angle). A PID controller fails if either parameter changes.

The programming is as simple as:

If ANGLE Is VERTICAL And ROTATION Is STOPPED Then FORCE Is NONE
If ANGLE Is SMALL_LEFT And ROTATION Is SLOW_LEFT Then FORCE Is NUDGE_LEFT
If ANGLE Is SMALL_LEFT And ROTATION Is FAST_LEFT Then FORCE Is MAX_LEFT
etc

Once the logic is set up, just tweaking the numbers for VERTICAL, SMALL_LEFT, SLOW_LEFT etc will tune the control for the desired result (speed, accuracy, or some compromise between the two)

[Fred]

fuzzy = assembly for us

Also, the idea is the the code is not gibberish to the average joe that decides to read it. Writing clever obtuse code that behaves in strange unintuitive ways is a "much later if ever" thing. Accessibility is key to contribution. Hence stuff all people contribute to MS code, first in assembly, now in a mix of heavily optimised C and assembly that is tricky to read for even someone who does a lot of coding regularly.

Keep up the discussions though. Thanks for explaining what you meant too.

[AbeFM]

The fuzzy controller can even start with the weight hanging down and swing it up before balancing it. And all you need is a 7x7 logic table (7 ranges for rotation angle and 7 ranges for rate of change of angle). A PID controller fails if either parameter changes.

The programming is as simple as:

If ANGLE Is VERTICAL And ROTATION Is STOPPED Then FORCE Is NONE
If ANGLE Is SMALL_LEFT And ROTATION Is SLOW_LEFT Then FORCE Is NUDGE_LEFT
If ANGLE Is SMALL_LEFT And ROTATION Is FAST_LEFT Then FORCE Is MAX_LEFT
etc

I'd like to get just a bit more on this 7x7 table. Do you have that as an example somewhere? Maybe start a fuzzy thread. So far, it doesn't seem like any difference to me other than how you write it down on paper before you code it. The idea of using variables instead of hard coded constants isn't exactly earth shattering. I'm not trying to downplay what you said, but I'm missing some of the novelty.

Make another thread and instruct us, Sensai.

[Fred]

An idea someone on the msextra site had to prevent burn stumble :

Or ”burn on next overrun”. So you hit burn, but it automatically waits until it detects the next overrun.

Apparently our chip has something to stop that happening, BUT, I haven't looked into it just yet. At all.

[AbeFM]

Oh, that's nice.

And I'm a big fan of burn-on-shutdown as well, assuming it's stuff you want to save (self set values), over a battery backup.

[GartnerProspect]

oooh ooh. Had an idea.

I want an output that latches on whenever a sensor is out of a specified range. And maybe if a number of other conditions are met.

Think check engine light. Maybe with a snapshot when it happens too would be nice.

Any thoughts on a RTC for that kind of thing too? It's about the only real use I can come up with for a RTC though so it might be an excess of hardware considering...

[Fred]

I'm keen for a single pin as a settable warning light of some sort for sure. Indicating issues with either just it's presence or perhaps even flashing a two digit code like OEM's do.

RTC is on the list for sure, I have one of these chips here now to play with when I get that far. Whether it is considered core or not is hard to decide though. On the one hand, it costs stuff all, on the other that cost adds up. If we include it in core stuff, everyone has to buy it. This is one of those design decisions that should be a group effort with discussion.

I think it's a really good idea to have it burned to eeprom with temperatures etc to do start up fueling calcs better, and I definitely want it in my datalogs, but should it be forced upon everyone? What would the default behaviour for start ups be without it? Can that be handled with ONE block of code? ONE code for all is the way I would like it to be. Let's try to find the best way to achieve that.

Fred.

[Russianblue]

one button start-stop logging to flash/SD/memorystick with auto filenaming and storage.

not a whole lot of suggestions on how to make this work, but i would just like to have a single 'logging' button near my shifter which would allow me to record a series of well-defined, targeted logs without having to pull over, reach in the glove box, turn on the PC....hook up cables....all that jazz.