Looking for ideas for cruise control programming

[Map63Vette]

This isn't entirely Megasquirt related, but I'm wondering if I can leverage variables that the Megasquirt already calculates to try to make a cruise control system work better. I've been through a couple different variations of my code in testing, but have yet to find a setup that works to my liking. What I can't seem to figure out is how the control algorithm for cruise control actually functions. My engineering brain looks at it from the free body diagram perspective where you are effectively trying to balance resistive forces of stuff like wind and rolling resistance with the propelling force of the engine, but that requires a lot of knowledge of the vehicle dynamics that I don't really have and aren't exactly out there (car is a 67 Dart, so not a lot of aerodynamic and such values out there like modern cars). What gets me even more is that you can buy an aftermarket cruise control system that you can install on any old car and it takes very little sensor input and basically no programming to function, so it can't be that vehicle specific.

I have toyed with some PID control algorithms to attempt to give me better response time for the system, but what I have learned the most is that you can't think of the throttle as a speed control in the most direct sense. The throttle is really a "torque demand" control that basically tells the engine to give some percent of available torque at any given rpm, which is where that idea is starting to break down for me. I have a dyno chart for my engine (though it's probably out of date now that I've changed my ignition setup and tables), but that's still only valid for full throttle. I don't think that 50% throttle just means 50% of the torque available on the dyno chart as it's more of an airflow thing at that point. At low rpm you don't need as many cfm, so 50% throttle might be the same as 100% due to the fact that the engine can only pump so much air at whatever rpm, and I might not even be able to reach 5000 rpm at 25% throttle under load.

So all that rambling aside, what would you guys suggest on how to set up a cruise control system? I have CAN communication between my Raspberry Pi that is running the cruise control code and the Megasquirt, so I should be able to get whatever variables I need to out of the system. The throttle control is a simple RC style servo connected to the throttle body in parallel with the throttle cable. I started with the most basic setup I could where I just monitored the speed and calculated my own acceleration and other variables, and while it technically worked, it had bad oscillation issues where it takes it a long time to "catch up" when you initially let off the throttle when turning it on, then massive overshoot of the target speed. I hoped PID control might mitigate this, but I never found constants that seemed to help that much. I think some of this boils down to the throttle not being a direct controller of speed, so the PID calculations I had maybe didn't work the best. I then added the TPS variable so I could "pull up the slack" in the throttle when you first turn things on to try to mitigate the bad initial lag, but I still have oscillation problems when the road conditions change and it's not super flat ground. I've been thinking about trying to use something like RPMDot, VSSDot, or torque values from Megasquirt, but based on my datalogs I'm not sure that would work as those values tend to be pretty "steppy" or jagged, so I think it would have the servo constantly bouncing around. Wondering if anyone out there has done anything similar to this. I built a dirt simple version of the setup back in college for a different car that just monitored speed and told the servo to move a fixed amount either up or down based on whether I was going faster or slower than the set speed. It worked surprisingly well for being so simple, but was also on a less powerful car with an automatic, so I think it throttle inputs were damped compared to the manual in my Dart.

[ol boy]

Looking at the TPS and closing the loop around TPS% to slow down how quickly you close in on the MPH error. **Example... desired speed is 70 mph and your at 65.. current TPS is 15% and you think that adding 5% more throttle will help get you the added 5mph your looking for. Instead of wacking the throttle to 20% right off the bat, slowly increase the throttle 0.5% per second. so it will take 10ish seconds to add 5%. this might be too slow.. maybe 1% per seconds is too fast.. IDK. testing required.. How often you run the loop and how much you move on each loop will tame the response and amplitude.

I've played with a PID loop type thing where there are 4 states.. 1) below target and fall farther away. 2) blow target but getting closer to the target. 3) above target but getting closer. 4) above target but getting farther away. In state 1, look at the current error along with how much more error we have this time over last. New output = current error + (current error - last error). The idea is we need to take big bite as we are loosing ground to the target value. State 2 is the same current error but we subtract a little to keep from over shooting. new output = current error - (current error - last error). As you get closer to the target the past error and current error fall near to zero. States 3 and 4 work the same as 1 and 2 but the math is inverted.

Even OEM cruise controls are pretty slow and may take 10ish sec or more to add 5mph and settle in a speed. Rolling hills are also an issue for OEM's They can't predict hills as they can't see the hill coming..

[Map63Vette]

I may have to go back and play with it some more and just try to tamp down the response. I was using a pretty generic PID equation initially (something like P*error + I*cumulative error + D*error delta from last tick), but in thinking about what you said I think the I term was likely the issue. You just get a lot of error build-up when you take a long time to get to the speed you want, even with a very small I coefficient. I think some of the problem too comes in the form of the values I'm working with. My speed only has a resolution of 0.1 and the servo position only has a range of around "400". If the values are super small they just get rounded off and if the servo change isn't big enough in a step it really doesn't move either.

Loop timing was another question that came to mind for me. I guess I never really tried to slow it down that much, but probably won't hurt to stretch it out. Looks like my old code updated the speed every 0.1 seconds and ran the cruise update every 0.5 seconds, but stretching that out to something like 1 second between update cycles would also help damp the effect of the error term building up. I had also read about just putting a damping term on the whole equation (like multiplying the PID result by 0.3 or something like that), which I guess might have a similar effect. I tried to get clever with the algorithm as well by having the equation change when the current speed was within a range of the set speed (like taking the I term out entirely when error < some value). I don't think it really make as much difference as I hoped it would, but it was also just getting annoying to drive the same long flat stretch of road, stop at the end, update the code, then turn around and try again. Being able to read the TPS via CAN lets me pull up the slack in the throttle when I set the speed at least, which was a major tuning issue before as starting at 0% throttle when you set cruise really just doesn't work.

[ol boy]

I suppose you can limit the response mechanically also. Have the full range of the servo only yield a 30% sweep of throttle input. Or some sort of cam deal where the first 50% of servo movement only gives 30Ish% throttle to soften the flat level ground cruise speed while the last 50% servo give a snappier remaining 70% throttle.. In RC airplane world we call it expo.. Softens up the middle but still allows full through at the limits of the input gimble sticks.

I'm my car at WOT under 14 psi I get 11ish mph/s accel. Looking at datalogs just driving around it may take 3 to 4 sec to gain 1 mph in normal city traffic at 45mph. I could see freeway traffic the same way.

What sucks is there are probably a hundred different ways to approach this... You could close the loop on the tps based on mph/10s acceleration to get to the target speed... Maybe that alone gets feed into the PID to reduce over shoot.. IDK..

Now you have me thinking about how to get some hardware for this..

[Map63Vette]

Yeah, I know I limited the servo to only be able to pull something like 60 or maybe 70% throttle as anything else seemed excessive, though maybe I could have the range extend with speed. With a 0.5:1 6th gear I can drop the revs pretty far and a steep hill would take a lot of throttle to accelerate up, but generally speaking I think that was about the most I ever saw on datalogs. The one issue with targeting TPS is that those values are only going to be accurate for a fixed gear, wind, slope, etc. conditions. While you might get something like 1 mph/s at 20% throttle on flat ground with low wind, start driving up a hill or into a 20 mph headwind and that value isn't really accurate anymore. That was the issue I was running into before where I think the algorithm doesn't quite work as well since TPS isn't really directly connected with speed in the truest sense. TPS is really "torque demand" and in a lot of modern cars (or at least the industrial trucks I work on), that is the actual CAN message that the computer is interpreting. 100% throttle just means you are asking for 100% of the torque the engine can produce at whatever speed it is currently running, which can be any number of values depending on your dyno curve and the current conditions. From an engineering point of view, if I knew the rolling resistance and had a way to measure aerodynamic drag (including wind) as well as incline then I could theoretically calculate the necessary torque to either maintain a given speed or accelerate at a known rate up to the desired speed. I don't have a full torque map available to me for my engine at all throttle positions and loads though, but if the output from the MS was reasonable enough I might be able to use it. The PID loop would then be targeting a torque value by varying throttle, which could work, but I feel like it might be very jumpy as the amount of torque change per throttle change would probably differ greatly depending on where you are in the rpm range or gear. So as an example, if I was cruising in 6th at 1500 rpm and hit a hill, it could be that 25%--50% throttle all give me the same increase in torque of 50 ft-lbs as it's just the limitation of what the engine can produce at such low speeds, while going along steady ground in 4th gear at 3000 rpm might yield a much large increase in torque output for a smaller change in throttle. I think the control equation would prefer to have somewhat consistent response as the PID coefficient tuning is going to be more/less effective based on stuff like that. Like, you'd want a much higher P term for a "lazy" response like the low rpm condition, but that would make higher rpm oscillate really bad.

I'm also not really a controls engineer and am probably getting a bit carried away with all of this. I keep coming back to the fact that there are aftermarket systems out there today that you can install on any car with no real knowledge of the particular vehicle dynamics and they "just work". Maybe they don't work quite as nicely as an integrated OEM setup, but they take limited information and function effectively, so it must not be as difficult as I'm making it out to be. I think I'm going to start with just slowing the system way down so it updates less often. That will give it a change to actually see what effect the changes it is calling for are actually making and will hopefully reduce oscillation. I think I also agree that it's better to potentially never actually reach your set speed, just get really close. I think there are a couple different ways to get there via coefficient tuning. Guess I just need to do some test drives again and try some more stuff.