Pack Dynamics Test Events (December 2022)

Hi all,

David will be along in a moment to provide additional details, but I’ve just put 3 races together on Friday which will use the latest incarnation of PD4.

All found here: The at Home Cycling & Running Virtual Training App

6 Likes

Ok, so to kick off another round of PDv4 test events I would like to give a more detailed description of how the system works in order to avoid more guessing and speculation that leads to false information being spread.

For the ones that are not familiar with PDv4, essentially the goal is to improve on the current pack dynamics system to try and fix a long existing issue which is the “automatic” relay of riders at the front of a pack, even without actively putting effort to pull the group, which leads to excessive pack speeds.

How the system works?

The core change behind PDv4 is the application of auto-braking when travelling inside a group in order to reduce automatic forward movement. If for some this sounds strange, the idea is to mimic what also happens inside IRL pelotons where if you are inside a group a lot of times you have to tap the brakes so you don’t crash into the rider(s) in front of you.

Rules for the auto-braking

Auto-braking will be applied if:

  • The amount of draft savings exceeds a certain threshold (this threshold is variable according to the gradient. For instance, it is set at 38% for flat. These thresholds are configurable server side, but there is no point in detailing the values given that they are not visible for you in the HUD. Maybe something to improve in the future…)
  • AND your speeds exceeds the speed of the bike in front of you
  • AND your power drops below your last 10 sec. average power (signalling you are slowing/relaxing).
  • AND your power does NOT exceed X% above your last 10 sec. average power (currently X is set at 110%. It can be changed if needed).

So to put it in simple terms, if the system detects you are “relaxing” your power but your speed is above the rider in front in HIGH draft situations, it slows you down.

Other situations:

  • If you are travelling at a much higher speed then the rider(s) in front of you, you will never get auto braking. Currently the limit is set at 3km/h (it can be adjusted).

Double Draft
The previous system contained double-draft active by default. This time we decided to turn it off by default in order to have the option to turn it on or off. However, for the first few test events we will be setting double draft ON.

Visual Feedback

One natural complaint from previous tests is the lack of visual feedback. To improve on that we included a visual queue every time auto-braking is being applied when you are inside a pack.
The power number of the top left corner of the HUD will turn red whenever braking is being applied. That way you can decide your actions based on that:

  • If your goal is to continue in the group and you see auto-braking perhaps you can just relax more and trust the draft in order to save energy.
  • If you see auto-braking but your goal is to be aggressive at that time, perhaps it’s time to accelerate and move up, either to break away or position yourself more to the front, for instance in the last moments of a sprint finish.

This visual feedback can also be easily turned on/off, so if we find that it’s more harmful than good we can easily turn it off.

Other concerns

Is the auto-braking some sort of draft lock?

It’s not. After the last round of events, and from the feedback seen here in the forums there was some concern around this system, like if the auto-braking was some sort of “tight lock”. It’s not, and you will see that with the visual feedback of the red power numbers.
Besides, the previous version contained a bug that made the system much slower to respond causing a bad experience in a lot of situations. Hopefully that will be sorted now.

I’m doing an all out sprint to the finish, maybe I get braked?

If you are in a position where you have mostly a clear road or riders not in a tight group formation, that is almost impossible. Unless you are boxed in a tight group the amount of draft savings won’t be enough to trigger it.

Current limitations

Currently the downhill experience might not yet be the best in terms of the speed reduction we are looking for. We need to test and adjust accordingly based on feedback.
Or, maybe I could be wrong and it’s already good enough :slight_smile:

15 Likes

Good info. It will be much easier to discuss when both sides know more about how it is implemented. Less guessing. I’m looking forward to more tests :slight_smile:

The 38% percentage threshold you are referring to - is that the same number (Draft) we can see in Sauce4Zwift?

1 Like

Good question about the draft percentage because I think in a sprint finish situation, all of these criteria could be met. High speed, therefore high draft (according to Sauce), while having a higher speed than the bike in front of you, and decreasing power because you launched your sprint too hard and are fading slightly. Sort of seems like a recipe for getting auto-braked based on the described criteria.

That said, @DavidP I thoroughly appreciate the full description of how it works and look forward to testing it!

The 38% percentage threshold you are referring to - is that the same number (Draft) we can see in Sauce4Zwift?

No, that’s not the one. I believe Sauce shows a measure of total draft. But surely they are correlated, just not the same number.

2 Likes

@DavidP, thanks for all the work you and your team have been putting in to improve the user experience, as well as being so responsive to feedback. I’m really looking forward to Friday’s test.

Quick question about the power dropping below the last 10s average. Is that a percentage below, or is it absolute? Just wondering because of sprints. The benefit, it seems, will be to stifle the riders who love to do the “pulse and glide” BS.

It’s a configurable percentage below. Currently it’s set at 1%.

1 Like

How do you handle situations while trying to grab back onto a blob as they stretch out? This was a huge problem in the first round of testing. Below are the criteria and my comments - The scenario is you are going all in to catch a pack that is 6-10-15m ahead and crumbling. So in the scenario where I am trying to grab a pack that is slipping away I was hitting the full scenario of auto-braking and just getting ripped out the back. You could visually see my speed drop while I was out of the saddle at 500+ watts. I think there needs to be some threshold of power to overcome the autobrake in this scenario.

EDIT _ This autobrake could also happen in a long sprint. If you sprint > 10 seconds and fade power then it assumes you are relaxing and will brake you if you are catching the wheel in front of you.

  • The amount of draft savings exceeds a certain threshold
    YES My draft is higher because I’m still in the group of riders stringing out the back.
  • AND your speeds exceeds the speed of the bike in front of you
    Yes - I’m trying to move up thru the pack so I’m faster then the bike ahead of me.
  • AND your power drops below your last 10 sec. average power (signalling you are slowing/relaxing).
    YES - I sprint hard to accelerate (8+ w/kg) then settle in at 5-6 w/kg… NOT Relaxing but definitely dropping power over 10s.
  • AND your power does NOT exceed X% above your last 10 sec. average power (currently X is set at 110%. It can be changed if needed).
    YES - See previous bullet.
3 Likes

There is a fundamental difference now:

AND your speeds exceeds the speed of the bike in front of you

This part was not working well before, causing a lot of weird behaviours. That effect you reported shouldn’t be the happening this time, and if it is, we need to go back to the drawing board.

My draft is higher because I’m still in the group of riders stringing out the back.

Besides, when you are in single file, it’s difficult to reach the necessary draft thresholds. You need to be in a more tight group.

1 Like

Thanks for the additional feedback. Hopefully the tweaks help this scenario.

as you know the website events interface is garbage… what route is this on?
I see it is one lap, 25 miles… picture looks like Neokyo?

Thanks!

Makuri 40

1 Like

wouldn’t it be great if you didn’t need to look at a 3rd party website to find that crucial information :wink:

Wonder if anyone has mentioned this before :thinking:

5 Likes

smashfest out the gate then to hold the main group uphill for the first few k :nauseated_face:

2 Likes

Oh good, it’s not just me, I was wondering where the route info was from that link - spent about 5 mins looking for it before giving up - Makuri 40 is a great route, some good opportunity for me to get dropped multiple times :slight_smile: Will see if I can make the 11am PST version of the ride.

Glad to see more test events on the calendar!

Very excited to see how this UX element works, I can see this making racing much more engaging actually, and help people trust the draft a bit more, and make more explicit decisions when to move up the pack - will be fun to try it out. Not sure if you’ll eventually run into accessibility issues from folks who have certain color blindness - you might need to bold the numbers when they go red (or have the numbers go into a different font -italics- or something etc…) before it goes fully live if that does turn out to be a problem, but either way it seems like a good thing to try out.

1 Like

Sneak peek

8 Likes

For the colorblind, instead of the red numbers there could be an auditory cue…like Matthew McConaughey saying “alright alright alright” or something equally non-intrusive.

3 Likes

Thanks for the very helpful post and the addition of the visual cue.

One question I have; in the previous iteration I believe there was a rule that autobraking would never be applied on an incline above 1-2%. Is that rule still present, or is the draft% tied to gradient?