mwkeefer
1 MW
Hello all,
I'm not here dissing friction drives, nor am I an expert by any means... just thought I would start a thread to compile some information.
Since I am considering a friction drive but use dd and geared hubs + RC direct link at the moment, I have been following to some extent the work of Kepler and EVTodd on their evolving designs.
Assuming people will want to equip (or can order) hobby type motors with halls (or an addon disc optical sensor type) many might want to look at the < 100.00 infineon controllers (6-12fet stock) as a very viable option to the HV110 / HV140 because they have proven capable of high electrical RPM and they are stable when setup properly...
Even with an RC based setup and controller, there still exists to my knowledge one serious issue - that of potential drive traction loss, the possiblity of tire damage or destruction in such an event (heat, abrasives, etc) and just as important the issue of traction loss actually effects all drive systems so any solution should be applicable elsewheres (ie: front hub motor wheel spin).
I am sure there are other possible concerns for longevity or things those of you using systems would like to see incorporated into an electronic and perhaps programmable black box type solution, so here I am asking for your input...
Anything you can offer for insight would be appreciated!
As of now, I list the following as issues which need addressing (for safety on friction drive but for all ebikes / levs in general)
1.) Traction control - possibly detection of loss and temporary throttle disable for 1/2 second (or programmable interrupt duration) - I have a functional system for detecting slippage on Direct or Geared Hub Motors but... I have no friction drive (which is a fully different beast) to test and see if it will need modifications. It was initially designed and is used now very similar to a car's traction control... it monitors driven wheel (dd motor) and rear wheel RPM and finally current... When it detects the front (driven) wheel moving faster than the rear then sees the current dropping - we have slippage huston... not even about 1/2 second of slippage before it causes the throttle to cut in 1/2 for a second before re-engaging full - lets me know and regain control. Works great for improving the efficiency of DD front wheel drive hub motors.
I see no reason why we cannot monitor 1 hall line (or use one of the 10$ EagleTree BLDC sensorless RPM sensors - connects to 2 of the 3 phase lines and outputs a single hall pulse for each commutation {shit I just realized a properly timed divide by 3 (to generate 3 outputs for each input) would provide hall sensor input for RC motors at a 10.00 cost - maybe} and the rear wheel RPM to very quickly detect and correct for slippage... within perhaps 2 motor roller revolutions, maybe 5 depending on motor speed, I could even see as many as 10.... this would still be better than 5 seconds of spin away right?
2.) True Programmable Throttle Curves - This alone (based on whomevers addition of a High and Low switch) would go a really long way to extending the life of the tire and roller... I see this as being`paramount to proper engagement of a roller drive (see I'm working on it) so that you never apply too much torque in a dry condition which if spin occours - that will smoke up and damage your tire (my only friction drive ever did this, then since it was spring loaded and the throttle was stuck... it destroyed the wheel too.).. in wet conditions it could very likely prevent the slippage (with a good roller) provided proper response curve was programmed into it.
To keep it simple(ish) I would just divide 0-4.7v (throttle range of hall throttle, ball park) by 254 and divide the possible values into as many (254) segments, meaning the same number of steps. I would think on Throttle Change, get the A2D value of the throttle position (a number between 1 and 2047) and store it as target (this is triggered on interrupt of throttle value changing, so it will adapt with dynamic changes to throttle) throttle setting...
Then I would check the previous throttle setting and determine throttle up or down, down should be instant... Up would require... A grab of the ramp interval (time between segment increases) durration, then I would enter a timer loop and each trigger increase the throttle output to controller voltage until it's the same as target throttle voltage.
That would provide us all (I can make it work with PWM type RC throttle signal in and out or Hall or Resistive) with a programmable throttle curve (and no reason we can't have more than one curve given sufficient onboard memory for profile variables - power switches).
Okay so those are my opinion of the remaining issues with Friction Drive control, anyone else (Todd, Kepler?) want to weigh in on other issues you have seen or can anticipate - I realize your issues may be different but I see no reason to create a solution for just one or another type when it's just as easy to do both.
Thanks in advance all, if there is no interest in this... I will simply abandon it as a serious project.
-Mike
I'm not here dissing friction drives, nor am I an expert by any means... just thought I would start a thread to compile some information.
Since I am considering a friction drive but use dd and geared hubs + RC direct link at the moment, I have been following to some extent the work of Kepler and EVTodd on their evolving designs.
Assuming people will want to equip (or can order) hobby type motors with halls (or an addon disc optical sensor type) many might want to look at the < 100.00 infineon controllers (6-12fet stock) as a very viable option to the HV110 / HV140 because they have proven capable of high electrical RPM and they are stable when setup properly...
Even with an RC based setup and controller, there still exists to my knowledge one serious issue - that of potential drive traction loss, the possiblity of tire damage or destruction in such an event (heat, abrasives, etc) and just as important the issue of traction loss actually effects all drive systems so any solution should be applicable elsewheres (ie: front hub motor wheel spin).
I am sure there are other possible concerns for longevity or things those of you using systems would like to see incorporated into an electronic and perhaps programmable black box type solution, so here I am asking for your input...
Anything you can offer for insight would be appreciated!
As of now, I list the following as issues which need addressing (for safety on friction drive but for all ebikes / levs in general)
1.) Traction control - possibly detection of loss and temporary throttle disable for 1/2 second (or programmable interrupt duration) - I have a functional system for detecting slippage on Direct or Geared Hub Motors but... I have no friction drive (which is a fully different beast) to test and see if it will need modifications. It was initially designed and is used now very similar to a car's traction control... it monitors driven wheel (dd motor) and rear wheel RPM and finally current... When it detects the front (driven) wheel moving faster than the rear then sees the current dropping - we have slippage huston... not even about 1/2 second of slippage before it causes the throttle to cut in 1/2 for a second before re-engaging full - lets me know and regain control. Works great for improving the efficiency of DD front wheel drive hub motors.
I see no reason why we cannot monitor 1 hall line (or use one of the 10$ EagleTree BLDC sensorless RPM sensors - connects to 2 of the 3 phase lines and outputs a single hall pulse for each commutation {shit I just realized a properly timed divide by 3 (to generate 3 outputs for each input) would provide hall sensor input for RC motors at a 10.00 cost - maybe} and the rear wheel RPM to very quickly detect and correct for slippage... within perhaps 2 motor roller revolutions, maybe 5 depending on motor speed, I could even see as many as 10.... this would still be better than 5 seconds of spin away right?
2.) True Programmable Throttle Curves - This alone (based on whomevers addition of a High and Low switch) would go a really long way to extending the life of the tire and roller... I see this as being`paramount to proper engagement of a roller drive (see I'm working on it) so that you never apply too much torque in a dry condition which if spin occours - that will smoke up and damage your tire (my only friction drive ever did this, then since it was spring loaded and the throttle was stuck... it destroyed the wheel too.).. in wet conditions it could very likely prevent the slippage (with a good roller) provided proper response curve was programmed into it.
To keep it simple(ish) I would just divide 0-4.7v (throttle range of hall throttle, ball park) by 254 and divide the possible values into as many (254) segments, meaning the same number of steps. I would think on Throttle Change, get the A2D value of the throttle position (a number between 1 and 2047) and store it as target (this is triggered on interrupt of throttle value changing, so it will adapt with dynamic changes to throttle) throttle setting...
Then I would check the previous throttle setting and determine throttle up or down, down should be instant... Up would require... A grab of the ramp interval (time between segment increases) durration, then I would enter a timer loop and each trigger increase the throttle output to controller voltage until it's the same as target throttle voltage.
That would provide us all (I can make it work with PWM type RC throttle signal in and out or Hall or Resistive) with a programmable throttle curve (and no reason we can't have more than one curve given sufficient onboard memory for profile variables - power switches).
Okay so those are my opinion of the remaining issues with Friction Drive control, anyone else (Todd, Kepler?) want to weigh in on other issues you have seen or can anticipate - I realize your issues may be different but I see no reason to create a solution for just one or another type when it's just as easy to do both.
Thanks in advance all, if there is no interest in this... I will simply abandon it as a serious project.
-Mike