Observed trials bike designing

[amberwolf]

I've often wondered about the practicality of building a chain deflection tensiometer - that's a relatively simple device that can give decent results. But I suspect that trying to get sensible data out of a motorcycle chain bumping about on dirt & rocks might be a signal processing nightmare.
First build something that can deal with the surface roughness of a multi-link chain, then deal with all the extraneous signal as that bounces about.

Maybe use IMU (accelerometer, etc) data from the frame the CDT is mounted to as reference to help cancel the noise? I don't know exactly what signal processing would be required, but probably some form of FFT to compare the two / subtract out the "global" noise the IMU registers (primarily on the axis the CDT deflects in).

 

[thepronghorn]

I think you're probably talking something much like I'm trying to prototype but without the physical clutch at all?

Yes, I wonder if an electric controller could be responsive enough to get rid of the clutch.

So to solve the zero throttle but high available power you'd have an algorithm that basically timed how long and how far the throttle was opened. That sets the "available power" which would decay at some rate. You'd need an audio generator to give the rider feedback on how much power is sitting there untapped (I saw some research today that showed that people can respond to audio feedback faster than they can visual feedback).

Yes a tone to indicate the rpm of the flywheel would be essential. It could increase in pitch and volume as the flywheel gains energy.

I get confuddled when I try to imagine how the variable relationship between RPM, torque, throttle position & clutch position interact.
When riding on throttle you want a relatively slow & response (trials throttle response is stupid slow compared to an MX bike for instance), but on clutch you need instant response finely controlled. So the controller has to be capable of running two response profiles. Which I'm working on with my Arduino project.

I think it would help if we start focusing on the specific units and variables that matter to us. Clutch position controls torque from flywheel to rear wheel. Throttle position controls torque from motor to flywheel. Power doesn't matter unless we don't have enough of it to get the torque we need. RPM doesn't matter except to indicate how much energy is in the flywheel. The arduino can easily run two maps for each of the two inputs.

I keep running into Wotif's like how do you address clutch changes simultaneously with throttle changes?

The clutch and throttle control separate entities. The code easily handles it.

Not impossible, but certainly takes some thinking about. Or how do you deal with instant power cut - with a clutch the only rotating mass connected to the wheel is the clutch and gears which have very low inertia and have a low gear differential to wheel speed. If you dispose of the clutch then the motor rotor is connected into the system and it has some significant inertia and has a high gear differential to the rear wheel (unless you use a very slow revving high torque motor, in which case the diameter usually increases so the MoI increases and how far ahead have you really gone? I don't know the answer to that question, just putting it out there.)

I don't think the bare motor inertia is that high. You could try spinning up your motor to max rpm without anything connected then command full brake to see how much the bike jumps.

Stopping a bike or cutting power virtually instantly is just as critical as accelerating it. Even the best riders typically top out on steps with excess power and control it by pulling the clutch for virtually instant power cut, the back wheel is now free to stop or even rotate backwards with very little inertia to fight. You've got to be a magician to get to the top of a step with exactly zero surplus power available.

I can see it might possibly work, but I always end up back thinking that it's got an awful lot of complications to overcome.

As far as my current bike goes, what I don't like are:

• The clutch itself is nowhere near nice enough for really fine, accurate control. It's a coil sprung unit - all modern trials bikes (except Beta) use diaphragm springs because they feel so much better. That's got nothing to do with the electrics, but it's a problem. Feel is very hard to quantify, but it's extremely important - if you can't feel what's going on you can't respond.
• The gearing is too fast. It can do about 45-50kmh on it's current single gear. That's so unbelievably frustrating when you eg want to snap up onto an obstacle that's maybe a foot or less in front of your front wheel from balanced stationary. By the time you've got enough energy in the system to get the pop needed then the back wheel accelerates to too high a top speed and hits the face much too hard, so it bounces. It also makes the overall action from go to woah too fast. With a lower gear the initial pop is slightly faster but the last 1/2 - 3/4 of the action (flight & landing) is slower, so the overall time is longer which gives more opportunity to react and respond. Maybe electronic control could avoid this, but then you need an even bigger motor to generate the torque - vicious circle. 2-speed gearbox hopefully arriving in next few weeks.

A multi speed gearbox will help. Or you could increase flywheel inertia to get the energy you need at a lower rpm. Or if we had a virtual flywheel, we could use the torque of the motor to simulate some extra flywheel inertia.

• When ridden without clutch it's woefully slow to respond (as are ICE bikes, that's just the problem with riding on throttle). You have to start movements so far in advance of when you need them, it's like always having to anticipate two steps ahead, never actually here-&-now. And then there are many movements that are simply out-of-bounds. And that's with a throttle that is definitely on the quick side of things.

This doesn't bode well for implementing a virtual flywheel. Can the fardriver be tuned to respond any faster? You wouldn't want that with a throttle controlling it, but a clutch lever could tame a violent controller response.

It's got a Fardiver running torque mode. I slightly preferred the Nucular with Torque+Speed mode, but my Nuc is only 12F so underpowered, and it can't idle properly.
Trying to coordinate clutch and a non-idling motor is way, way too complicated - it completely does your head in. Touch the throttle before you've got the clutch in and you lurch forward. Or if you've got the clutch in too far then you get a motor that spins up quickly, but then you've got to flick out some clutch to find the engagement point before you lose balance - and oops too much and you lurch forward. Clutch not far enough in when you touch the throttle and guess what? Lurch forward. Horrible!

What do you mean by clutch and non-idling motor? Do you mean the motor spins up and down too fast? Can you just lower the controller torque by a lot and reduce any off throttle braking?

All this is why I've come to thinking that a hybrid system might be achievable and provide some good insights to go forward from. The Virtual Flywheel should make the physical flywheel 'tuneable'. Slippery conditions? Dial down the flywheel acceleration to smooth out the power. Dry granite? Dial up flywheel acceleration and dial down deceleration so you can spin it up fast then smash power down onto that grippy surface.

The tunability you want sounds more like different throttle maps. How will you sense clutch lever position on a hybrid system?

All while keeping the light switch power off, separation of available and applied power, insensitivity to throttle variation etc.
Seems like a feasible and possibly useful step forward.

I'm interested to see how it turns out. I'd be interested in helping with the Arduino if you want.

 

[speedmd]

Possibly a motor mount pressure transducer for power readings? Or possibly add load sensor to cut out section of primary chain case of a first stage gear reduction custom setup. Unfortunately both are deep into specialized customization I am no help with. Maybe some of the folks knowledgeable with crank torque sensors have a easier solution.

Great work on quantifies of time frames. 0.1 seconds is a good round number for simplifying math of bench marking options. It matches up well with the elastic bounce I believe is a good example of calculations needed to best estimate virtual side targets. A simple ball bouncing or being kicked is a much shorter time frame. On the order of 0.1 times this. However we are dealing with much slower rebounding soft tire and suspension and the daisy chain of flex from the rim - spokes - chain -frame and gear train for starters. Eliminating - combining one or more of these steps may make things much more responsive.

Best long term solution may be to just customize the motors rotor by adding the mass needed into iron and magnets sufficient to easily give you a bigger boot to kick with. Anyone do the math on problem 6? LOL

 

[bikerpete]

I think it would help if we start focusing on the specific units and variables that matter to us. Clutch position controls torque from flywheel to rear wheel. Throttle position controls torque from motor to flywheel. Power doesn't matter unless we don't have enough of it to get the torque we need. RPM doesn't matter except to indicate how much energy is in the flywheel. The arduino can easily run two maps for each of the two inputs.

I think I'm missing something here, probably embarrassingly simple.
On an ice bike with slipping clutch increasing throttle doesn't increase torque significantly. Yes, it does, but only enough to spin faster. There isn't any significant torque output increase to the wheel.
What increased throttle does do in this situation is increase the speed of reaction when the clutch is released. Acceleration is faster & Max speed is higher. It depends on the situation how much torque is developed/absorbed.
If you are eg. hopping the back wheel across a horizontal gap it doesn't take much power (you let the back wheel drive under the almost vertical bike & reach forward to the other side. You only need enough forward velocity in the mass to rock forward over the wheel when it stops on the face on the other side) but it does require some speed to get a very flat back wheel trajectory.

I'm not seeing how controlling torque motor to flywheel & torque flywheel to wheel would achieve this?
Wouldn't one just cancel or add to the other with a nett cumulative change in torque at the wheel?

It's partly this speed factor that makes me think RPM needs some direct measurement & control.

This doesn't bode well for implementing a virtual flywheel. Can the fardriver be tuned to respond any faster? You wouldn't want that with a throttle controlling it, but a clutch lever could tame a violent controller response.

Setting controller to Max fast response is my plan, but I've got serious doubts that's going to be anywhere close to the figures I posted yesterday. I find it hard to imagine the QS138 accelerating to 1500rpm in 0.08s while under quite high load load, which is about the equivalent of what my Ice bike was showing. Happy to be surprised.

Edit: I thought I'd explain part of my reason for skepticism. I have a 3ph turret mill, 5hp motor. That motor is BIG compared to the QS, or indeed any motor in any trials bike. If I hit start with the spindle clear of the workpiece it spins up very fast. If I hit start with the cutter against a workpiece it starts up very, slowly indeed. I know there's probably a big difference between a 50hz induction motor and a PM motor being actively controlled by a smart controller, but I can't help but think that the basic problem is likely to remain. Once we start trying to accelerate a motor very fast under high load I suspect we're going to have to start throwing way more copper, iron, mass and volume than is worthwhile for the dubious benefit of getting rid of some moving parts.
I don't mind moving parts, they can be very useful.

There's what I find a slightly weird phenomenon when it comes to electronics. Once people start seeing how good electronics are at many things they seem to lose track of the fact that mechanics are very good too.
Take your ordinary car heater controls. Back in the day we had levers or knobs that dialled up the fan and sent the air where we wanted. You could find them in the dark, you could tell visually or by feel what the settings where and when you moved something there was a more or less immediate response.
Now to shift the air from somewhere to somewhere else there's likely a touch screen that doesn't even display the possible options until you've interacted with it, that only has visual feedback forcing you to take your eyes off the road and that after you change a setting you wait for the various servos etc to make some change. Madness in my opinion.
Either industrial designers have lost the plot and forgotten how real people actually operate, electronics engineers have taken over the world or accountants have discovered electronics can save them pennies, safety and function be damned. Or all 3.
Edit to my Edit: I neglected to malign another profession - the marketing boffins who conspire to make us believe that this ridiculous over complication is an 'improvement'.
I entirely blame the Golgofrinchan Starship A for this parlous state of affairs. NB. if you're British or Australian and don't get that reference - shame. If American - to be expected. Anyone else - you're excused.
Right, I've now maligned a bunch of professions, offended a nationality and embarrassed members of a couple of others. Job complete.

I feel like the mythical electronic clutch is perhaps just another "touchscreen" to complicate what is really a very simple mechanical task.

Bring back the horse and cart.

What do you mean by clutch and non-idling motor? Do you mean the motor spins up and down too fast? Can you just lower the controller torque by a lot and reduce any off throttle braking?

If you've got a motor that completely stops when throttle is off & a physical clutch then it's really hard to coordinate picking up from zero. Picture stationary balancing, now you want to creep forward an inch or two. You can't coordinate spinning up the motor & easing the clutch at the same time. You've got to hold in clutch, spin the motor, then ease out clutch while trying to keep motor rpm low, but not cutting throttle & losing power. Nightmare. Usually ends in a lurch or a foot down.
It's much better to have the motor constantly spinning so you can continuously feel the engagement point of the clutch & get instant small adjustments.

The tunability you want sounds more like different throttle maps. How will you sense clutch lever position on a hybrid system?

If throttle maps are still controlling torque they're still disfunctional.
Consider traction control, be it manual or electronic. The goal is to match wheel speed to ground speed.
If you're controlling torque then there is no speed control. Even at stupidly slow throttle response settings a torque controller will spin up very fast indeed if traction is lost. This is where a flywheel provides both torque & speed control response. You can provide big torque, but if traction is lost there is absolutely no acceleration, so wheel & ground speed remain very close. Change of relative speed is purely a function of vehicle inertia & slowing forces. Neat trick from a hunk of dumb steel.
So again, motor RPM is an important input to the control system. You could use real applied torque, or accelerometers or whatever, but we've got the ability to read RPM easily with what already exists on the bike. Keep it simple.

Sensing clutch position? I don't intend to. I'm sticking with a "real" clutch.
I've no confidence the electronic clutch idea is going to be functional & practical anytime soon. I'm interested to see if it can be made to work, but I prefer to bet at shorter odds. So my efforts go elsewhere.

The e-clutch could be great for trail/street/enduro riding - really snappy & much safer wheelies, all sorts of fun stuff. But it's miles away from useful for trials in my view.

m interested to see how it turns out. I'd be interested in helping with the Arduino if you want.

That would be absolutely awesome!
I'm enjoying learning to develop Arduino, but it's crazy slow & every step of the way I have to take detours to find out what I need to know.
I've started a GitHub project but it's not quite in a sane state (learning Git as I go too). As soon as it's vaguely comprehensible I'll post a link and also start a thread dedicated to that topic.

 

[bikerpete]

Possibly a motor mount pressure transducer for power readings? Or possibly add load sensor to cut out section of primary chain case of a first stage gear reduction custom setup. Unfortunately both are deep into specialized customization I am no help with. Maybe some of the folks knowledgeable with crank torque sensors have a easier solution.

Great work on quantifies of time frames. 0.1 seconds is a good round number for simplifying math of bench marking options. It matches up well with the elastic bounce I believe is a good example of calculations needed to best estimate virtual side targets. A simple ball bouncing or being kicked is a much shorter time frame. On the order of 0.1 times this. However we are dealing with much slower rebounding soft tire and suspension and the daisy chain of flex from the rim - spokes - chain -frame and gear train for starters. Eliminating - combining one or more of these steps may make things much more responsive.

Best long term solution may be to just customize the motors rotor by adding the mass needed into iron and magnets sufficient to easily give you a bigger boot to kick with. Anyone do the math on problem 6? LOL

I had a look at load cells on Aliexpress last night. I had no idea they'd fallen to such ludicrously low prices. I should have guessed - it's Chinese electronics industry after all.
It doesn't look that hard to force a bend into the top strand of drive chain with a load cell feeding an arduino to get chain tension and hence real-time applied torque and power.
There'd be a fair bit of signal noise from sprockets, vibration, chain slap etc but the bigger forces should so totally overwhelm the noise that it wont really matter for what we're after. Probably wouldn't help much with the fine control end of the requirements, but should give some empirical figures for the upper thresholds.
Another project to find time for. Hmmm. Lucky I ordered a couple of Arduinos from China.

Load cell on a motor mount would be very tricky because the motors are structural members and anchored rigidly to the frame in at least 4 places.

I'm not so sure about sticking with 0.1s as the time frame. Even my amateur efforts are 50% lower than that. Not insignificant!

I'm also a very long way off seeing any evidence that adding iron, magnets, copper etc are actually solutions to all, or even any, of the problems we're trying to solve.
One of my fundamental gripes with moving from a clutch to an electronic analogy is, "What's the real-world advantage of swapping out a very functional mechanical solution for an electronic solution if we end up carrying around as much or more weight?"
There has to be some compelling advantage and so far the only ones I see are:

• It's more adjustable. But the evidence out there right now is that almost no one adjusts anything except occasionally the rate at which the clutch responds by swapping oils. A small number of people adjust the springs and/or add flywheel weights, and an even smaller number adjust the plates themselves. Yes it would be nice to be able to do that with a knob or a phone app, but it doesn't seem to be too big a deal. Mostly the factory setting is perfectly suited for 90%+ of the riders. The few who fiddle it spend some time getting it feeling "just right" then move those settings from bike to bike.
• There's no maintenance and fossil oils needed. This is certainly a good advantage.

There's absolutely nothing I've seen that suggests the function of the e-solution works anywhere near as well as the current mechanical one. We're talking about how it might get there, but we haven't even got a glimmer of a suggestion that it actually will.
To my mind Step 1. is see if more or less existing hardware can be made to operate in a similar mode to the current state-of-the-art clutch/flywheel. Presently it doesn't appear anyone has made that basic experiment in the form we've been knocking about. Dingus is making some preliminary tests.
Step 2. would then become a process of identifying where the more significant changes need to be made based on results from step 1.
Leaping straight to bigger motors before the control strategy has had even basic testing seems counterproductive. That just makes for bigger control problems.
If we had the DAQ equipment and the benchmarks we could probably develop it at 10th scale - much cheaper & faster. Unfortunately our test equipment and benchmarks remain 1:1 scale riders.

 

[bikerpete]

Next thought.

Considering what I wrote above about using throttle to increase RPM while the clutch is slipping, what about this idea.

1. Clutch controls applied torque to the wheel
2. Throttle controls RPM
3. The algorithm blends between those two basic systems.

When the clutch is within it's slip zone then clutch = torque, throttle = rpm.
As the clutch moves through that fine transition from slipping to locked, the throttle begins to gradually increase it's influence on applied torque.
When the clutch is fully released the throttle fully controls torque, but is RPM moderated (effectively part of the virtual flywheel).

You still need the virtual flywheel to provide for those many situations where you build RPM before the maneuver, but during the move everything is done on closed or closing throttle using stored inertia.

This 'feels' sort of right to me. Although I'm still skeptical about the size of the motor required to provide the equivalent of real flywheel inertia.

I've no clue how you do it in software, nor do I really understand yet what the controller/motor actually does to control "RPM" when there isn't a physical change in RPM. I'm guessing it's some sort of manipulation of acceleration rate and maximum RPM limit.

I just thought of this as I hung out the washing a few minutes ago, but it felt excitingly "right".

EDIT: I'm excited about this train of thought, so just spitting stuff out here.
I think this relates to me liking the Nucular Speed & Torque mode better than straight torque mode. Especially when operating with slipping clutch we ride on purely RPM feedback from the motor and torque management from the clutch. With the Nuc in S&T mode the RPM rise when slipping clutch was far more controllable than torque alone. It also had really nice feel when riding on throttle, just that little bit smoother on acceleration and slightly less likely to spin-up on brief loss of traction.

When we wind on revs prior to a move we are 100% responding to the sound of RPM, not torque. Yes, that RPM represents torque when we release the clutch, but that's the point where we control the torque, not when we build RPM.

That transition from separate control regimes to combined is going to be critical and very sensitive.
The lever movement in that zone is tiny, and needs to be to get the minute accuracy required. I'd guess the very end of the lever only moves 3-5mm, and trials levers are long ungainly things. (I've never understood why we use such long levers when everyone rides with just one finger right in close to the pivot point. Most of the lever just waggles in the breeze). The movement at the lever piston must be just a fraction of a mm. Might require a considerably redesigned lever system to provide a much larger movement at the sensor.
Actually perhaps it's not trying to measure just movement but force combined with movement? In a clutch you aren't so much moving plates closer and further apart, you're applying a balancing force against the clutch spring. I'll pay close attention to that aspect next time I ride.
The lever design itself could be quite critical in getting the right response. Careful selection of spring force, movement and sensing.

Thoughts?
Shoot me down.

 

[amberwolf]

There's what I find a slightly weird phenomenon when it comes to electronics. Once people start seeing how good electronics are at many things they seem to lose track of the fact that mechanics are very good too.
Take your ordinary car heater controls. Back in the day we had levers or knobs that dialled up the fan and sent the air where we wanted. You could find them in the dark, you could tell visually or by feel what the settings where and when you moved something there was a more or less immediate response.
Now to shift the air from somewhere to somewhere else there's likely a touch screen that doesn't even display the possible options until you've interacted with it, that only has visual feedback forcing you to take your eyes off the road and that after you change a setting you wait for the various servos etc to make some change. Madness in my opinion.
Either industrial designers have lost the plot and forgotten how real people actually operate, electronics engineers have taken over the world or accountants have discovered electronics can save them pennies, safety and function be damned. Or all 3.
Edit to my Edit: I neglected to malign another profession - the marketing boffins who conspire to make us believe that this ridiculous over complication is an 'improvement'.
I entirely blame the Golgofrinchan Starship A for this parlous state of affairs. NB. if you're British or Australian and don't get that reference - shame. If American - to be expected. Anyone else - you're excused.
Right, I've now maligned a bunch of professions, offended a nationality and embarrassed members of a couple of others. Job complete.

I agree with the entire section above...there are many places where UIs of whatever type are not correctly designed for the situational usage they're intended for. I fought for years with various software (and some hardware) manufacturers, often as a beta tester, to fix or change or redo various UIs, to virtually no avail. Many times I was told that marketing said it had to look a certain way so they could put screenshots on the box to catch a buyer's eye, which is a totally completely utterly &*_))%(*$)%&$)% retarded way of choosing how to design your product, unless you are just making "BSOs" whose only purpose is to be sold, and not used, and you don't care about your existing userbase or future upgrade-buyers, etc.

It's only partly the fault of the GF Ark Fleet Ship B, though...if they hadn't been there, we would have come up with all this crap on our own anyway. :/

And contrary to THHGTG, despite being human, and thinking that at least some of them *are* pretty neat, I don't wear a digital watch (anymore, since the 1990s). But only because I got used to not wearing one after breaking something I was working on (neck of a CRT in a Mac Plus) because I caught the band on the circuitboard.... It was too complicated to remember to take it off and put it on since I fixed things all the time that I'd have to do that for, so I just stopped wearing it. But it took me YEARS to stop hearing the BEEP on the half hour and BEEP BEEP on the hour, even though I did not actually have anything making that sound around anymore. :lol:

 

[thepronghorn]

Ok I'll ignore the implementation of virtual clutch for now. I'm interested in it one day being implemented, but that's not for this thread.

So how do we implement a virtual flywheel. Below is my first pass at how to do it:

A virtual freewheel controller uses the throttle signal and motor rpm to add virtual inertia to the system. Without knowing the clutch lever position, it has to derive the clutch torque from the derivative of the rpm, so it is inherently a little laggy, but it might still be useful. Even if it knew the clutch lever position, calibrating the lever position to the clutch torque might be impossible. It could sense the chain torque or sprocket torque, but those are going to be difficult to get a sensor on.

First we need to calculate the clutch torque.
The change in flywheel energy is equal to the sum of the motor torque and clutch torque times angular velocity times time.
delta(Eflywheel) = (Tmotor + Tclutch) * w * t
Eflywheel = 1/2 * I * w^2 (I is the actual mechanical flywheel inertia, w is angular velocity)
Tmotor is known from the torque we were commanding the controller
Tclutch is what we are solving for (it will be negative since it removes energy from the flywheel)
w is angular velocity
t is the length of time from our last sample to our current sample

Once we know the clutch torque from our most recent time period, we read the current throttle position, calculate the torque we actually want from the motor, and send that to the motor controller. The motor controller setpoint is equal to 1/ratio*(Tmotor - Tclutch)
ratio modifies the flywheel inertia, to double the effective flywheel inertia, use a ratio of 2

For example, if we calculate clutch torque to be -200 Nm from step 1 and the rider is requesting 100 Nm with the throttle, then the net torque without modifying the controller command would be -100 Nm which slows the flywheel down. However, we want it to slow down half as fast, so we actually send 1/2*(100-(-200)) = 150 Nm to the motor controller. The net torque is thus -50 Nm and flywheel slows down half as fast.

Will this work? I'm not sure. I think the math is right, but it needs good data to estimate the clutch torque accurately, so it needs a good rpm measurement and the controller needs to be putting out the torque we are commanding it to, neither of which I am super confident in, but it's probably worth a try.

 

[DingusMcGee]

bikerpete et al,

You did mention not understanding what part voltage plays in this development. The motor employ circuits that are electrical inductors.

The voltage in the simplest inductor circuit behaves as

V = L di/dt + Ri, L is the inductance load, i is the current and R is the resistance. Think of this equation as…a crude motor electrical response. An excellent equivalent would be Thevanin’s Equivalent Circuit for a BLDC motor - 3 phase. di/dt is the rate of current change and the faster the current is changing the more voltage is in needed in an inductor circuit.

For time Constants or Frequency of response we mostly agree to use 100msec. To support this benchmark of human fastness, consider outstandingly fast typists. 120 words per minute = 2 words per sec = 10 character strokes/sec = 1 keystroke per 100msec.

 

[DingusMcGee]

My Momentum Tests:

Since the BLDC motor and bike mechanical system is a determinist system if we have no freewheels, we can formulate a math expression for the total equivalent linear momentum. Angular momentum can be converted to instantaneous linear momentum by dividing the angular momentum by the radius of gyration of that piece (wheels and rotor are such pieces). This total momentum expression can employ RPM as the sole input for determining inst momentum. Any changes in momentum comes about by either by internal impulses ( the motor) or external impulse ( like the tire traction used to go uphill).

Knowing the energy and other constants of a flywheel will permit calculation of the momentum the flywheel has for an RPM. Some kinetic energy is lost through the clutch plates when any slipping occurs. Hence, knowing the momentum demand per 0.1 sec is far more useful at this stage than what calculation energy methods permit.

For a given bike-motor-controller-battery system with accurate electronic timing and the bike wheels on flat ground we could measure producible demand momentum for 0.1 sec and see if that was as great as what momentum change the flywheel does in 0.1 sec. I do not have fast electronic timing instruments for such measurements, but with some sensors and Arduino a devise could be made.

My controller senses/detects the slightest rear brake pressure as “infinite motor inductance” and it will not let the output surge even to 5 amps upon WOT on the throttle — safety features. There is almost no rise in amps observable on the shunt meter. Perhaps an oscilloscope display could show how transient this amperage rise is?

Testing wheels on the ground WOT response is hazardous unless the throttle output can be terminated say after 0.1 sec. Hence the need for an Arduino chop-off circuit. For now my controller seems to have checks on allowing the controller to respond to a step like throttle input as a surge in amperage output to be sent to the motor.

The controller we need for this project may not be found on the market yet. I likely will not drop $$$ on one just to test it’s step function response.

I do have a few more tests of the bike system after the snow leaves the roads.

What we have within a motor is an electro-magnetic mechanical coupling. This coupling is faster than any spring on a clutch plate. It occurs in lock step fashion as di/dt changes.

And yes, lower gears could help shorten the time of momentum rise rates to facilitate using a controller with a slow amp rise rate.

And so from my voltage tutorial above on induction, a faster current rise rate di/dt necessitates more voltage. The steeper the step function that has any power, the more voltage is needed to drive the current change rate.

 

[DanGT86]

The throttle in a gas motor is essentially a torque request lever. Its the wide range of torque produced at different RPM that provides such a controllable experience. Full torque is simply not available at all rpms.

With clutch pulled in and say 5% throttle angle your unloaded gas motor goes to max rpm. When you release the clutch loading the motor that same 5% throttle suddenly equals a very small amount of torque. Lets say 5%. This is very controllable.

So with no load the bike kinda feels like a speed based electric throttle. With Load applied it suddenly feels way more like a torque based throttle.

So like bikerpete was saying there may be a solution in switching throttle strategies transitioning from speed to torque throttle based on clutch lever position. This is going to require an extremely programable controller or a throttle buffer device that has the ability to measure motor current in real time.

One could possibly achieve a successful ride feel if a device remapped the throttle on the fly. Im picturing it working like this:
Use a straight current based controller. When the clutch is fully pulled such that there is no motor load the throttle is mapped such that the whole stroke only controls from zero to maybe 3-5 amps or whatever your motors no-load current is. This gives you huge control of the modulation of the unloaded motor. In this case it takes a lot of twist to change the no-load rpm. As the clutch lever is released the throttle map gets progressively closer to normal such that 100% throttle equals 100% current.

The cycle analyst 3 from Grin is available with a potentiometer to scale power output from 0-100%. This potentiometer always scales the throttle range appropriately. So at 50% on the dial your full throttle is 50% torque. I don't know how much time is required for a setting to take effect. It seems to me that if the clutch lever position sensor was the output potentiometer than you would have a nice affordable setup to vary throttle sensitivity based on clutch position. This is assuming the CA3 is ok with a continuously moving potentiometer during changing throttle. Maybe email Grin and ask if a cycle analyst potentiometer input can be varied continuously while throttling.

I have a CA3 here. I may try a simple test with dual throttles on my ebike. One to pose as the variable clutch lever output to the potentiometer and one as the normal throttle.

You could maybe get a nice feel if this was simply time based. When the clutch crosses a micro switch the transition from the dumbed throttle map to the sensitive throttle map occurs over several milliseconds.

Short of some advance control like that I think the only other way to get a good match is to severely limit the electric motors torque curve based on RPM to match that of a gas motor. That would be a shame because you would be using a larger motor than necessary since you are handicapping it to achieve better feel.

 

[DanGT86]

Sorry if I'm preaching to the choir here. I marked up this dyno chart of a Beta bike to illustrate my thoughts on why you will need to clamp the electric motor torque per RPM to get the right feel.

The way I see it a clutch allows you as the rider to basically apply any RPM you want to any situation. This is allowing you to pick the exact level of sensitivity you want in any situation. In my view this is the entire "feel" of the gas motor.

When you splat onto an obstacle the wheel is stopped and pulls the RPM way down such that the throttle is not sensitive and you can control traction.

I also think at super low RPM the torque available is inadequate to overcome the inertia of the tire and drivetrain so you don't have the wheel spin up instantly when traction is lost the way an electric system with speed based throttle will.

 

[speedmd]

Looks like we are getting closer to being able to benchmark a typical WC ICE trials powerplant setup to target.

I'm not so sure about sticking with 0.1s as the time frame. Even my amateur efforts are 50% lower than that. Not insignificant!

I'm also a very long way off seeing any evidence that adding iron, magnets, copper etc are actually solutions to all, or even any, of the problems we're trying to solve.
One of my fundamental gripes with moving from a clutch to an electronic analogy is, "What's the real-world advantage of swapping out a very functional mechanical solution for an electronic solution if we end up carrying around as much or more weight?"

Pick two time frames. .1 and .01 seconds? We can then start to quantify a bit better.

No replacement on the mechanical clutch for starters. We are trying to dial in the power plant requirements. Questions of adding flywheel mass vs adding active mass to the motor is a tradeoff study we need to make. The flywheel will calm the motors acceleration and allow for much greater punch at the expense of being somewhat parasitic and opposite to lightening the cycle. At some point, we will have a optimal balance between the two. Too early to tell.

My gut is suggesting the 138 class motor is a bit shy compared to a 300cc modern setup with regards to max punch and drive. At least at sub 100V and 300 phase amps. For me is is just Too early to tell with some confidence.

 

[DingusMcGee]

Sample Rate? Another hidden factor affecting controller response is the rate at which the controller samples the throttle input voltage. If they do it greater than every 100 msec we’ll never get the desired input on time.

I see a lot of continuous signal input ideas but let us not forget that with a fast enough sample rate of the throttle input by the controller we could rather send a chain of short duration “different current boost packets” above the throttle signal in a manner that the harder the “clutch” is pulled the more packets sent and of more magnitude.

 

[DingusMcGee]

Speedmd,

I have put some high amps to both the QS 1000 —10,000+ watts and some 20,000 watts to the QS2000. Short busts, felt no overheating. I suspect the QS3000 can handle more than 30,000 watts for 0.1 sec?

We need a number as to how much momentum the flywheel typically transfers in 0.1 sec. We are close to having that number. From here we can test how fast a bike/battery/motor controller system can change linear momentum from zero speed or maybe creeping in 0.1 sec.

But all the throttle/clutch dreams in the world are useless without a controller that can deliver.

 

[DanGT86]

I just sent an email to Grin to ask about the sampling rate of the CA3 with regards to the ramping of the current limiter. I was thinking similarly that current limiting packets would need to be updated in discrete time scales that could take effect. Ultimately the CA3 would be obsoleted by an arduino or similar but in the meantime its a nice convenient closed loop throttle buffer that exists and offers some other handy instrumentation.

The poor mans version of this would be maybe 3 total current limiters that span the RPM range. Not as elegant but way closer to my particular experience level with microcontrollers.

With regards to flywheel mass vs larger motor I would vote for getting as much functional mass into the rotor of the motor. There is no sense in adding mass to a hunk of steel if that same mass can be working for you in the form of magnets and rotor diameter. Even if you don't use the power its nice to have the option compared to just dead weight.

 

[DingusMcGee]

DanGT86,

I am employing both a high amp shunt reading CA and a stand-alone shunt with meter. The stand alone meter seems better for instantaneous RO. So maybe slow sampling/display time does exist with some of the CA.

 

[DanGT86]

DanGT86,

I am employing both a high amp shunt reading CA and a stand-alone shunt with meter. The stand alone meter seems better for instantaneous RO. So maybe slow sampling/display time does exist with some of the CA.

The sampling time on the CA3 is adjustable. I don't recall if its the true processor sampling I/O or just the display sampling that it is adjusting. Too fast and its just a blur for the operator to read on the screen.

On one of my bikes the controller didn't like the pwm rate of the CA throttle output signal. The controller was trying to ramp way higher than my CA current limit was allowing to. This caused oscillations during limiting. I was able to tune the CA3's proportional and integral gain settings to try and smooth it out. So this leads me to believe it is very adjustable.

For me the open question is whether sweeping the current limiting knob through its range while accelerating would yield good controllable results or if the CA3 needs some user perceptible amount of time to settle on a particular percentage of current limit.

My guess is that all of these things happen on the order of milliseconds such that it would feel pretty smooth.

Again, there are more elegant methods out there. For me I already own a CA3 and have zero experience writing code. So id likely approach it by letting the CA3 do the current limiting and just make a device that takes RPM in and outputs 0-5v signal to go into the CA3.

Tach signal in to voltage out seems like a beginner Arduino project. A closed loop current limiter throttle buffer like the CA3 is way outside my wheelhouse.

I could be after the wrong variable here completely. I just cant shake the feeling that the feel of a gas bike is mostly due to the hugely variable amount of torque a gas motor produces based on its RPM.

 

[speedmd]

test how fast a bike/battery/motor controller system can change linear momentum from zero speed

Will be interesting to get these numbers. I am somewhat in the "Body at rest remains at rest" camp and know from experience that things most times take a bit of a good swift "Kick" to react as what is evident from what the WC riders are showing. Nothing a few hundred volts and a few thousand amps can't cure. LOL

 

[DanGT86]

Will be interesting to get these numbers. I am somewhat in the "Body at rest remains at rest" camp and know from experience that things most times take a bit of a good swift "Kick" to react as what is evident from what the WC riders are showing. Nothing a few hundred volts and a few thousand amps can't cure. LOL

Cant cheat physics for sure. But thats a good thing. Look at existing EV tech. A 1000hp tesla runs the quarter mile at basically the same time you would expect a 1000hp gas motor to do it. Ultimately the wheel shouldn't care where the power is coming from.

I see no reason why an electric motor with similar rotating mass and power wouldn't spin up as fast as a gas motor.

 

[bikerpete]

Wow.
There's a bit to digest in that little flurry of activity!

I haven't got my head around even a fraction of what's been talked about yet, but it certainly feels like there's some really interesting avenues opening up here. Considerably more interesting than just sending an inverted throttle signal out of the clutch which is where things were not so long ago.

I'm investigating how I might make that chain tensiometer so we can perhaps get some real back wheel torque figures. I might be dreaming how hard/easy it is to get sensible data off a chain drive.

Testing wheels on the ground WOT response is hazardous unless the throttle output can be terminated say after 0.1 sec. Hence the need for an Arduino chop-off circuit. For now my controller seems to have checks on allowing the controller to respond to a step like throttle input as a surge in amperage output to be sent to the motor.

I don't think I'd find that too much of a problem with a mechanical clutch to cut drive - it's more or less what we do anyway. Build up gradually.
I very much suspect that availability of a controller that can do what we're asking (at a viable cost) will be the show-stopper. It's just too far outside normal use case.

For a given bike-motor-controller-battery system with accurate electronic timing and the bike wheels on flat ground we could measure producible demand momentum for 0.1 sec and see if that was as great as what momentum change the flywheel does in 0.1 sec. I do not have fast electronic timing instruments for such measurements, but with some sensors and Arduino a devise could be made.

In English please Sorry, not quite getting what you're measuring here.
Fast frame rate video can be pretty good for some measurements. ?

 

[DaLanMan]

Y'know... One of my buddies built a robot that balanced a stick on it's nose (no really, I have a place I am heading with this) it ended up being easier to do it with a separate mechanical sensor than trying to fix it digitally, so the separate package would direct access the motors and pre-tension them back and forth, so the response from the sensor looking at the tilt alignment of the stick did not have delay lag cause said stick to catapult.

I can get more detail on this is ya like, I don't know if he ever published his solution, but I am sure he would donate the knowledge.

 

[speedmd]

Chain - torque?
Torque sensor options in 2022?

Wealth of sensor info in the PAS chapter. Worth a refresher look for some possibilities.

Cycle Analyst V3 preview and first beta release

Here is a link to the now unofficial user guide and other documents and thread index by Teklektik http://www.endless-sphere.com/forums/viewtopic.php?p=571345#p571345 and the wiki http://www.endless-sphere.com/w/index.php/Cycle_Analyst_v3_Setup and the official CAv3 info page...

endless-sphere.com

 

[DaLanMan]

I have never in my life looked at guys on trial bikes and thought "Hey, wonder if that is a hobby for a 6'4 old solder who is a wee bit gimpy because he broke his pelvis" nope, never crossed my mind...

I have however watched the hell out of the vids. I am not even sure I am expressing this correctly, there is a lot of cross tension put on by the riders, a delay from pause to move would be extremely problematic. Consequently pre-loading the system which is how I have heard it described... not sure I am doing this justice. but yes, if you pre tension you have less delay.

 

[bikerpete]

I have never in my life looked at guys on trial bikes and thought "Hey, wonder if that is a hobby for a 6'4 old solder who is a wee bit gimpy because he broke his pelvis" nope, never crossed my mind...

I have however watched the hell out of the vids. I am not even sure I am expressing this correctly, there is a lot of cross tension put on by the riders, a delay from pause to move would be extremely problematic. Consequently pre-loading the system which is how I have heard it described... not sure I am doing this justice. but yes, if you pre tension you have less delay.

You'll never know if you don't try!
I think you might be pleasantly surprised by how accessible trials is at the entry level. The stuff you see on YT etc is pretty much designed to put beginners off!
Around the world the average age of trials riders is probably into their 50's. I'm 61 and still getting better. Find me another action sport where a 61 year old can actually meaningfully compete against 20 year olds! They're pretty rare. I ride at some events with a 73 year old who can run rings around me if things aren't big and scary. If it gets a bit scary I do better. If it gets a bit more scary the 20 year olds do vastly better than me!
At lower grades there is rarely anything actually scary at all, difficult yes, scary no.
I know of guys with prosthetic feet, missing clutch fingers, grossly overweight .... all out there on their bikes challenging themselves and having a blast right alongside their fully able bodied mates & competitors.
And trials events are just so friendly - your toughest competitor will invariably stand with you at a tricky obstacle discussing how best to tackle it. You're only ever competing against your own ability, or inability.
Don't let the crazy antics of the elite crew distort your perception of what the vast majority of trials riders ride. You'd probably be amazed at how hard it is just to make some tight turns around a few rocks when some vindictive, malicious section setter puts a bit of tape and a couple of markers in the way. Heaps of fun for young and old.

You are absolutely spot on about timing. Balance, traction and timing are the heart of trials at all levels. Precision trumps everything in 90% of trials riding. Put your wheel where you want it to within a 1/2", apply that pulse of power exactly on that little pebble that's sticking up out of the goop. At higher levels it becomes timing the power to the exact moment just before the wheel starts to lose downward pressure as you leap forward through the bars - 0.05s late and it just doesn't work the way it should. If you can stand on the pegs and ride a bike and are a little bit obsessive you'll probably love it no matter what level you ride to. True.

A lot of people just don't quite get that more power can be a major disadvantage when timing & precision are the critical factors. More power just means your mistakes are bigger and more consequential. Failing a section because you stepped off the back due to excess enthusiasm is a 40% worse score than paddling through with both feet. Mistakes hurt your score, big mistakes hurt big time.
Enough power is just perfect. Too little power can be compensated for with (on ICE bikes) more revs. Too much causes havoc.

Interesting story about the robot. We can all get blinkered and not see the obvious solutions sometimes.