Simplified Route to Wind Generator MPPT
Disclosure
I have not implemented the following in a wind generator; I have not even built a wind generator yet (I'm still searching for a semi-permanent resting place). In the meantime, I'm working on a microcontroller-based solar MPPT and dump load controller; I figure that it's better to work out the kinks of a buck converter with solar before I unleash the wind on it.
WARNING: I'm long-winded, there's no pictures, and there's a fair bit of math as well.
Preamble
There's a significant difference between MPPT (maximum power point tracking) with solar and MPPT with a wind generator.
With solar MPPT, it's common to vary the controller duty cycle around the current point to find the maximum power. While the actual implementation is more complicated than this, this is the basis of the Perturb and Observe algorithm that is usually used because it works tolerably well.
With a wind generator, because of prop inertia, if we perturb the controller with an increase in duty cycle, we will always get an immediate increase in current, resulting in a runaway feed forward loop. To get around this, we could:
- Slow down the response rate to make sure that the prop inertia has settled each time before making another adjustment. This is fine with a constant wind speed, but responds very poorly to gusts.
- As above, but continually measure the rotor response (i.e., not just RPM but also acceleration) and adjust the time step accordingly. This is a lot of development work to make sure it works for a reasonably wide variety of wind generators, which I'm not prepared to do anytime soon. I think this is what Midnite Solar has done; kudos to them, but I want my own controller, and don't want to pay that much for it.
- Make like the big boys and record wind speed, direction, gear oil temperature, etc, and develop a complete operating profile. Note that large wind generators do not implement MPPT; the operating parameters are set based on complete state measurements (and calculations). The end result is the maximum power point (second to robust dynamic control) for the conditions because of their very accurate operating profile, but direct feedback to get to the MPP is not involved.
- As above, but make do with just Battery volts, RPM, and a far less complete operating profile. This is my choice !
A simplifying assumption of MPPT for wind generators used here is that we are trying to make the TSR constant and equal to what we designed the blades for, and this will give us our MPP, or close enough.
Enter Microcontrollers
A microcontroller makes it pretty easy to find the relationship between RPM, battery volts, and duty cycle without using current as feedback. Well, that's a bit misleading; it uses current but it is a calculated current from both sides that cancels out when the two equations are set equal.
As you'll see below, it ends up being 2 multiplies, a subtraction, and a division for the microcontroller to figure out the duty cycle from RPM and battery volts. Even an 8-bit microcontroller could do that sequence in double precision floating point hundreds of times per second, so the response time should be as good as we want it to be.
Why would we want to do it this way ?
The advantage of using RPM instead of current is that we're not trying to maximize RPM (other than wishing the wind would blow harder !).
Consequently, there is no feedback loop; there is a defined duty cycle for each RPM (varied by the battery volts). We don't have to worry about P, PI, PD, or PID controller algorithms and tuning them to get the best response, which means dealing with the varying time constant and incorporating that into the tuning.
Caveat
This method will not work if you don't know the parameters of your wind generator (for example, if you [horrors !] bought it). However, you could measure them, probably guess well enough to make it work, or use trial and error.
In practice, this means that certain constants would have to be set in the firmware (software) to make the controller work for different wind generators, which I do not see as a problem since current microcontrollers have re-writable flash memory that makes this pretty easy, even in the "field".
If the parameters you enter are a little off, the TSR may be a little off, but it shouldn't be enough to reduce the power significantly. The most significant parameters are V/RPM, which can be very accurately measured by the microcontroller by unloading the prop for a second and reading RPM and volts simultaneously, and design TSR, which should be readily available.
It's not that intuitive, but even if the value for Cp is way off, you will still be very near the MPP; the current will just be a lot different than expected. Remember that the current cancels out of the equations, but there is a small residual effect because the line and generator voltage losses will be slightly different if the current is different than expected. The same can be expected if the line and generator impedance values are a little off.
Derivation
Definition of Terms
rho = density of air
V = wind speed
D = prop diameter
Cp = efficiency of prop (relative to 1, not 0.593)
Vrpm = open circuit volts / RPM
Voc = generator open circuit volts at a given RPM
Pp = power output by the prop
I = current from the generator to the converter
Zg = impedance of generator
Vgl = generator volts lost to impedance
Vg = generator volts under load (Voc - Vgl)
Pg = power output by the generator
Zl = impedance of line (from generator to converter)
Vll = line volts lost to impedance
Vl = line volts at converter (Vg - Vll)
Pl = power at entry to converter (after line losses)
Vb = battery volts
duty = converter duty cycle
Simplifying Assumptions
- The converter efficiency is 100%
- The rectifier efficiency is 100%
- Air density is constant
- Cp is constant
For completeness, both converter and rectifier losses could be added to the line and generator losses, if desired, and the air density could be left as a variable and calculated based on the temperature. In practice, the rather broad TSR plateau will allow these to be neglected without affecting finding the MPP; i.e., even though the actual power may be less than calculated (or more, if it's -30 C !), it will still be the maximum power available, or so close it doesn't matter.
Also, Cp could be varied with RPM to approximate it varying with wind speed (although it really doesn't vary much in the useful power band), but let's look at the forest first.
Meat of the Matter
RPM = V * TSR / (pi * D) * 60 => V = RPM * pi * D / TSR / 60
Pp
1/2 * rho * V^3 * pi * D^2/4 * Cp
Voc = Vrpm * RPM
I = Pg / Vg = Pp / Voc (non-intuitive, but work it out)
Vgl = I * Zg
Vg
Voc - Vgl
Vll = I * Zl
Vl = Vg - Vll
For a buck converter,
Vb = Vl * d => d = Vb / Vl
For a boost converter,
Vb Vl * 1 / (1 - d) => d = 1 - [1 / (Vb / Vl)]
The important thing is to calculate Vb / Vl; then we can calculate d whether for a boost or buck converter. The following assumes a buck converter, but the method would work for either.
Working backward,
duty = Vb / Vl
= Vb / (Vg - I * Zl)
= Vb / [Voc - Pp / Voc * (Zl + Zg)]
= Vb / {Vrpm * RPM - [Pp / (Vrpm*RPM)] * (Zl+Zg)}
= Vb / {Vrpm*RPM - [(1/2*rho*V^3*pi*D^2/4*Cp)(Vrpm*RPM)] * (Zl+Zg)}
= Vb{Vrpm*RPM-[(1/2*rho*(RPM*pi*D/TSR/60)^3 pi*D^2/4*Cp) / (Vrpm*RPM)](Zl+Zg)}
It looks daunting, but since the only things in the above equation that are not constants (or very close to being constants) are Vb and RPM, the calculation will end up being:
duty = Vb / [RPM * (C1 - C2 * RPM)]
where
C1 = Vrpm
C2 = 1/2*rho*pi^4*D^5*(1/TSR)^3*(1/60)^3*(1/4)Cp/Vrpm(Zl+Zg)
= 7.27e-5 * D^5 / TSR^3 * Cp / Vrpm * (Zl + Zg)
Implementation in "C"
/********************
Definitions in header file
Note that we could implement these as variables in the
function, but by using '#define', they will be pre-
calculated by the compiler pre-processor, and the
microcontroller doesn't have to do it on the fly.
*******************
#define D 4.5 /
in meters (~ 15 ft)
#define TSR 7.5
#define PI 3.1416
#define RHO 1.29 / kg / m^3 @ 25 C
#define C_P 0.42 / YMMV !
#define V_RPM 0.65 / 48V Gen, optimized for MPPT
#define Z_G 1.2 / Ohms
#define Z_L 0.3 / Ohms
#define C1 V_RPM
#define C2_1 0.5 * RHO * PI * PI * PI * PI
#define C2_2 D * D * D * D * D / TSR / TSR / TSR
#define C2_3 1.0 / 60.0 / 60.0 / 60.0 / 4.0
#define C2_4 C_P / V_RPM * (Z_L + Z_G)
#define C2 (C2_1 * C2_2 * C2_3 * C2_4)
* The minimum duty cycle is application-specific; it keeps
the prop from turning too fast and will start inducing
stall just like a directly connected wind gen, just at a
higher (selected) RPM. It's approx. (RPM @ cut-in) /
(~20% less than desired max RPM). This is definitely a
trial-and-error number that will vary with your furling
implementation and generator efficiency.
#define MIN_DUTY 0.35 /
~ 300 RPM @ 53V
/*******************
Function windGenDutyCycle
Execution is less than 1 ms on an (8-bit) AVR at 8 MHz, and
could even be done effectively on a PICaxe, Basic Stamp, or
Arduino (I prefer bare silicon myself).
*******************
float windGenDutyCycle(float rpm, float Vb) {
float duty;
duty = Vb / (rpm * (C1 - C2 * rpm));
/ A duty cycle greater than 1 is physically impossible,
/ so limit it to that. This will occur at RPMs below
/ cut-in and is equivalent to a direct connection.
if (duty > 1.0) return 1.0;
/ Also limit it to the MIN_DUTY as above.
else if (duty < MIN_DUTY) return MIN_DUTY;
else return duty;
} /
Yep; it really is that simple !
Comments ?
