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.