idle IM_AUTO fixes and development.

It's all about the code!
spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

idle IM_AUTO fixes and development.

Post by spags » Sun Dec 21, 2014 6:01 pm

Hi everybody, I've been playing with the automatic idle algorithm. I have propose two enhancements.

TPS lockout - The algorithm thinks you are in idle when you are using the throttle. This is not good since it will close the ICV to try and get you back into idle RPM, when you let go of the throttle the ICV is closed and the car stalls. I have a patch that works for me, cant post it because forum will not allow .patch or .diff files.

ICVHomeValue - Proposed config struct field. This would serve a dual purpose, when idle is automatic (IM_AUTO) it's the known good point that the idle starts from after cranking (maybe even the panic value too). When idle is in manual it's the saved ICV value the engine will use (i think there is a ticket for that somewhere).

I don't mind doing the work to implement these things as long as there is interest.

User avatar
rus084
contributor
contributor
Posts: 678
Joined: Sun Dec 01, 2013 1:40 pm
Location: Russia , Stavropol
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by rus084 » Sun Dec 21, 2014 6:16 pm

you can post patch in .zip archive .

i want see interesting

Tomin
Posts: 39
Joined: Fri Oct 18, 2013 8:03 pm

Re: idle IM_AUTO fixes and development.

Post by Tomin » Sun Dec 21, 2014 6:19 pm

I very recomend to study Ford's strategy document (https://www.google.cz/search?q=ford+str ... 8gPVwIDICg).

I think there is fully/partially opened ICV valve while you are cruising and there is some algo. like "dashpot preposition". Try to find it there.

Also I very like Ford's approach for autocalibration of minimal TPS position. Find "RATCH algorithm".
https://www.google.cz/search?q=ford+rat ... AA&dpr=0.9
Tomas

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Sun Dec 21, 2014 6:23 pm

Thanks, going to give this links a good read. As for the TPS lockout, this is a first hack to stop the problem. It will evolve into something smarter like using the highest seen value or something like that. Here's the patch for my fix, dead simple.

Code: Select all

diff --git a/firmware/controllers/algo/idle_controller.cpp b/firmware/controllers/algo/idle_controller.cpp
index 6a40c4a..59d6e3e 100644
--- a/firmware/controllers/algo/idle_controller.cpp
+++ b/firmware/controllers/algo/idle_controller.cpp
@@ -17,6 +17,7 @@
 #include "idle_controller.h"
 #include "efilib.h"
 #include "rpm_calculator.h"
+#include "tps.h"
 
 static int lastGoodValue = DEFAULT_IDLE_DUTY;
 
@@ -58,6 +59,13 @@ static int changeValue(IdleValveState *idle, int currentRpm, int now, const char
  * now - current time in seconds
  */
 int getIdle(IdleValveState *idle, int currentRpm, int now) {
+  
+        if (getTPS() > 5.0) {
+	        // We are not supposed to be in idle mode. Don't touch anything
+	  idleDebug("TPS Lockout, TPS=", getTPS());
+		return idle->value;
+	}
+	
 	if (currentRpm == 0 || isCranking()) {
 		return setNewValue(idle, currentRpm, now, "cranking value: ", DEFAULT_IDLE_DUTY);
 	}


puff
contributor
contributor
Posts: 2733
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: idle IM_AUTO fixes and development.

Post by puff » Sun Dec 21, 2014 9:23 pm

hope, by May we'll have idle valve control for a stepper motor ;-)

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Sun Dec 21, 2014 10:06 pm

spags wrote:forum will not allow .patch or .diff files.
Fixed.

TPS lockout is undoubtedly a step in the right direction, will merge it in asap.

As for ICVHomeValue, how is it different from idleSolenoidPwm from board_configuration_s (which probably should not be in board_configuration_s but that's a different subject)? It could be that some code is missing though.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Mon Dec 22, 2014 5:25 am

spags wrote:Here's the patch for my fix, dead simple.
As is this patch breaks unit tests - they would not compile. DECLARE_ENGINE_PARAMETER/PASS_ENGINE_PARAMETER all that b.s.

Checked in.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Tue Dec 23, 2014 12:34 am

hope, by May we'll have idle valve control for a stepper motor ;-)
The only difference I can see between solenoid and actuator is the reaction time. A well designed algorithm may work for both without issues.
As for ICVHomeValue, how is it different from idleSolenoidPwm from board_configuration_s?
It isn't, that should work nicely!

I had a read at the the ford docs. I was thinking of going with finite state machine. Those docs give a good idea of what those states should be. As for the control algorithm i was thinking of using PID. Still have to give RATCH a good read, but i know PID better and it should be able to handle the changing loads and chase the variable control signal (two different idle speeds). In the end that should be an exchangeable part of the system.

All the states described in the document make since to me except DASHPOT LOCKOUT OF RPM CONTROL in page 232. Not really sure what conditions they are referring to there. Any words of clarity are welcome.

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Tue Dec 23, 2014 2:52 am

Ok, baby steps.

I think idleSolenoidPwm should be in engine configuration. Given that every user will want to change it to whatever they need from car to car within the same model. Here is a diff moving it to engineConfiguration.
Attachments
idleSolenoidPwm.diff
Move idleSolenoidPwm to engine configuration.
(2.95 KiB) Downloaded 415 times

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Tue Dec 23, 2014 8:25 pm

spags wrote:I think idleSolenoidPwm should be in engine configuration. ... Here is a diff moving it to engineConfiguration.
This patch breaks stuff, it breaks stuff because this area is fragile and lame. See https://sourceforge.net/p/rusefi/tickets/125/
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Tue Dec 23, 2014 9:51 pm

spags wrote:As for the control algorithm i was thinking of using PID.
I believe the current 'algorithm' is pretty much a very naive PI without D, is not it? Please note that there is a pid implementation in the repository already - there is a unit test but it's not used anywhere yet.

A first incremental step could be refactoring current stuff into PID, the challenge would be to figure out the matching coefficients.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Wed Dec 24, 2014 1:41 am

This patch breaks stuff, it breaks stuff because this area is fragile and lame. See https://sourceforge.net/p/rusefi/tickets/125/
I see... messy. I the future it would be cool if engine_configuration.h and rusefi.ini were generated from a common definition file. Or some other more clever way of unifying both.
I believe the current 'algorithm' is pretty much a very naive PI without D, is not it?
According to my degree from College of the Internets (http://en.wikipedia.org/wiki/PID_contro ... ler_theory) kinda, sorta. Correction is only derived from current error (the P term) and even then it's not a product of the error and a damper coefficient but a stepped response depending of the magnitude of the error. I don't see I or D element anywhere in the code. In fact if you take out the time brake and have it run on every thread wake up you see the droop manifests itself pretty strongly (i thought that was hilarious for some reason). That being said, i got it to work pretty damn well after some small tweaks like a positive bias on the corrections to offset the droop.

After reading the ford docs I came to the following conclusions.
- A more formal state machine for correction strategies is desirable.
- A mechanism for fueling corrections as part of it to offset lean spots is really worth looking into.
- Cranking behavior should be more advanced, like taking cranking temps into consideration.
- A propositioning strategy will improve drive ability.
- This shit goes deeper than I realized.

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Wed Dec 24, 2014 1:42 am

spags wrote:- This shit goes deeper than I realized.
:roll: :!: :?: :idea: :arrow: :| :mrgreen: :o :shock: :? :lol:
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Wed Dec 24, 2014 1:45 am

spags wrote:I the future it would be cool if engine_configuration.h and rusefi.ini were generated from a common definition file. Or some other more clever way of unifying both.
Image
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Wed Dec 24, 2014 2:23 pm

:lol: I'm stealing that one. Happens all the time at work.

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Sat Dec 27, 2014 3:39 pm

Ok, small update.

I've basically re-implemented idle to use the PID algorithm and a state machine to judge when it should be used. It builds and mostly works.

Changes up till now:
- On the idle thread use the efitimems_t type for timestamps. Gives us milliseconds resolution. Right now I'm sampling about every .6 seconds. May be able to half that with tuning.
- The algo/idle_controller.cpp code has been gutted and redone. I'm using a typical textbook pid implementation, if i'm sure its going to stay i will test and use the generic one in math/pid.cpp (the same right now).

How it works:
- While cranking opens icv to allow more air. In the future this should be dynamic (depending on starting conditions), right now it just opens to a static value.
- There is a warmup period, this uses the old algorithm to climb down from the cranking value and transfer to normal pid control. A rough estimate of the home value is done here.
- After the warmup period we go into active PID contro (AKA Dashpot mode). This updates the home value to the highest adjustment it has done.
- If the driver uses the throttle, the system goes into preposition mode where it resets the ICV to home value and waits for the throttle to go back to 0, passing control to the DASHPOT mode again.

I ran it last night and after some tuning got the PID to adjust well to small loads except for the following problems:
- It doesn't work :lol: Still can't handle larger loads like a/c or headlights for that mater. The car was running rich and the ignition was very conservative. Might be remediated by tuning.
- Preposition is wonky. Bliping the throttle stalls the engine when it comes back down.
- There are a lot of constants that should be normalized so this runs on other cars.
- No idea if it will work with stepper motor actuators? Might need to slow things down to wait for them to move into position.

Hopefully this weekend I will be able to fix some of those issues and get video.

The code is here: https://github.com/jmt42/rusefi-code it's git-svn mirror of the russian's sourceforge repo with my code added on top. All of the changes are in firmware/controllers/{idle_*,algo/idle_*} Constructive criticism and idea's are welcome.

Caveat: I would not recommend people test this code on their cars unless you understand what it's doing.

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Sat Dec 27, 2014 8:24 pm

spags wrote: - No idea if it will work with stepper motor actuators? Might need to slow things down to wait for them to move into position.
I would suggest to not bother for now, but that's obviously a legit concern. Will post something meaningful once I look at the code :)
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Mon Dec 29, 2014 1:54 am

Ok, update and as promised.. video.

[video][/video]

What it can do:
- Adjusts to normal loads such as using the brakes and turning on the lights.
- Does not crash when coming off the throttle (mostly... see special case below).
- Uses the builtin PID code.

Problems/Todo:
- Does not support engine braking. Engine braking will stall the engine. This is an issue with the idle lockout, it lets go when it shouldn't and the dashpot state lowers the icv pwm too much. Still thinking of a clever way out of this without wiring the clutch switch... but I will probably have to bite the bullet and implement something like inGear(engine_t) to catch engine braking.
- Still needs to be tuned properly. Have to write console commands for adjusting pid factors and final scaling as well as check interval (i think these should be in the persistent config at some point in the future).

Bonus:
- Got my a/c ac subsystem to use this without messing directly with the ICV! This uses the existing persistent config fields. It's in a separate branch called ac_idle. Code still needs love before i consider it ready but it works!
Attachments
2014-12-28_19.44.45.msl
MSL file of a run using the PID idle and AC controller. Stall where due to engine breaking.
(515.58 KiB) Downloaded 391 times

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Thu Jan 01, 2015 4:59 am

I've merged a tiny part of the change - the trivial part. The rest would become the most significant source code contribution in a while which raises the question http://rusefi.com/forum/viewtopic.php?f=13&t=325 so I will call you.
spags wrote: - Does not support engine braking. Engine braking will stall the engine. This is an issue with the idle lockout, it lets go when it shouldn't and the dashpot state lowers the icv pwm too much. Still thinking of a clever way out of this without wiring the clutch switch... but I will probably have to bite the bullet and implement something like inGear(engine_t) to catch engine braking.
That's cool that we are starting to think about engine braking :)
spags wrote: - Still needs to be tuned properly. Have to write console commands for adjusting pid factors and final scaling as well as check interval (i think these should be in the persistent config at some point in the future).
set_float X Y
set_int X Y


these might be used as a shortcut once you have the fields in the persistent config. I think that if you put your fields into the tail of persistent config that would be the easiest to merge later once this is fully ready to be merged.

That's some cool progress!
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

spags
contributor
contributor
Posts: 136
Joined: Mon Oct 13, 2014 1:04 am

Re: idle IM_AUTO fixes and development.

Post by spags » Thu Jan 01, 2015 4:47 pm

russian wrote:I've merged a tiny part of the change - the trivial part. The rest would become the most significant source code contribution in a while which raises the question http://rusefi.com/forum/viewtopic.php?f=13&t=325 so I will call you.
Ok, cool. I'm not working today so feel free to call anytime.
russian wrote:That's cool that we are starting to think about engine braking :)
Yeah! While I was test driving it and I got it to stall reliably on engine braking, my son was asking my why I was smiling, i tried explaining that it's a good problem to have. He didn't get it :lol: .

I've rolling the stalling issue around in my mind. From what i can tell my cars OEM algorithm uses the VSS to climb out of it's lockout. That would be a universal fix so one more use for VSS! For the short-term while VSS is being done I would have to kludge it raising the minimum ICV rate (which should be there anyways).

Today I'm going to be moving these values to the engineConfig struct, with these we should have enough control for any engine as long as it doesn't have more than one different ICV. I can't recall any but I'm sure they exist.

Code: Select all

// These should be broken out persistent storage
#define IDLE_PID_KP 0.3f
#define IDLE_PID_KI 0.1f
#define IDLE_PID_KD 0.0f
#define IDLE_PID_KC 0.12f        // What is the ratio of RPM change per ICV change.
#define CRANKING_IDLE_VALUE 530  // This will change for every car

// Delays and intervals (all in ms)
#define IDLE_LOCKOUT_DELAY 1000  // Affects how long to wait after lockout
#define IDLE_CHECK_INTERVAL 300  // Minimum check interval

// This one is probably boardConfiguration->idleSolenoidPwm
#define DEFAULT_IDLE_VALUE 400

// Per mil (1/1000) values
#define MIN_IDLE 100             // Should be changed the lowest we can go without stalling
#define MAX_IDLE 900            

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Thu Jan 01, 2015 5:10 pm

#define DEFAULT_IDLE_VALUE 400
I believe there is already some field for current idle or start idle or some idle value in the config

As a matter of fact I should probably fix this crazy 0-1000 thing, it's absurd. It should be a float value, either from 0 to 1 or from 0 to 100. Probably from 0 to 100 just because that's the most human-readable form
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Thu Jan 01, 2015 6:35 pm

russian wrote:As a matter of fact I should probably fix this crazy 0-1000 thing, it's absurd. It should be from 0 to 100 just because that's the most human-readable form
Done. Also added testIdleController unit test.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

stefanst
contributor
contributor
Posts: 579
Joined: Wed Feb 17, 2016 12:24 am

Closed Loop Idle

Post by stefanst » Mon Feb 13, 2017 12:28 am

Driving @russian's '03 automatic Miata today, it became clear that the current implementation of idle control is not sufficient for running cars with small engines and automatic transmissions.

Issue:
A lot of items can cause drag on the engine idle. A brief list that makes no claim whatsoever of being complete:
- Power Steering
- Automatic Transmission in "D" (torque converter)
- Alternator
- Increased internal losses (for example caused by highly viscous oil due to low oil-temperature)
- Air Conditioning

Old carbureted engines have an "idle-up" valve to deal at least with the additional drag caused by the automatic being put in non-idle position.
We need to emulate this in code.

I would also like to see engine temperature dependent target idle rpms. This target table also gets additional offsets based on load items. So for example we'd add 50rpm for automatic going in "D".

Suggestion: Have a PID controller for idle that uses a load-factor (y-axis) and target-rpm (x-axis) based offset table.

Load factor:
On/Off items just get a fixed number. For example the AT in drive or idle adds a certain load-factor (let's say 10), or not. Same for Power Steering (I believe modern-ish cars often have a pressure switch that indicates if the power-steering pump is being taxed or not). Same for AC. If we have an alternator that is controlled by the ECU, we could potentially add a load factor based on the commanded PWM to the alternator.

All those load-factors get added up and then we look up the idle-valve position from the target-rpm/load factor table. Run the PID loop on top of that and Bob's you're uncle- right?

Not quite:
The code should actually be able to figure out if it should enter CL idle mode or not. Why? That pesky PID I-term is why. Let's say we're coasting towards a stoplight. Foot is off the gas and the rpms are slowly dropping. With TPS around 0%, the code would typically assume we're in idle mode. Yet the engine is actively driven by the inertia of the car, so its not able to reach target-rpm. So the P-term and Offset will command a certain value and the I-term will keep decreasing, since we're above target idle rpm. Then we depress the clutch, because we're getting close to a stop and the car stalls, because the negative I-term drops the commanded idle valve position below what's needed to actually maintain idle. Embarrassment ensues and the cars behind you honk their horns.

So conditions for entering CL idle should be at least;
- TPS near 0% (for example <1%, selectable by the user)
- On a manual car: transmission in neutral, or clutch depressed
- On an automatic car: ???

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Mon Feb 13, 2017 12:34 am

Not much has changed since 2015 - https://sourceforge.net/p/rusefi/tickets/216/ is still open. Reviving this old thread :)
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
kb1gtt
contributor
contributor
Posts: 3469
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA
Contact:

Re: idle IM_AUTO fixes and development.

Post by kb1gtt » Mon Feb 13, 2017 1:18 am

It's common for PID algorithms to have a band around the target. Such that if you are outside the band, you are either full on or full off, or some times it's P only when outside the band. Then you only PID when you are inside this band around the target. If you are ever outside this target you blank the I term, to prevent integrator windup.

Also I think it's common for OEM's to have a target idle RPM, then PID to that RPM. Basically if you add a load for what ever reason, it opens an idle air valve to let in more air. I think that switch inputs is a better way, but costs more so is more common on more fancy cars, or if a load is to large that it could cause a stall, then you might need the extra expense to prevent stalling.
Welcome to the friendlier side of internet crazy :)

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Tue May 23, 2017 3:23 am

2.5 years later let's continue :)

[video][/video]
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Sat May 27, 2017 8:43 pm

Current automatic idle implementation is pretty much not useable if you want to actually drive the car out of garage. Need to actually implement at least some strategies for not applying idle PID all the time :) Will record a log today or tomorrow.
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

puff
contributor
contributor
Posts: 2733
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: idle IM_AUTO fixes and development.

Post by puff » Sun May 28, 2017 2:27 pm

why can't you drive the car with PID on all the time?
(i used to use idle when moving in traffic jam, but so far the only nice implementation I saw was with electric throttle on citroene C5)
what are the strategies?
Like no idle regulation when TPS>0?
Idle valve completely closed on closed-throttle decelleration?

stefanst
contributor
contributor
Posts: 579
Joined: Wed Feb 17, 2016 12:24 am

Re: idle IM_AUTO fixes and development.

Post by stefanst » Sun May 28, 2017 10:46 pm

If the PID idle algorithm runs while you have your foot on the throttle, the I-term will quickly go as negative as possible, because it's trying to lower the rpm, which it can't, because it's controlled by your foot on the throttle and not the idle valve. So now, if you take your foot off the throttle, the idle valve will be closed and the engine stalls.

User avatar
russian
Site Admin
Posts: 9683
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Soldering skill: yes
Coding skill?: yes
Contact:

Re: idle IM_AUTO fixes and development.

Post by russian » Mon Jun 05, 2017 1:38 am

pFactor=0.05/iFactor=0.0001/offset=30/period=50ms

I can at least go N>R>D>R>N>D>R>N etc with some driving back and forth without touching throttle, but RPMs are pretty crazy and this is far, far away from being serious.

https://svn.code.sf.net/p/rusefi/code/m ... dle_pid.7z
https://rusefi.com/s/howtocontribute
very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
my skype is arro239

Post Reply