During the 70.3 World Championships last year, athlete Josh Amberger was staying with me. He received a tweet from @BestBikeSplit stating he was going to ride 2:15 on the Vegas course. Josh thought this was rather slow and a twitter discussion began. A few days later, Josh blasted off the front of the bike course and to his disbelief, he rode a 2:15 and @BestBikeSplit was right on the money. Naturally I thought, how did he predict that time with that amount of accuracy?
I got in touch with Ryan Cooper, the owner and the brains behind Best Bike Split, and he gave me access to a beta account of the Best Bike Split system. In short, I was really impressed. Ryan is a PHD mathematician that specializes in optimization mathematics. He’s the kind of guy who can do math that makes even engineering math look like simple addition and subtraction. By combining power data, rider aerodynamics, and course conditions, Best Bike Split can predict your bike split AND provide you with a section by section plan on how to reach that goal.
Naturally, we had to interview Ryan. Below are a series of questions and a walkthrough of how this amazing product works. I personally think this product has tremendous value, and that it can be very helpful to any athlete who uses it.
Q1. What is Best Bike Split?
Best Bike Split (BBS) is a web app that uses very detailed information about a race course, a cyclist’s equipment, power data, riding style, and race day conditions to develop the optimal power plan for an athlete to achieve the fastest possible time on a course while staying within target power ranges. It uses advanced mathematics to determine where on the course it makes sense to power up and power down to hit the best time for a given Normalized Power (NP) target. This power plan can then be output to several different file formats that are compatible with trainerroad.com (.erg/.mrc), computrainer(.erg/.mrc/.crs), and several Garmin devices(.fit), so users can train very specifcially for an upcoming race. The Garmin workouts can also be used on race day to give power range instructions throughout the race.
We have also created an advanced version of our basic web model. This model has been used in multiple case studies to predict times of cyclists and triathletes at various events with sometimes uncanny precision, although not always initially welcomed by the athletes (sorry Josh). This flavor of the model can be very specific down to roadside obstructions and is fast enough to run in near real time. This means that BBS could be possibly adjust time trial race plans from the support vehicle as a race unfolds due to a cyclist going out too easy, pushing too hard at various points in the race, or changes in weather conditions. It could also be used to help pick the optimal equipment for a specific course. It would have been interesting to use the model for the second time trial of this year’s tour where many riders switched bikes at the top of the hill. Turns out that it was probably the right thing to do, but it would have been good to run some “what if” scenarios prior to the race to have supreme confidence in the choice.
Q2. How did you come up with the idea for BBS?
In late June of 2013 there was a symposium called Math in Cycling (or something like that) streamed online from the University of Utah. It was a series of presentations seemingly catered to a small section of the slowtwitch crowd. While I was listening to one of the presentations a light went off. I’m a math nerd and a huge fan of cycling, so with the tour coming up I wanted to try to make a math model that could accurately predict a rider’s time based on power data, bike details, estimated CdA, weather details, and course data. My wife was 8 ½ months pregnant so I figured I had limited time to knock it out. I set the tours first time trial (Stage 11) as my deadline.
There were many late coding nights (and a few very early mornings with my new little son), but I completed the model and had a very detailed model of Stage 11 finished by about 2:00 am the day of the race. I had several CdA estimates for some of the favorite riders based on the frontal area pixel approach (and adjusted for various yaw angles). For power data, (hard to come by with pro cyclists) I used anything that I could find and verify. For Chris Froome, I used a target power of 422-425 watts based on a 405 FTP and the distance of the race (~19.6 miles).
So as I was watching the race, Tony Martin set the mark with a blistering split of 36’29 but it was fairly early in the day. By the time Froome started, the wind conditions had changed fairly dramatically. With the current conditions, our model gave a final time for Froome of 36’32, and had Froome ahead at the first two checkpoints only to lose the time back to Martin heading back into the wind towards the finish. It was a real Holy S#@% moment when the race actually played out that way. My wife and I just kind of stared at each other. I think I said something like, “math and physics freaking rock!”. So now I had this model, but I wasn’t sure what to do with it. In the mode,l I had broken the course down into roughly 50 segments based on gradient and direction changes but also road condition changes, roadside obstructions, and a few other things. I was reading slowtwitch later that day and stumbled onto a thread about Tony Martin’s race plan. Sure enough, Martin had the course broken down into 30+ segments with notes about each segment (pic below). I figured why not have the model show the ideal power targets for each segment, then take it a bit further by having a garmin file that gives an athlete the right power ranges for each section as they race.
Anyone can get lucky with a prediction once. I wanted to see if I could verify the model with a few more athletes. To do this, I shifted to triathlon where power data was a little easier to come by. I figured I would use a young pro named Josh Amberger as a test case. The guys at FLO have been talking about him for a few years now. After mapping out the 70.3 World Champs in pretty good detail in the model, (about 90 segments) I used Josh’s Buffalo Springs 70.3 power (with a bit of a bump) as a starting point. With the weather conditions predicted, we estimated a realistic time of 2:15 flat (actually a little faster but we rounded up for potential wet roads). We posted this up on Twitter and surprisingly got a text back from Josh saying our algorithm was off. We felt vindicated when Josh hit a 2:15:40 split the next day. Little did we know that he was staying with Chris (FLO) for the race! To his credit the course had changed a bit from the year before and everyone’s time was about two minutes off the previous year. He was a very good sport about it and in our last prediction using our more general model for the Noosa Tri, he beat our original prediction by almost a minute. We are in the process of writing up a Case Study discussing how we used Josh’s races to help refine the model.
|Josh Amberger’s Noosa Triathlon Bike Prediction / Plan|
Q3. So, How Does BBS work?
BBS has some very sophisticated math models under the hood, but what the end user sees are a few basic setup screens such as: Rider Data, Bike Data, Course Uploads, and Race Day Setup. Rider Data simply collects some basic information about the user (weight, height, age, training elevation, FTP, etc.) so the model can fine-tune future calculations. A user can set up multiple bikes or multiple configurations of a bike in the Bike Data section. On my account I have saved several configurations of my Speed Concept with different wheel/tire configurations. Most users will use the default values for rolling resistance and drag, but we do allow users to override these numbers if they have more accurate data or are lucky enough to have been in the wind tunnel.
My Bike Setup (Some FLOs on there for sure)
Once the basic data is set up, a user can either upload a course via a .gpx file or add an existing course from our course database. GPX is a fairly standard format that you can get from mapmyride or from garmin connect downloads. When courses are uploaded the system performs some very cool graph theory calculations to help smooth out elevation data. Elevation data can be tricky as some garmin devices are pretty unreliable, so we typically use “corrected” elevation data from several sources but are continuously in the process of looking for more accurate data sources. Some courses that we have in the database are marked verified, meaning we have verified the elevation data. Once you have courses uploaded or selected you can set up your race plans.
Course Upload Celtman (Crazy!)
Setting up a race plan is fairly straightforward. A user selects a course, chooses which bike they will race with, selects a general road condition (from really good to why are we even riding this), inputs the forecasted weather conditions, and finally adds IF (Intensity Factor or % normalized power) goals. There are also settings for several other power limitations (that could be set up using data from a previous good race effort). Once the race plan details are set up, the system will run the optimization algorithms to determine the ideal power plan for the course.
My 2014 USAT AG Race Plan Setup
The resulting race plan will map out the power segments for the course and give some basic data the model produced including estimated finishing time, average speed, average yaw angle, average power, normalized power, IF, and TSS. The system also outputs a specific power plan by interval similar to Tony Martin’s printed plan from the tour.
This can seem very overwhelming at first, but there are some cool things that we are working on to remove the thought process for course-specific training and for actual race day. For training and simulation, we provide four types of downloadable files. The first two file types, .erg and .mrc, can be used with a computrainer or can be imported directly into TrainerRoad. This is a great way to pre-ride your power plan for any upcoming race taking into account race day conditions.
The .crs file can be imported into the computrainer Racermate One software to pre-ride the course in a simulation mode. It will simulate the course gradients as well as the headwind/tailwind you will experience on the course.
The last file type is a Garmin .fit workout file. The workout file will give power range instructions on your garmin as you ride/race your course. Because garmin arbitrarily limits the number of total steps of a workout in garmin connect to 20, you will have to load the files to your garmin manually for now. Currently these file can be manually loaded onto a Garmin 500/10, 800/10, or 910xt. The actual devices do have a hardcoded limit of 50 steps, so all courses are reduced to 50 segments for these files. There is still quite a bit of testing to do with the Garmin outputs, but initial results have been very cool. The only real downside about this is that the garmin workouts are based on distance (lat, long flag points would have been better) so you will need to make sure you start the workout at the right spot and follow the course. I have tested the distance based workout on several courses with good results outdoors so far. We should know more about the accuracy as the season starts to kick off next year.
The following youtube channel shows a couple of videos detailing how easy it is to transfer the files to various training programs as well as specific Garmin Devices.
We have also developed an initial API for our cycling math and physics engine and are currently in talks with a couple of partners to build our technology directly into their products. I think the possibilities with additional partners like Garmin or Recon (with Jet) could be awesome for real time race planning, evaluation and adjustment.
Q4. Who is BBS for and how does it help them?
I originally designed BBS because I thought it would be a difficult challenge (had to relearn all my cycling physics) and I wanted to try to predict race times at the tour’s time trials. As I was building it out, I realized that it could be an awesome tool for anyone training or racing with power. The general model can help athletes of any speed or level figure out their best race day equipment choices, gauge what their bike split could be, and most importantly, help plan out their race strategy. Our advanced model requires very detailed input but can also be extremely accurate. This could potentially help pro teams/triathletes with very specific equipment selection, race planning/mid race adjustment, or even help evaluate the competition. I personally have been using it with Trainerroad to test out a few races I have planned next year and am addicted.
Our short term goal with BBS is to give athletes a tool to help them effectively train for and plan their race efforts while giving them a very good estimate of their finishing time. As mentioned before, we are also in the process of creating an API that will be available to hardware and software manufactures to make use of our optimization engine. We hope to announce some partnerships in that area soon. We are also available on a limited basis for consulting using our advanced modeling capabilities. When I start to develop something new I try to always create technology that I would want to use every day and figure there are probably a few more people like me out there that will like it, too. So far, this has been a really fun experiment and the current plan is to keep the basic web app available to the public for free. We are still in beta, but the site is open and everyone can sign up and see what they think.
I hope you have enjoyed this blog article. As always, please feel free to comment or ask questions below. We an even get Ryan involved in the conversation if you have questions for him.
Happy New Year!