So, you have good intuition about this problem. There are three components: the first, statistical to deal with "random" errors, second, functional to deal with "systematic" errors, and the third to do the calculations in "real-time" (or near real-time). Years ago we realized that in order to deal with the systematic errors, we'd need at least one additional sensor to measure air speed and yaw; though we also discussed back then an improved sensor to determine multi-axis tilt and possibly to detect accelerations related to changes in road surface. The second issue is statistical to deal with random errors where the error distribution isn't Gaussian (for example, wind speeds follow a Weibull). But I think we had a solution for that. So, we thought (and I think this has been borne out) the larger issue is getting the right sensor inputs, whence the Aerostick project (which *might* still be the only aero sensor that will detect yaw, though I'm not current with all of the newer implementations). The third part of that is the combination of all of that with the statistical bits into a real-time solution. Marcag might be able to tell you more about the issues with bringing a real-time device to market, but I suspect a key part of it is an occasional "anchoring" so you can reset and "zero" the estimate without, as you say, invalidating the entire run. In my original protocol I suggested using laps to anchor, but a subtlety that may have escaped some people was that I wasn't anchoring at just the start (or finish) of a lap: since you were going over the same damn road each time, I was using the entirety of the lap profile, as an anchor. That works for out-and-backs, too, which are degenerate laps. Since you seem familiar with control theory, you know that an occasional anchor makes the estimation a *lot* simpler. I could use the whole road as an anchor, and the Track Aero System sits in a velodrome so you get a constant anchor there, too. In a real-time device where you weren't going over the same road, you have to use sensor input (like from an altimeter or a gradiometer or an accelerometer or all three) and then you have to worry about error in those sensors, too. So that problem made my head hurt; and I have a day job, so I decided to put that off until I retire. But if you have ideas about it (and you seem to) then I encourage you to work on this problem and you can bounce ideas off me.

Thanks for summarizing the problem Dr. Chung.

I have to focus my time on aerodynamics, but I may tackle this project if I manage my publication goals before summer. When I do, I’ll be sure to share any progress or questions :)

Around here I'm "Robert." And, usually, people want to know the "how to do it" so it's nice every once in a while to be asked about the "why does it work."

One last thing about the real-time CdA problem. The first big use of the Kalman filter was for real-time tracking and control of a moving object. Before GPS, cruise missiles (especially ship-launched cruise missiles) had not-great accuracy and precision. Over water, they typically used an inertial guidance system and then when they got to the coast, they'd switch to a terrain-sensing and terrain-matching system to guide them to their target (as you can imagine, a lot of early effort in pattern recognition was related to this problem of figuring out how to kill people with flying weapons). The inertial guidance system over water was close enough to get them into the right approximate strip of coast (depending on how far away the launch was) then they had to do pattern-recognition to figure out exactly where they were (then they had to navigate over to where they wanted to be). So, in real-time CdA, if we're traveling over a previously unknown terrain, we can use sensors (including inertial ones) to get close but unless you have a unique anchor point you have to worry about drift. That's why real-time CdA on an arbitrary route is hard. However, by doing laps, the first lap is like going over unknown and featureless water, but every subsequent lap is now over a known and recognizable path. So that makes the real-time CdA problem much much simpler. The first lap is a "burn-in" and every second after that for every subsequent lap can be used for CdA and Crr estimation. At least, that's the way I do it. Maybe you can figure out something better, and that would be fantastic.

Interesting historical context.

I attended a talk just prior to the Covid lockdowns where the speaker (Prof. Michael S. Braasch, Ohio University) discussed control systems particular to maritime navigation. My question for him relates to the drifting problem, and I asked why not measure a system with known dynamics in a body-fixed reference frame (presumably with frequencies much faster than the drift error timescales). Their response was that such a method is coined “carrouseling,” and it has been effective for correcting inertial drift. Perhaps there is a non-silly adaption for this in cycling.

Sometimes on a long ride into a headwind, I’ll question what position is most efficient and by how much? I end up mentally calculating 30s avg power/velocity to make a guess, while trying different positions. In those cases I might not care what the true CdA is, only that it is locally minimal for my current conditions. So in my mind, I’d be happy to manually initiate a run on a stretch of road where I hope to have constant conditions, naively implying that any drift is error.

Very cool. I'd never heard of carouseling before but it looks like a way to perturb the gyros in a known direction by a known amount to check how the data are perturbed, and thus to calibrate the instruments on the fly? If so, that's very cool. We do essentially that with designed experiments. It's also related to the delta mass test I suggested a couple dozen posts above.

Those recent exchanges about filtering techniques and statistics were a bit beyond me, I’m afraid, but the discussions about real time CdA estimations reminded me of some attempts I made a couple of years ago to extract real-time CdA from a 10-mile time trial. I think it’s worth sharing what I did, even though it was unsuccessful, because it helped me to understand why the VE method works so well. In addition, I think it’s sometimes useful to share what doesn’t work, as well as what does.

It probably doesn’t need explaining to the people that follow this thread, but calculating real time (instantaneous) CdA is done simply by solving the power equation on slide 14 of Robert’s VE presentation to solve CdA using a measured elevation, instead of the usual procedure of guessing a value for CdA and then solving elevation. It did this every second, using the data recorded by my Garmin (barometric pressure and wheel speed sensor).

I didn’t have high hopes that it would be successful, but I was curious anyway and wanted to give it a go. The noise in the resulting CdA values was even worse than I expected though, with real time CdA values ranging from -1.4 to +1.0 m2! (see plots below). The average of the real time CdA data, over the 10 miles, was actually relatively good, agreeing with the CdA from my virtual elevation analysis to within 0.01m^2 (0.220 vs 0.213). The noise in the drag clearly makes it unusable as a real time drag extraction method though (with my setup and sensors).

What I realised is that the noise in the CdA calculations, to a large extent, comes from the poor precision of my Garmin’s elevation measurements, coupled with sensitivity of the CdA calculation to elevation errors. My Garmin elevation data has a precision of 0.4m (or at least I see 0.4m increments in its output). The high sensitivity of the real time drag to elevation precision is best explained with an example, assuming: Mass = 80 kg rider+bike, Speed = 45 kph, CdA = 0.217 m^2, CRR = 0.004, Power = 300W, Rho = 1.2 kg/m^3

In this situation, 252W is overcoming aerodynamic drag. An arbitrary 10cm increase (or error) in elevation over a 1 second period equates to a slope of 0.8%, is 78 Joules of potential energy (80*9.81*0.1) and is therefore 78 Watts that gets injected into the power balance equation. This results in a 31% reduction in the real time CdA ((252-78)/252) if speed remains fixed. Of course, if the elevation really did increase by 10cm, there would be an associated reduction in speed for a constant power, which would offset the potential energy change, and the CdA would remain the same. However, the precision of the Garmin barometer means that large elevation steps (40 cm in my data) were introduced into the real-time CdA calculation, causing the CdA spikes.

This sensitivity to elevation data can be mitigated by using longer sampling periods. Alternatively, or in addition, more accurate elevation data will help, and I know there are some folks like Pierre (Bugno) that are using more precise barometric sensors to help with this. The example above, though, shows it’s a tough problem. Even a really small 1cm elevation error would be a 3% drag change over 1 second.

As an aside, as part of my day job, I’m involved in predicting and measuring aircraft drag. For our flight test aircraft, mainly due to their higher speeds, the drag is one or two orders of magnitude less sensitive to elevation changes, so this is much less of a problem. But for us cyclists, it's really a challenge.

The beauty of Robert’s method, the way I see it, is that it disregards this instantaneous elevation data that CdA is so sensitive too, and instead calibrates to known elevation information over a longer time period, thereby elegantly avoiding this difficulty. Another alternative, of course, would be to ride a perfectly flat road like a velodrome. However, I’m lazy and would prefer to do my testing close to home.

For the people that have been involved in this community much longer than me, this may be nothing new, and I’m sure it has been tried by other people in the past, so please forgive me if this has been covered elsewhere.

P.S. I also looked at the sensitivity to speed errors, and there are errors coming from my lack of a wind sensor too, but this post is already too long!

Nice post Nick!

My understanding is that your 1s and 30s “real time” values are not employing any filtering techniques, Kalman or otherwise, but I’d say the 30s values are about as good as I’d expect in that case.

What I suggested (and you can run this on your existing data) is imagine you are TT’ing, and you initialize your averaging at the 100s mark where things seem more settled, but instead of 30s averaging let it accumulate indefinitely, and if no significant gusts (or position changes) arise, maybe by 1 minute you could see that the predicted value stays within a tight error band of what you may consider the “true mean”.

Try plotting the running average of CdA, starting from various points after 100s, along with something like abs(CdA_avg(i) - CdA_avg(i-1))... How close to zero can this get for your data, and does it behave nicely?

What I am not claiming is that it would be appropriate in varying conditions, but I think in such cases the value you get has a questionable definition either way.

Kalman filtering would help provide better, more rapid convergence by correcting the raw “estimate of states” given sensor errors (it figures out the most likely actual values, provided some assumptions aren’t too grievous, as Robert mentioned above).

I’m not sure how common it is for cyclists to review the time series data from wind tunnel tests, as what people receive tends to be up to what you request in commercial tunnels. But, the averaged values you get in a given “run” are derived in a similar (naive) fashion... the wind tunnel operators run a typical test article benchmark and see how long of a sample period needs to be taken to achieve a certain amount of “repeatability”. The time series data itself can be (read: will be) very noisy, with large variance as a percent of the mean value that clients get on a nice spreadsheet, even in a “steady-state” wind tunnel test. I have a feeling people think wind tunnel data is absent of this noise.

Very nice.

Yes, I think Pierre (bugno) uses a Blue Fly variometer, which has a nominal accuracy of 10cm but I suspect is much more consistent than that in second-to-second to reporting.

As I said, I kinda stopped working on "real-time" estimation because I would have needed additional sensors and my day job was beckoning -- but laps help there, too. If you take each second's estimated CdA and do the conversion so you can plot it by distance instead of time, you can get an estimated CdA for each point along the loop or lap. When I did this, one of the things I noticed was that for the test course I was using the estimated CdA was systematically high on certain parts of the loop and systematically low on other parts. What was amazing to me at the time was that there was a section of the loop where a couple of different things were happening: one was that there was a part of the loop that was less protected and more "open" to the wind, and a place where there was a corner and I slowed down a bit to make the turn (and thus, small errors in speed may have crept in). So I was getting a consistent bias in the measured CdA in the same places. That made me think that if I could ever find time to get back to this problem, this kind of systematic error pattern could be a good place to start.

Many thanks to both of you for those replies and suggestions. You're right, that I'm not using any filtering techniques, for no reason other than I don't know how to! There's a bit of reading I need to do about techniques like Kalman filtering I think.

I will try to have a play around with different averaging techniques like you suggested if I have time this weekend. As it is, at the moment the "30s average data" is simply obtained from the change of speed over the previous 30s, the change of elevation over the previous 30s, then with speeds and powers are the mean values over that previous 30s. So nothing fancy, and lots of scope to improve that I'm sure. You're right, I should have thrown away the data for the first 10-20s when I was standing up and accelerating on the base bars.

I'm in the same position as Robert though, that I'm not too optimistic about getting to a point when real time CdA can be obtained on a random road, where the forces are determined in this manner from a power meter. I did this more for curiosity. It'd be great to look down and have CdA updating every second or so on my head unit, but I'm not optimistic that's achievable with a method like this. Having said that, I don't want to be too closed-minded either, and maybe there is something that can be done with filtering, better sensors, or perhaps some way to accurately survey a road to gather very precise elevation data (as a function of longitude and latitude).

The plotting of CdA versus distance, instead of vs time, was something easy to do though, so I've just done that. You do indeed see some features in the CdA trace that seem to happen at a once per lap frequency. I was expecting to see some gradual oscillations in apparent CdA, due to my lack of an airspeed sensor, but there seems to be regular spikes and features on top of that (although it's possible I'm now looking too hard at it!).

Thanks! I knew there'd be somebody that has looked at this in the past, and in much more detail than me. Yes, perhaps it needs a separate thread, so sorry If I've taken things off on a bit of a tangent, but I thought it's interesting to highlight some difficulties of alternatives to the VE method.

Elevation data from barometers would be affected by, to some degree, the local airspeed at it's location. I'm sure you know this already and it might be what your were eluding to. I haven't worked out how significant this would be at the speeds we cycle at. Unless the barometer's pressure port is located at a position where the pressure coefficient is zero in all wind (yaw) conditions, which is probably difficult to achieve, it would need a calibration factor or equation to account for the suction or stagnation pressure increment with speed. On aircraft, it's not a trivial task to calibrate the static pressure measurements to give accurate ambient pressure data for all incidences, yaw angles, slat/flap settings etc.

I have no problem discussing it here if others agree. Or we can move it elsewhere. There is also an aerometers for dummies thread somewhere

Take an anomoly of the barometer say at 540s (see the dip?). Now go 30s later. When you calculate your average CDA, you will be using those 2 points, will get a very bad delta Elevation and your CDA will be way off. The very noisy part of your signal is mostly the barometer problem. The slower moving more cyclical error is wind. That is at a 100 feet level.


Bingo!

However if you know wind speed, wind direction and a few other data points, there are things you can do to improve it. If you don't rely entirely on the barometer you can do even more.

I mounted all these sensors on a drone, use sonar to get uber accurate elevation, and fly around the neighbourhood. Canadian winters, covid lockdowns and an amazon prime account make us do weird things.

It sounds like you’re doing some really cool stuff with the extra spare time we all have available at the moment.

Yeah, I noticed that too with my crappy elevation data. In my excel spreadsheet, it’s really obvious that those big changes in measured elevation are what’s causing the biggest spikes in CdA.

I've occasionally thought that combining accelerometers with brake sensors could be handy so you could separate out the parts of deceleration due to increasing drag that were intentionally produced.

We did put strain guages on a brake line. More maintenance headaches than value.

Cool. I said "occaisonally" because I think it possible that braking might be detectable in other ways, but I hadn't thought about the maintenance aspects. That's cuz I'm a theoretician so I don't actually build things. Hhmmm. To be more accurate, I should say "I don't build things that absolutely positively need to work."

I've been idly following news from BrakeAce, who are offering a brake power meter focused on the downhill and enduro market. If/when they ever go to a public release, if it can be mounted to a road or TT bike (disc brake only, though), and if they have enough interoperability to plug the data into AeroLab or a similar tool (big caveats, I know), I'd love to see if that opens up more possibilities for incorporating braking events as a known input. That'd mostly be a bonus, since my main hope is to use it for handling practice to be less bad at cyclocross!

I've tried to use the VE method to get some idea about the Crr and CdA of my setup before, but finding a suitable place and there not being much wind was tricky. But now I found a nice spot, in the woods, between two hills, with little traffic, and I spent some time during my last ride getting a baseline. This was in winter kit, with a pair of Decathlon tires that have 5000km on them, and a drivetrain full of mud, so obviously I wasn't expecting good numbers, just a baseline to compare against when I start swapping in nicer things.





This was a comparison of two positions. The valleys aren't perfectly level, but if I increase or decrease CdA by 0.01, their line ends up going clearly up or down, so that seems to be about the precision I can get. Would it be fair to conclude the difference between the two positions must then be less than this?

Teasing apart Crr doesn't seem to be possible from this, guess I'll need much bigger speed differences or a known elevation test.

Someone read it?

https://pubmed.ncbi.nlm.nih.gov/33590804/

Sorry, I didn't see your post earlier.

Yes, pretty much, if you increase or decrease CdA by .01 you should be able to tell the difference. However, CdA and Crr are related so when one goes up the other goes down. That means if you want to know the absolute values of CdA and Crr you have to be pretty careful about test protocols. If you just want to know if position 1 is slipperier than position 2, you can do as you've been doing.

I haven't read it yet.

I can't access full text but if anyone does I would be interested in reading it.

I skimmed through it. It seems to correlate ok according to their test, but they could not account for some rider specific offset, which probably makes sense if the probe is installed anywhere near the rider. It’s not a thorough study.

I don’t see what justifies this as a product for $600...

Interesting side note. I was thinking the other day that it should be possible to detect wind speed using acoustic analysis from a smartphone’s microphone, basically find peak frequency from the shedding off of a small diameter wire (use Strouhal number, and Fourier analysis), but it may be easier than that since there are microphone based anemometers that don’t require extra hardware, even some apps for ios and android.

I bet it would work well enough so that a simple stock android phone could do more than this device.

So get this... wind speed from microphone, camera-based wind direction from a simple weathercock device, we can get also get camera-based ground speed simultaneously (and steering angle if you’re ambitious). phones have gps already and inertial sensors, all we need is time, money, and will :) Also, remember this as prior art in case anyone tries to patent these things lol.

Nice. I've seen hot wire anemometers but this could be cool.

In the paper, they referred to another study that didn't get stellar results. That previous study had issues, mostly related to they configured and processed the data.

This study looks a lot better. But, they also refer to something they call velodrome mode. They mention it sets altitude to 0 which makes things a lot easier. They mention measurement of banking which would improve precision of results. I suspect, but do not know for sure, they probably turn off air speed as well, or at least can do some calibration. This makes the velodrome use case MUCH easier to get accurate results. Nothing "earth shattering" here. You would probably get similar results with Aerolab. Aerolab doesn't take banking into consideration. I suspect they made some features to make testing a little easier.

Turn back on altitude and airspeed, outdoor and it's a whole different ballgame. IF they get that right, it's worth $600 IMO.