I’d like to open the idea of some objective testing of Zwift’s ride dynamics. Under the Zwift Community Test Labs aegis?
As an example, we might choose a course with with flats and moderate climbs and run robo-rider tests:
- Constant power - single rider. Examine the effects of terrain on speed for 50, 75 and 90 kg riders.
- Constant power - in draft. Examine the effects of terrain on speed for 50, 75 and 90 kg riders.
- Constant speed - single rider. Examine the effects of terrain on power for 50, 75 and 90 kg riders.
- Constant speet - in draft. Examine the effects of terrain on power for 50, 75 and 90 kg riders.
- Draft vs Double Draft - Measure the difference in power and time required for a single rider to catch
Single Draft and Double Draft blobs form 20 seconds back.
It seems to me that the single rider tests ought to be relatively easy. The pack tests harder - perhaps much harder.
You mean like this:
@Eric_Schlange_ZI has done a bunch of tests (e.g., rider weight, rider height, wheels, frames, etc.,) over the years.
Also, I’d imagine Zwift do all these sorts of things internally to validate the various algorithms.
Right. I commented on that article as well. I thought of this from working the JBT on Sunday.
I’m asking here because we get lots of questions in the Herd and I like hard data rather than opinion.
Robert Chung of Berkeley has used the GoldenCheetah AeroLab with Zwift. The key is to avoid drafting and avoiding standing (which might potentially change CdA).
To use GoldenCheetah, you export your ride as a FIT file, and load that into GoldenCheetah. I helped work on the GoldenCheetah code years ago, for CP/AWC analysis, but this stuff is newer.
The way the “Chung” method works is you ride a closed course then adjust the CdA and Crr so the modeled elevation profile of a closed loop doesn’t gain any elevation. He designed the method to work outdoors, where it works well but conditions are constantly changing. In the Zwift world, however, the data tend to be very clean.
Here’s a screen shot he took comparing Zipp 404 wheels to “stock” wheels. The “stock” wheels were essentially the same added power as adding 5 meters of climbing per lap (20 meters / 4 laps). The model parameters result in an excellent match of the actual profile to the modeled profile for the Zipp wheels. He could then move the slider for CdA to match the “stock wheel” portion and he could directly compare CdAs.
Here’s his Facebook post:
Here’s an example. Green line is the elevation profile, white is the virtual elevation profile; first 3 laps were with the 404’s, the next 3 were with the stock wheels. I didn’t hold constant power or constant speed – in fact, there were a couple of places where I coasted, and a couple where I sprinted. Even so, the calculated virtual profiles match the “actual” pretty well so it means my physics model and theirs match pretty well too. Compared to the 404’s, the stock wheels make it seem like the last 3 laps were uphill, i.e., they had higher drag.
I have been using GC for a few years and never knew this. One more thing for me to play with.
Did you see that you can now link GC to Strava.
I didn’t know that. I stopped using a power meter on the road years ago because I wasn’t racing anymore and wasn’t interested in spoiling a fun climb getting depressed over how little power I was producing. Unfortunately it can’t be avoided with Zwift :). I basically just started logging my data on Strava directly. I remember how much power I produced when I raced and… sigh. But I mostly run now.
This is sort of the opposite of what I’m looking for in that it takes virtual world inputs and computes Zwift data. I’m looking for Zwift world responses to constant inputs. The purpose is more to build a data-driven answer to newcomer questions about group rides. I have lots of personal data points but so long as what I say is based on anecdotal observations, the answer can be, “well that’s you but why to I have to work so much harder.”
I’m not sure what question you’re trying to answer. What aerolab does is to produce an equivalent elevation profile based on assumed model parameters. So suppose I ride solo, then sit in a group, then ride solo again. You tune the parameters to give the proper elevation on the solo bits. Then you’ll see the group ride is losing altitude. This is because in that section, power was too low for the speed, so the conclusion of the model is you must have been descending. Or the opposite: if you tune the parameters for the group ride (which won’t be constant, since draft changes, but at least you can crudely match the profile) you can see how much CdA was reduced, and the solo sections will appear as elevation gain.
I don’t know how constant power data are generated: an emulator? But it’s easy to go out and ride solo around a mixed terrain course, then plug the data into AeroLab for parameter modeling.
Hmmm. This was originally in the Club Jarvis forum, at least that’s what I’d intended. We’ve had rides there with robotic leads at fixed w/kg.
As a ride leader, I found it fascinating just how tricky it can be to stay on that beacon’s wheel even in the desert.
Our group generates hundreds of confused questions - no exaggeration - a year about group riding. We have our own answers, refer them to ZwiftInsider and GPLAMA and so on.
What’s lacking is something definitive based on Zwift’s numbers on what happens to that fixed pace rider’s speed in and out of the draft as the avatar moves over mixed terrain (and surface). The same with fixed speed v w/kg. Does AeroLab have access to Zwift’s parameters?