In Articles

The curious case of bike pitot tubes

Pitot tube on Kawasaki C1 plane.

Failure is always an option, so stop an unrealistic project before you put too much effort into it.

In the previous post, I outlined my plan to gather aerodynamic data for a moving bicycle without the need for costly wind tunnel testing. The idea was simple — use an anemometer of sorts to measure windspeed and plug it into an Arduino development platform to save it for live drag coefficient calculations or later analysis.

Expectations

ThrustSSC nose cone
Nose cone with pitot tube of ThrustSSC supersonic car (photo by Morio, CC BY-SA 3.0)

The obvious choice was to slap a pitot tube on the bike. This device is used all over the aeronautical industry for exactly this purpose, so why shouldn’t it work on a bike? Besides, a pitot tube is very small compared to other types of airspeed measurement devices. Not only does it minimize the drag, increasing readouts’ meaningfulness but also makes it suitable for usage in competition. Moreover, it would be a great tool for position optimization and component testing.

Obviously, I am not the first to think of this idea. There are actually companies that have already monetized it, such as Notio or Aeropod. The cheaper of the two costs around 400 dollars at the time of writing, so you could get one without breaking the bank. On the other hand, though, it seemed to me that designing a custom system would still be a go-to solution, especially since it would have given me more control over the collected data. You know, how it’s stored, processed, and so on. Oh, and I’d learn a lot along the way, too.

But before committing fully to a project, it’s best to do some feasibility analysis first. And unfortunately, the outlook was quite gloomy after completing it.

Reality

A man crashing a bike
Reality is often disappointing (Anthony DeLorenz, CC-BY-2.0).

Let’s get back to the airplane case. A pitot tube is usually located somewhere in the front so the flowing air is as unperturbed as it can be. Therefore even if the airspeed experienced by the probe is different than the true aircraft speed due to the probe’s location, the readouts can be calibrated so that the real speed is indicated. I expected to carry the very same procedure in the bicycle case, but there is one huge complicating factor — the rider.

The problem is that unlike an aircraft — whose shape does not change much during the flight — a biker can shift in the saddle or move the hands on the handlebars. All that affects the airflow around it and the pitot tube. Untrustworthy measurements would follow as collateral damage. I found a research paper that investigated this issue using the aforementioned commercial solutions. It’s a very interesting read, but a TL;DR is that even though both sensors were quite precise, changing positions introduced huge errors to the readouts. To alleviate it, you’d have to perform sensor calibration before every position change. Poof goes the ease of use.

This is due to sensor location in both solutions — directly under the bars, in the area affected by the flow of air around the rider. A solution is to place the probe somewhere in the so-called clean air. SwissSide had this exact idea back in 2015. According to their research, the ideal place to put a probe is far in front of the bike, above the tip of the front wheel. But to do so, you’d need gargantuan probes. Apart from funny looks, it could also be a safety hazard in competition. Poof goes the live data gathering.

Salt in the wound

The cherry on top is the issue of the angle of attack. You see, a bicycle drag depends heavily on the direction of the wind. Quite interestingly, a rider is not most aerodynamic in a direct headwind. Instead, the drag goes down in a slight sidewind and reaches a minimum before going back up for harder crosswinds. That variation needs to be somehow taken into account to get meaningful results. Therefore, I’d also need to measure wind direction as well.

Of course, it can be done with an appropriate yaw sensor, but in conjunction with the problems I mentioned before, it was the straw that broke a camel’s back. Well, my back.

Conclusion

Neither of the problems that I mentioned is unsolvable, as SwissSide proved. But just because something can be done, does not necessarily mean it should be done. Surely, all obstacles could be overcome even by a single person given enough amount of time… and money. But since the main goal, i.e. in-competition data gathering, is unfeasible, I’d rather divert my attention elsewhere, without really starting. But that’s fine. Failure is always an option.

You Might Also Like

No Comments

Leave a Reply