search

mutovis / control-software

Software design files for controlling the hardware from https://github.com/mutovis/hardware
GNU General Public License v3.0
0 stars 1 forks source link

the new gradient_descent MPPT algorithm doesn't seem to handle perturbations properly #15

Closed greyltc closed 5 years ago

greyltc commented 5 years ago

Making step changes in the amount of light on a device while using the new gradient_descent MPPT wasn't showing the algorithm track the corresponding Vmpp change as I expect.

greyltc commented 5 years ago

@rbrenesh, this should be solved in 6b2a0d085f8d8cea68e99a17ea03ada98d3b4e7d which I rolled into the v1.1.3 release (yay -S python-mutovis-control)

I've made a few changes to the algorithm to address this including adding a new parameter min_step (read about it here: https://github.com/mutovis/control-software/blob/master/MPPT.md)

I've also tweaked the default values so please let me know how this new MPPT is working for you.

I've also made some fixes and stability changes in the old MPPT algorithm in 06853af7e8cfc9aff5f2693a627859620435b6a7 so it should me much improved as well.

rbrenesh commented 5 years ago

New MPPT is working great, as long as I set the learning rate to 1. A learning rate of 10 causes pretty wild oscillations. Photos below from a crappy cell.

Learn rate = 10 Screenshot from 2019-04-09 17-07-36

Learn rate = 1 Screenshot from 2019-04-09 17-08-24

rbrenesh commented 5 years ago

I'm seeing weird behavior with a better cell (PCE ~ 16%). I'll play around with the algorithm a bit and if nothing works I'll open an issue.

Screenshot from 2019-04-09 17-36-45

greyltc commented 5 years ago

that last one is a bit alarming. looks like the initial conditions were somehow very off. can you recreate this and if so, can you send me the full command you used to run the program when this was generated?

greyltc commented 5 years ago

I should also mention that the first 10 seconds of every mppt session (no matter what the algorithm is) is to dwell at whatever I think Vmpp is for 10 seconds. Then after that 10 seconds the actual tracking algorithm turns on. The tracker should begin at Vmpp. So seeing the discontinuity here at 10s probably means there is a bug. Then as the algorithm runs, it drives power to zero (or below)? Could you have used a negative learning rate here or something?

I choose Vmpp for the start of the tracking algorithm to be whatever the voltage was when the power was at its maximum from an IV sweep that may have been done on the device previously. If no IV sweep was done then I think I take 0.8 of the Voc or something as Vmpp.

The fact that the tracker tracks the power all the way down to zero (then "bounces" off it) is also something I've never seen before. It looks like probably there's an abs() in my power plotting or calculation code that is causing it to show negative power as positive.

So anyway, I'd really like to be able to recreate and study this because I think it shows some problems I should fix.