Paul & Sabrina's cheap DIY 144v motor controller

[dcb]

Originally Posted by MPaulHolmes

My delta_t is 1/1000 of a second.

1/1024 of a second, but who's counting

Originally Posted by MPaulHolmes

Man, I'm not going to lie, "my kingdom for 32 bits"

I have some low cost 64 bit routines you can use, but they are built like a register machine, everything in the guino is stored as 32 bits (8 bit atmega168) but gets promoted to 64 for mathematical operations. Though it may be a bit much for this application.

[JayC]

BTW, P is usually referred to as Kp or proportional constant and I as Ki or integral constant.

some code I use on my robot modified for this context. Mine is a PD loop.
{
// Error = difference between desired and measured
error = (desired_Current - current_measured);
_pd = ( (error * k_p) + ( (error - last_error) * k_d) );
last_error = error; // store our last error
pwmDuty += limit_range(pwmDuty + _pd, MINRANGE, MAXRANGE);
}

// limit the range of the value to between low and high. Si
int16_t limit_range(int16_t val, int16_t low, int16_t high)
{
if(val < low) return low;
else if(val > high) return high;
else return val;
}

Jay

[MazdaMatt]

Geez... looks like Mr. Math Teacher is getting the hang of this... just had to speak his language!

Paul - you don't need a 32-bit cpu to do 32-bit math. Just declare the variables as 32-bit and your compiler will optimize it. Just double-check to make sure that you aren't dragging it down with all the conversion. If it does, try 16-bit. No biggie.

Great work!

[MPaulHolmes]

Well I'll be hornswoggled! I declared some 32 bit integers, and when I did some multiplication with them in the simulator, the simulator acted really weird, but it seemed to compute them correctly. very disturbing, though.

[dcb]

I've seen the gcc math libraries up close, they are waaay funky.

[MPaulHolmes]

Holy hanna montana! I changed a couple of the variables in the code to 32 bit, so that now I have Kp and Ki with a resolution of 0.001 (OK, dcb, 1/1024! hahaha!). I think it's going to be plenty! My first attempt was with Kp = 16/1024, Ki = 16/1024. It was WAY too gentle to a step response on a hill. By step response, I mean I "stepped" on the gas. If I do some sort of bisection method, and then drive super slow up a steep hill each time, I figure I can find the perfect PI variables for this motor quicker than a yeller monkeyturd! (Like Old Yeller, meaning Yellow... He's my dog... I'll do it... Old Yeller is dying of the slobbering fits...) Then I can back off that a bit, and call it good for all motors? I don't know, so back off! Geeze! I want to try to implement some sort of perfect Kp and Ki seeking algorithm, so that the controller can LEARN it's motor. That would be awesome. It would also make use of the EEProm so we could store those values. Not right now, of course! hahaha!

I cleaned up the PI loop. Thank you, JayC! ya...
//////////////////////////////////////////////////////////////////////////////////

errorNew = _throttlePos - _current;

pwmDutyFine += Kp*((int32_t)errorNew) + (Ki - Kp)*((int32_t)errorOld);
errorOld = errorNew;

if (pwmDutyFine > MAX_PWM_FINE)
pwmDutyFine = MAX_PWM_FINE;
else if (pwmDutyFine < 0l)
pwmDutyFine = 0l;

/////////////////////////////////////////////////////////////////////////////
To cut down on shifts and multiplies, I store Kp as scaled by 1000 (1024). hehe


EDIT: 128/1024 < Kp < 1
EDIT: 128/1024 < Kp < 512

[NiHaoMike]

Holy hanna montana!

At least you're not actually dealing with code for a Hannah Montana. The radically different architecture, the non-IEEE floating point handling, and lack of GCC support make programming that a bit of a pain. Hopefully Intel's Larrabee will perform at least as well and be easier to program...

I want to try to implement some sort of perfect Kp and Ki seeking algorithm, so that the controller can LEARN it's motor.

What you're trying to do is APID (Adaptive Proportional Integral Derivative) control. A friend of mine (known as "fridge girl") is actually working on an APID controller for HVAC. She's using hardware that is considered pretty powerful by embedded system standards - a 266MHz RISC CPU (ARM), 32MB SDRAM, 8MB boot ROM + 512MB SSD, Ethernet, USB 2.0, CAN, and it runs Linux. From my understanding, it analyzes data from the past and uses it to change the PID variables for better control. The interesting part is that it does this over several different timescales - from a few minutes to a day or two. Then again, it depends on the periodic property of most HVAC applications. I highly doubt an EV will be very periodic. Best to stick to manual adjustment.

[dcb]

I wouldnt throw out dynamic entirely just yet.

Maybe this is obvious, but I would put a lot of weight in how fast the accelerator pedal actually moved.

You can get a fix on the ends of the problem anyway, such that if the pedal went from one position to another as fast as humanly possible then that is an "instant change" request. Whereas if the pedal motion acceleration is within normal "noise" for steady state cruising then take your time making any current changes and move to an average of the last x pedal readings. Then draw the graph for the intermediate accleration changes based on how quickly the gas pedal moved.

Edit: but it looks like paul is hard at work still, lets see if he found a combo he likes

[MPaulHolmes]

Paul is now making apple fritters. No longer hard at work. I had to stop right in the middle! I'm not going to be able to sleep tonight. That Kp and Ki are just sitting there, mocking me. I like the idea of the instant pedal vs. regular. I just may steal that idea and pass it off as my own.

NiHaoMike: My chip is comparable to what that one lady is using. 6 petaflops, 4 terraquads of ram, massively parallel architecture. It can add 1024 doubles simultaneously with a single SIMD instruction. Well... OK maybe it's a piece of crap from 1972. Quit picking on me! hahaha!

[blackpanther-st]

Originally Posted by dcb

I wouldnt throw out dynamic entirely just yet.

Maybe this is obvious, but I would put a lot of weight in how fast the accelerator pedal actually moved.

You can get a fix on the ends of the problem anyway, such that if the pedal went from one position to another as fast as humanly possible then that is an "instant change" request. Whereas if the pedal motion acceleration is within normal "noise" for steady state cruising then take your time making any current changes and move to an average of the last x pedal readings. Then draw the graph for the intermediate accleration changes based on how quickly the gas pedal moved.

Edit: but it looks like paul is hard at work still, lets see if he found a combo he likes

yes I agree, this is basically what I was getting at in my post a page or two back.

I think that part of the problem is that we are trying to get the controller to accommodate two very different driving styles.

That being said my personal preference would be to have a direct and instantaneous relation between throttle position and current output. To me any delay in response or mushiness is a loss of control; but I'm a control freak when it comes to driving, so what can I say?

For others that would be way to harsh and would feel jerky to the untrained foot.

----------------------------------------------------------------------

Thinking about this further and editing again, if the idea is to mimic the familiar response of ICE, (no, not the dripping; the throttle response) most engines have the trait, that they respond faster to throttle changes when the RPM is high, than they do when the RPM is low.

This response tapper, between RPM ranges, may be what we are missing to get that smooth yet responsive feel.