Those of you that follow this blog from some time ago know that the development of an accurate bike model was one of my main objectives. From the first model that I presented here (very similar to the one that is used by analyticcycling.com), passing by a second one that was richer, I have tried to increase complexity progressively to give answer to some questions that, to the best of my knowledge, nobody has answered. Those questions appear regularly in bike forums without a clear answer, showing that there is still job to be done to explain properly the link between the traditional methods for quantifying bike performance and how a bike behaves in real world. Bike design and construction have improved enormously in the last few years and I think that the effort done to explain scientifically how those improvements are beneficial to the consumer isn't enough.
After those two simpler models, I decided to devote more time to the development of the dynamical model. It started with a tire model able to handle discontinuous contact. Later, I tried to build the whole system around this tire model without success so I decided to step back and add elements to the model progressively.
A virtual ergometer was the first sub-model built. Everything worked flawlessly until I decided to include the elastic couplings between the torso and the bike (arms and saddle) so that feature was removed. Next, the bike-wheels sub-model was built with better results so I only needed to merge those two models. Once again there were problems so I have to calculate saddle loads using the virtual ergometer and use those forces as input in the full model.
I have to say that this trial and error procedure is really frustrating. When you spend some days/weeks gathering all the data needed to add a certain element to the model and integrating it and finally the software fails to solve and it doesn't give a meaningful explanation to the error, you want to give it up. I could have used other solving procedure and maybe this would have speed up the process but I also value all the things that I have learned finding the limits of the solver. For example, a dynamics program (Adams, Working Model or SIMPACK) could have done the job but I doubt I could have integrated the most complex and interesting features.
It's isn't perfect yet but I think that it is accurate enough to give some interesting answers for the future direction of bike design.
A quick animation. Take a look at how the BB and the chain moves during the downstroke ;)
More soon. Thanks for reading!
Hi, have you thought about open sourcing the code (in whatever language it is??) to github?
ReplyDeleteHi Aralo,
ReplyDeleteSystem of equations (obtained applying Newton laws) is written manually in MAPLE (not MAPLE Sim) and solved using its DAE solvers. Coding-wise there isn't a lot to show. The name of the solver is MEBDFI, it's capable of handling up to 3rd order stiff DAE problems. There is a Fortran version available in the following link if you want to take a look: http://www.dm.uniba.it/~testset/solvers/mebdfi.php
I have spent a fair amount of time tuning every aspect of the model so I don't want to share it as freely. Moreover, I plan to cotinue improving it. Nevertheless, I will write some posts about how I've modelized the most important features to encourage debate and illustrate anybody that want to take up a similar project.
Greetings