Q re PowerMatch implementation (PID vs Alpha-Beta Filter)

[MyJunk Junk]

I & some others are looking forward to seeing some sort of powermatch happening so I thought that I'll go down this rabbit hole and see what I can make out of it.

So reading the wikipedia page on g-h filter (https://en.wikipedia.org/wiki/Alpha_beta_filter) and then trying out the sample program via google sheets (https://docs.google.com/spreadsheets/d/1lmv54RK98OCaxmoYTJifaNcM-pzx_UbVwhAFZyiL-Hs/edit?usp=sharing) , I'm confused as to how this algorithm is actually taking into account the target power (Smart Trainer Power) and the measured power(eg: Pedal PM). 

I've tried using the below for xm with a fixed Trainer Power and a fixed Pedal PM power but the result I'm getting isn't correct. (My expectation is that the rk value would end up as being close to the Delta Power) but it's not.

• measured power (pedal PM)
  
• target power (Trainer Power)
  
• Delta Power (Trainer Power - Pedal PM)
  

My expectation would be that the rk value would eventually converge to ~20w (which is the delta between Smart Trainer and Cycle PM)

In this screenshot, I'm using Trainer Power as the Measured power. 

I've also tried to use the initial vK being the Delta Power, but after the 2nd iteration, the delta is already replaced but the algorithm's estimated power.

While Mark's comment is that using the gh filter is the best for this scenario, I'm wondering why not consider the PID algorithm (which I've been reading and comparing between gh and pid). Power Match seems to me very close to a car's cruise control where you have a target speed, then you have the measured speed (actual speed) and the error being the delta between actual and target.

forking the discussion from this thread 

https://groups.google.com/d/msgid/golden-cheetah-users/2eea6869-6f9b-45d5-a106-94db7b86a9afn%40googlegroups.com

and 

https://github.com/GoldenCheetah/GoldenCheetah/issues/1789

[Mark Liversedge]

The PID controller looks pretty good to me, today is a learning day for me, I was not aware of this algorithm. Thank you for the post.

If you think it could be used we welcome patches, but will update the feature request to link to this post.

Thanks again

Mark

[MyJunk Junk]

Hi Hi....

(Part 1 of 2  - Message too long complain)

So I went down the rabbit hole and tried a variation of PID control using "cruise control" type algorithm.(link)

the kP/kI/kD parameters were chosen as 0.5/0.2/0.2

I was also looking at GpLama's video (<--link) on how he looked at comparing/getting the Kickr to use a 3rd Party Power Meter as a controller (P1 PowerTaps). But alas, I didn't know how to adjust my trainer's resistance, so I did it on my Cycle PM via it's app by increasing it to +15% (it doesn't give a fixed offset, so I have no idea how large is the offset in watts)

Data is below. So, on a 5min test ride, steady state, there's a 20w delta (Cycle PM - Target) to the target power.

This next data is obtained by turning on the PID loop. (Please note the comments within the picture. It is to be expected that the Trainer Power will reduce to the target). 

In turning on the PID Loop, this managed to bring down the delta from +20w to +6w (70% reduction in power delta). So, this is pretty good, I think.

 

[MyJunk Junk]

Part 2/2 

This 3rd set of data is me doing a 60m workout with a couple of target power increases. (I should have used my "powerMatch" workout (which is actually GpLama's workout from his view) but I wasn't feeling too strong today :-( )

NOTE: On this dataset, the CyclePowerMeter has been zero-calibrated and reset back to +0% power offset) [typically my data shows that my CyclePM reads about  ~6-10w higher than my trainer.

Anyways, now my average power to the target is ~1-3w for each interval. while I think that's pretty good, I do not have comparison data of how other vendors (TrainerRoad / Zwift etc) does their power matching. (I signed up for TrainerRoad acc, but then found out TR doesn't want to control my trainer)

What I dislike in the below however is the power variations. Is this acceptable?

Here's a plot of the sec-to-sec variation overlaid  w/ the target power at each interval. +5 to -15w of variation. When I looked at the data in more detail, on thing I noticed was, I believe the PID algorithm is driving this with possibly too large variations being sent to the trainer.

Here is another look. Focusing only on 1 interval at 102w Power Target (RedLIne)

Yellow is the Instant Power at that point in time.

DottedRed is the (new)Power Target sent to the trainer to control.

I think this is not optimised, anyone has any suggestions? Tune kP down from 0.5?  

Here are the files if anyone's interested. 

XLS in Dropbox (https://www.dropbox.com/s/mpgbi9o5s53f4dk/PM-adaptive%28forGC%29.xlsx?dl=0) - 13mb

Zipped XLS in Dropbx (https://www.dropbox.com/s/49wa2mzne174hk7/PM-adaptive%28forGC%29.xlsx.zip?dl=0) 5mb

[Ale Martinez]

El lunes, 2 de agosto de 2021 a la(s) 08:11:19 UTC-3, mjunk....@gmail.com escribió:

Part 2/2 

This 3rd set of data is me doing a 60m workout with a couple of target power increases. (I should have used my "powerMatch" workout (which is actually GpLama's workout from his view) but I wasn't feeling too strong today :-( )

NOTE: On this dataset, the CyclePowerMeter has been zero-calibrated and reset back to +0% power offset) [typically my data shows that my CyclePM reads about  ~6-10w higher than my trainer.

Anyways, now my average power to the target is ~1-3w for each interval. while I think that's pretty good, I do not have comparison data of how other vendors (TrainerRoad / Zwift etc) does their power matching. (I signed up for TrainerRoad acc, but then found out TR doesn't want to control my trainer)

What I dislike in the below however is the power variations. Is this acceptable?

Here's a plot of the sec-to-sec variation overlaid  w/ the target power at each interval. +5 to -15w of variation. When I looked at the data in more detail, on thing I noticed was, I believe the PID algorithm is driving this with possibly too large variations being sent to the trainer.

Here is another look. Focusing only on 1 interval at 102w Power Target (RedLIne)

Yellow is the Instant Power at that point in time.

DottedRed is the (new)Power Target sent to the trainer to control.

I think this is not optimised, anyone has any suggestions? Tune kP down from 0.5?  

Yes, PID controllers are easy to implement but difficult to tune, here are some guidelines for manual tuning: https://en.wikipedia.org/wiki/PID_controller#Manual_tuning

[andy aardema]

I've implemented PID loops in devices before and can confirm tuning is the hard part.

Here's a classic method for doing it:  https://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method

How fast can your trainer respond to input and adjust resistance?  I believe that will constitute your oscillation period (Tu).  You may need to pre-smooth the input if it's frequency is high compared to your control loop frequency (likely 1 hz), though that adds lag (i.e. phase delay) to the system and consequently error.

[MyJunk Junk]

Currently I think (feel) that once (a diff) resistance is applied to the trainer, it takes about 3-4 seconds before I start to feel it in the legs (eg: 100w to 300w). 

You are right, from looking at the data, my assioma per sec data is really noisy (which also makes me wonder if the IAV that it touts - https://cycling.favero.com/blog/tech-tests/whats-iav-power is really just making things more noisy, at least for my pedaling style). Thus, I am experimenting with, instead of sending the PID the instant power, I'm gonna send it a 5s moving average power which would at least smoothen the peaks and valleys more (at the expense of lag response (since most trainers can't adjust instantly anyways). 

However, I did also put in a condition that will remove/reset the smoothing if there is a SetPoint change (eg: 100->300w etc), so this will reduce the delay lag somewhat but it will re-introduce the noise.

(you are also right, it's a 1hz sample, I also checked the data from the assioma, tho the specs say that PM should transmit every 4hz, I seem to only be getting it like every 1hz. I didn't explore the code further to determine what's happening)

As for the tuning part, I did try (my own variation of) the ZN method (https://en.wikipedia.org/wiki/Ziegler–Nichols_method) but I figured that I'm doing something wrong. (esp since I'm off the bike and can't do any testing at least until possible end of this week) and just "modelling" it in Excel. 

So I guess this is an even more pertinent question. If the tuning is tied to the trainer/user, does this mean that diff trainer would need diff tunings? How does the auto industry Cruise Control does these sort of calculations?

Appreciate the thoughts/discussion.

https://math.stackexchange.com/q/4218924/953295

(in this below, the iTerm, I can't seem to get it down to zero, tho this is highly likely due to the way I'm simulating it)

[MyJunk Junk]

To update, I have abandoned the PID version of the algorithm. At least in my case, I am unable to get it to tune it to behave the way that I like it to. IN My case, there is just too much (input) data fluctuations unless the user chooses to use something like a 10second power average.

Hence, now instead of trying to set the target power based on the input data (and it's variations), I have chosen to instead Power Match based on offset to the target power. The result of this is shown in the below plots.

As of now, this looks fine since I'm in a "hot" country, I do not have to deal with issues where the trainer and power meter (might) have different temperatures and thus behave differently as it warms up.

Thoughts? Comments?

[Mark Liversedge]

On Tuesday, 24 August 2021 at 03:53:41 UTC+1 mjunk....@gmail.com wrote:

As of now, this looks fine since I'm in a "hot" country, I do not have to deal with issues where the trainer and power meter (might) have different temperatures and thus behave differently as it warms up.

I don't quite follow, temperature compensation will be performed by the power meter, so long as the coefficients are being adjusted continually this will be taken into account-- or have I misunderstood your point?

Mark

[MyJunk Junk]

On Tuesday, August 24, 2021 at 4:05:43 PM UTC+8 @gmail.com wrote:

On Tuesday, 24 August 2021 at 03:53:41 UTC+1 @gmail.com wrote:

As of now, this looks fine since I'm in a "hot" country, I do not have to deal with issues where the trainer and power meter (might) have different temperatures and thus behave differently as it warms up.

I don't quite follow, temperature compensation will be performed by the power meter, so long as the coefficients are being adjusted continually this will be taken into account-- or have I misunderstood your point?

I'm not entirely sure, but that was the comment which came from this post https://forums.trainerday.com/t/how-does-the-new-power-match-work/14/25 

...

Then the corrections became gradually lower because trainer and tire got to temperature.

...

(do note that the comment specifically was referencing tire, hence a wheels on trainer which may have introduced other issues)

[MyJunk Junk]

Sorry.. I also meant to say that I do not have a way to test for temperature influence (if any)

[Mark Liversedge]

On Tuesday, 24 August 2021 at 09:21:17 UTC+1 mjunk....@gmail.com wrote:

On Tuesday, August 24, 2021 at 4:05:43 PM UTC+8 @gmail.com wrote:

On Tuesday, 24 August 2021 at 03:53:41 UTC+1 @gmail.com wrote:

As of now, this looks fine since I'm in a "hot" country, I do not have to deal with issues where the trainer and power meter (might) have different temperatures and thus behave differently as it warms up.

I don't quite follow, temperature compensation will be performed by the power meter, so long as the coefficients are being adjusted continually this will be taken into account-- or have I misunderstood your point?

I'm not entirely sure, but that was the comment which came from this post https://forums.trainerday.com/t/how-does-the-new-power-match-work/14/25 

...

Then the corrections became gradually lower because trainer and tire got to temperature.

Ah, this is more an issue of calibration and initial warm-up before use- totally separate from power match- its part of the operating procedure for using press-on trainers like the old computrainer.

You do not need to worry about it- the user should take it into account regardless of whether they use powermatch or not.

Mark

[MyJunk Junk]

Ah.. got it.

[Mark Liversedge]

After the brief sojourn into PIDs etc I guess we are back to a gh-filter.

If you are still interested in understanding it, the first two chapters of this highly readable book will get you there:

https://reader.bookfusion.com/books/139327-kalman-and-bayesian-filters-in-python

No more than an hour or so to read and digest thru Ch2, it's a great book.

Mark

[Mark Liversedge]

Actually, for gh you really only need to read the first chapter, result !

Mark

[MyJunk Junk]

I took some time reading thru chapter 1 and I can't say I am truly enlightened. In my previous dabbling w/ gh filter, the issue I found was :

I've also tried to use the initial vK being the Delta Power, but after the 2nd iteration, the delta is already replaced but the algorithm's estimated power.

But reading chapter 1, I saw this little bit:

which seems to be the thing which I'm guessing I'm missing? It's to provide the algorithm a set list of measured power at the beginning as opposed to what I was doing which was feeding it the measured power at that time? I would believe there's (should be) more to it.

anyways.. 

[Mark Liversedge]

There are two measures here- the power meter and the trainer. We are trying to estimate the true power (somewhere between the PM and the trainer), then once we have that we can apply a coefficient to "uplift" the trainer load to match the estimate (hence power match).

We will need to decide how much weighting we give to the power meter vs the ergometer (g) and how quickly we think the ergometer adapts (h). These could be user definable or just hard code (we probably trust the PM and expect the trainer to change almost instantly. The estimate and associated coefficient will just get updated as each sample arrives (typically 4hz).

I would code this up but I no longer have a functioning trainer (computrainer in a landfill somewhere and lost the power supply for my kickr).

Mark