Aerolab 2.0

Hey ST,

I certain amount of momentum has been gathered and an Aerolab 2.0 project has been kicked off. Mark L got a bunch of aero-nerds together and has started the requirements/ideas process. I plan to contribute any combination of ideas, code, testing and data. Whatever he needs.

I thought it would be a good idea to ask the ST community.

For those that have used Aerolab, what would you like to see ?

For those that tried and didn’t succeed, what happened ?

For those interested in how it progresses, maybe post here so we get an idea of interest. If there’s interest we can keep this thread going with progress updates.

Thoughts and comments welcome.

Thanks for kicking off Marc,

To let folks know, it will be a total rewrite, so nothing is off the table- small or large.
We are working towards a totally new GC v3.6 for next Summer with everything modernised and a UX that makes GC best in class…

Cheers
Mark

gc36rewrite.png

I think it already uses airspeed, correct?

I’ve mentioned this a few times on here…

  1. Peg a turn (out-back course) using rider heading, then use the odometer to mirror-image the run. Besides allowing #2 it lets you specify the part you want to analyze, cut out the turn, etc.

  2. Analyze a set of runs to create an accurate elevation map of the course.

  3. Perform CdA analysis with elevation as a known. Great for error checking and refinement… variable CdA with location, yaw.

I’d like a Web app rather than a monolithic desktop application. Easier to use in the field (like CrrCda is). Platform agnostic.

I think it already uses airspeed, correct?

I’ve mentioned this a few times on here…

  1. Peg a turn (out-back course) using rider heading, then use the odometer to mirror-image the run. Besides allowing #2 it lets you specify the part you want to analyze, cut out the turn, etc.

  2. Analyze a set of runs to create an accurate elevation map of the course.

  3. Perform CdA analysis with elevation as a known. Great for error checking and refinement… variable CdA with location, yaw.

+1 to this

  1. Perform CdA analysis with elevation as a known.

It is a “known” in Aerolab, in the sense that it’s a measured quantity (the “altitude” field of a FIT file, as opposed to the calculated virtual elevation). Are you referring to using a “ground truth” (no pun) elevation vs. GPS/altimeter? Aerolab has this for known constant elevation (velodrome). How would ground truth be acquired? Some super high accuracy GIS service? Multiple passes with various different GPSes/altimeters to perform statistical modelling to reduce bias, increase accuracy, etc?

Full disclosure, I’ll hijack all these ideas for my (currently bare bones copy of Aerolab) aeroanalysis.org site. Though it’s fully free and open source, so anyone is free to take the source code.

I think it already uses airspeed, correct?

Yes, if the headwind column is populated it is used by Aerolab

I
I’ve mentioned this a few times on here…

  1. Peg a turn (out-back course) using rider heading, then use the odometer to mirror-image the run. Besides allowing #2 it lets you specify the part you want to analyze, cut out the turn, etc.

  2. Analyze a set of runs to create an accurate elevation map of the course.

  3. Perform CdA analysis with elevation as a known. Great for error checking and refinement… variable CdA with location, yaw.

Thanks. All noted.
In fact they were part of the initial gathering of ideas between the 9 smart guys and 1 not so smart guys.

Multiple passes with various different GPSes/altimeters to perform statistical modelling to reduce bias, increase accuracy, etc?

If properly done, multiple passes aren’t needed. However if multiple passes are done, it’s more data to refine the accuracy.

I’d like a Web app rather than a monolithic desktop application. Easier to use in the field (like CrrCda is). Platform agnostic.

Extracting it from GC is on the list of ideas.

Personally I love the idea.

But also love many of the features of GC that I do use when analyzing things. I also like all the plumbing for import, exports, mapping…

Anyways, it’s on the list

I’m talking about creating an elevation map from your data, not a separate measurement. You use the VE. I think you’d get much better fidelity if you did this at slow speeds and calm winds using several “laps”. Mirroring the out-back makes anomalies easy to spot.

Spend some time finding a good venue, develop the elevation map for it, and then that’s your test site. You can have several of them, but each will take a bit of time to sort out. The best venue will have a hill at both ends to make getting up to speed easier, and of course nil traffic. Ride near the centerline so you can calibrate the airspeed sensor with your runs.

I’m talking about creating an elevation map from your data, not a separate measurement. You use the VE. I think you’d get much better fidelity if you did this at slow speeds and calm winds using several “laps”. Mirroring the out-back makes anomalies easy to spot.

I’m skeptical that VE (as calculated via Chung) would result in a more accurate elevation map than simply using GPS/altimeter data. Because VE is subject to wind and rider input, both of which are hard to control.

I think it could maybe be worthwhile to do some sort of cross-validation of VE vs ME (measured E) by doing slow-speed traversals at zero wind. That way anomalies could be detected.

However I think part of the beauty of the Chung method is that you don’t have to really care about isolated anomalies that much - crap altimeter or GPS samples, power meter barf, or a rider slapping at the murder hornet that just went in his helmet. It’s the totality of the fit that contains the signal.

I am intrigued by high quality altimeters. For my day job, I tested a consumer grade one where I could move the sensor down by a foot or so above my desk and back down, and it could detect the difference in air pressure. I don’t think the stuff we get from Garmin/Wahoo is that good. But I haven’t tested them.

Edit: Chung did do some VE vs altimeter cross-validation here. (Palomar and San Bruno pages). But there’d have to be demonstrable benefit to establishing a baseline using constant-power, low-wind runs vs. just using what you have. Because more runs is a hassle.

I am intrigued by high quality altimeters. For my day job, I tested a consumer grade one where I could move the sensor down by a foot or so above my desk and back down, and it could detect the difference in air pressure. I don’t think the stuff we get from Garmin/Wahoo is that good. But I haven’t tested them. .

I’ve tested multiple sensors based on barometric pressure and a) they are not equal b) how you sample and filter them is critical c) there are conditions in which they do better than others. I get amazing results in my living room, on a high speed rolling hills is another story.

That’s where complementing one sensor with another comes in. In fact complementing one sensor with 3 or 4 others.

With more and more sensors becoming available, hopefully their capabilities will be taken in consideration in 2.0

And if you don’t have sensors, then yes, laps, out and backs will help construct the data.

Edit: Chung did do some VE vs altimeter cross-validation here. (Palomar and San Bruno pages). But there’d have to be demonstrable benefit to establishing a baseline using constant-power, low-wind runs vs. just using what you have. Because more runs is a hassle.

I’ve done some tests on the Bay Trail right next to the Bay. There’s less than a meter difference between the low and high spots over the course of 1500 meters. More interestingly, I was seeing a consistent little dip in the VE at a particular spot on the trail, whether I was going slow or fast or coasting or under power. The dip was just a few centimeters from the “flat baseline” but I could see it was consistently X meters from the start of the test run, so I went to the start, rode X meters, and looked down. There was dried sediment on the road right there. A couple of months later, after a little rain, I went back out there again. There was a little puddle of water on the road right there.

I’m not sure a normal GPS/altimeter would’ve picked up the puddle.

on a high speed rolling hills is another story.

I’ve had good luck in my day job, which is a military vehicle. Went up and down a big hill 20 times at high speed. It was precise, accurate, repeatable (by the navigational standards of the vehicle) This is with a $100 sensor (talking about just the chip, not the retail package) vs. I think the $2 sensors we get in head units.

Didn’t do any fancy filtering. Just Kalman filtering after doing some noise analysis on the ground truth hill.

I’m talking about creating an elevation map from your data, not a separate measurement. You use the VE. I think you’d get much better fidelity if you did this at slow speeds and calm winds using several “laps”. Mirroring the out-back makes anomalies easy to spot.

I’m skeptical that VE (as calculated via Chung) would result in a more accurate elevation map than simply using GPS/altimeter data. Because VE is subject to wind and rider input, both of which are hard to control.

Any error in elevation will show up as a consistent anomaly when you mirror out vs back. Looking for and correcting these anomalies will be part of developing the elevation map. Sure you can use other means to measure elevation, but the altimeter and GPS I’ve used are definitely worse.

if I understand correctly: “Any error in elevation will show up as a consistent anomaly” any change in a parameter should show up and a VE anomaly, and what you are saying is if the anomaly happens happens at the same location on the road it is likely an elevation anomaly? whereas other anomalies are likely due to some other issues hopefully the things you are testing? The Chung method is facilitating and I do believe you need to have a good site set up for it to work really well.

Edit: Chung did do some VE vs altimeter cross-validation here. (Palomar and San Bruno pages). But there’d have to be demonstrable benefit to establishing a baseline using constant-power, low-wind runs vs. just using what you have. Because more runs is a hassle.

I’ve done some tests on the Bay Trail right next to the Bay. There’s less than a meter difference between the low and high spots over the course of 1500 meters. More interestingly, I was seeing a consistent little dip in the VE at a particular spot on the trail, whether I was going slow or fast or coasting or under power. The dip was just a few centimeters from the “flat baseline” but I could see it was consistently X meters from the start of the test run, so I went to the start, rode X meters, and looked down. There was dried sediment on the road right there. A couple of months later, after a little rain, I went back out there again. There was a little puddle of water on the road right there.

I’m not sure a normal GPS/altimeter would’ve picked up the puddle.

I experienced the exact opposite. Van Fleet trail in Florida, not far from Clermont. Barometric altimeter said there was a dip on 2 different devices. VE said it was flat. IMU said it was flat. My eyeball said it was flat. I always thought there was a kind of “bubble” of pressure difference. It was repeatable but I never took the time to figure it out.

Yep, that’s about right.

This is with a $100 sensor (talking about just the chip, not the retail package) vs. I think the $2 sensors we get in head units.

But most people won’t have one of those…

Plus I think you underestimate how good the VE can be with anomaly-checking.

on a high speed rolling hills is another story.

I’ve had good luck in my day job, which is a military vehicle. Went up and down a big hill 20 times at high speed. It was precise, accurate, repeatable (by the navigational standards of the vehicle) This is with a $100 sensor (talking about just the chip, not the retail package) vs. I think the $2 sensors we get in head units.

Didn’t do any fancy filtering. Just Kalman filtering after doing some noise analysis on the ground truth hill.

If it’s commercially available let me know, I’ll buy one and compare it to ones I’ve tried.