Brake Locking Maths Channel Formula - Motorcycles

Hi everyone,

In this module we looked at the brake locking maths channel formula for either FR or FL corners, but what about a situation where we only have one front wheel and one rear wheel like with motorcycles? Can someone help me determine the correct formulas in this situation to calculate single wheel front locking rate, and single wheel rear locking rates? Thanks

At a professional level, you might have another speed reference, using something like laser ground speed sensing, or inertia / gps units.

If I were analyzing a Motorcycle, I would just plot both wheel speeds on the same graph to look for instances of locking that I could detect.

Hi David, thanks for the speedy reply as usual!

Yes, what I'm currently doing at the moment in RS2 is just plotting my three speed channels in the same view in my measures graph visual (GPS, front wheel, and rear wheel speed), and looking for any dips between the two wheel speeds. It's a bit difficult I find though to detect small changes in front locking (well, easy to see in my lowside crash data, but not so much when the tyre is near the limit of surface slip) as my rear wheel speeds vary quite drastically under downshifts, sometimes with the rear end lifting under heavy braking zones and showing very large dips in wheel speed, so it wouldn't be a good reference speed for the front wheel.

After watching the throttle/drive slip section of the course, and how the front axle speed is used as an approximation for free rolling speed and used as a reference speed for the rear axle slip, I thought perhaps I could use my GPS speed as a reference speed for front brake locking since it's more consistent/stable compared to my rear wheel speed. However, one concern I had with this is the motorcycle tyre profile. If you see my minimum cornering speeds when the bike is leaned over at max lean angle, the GPS vs wheel speed discrepancy is quite large due to the changing contact patch of the tyre whilst leaned over, whereas when the tyre is upright, the GPS speed trace tracks front wheel speed quite accurately. To complicate matters further most lowsides happen when the front tyre locks under trail braking and when the tyre contact patch is smaller (and the GPS vs front wheel speed discrepancy is larger) so it makes it a bit tricky then I suppose to use GPS speed as a reference speed then for the front wheel under trail braking where an accurate slip ratio calculation would matter most, and therefore would make it hard to accurately estimate slip ratio under trail braking.

I wonder if there's a maths channel I could write to correct for this tyre profile consideration and changing contact patch mid corner vs upright? Then I believe my GPS speed would provide a better approximation of free rolling speed?

I did some work with the GripOne IMU CAN device (added communications support to a MoTeC firmware package). It has calibration to provide corrected wheel speed channels compensating for lean, etc. Might be something for you to explore.

GPS data often lags behind in terms of actual speed, (but it does give you the trend), I have used the Race Technology SpeedBox which uses an accelerometer to calculate instantaneous speed, then compensates the inevitable drift by using the GPS. We used it for doing traction control on a 4-wheel drive at the Bonneville Salt Flats.

Noted regarding the GPS lag, and very cool about compensating for drift. Interesting about the GripOne device, I know a lot of stock sportbikes come with IMUs fitted, didn't know there were aftermarket options to add, definitely something I'll research further to see if any aftermarket IMU options exist for AiM.

In one of the AiM Learnfast webinars on motorcycle data, I do remember some talk about maths channels which can provide corrected wheel speed channels compensating for lean, but my memory is hazy on the subject. I've messaged Roger Cadell over at AiM USA as well to see if he has those formulas on hand.

Thanks for answering all of my recent questions David, it's much appreciated. I'm relatively new to telemetry and data analysis (around 5 months now working with my MXm system), so my apologies if my questions seem very elementary! Very happy to have found these courses and this forum, learning loads everyday.