Observed trials bike designing

@bikerpete,

I did get a chance to review some of the manuals for the Nucular 24F controller. It looks like the authors were native English speakers/writers.

But what a morass of items one can control with the Nucular controller that are just about worthless for an edirtbike.

BTW, I did not see how one changes the PID parameters, but with all those “control” options one unknowingly could think he has surrogate access to the PID parameters and is getting the best bang for the $$$?

So, cast your fate to the Wind when you go Nucular?
 
Last edited:
Speedmd,

The lift (front tire unweighting) begins as soon as the squat begins but the lift is a stiffer system so not much motion is felt initally.

The squat is described in engineering as a mass/spring/dashpot system while the lift is more akin to a pendulum system. They can be simulated/modeled with 2nd order DEQ’s.

I did see a book titled approx: the DEQ’s for the Motion of a Bicycle. It was overwhelming: some 157 DEQ’s. Now add a motor and full suspension?
 
@bikerpete,

I did get a chance to review some of the manuals for the Nucular 24F controller. It looks like the authors were native English speakers/writers.

But what a morass of items one can control with the Nucular controller that are just about worthless for an edirtbike.

BTW, I did not see how one changes the PID parameters, but with all those “control” options one unknowingly could think he has surrogate access to the PID parameters and is getting the best bang for the $$$?

So, cast your fate to the Wind when you go Nucular?
It was a couple of firmwares ago but I was given a bunch of different PID settings from the Nucular team to try on a motor that had some stutter to it.

I don't know if you are suggesting that those settings are nolonger there or that they don't actually do anything.

I can say for sure that they did exist at one time.
 
The lift (front tire unweighting) begins as soon as the squat begins but the lift is a stiffer system so not much motion is felt initally.

Great to have help and some deeper insights on the math. Not sure we are talking about the same lift. We were trying to explain the reaction causing the rear wheel hop up off the ground shortly after the slight wheelie. It is clearly not just the squat rebound or chain loads effecting the swing arm motion. Agree, the squat would follow the mass spring equations but how do we handle the mass spring equations with the addition of the rear wheels torque-motion driving somewhat into the loaded squat? Need to spend some time reviewing the stacked ball bounce math when I have a few moments. Just a hunch at this point as we are getting similar reaction IMO.
 
bikerpete,

Just so you are not uninformed about current Fardriver controllers and merely report your bad history, I have some news contrary to the info posted in your Rant.

Your rant does beg one question? that appears to be what a lot of the posters in the Fardriver thread hint they lack:

—- they cannot reads the manual and apply. Poor victims?

From dun electric store Malaysia: “The new controllers are all unbound versions, you can use the latest APP.”

You say 50,000 a/sec. Do you have a figure for the current rise rate for what LiPo’s produce?
For crying out loud, stop being a bleeding pedant!
Rant? You've apparently never seen a real rant.
Reading manuals is totally irrelevant to the fact that some things work in their software and some flat out do not. As you ran up against yourself.

"you can use the latest app." Wow that's incredible, who'd have thought?
Presumably that's the same version you had to downgrade from to get access to PID. Fabulous.

If you think Fardriver are exemplary pieces of hardware and software you've a lot to learn!
I suspect that's not the case, but it's hard not to read it that way from how you defend them.

I did say, "allows setting .... - 50,000 A/s."
Can it deliver that? Who knows.
Do I have a figure for LiPo rise rate? No. Do you?
The point is that I have a controller here that suggests in documentation it can deliver fast rise rates, which is more than we can say about Fardriver at this stage.
The proof will be in the pudding.
 
On my ICE trials bike the drive sprocket is set inline with the swing arm pivot with normal weight rider static loading the suspension. Somewhat set there as most understood to best balance the torque induced squat behavior. When extended it acts somewhat anti squat and when more compressed it adds to squat. I do not see this as what creates a significant portion of the lift we have been discussing (With regards to the well timed rider compression - clutch dump).
Correct. I doubt there is much effective anti squat on trials bikes.
Once you really stand hard on the pegs the suspension will compress well into squat effect, then as the bike lifts it might transition into anti-squat perhaps, but I suspect by then there's very little traction or acceleration going on.
I rather suspect that effective anti-squat would be a major hindrance.
 
We were trying to explain the reaction causing the rear wheel hop up off the ground shortly after the slight wheelie. It is clearly not just the squat rebound or chain loads effecting the swing arm motion.
The key to getting lift is simply accelerating mass vertically. No complex suspension behaviour.
Yes, a bit of output from suspension can add a little bit, but shock absorbers are there precisely to limit that pogo stick effect.

Max lift is generated by completely stopping the bike, compress the suspension fully, then (& only then) rider extends up to get their mass headed vertical.
A moment later (so the pressure on the pegs is about to fall, allowing them to rise) drop the clutch so the back wheel drives in FAST so the mass of the bike (effectively the engine) rotates without going forward. Now both rider and bike CoG are headed more or less vertical, so that's where you go.
Simple.
The most effective punches are when you land front wheel with brake locked, hold it locked until the point you release clutch. It's like a big hand plucks you off the ground.

If you want to get 150kg flying vertically, you've got to get 150kg headed that direction. A piddly little trials spring isn't going to do it!
 
In regards to the simple analog throttle intercept circuit, I have it mostly built and housed in a project box.

To integrate this module’s manner of performance with the existing throttle demands of the controller circuit, state changes of these analog circuits need to be made quite rapidly. A SSR (solid state relay) likely will suffice.

State changes that happen:


States:

1. Throttle signal pass thru mode

2. Battery voltage adds your chosen voltage in series to the throttle signal to send a larger throttle voltage.

To change from state 1 to state 2 requires a disconnect in the circuit 1 and a connect to circuit 2. This logic function could be done manual fashion with a DPDT switch, but in terms of controller sampling rate the switch is too slow and I merely want to pulse hold the state of having additional throttle voltage.

Even though I have a grouping of different (SSR) relays, the ones that I have on hand that do the correct function need 12VDC to drive the relay/circuit. I suppose I could easily get 12v off the 5v lines with a boost converter which I have on hand.

The SSR most elegant for circuit simplicity would be low voltage (5v would work as the nearby throttle signal operates at 5v) and have pins for acting like a STDP relay. Then, with the push button engagement, the analog circuits set-up could be changed from state 1 to state 2 with sufficient change speed.

I will have to track down such a relay before reporting how the circuit works.
I might have missed something.
Isn't the present sticking point that the controller doesn't respond quick enough to the throttle?
If that's the case, building a faster throttle signal isn't going to change anything is it?

I found a thumb throttle in my box of bits. I think I can screw a short lever onto it & mount it as a clutch lever but feed it to the throttle input. No twist grip, just the clutch lever.
Given the figures from my clutch release video I should be able to go 0-5V in under 0.1 seconds. And more importantly for my wellbeing, 5-0v in about the same time.

That should give an idea if the parts I have here can provide useful fast current. If not then it becomes a process of working out what's the blockage.
 
bikerpete,

presently a very quick twist of the throttle seems to result in too much torque to the wheel.

No problem with the controller’s potential, yet.

Changing the PID parameters made a big difference in torque rise rate. I have not measured momentum change for 0.1 sec but have most of the tools.

As I see it, getting a handle on the throttle/clutch emulator is most definitely on the critical path. For now the task is easier started with my present set-ups. I have a QS4000 v3 motor uninstalled. I have more batts. If the only path to such performance we seek is via Nucular controller I can drop the $$$.

The capability to measure amps rise rate is a simple feat and could readily be carried out with a shunt and Arduino timing — if the rate is too fast sent a brake signal to the controller. What does the Nucular controller do with the amps rise rate?

I do not know the LiPo A/sec rise rate. I have not seen this stat for any batt.

I have thought of employing a thumb throttle but, I am more curious about the effects of small voltage spikes/step ups. This controller senses how fast the throttle is twisted and does who knows what exactly? More amps quicker for sure, but at what rate?

Besides the thumb throttle’s analog output is not easily added to RH throttle output unless it’s voltage is added in series or added within an Arduino module. If the voltage is added in series analog fashion, the throttle voltage at the controller will go to below the active threshold when either are idle.

But employing an SSR makes for a very quick connection — steep.
 
Last edited:
DanGT86,

Likely the most difficult task for PID control is start-up. Motors are under full inertia as the system has no momentum hence, motor’s perceived inductance L can be way larger than normal. To get more torque the motor needs more amps — current. In generalized form the voltage acts like V = L di/dt where di/dt is the current rise rate. As V surges the controllers problem is to keep V max low enough to not burn up some components of the controller. The parameters for PID systems are continuous but not just any set of parameters of nearly the the same settings (in the same region ) will always give system stability.

Hence companies like Fardriver use SURROGATE variables for the settings of the PID parameters that are known to have voltage stability. In others words they let the user choose categories which are not the continuous PID parameters the system uses but merely whole numbers that correspond to a real parameter settings. A benefit of this method is a simple “check sum” can determine whether the user entered PID parameters are of a known stable voltage responses pattern.

Having a controller with wide open source code can lead to uninformed “hackers” unknowingly making small changes with PID parameter setting that are hazardous. The training for EE’s in control management has much to do with determining system stability. The ways of PID controllers is not intuitive, hence I am satisfied for surrogate control when it comes to PID parameter changes.

A high spurious V max surge can arise at start-up, if the perceived L and di/dt are very large. This voltage can easily be greater than batt input voltage. We never see this spurious voltage rise but it could be measured and displayed.
 
Last edited:
The key to getting lift is simply accelerating mass vertically. No complex suspension behaviour.
Yes, a bit of output from suspension can add a little bit, but shock absorbers are there precisely to limit that pogo stick effect.

Max lift is generated by completely stopping the bike, compress the suspension fully, then (& only then) rider extends up to get their mass headed vertical.
A moment later (so the pressure on the pegs is about to fall, allowing them to rise) drop the clutch so the back wheel drives in FAST so the mass of the bike (effectively the engine) rotates without going forward. Now both rider and bike CoG are headed more or less vertical, so that's where you go.
Simple.
The most effective punches are when you land front wheel with brake locked, hold it locked until the point you release clutch. It's like a big hand plucks you off the ground.

If you want to get 150kg flying vertically, you've got to get 150kg headed that direction. A piddly little trials spring isn't going to do it!

Great topic Pete. Good also to help the "metal balance" a bit thinking this all through.

Most interested in the forces involved and their resultant vector trajectories so we can model this a bit deeper. Rider certainly helps with the hop but most interested in the drive off the rear wheel "wedging under" it all and kicking it all into the air. Agree, the suspension adds very little force but does help set the motion in play.

We do have a significant amplification from the motor torque affecting this hop.

Some thoughts:

The motors thrust will induce wheelie forces. The combination of forward drive and rotational (Torque) forces. As the suspension unloads, the mass center becomes higher with respect to the contact patch and even easier to rotate. Added is the wheel/ tire compressing a bit and allowing it to wedge itself under the mass center significantly deeper with even slightly added torque from the effective reduce wheel diameter. With a rider being static and if the wheel stays in ground contact, it would just flip you off onto your tail and cycle would flip up into the air (without rider) and over with enough force. We have seen this many times.

The relatively sudden wedging in- under of the rear wheel I believe is greatly accelerating the vertical motion-forces on the well timed punch and the rider is also spring boarded off of this. A bit to late and if your caught fully compressed you could get spit off like the tennis ball in the dual ball drop example. :oop: Need to review more video's. Too icy here to practice this effectively.
 
@speedmd look up Neil Price, Trials and Enduro Skills.
Much of his stuff is in a closed coaching group, but there's quite a few YT videos. They tend to be a bit chatty & long, but his analysis of a lot of this stuff is just so good.
Well worth the time if you're interested.

Consider if you held the rear tyre still. The bike just rotates around the axle as the chain 'unwinds'. I think that's a big part of punch, splat etc.
 
What does the Nucular controller do with the amps rise rate?
What do you mean here?
Does it manipulate it?
I really don't know.

I modified a thumb throttle today to reverse it - out is full signal, pulled (or pushed) is zero. Use it in place of the clutch lever.
Haven't tested it yet but plan is just that one device for control, no twist throttle at all. And a wrist lanyard kill switch for when it gets a little crazy!

I've also made some progress on the logic & code for the Arduino - slow going when you've got to learn every step of the way!
Fun though.
I've got an LMX motor here in pieces. I'll put it together again and start with that as a test bed. It was intended for a bicycle based trials bike but that project got derailed by changing wants. If this works it might get back onto the menu.
 
Consider if you held the rear tyre still. The bike just rotates around the axle as the chain 'unwinds'. I think that's a big part of punch, splat etc.
I will check out more of the Price video's. Thanks.

Agree, the torque equation is a major player, but how to integrate the drive force vectors amplifying effect is still in need of some basic ball park analysis. The rider adds much mass loading to the spring vertically as does the forward motion to a variable degree ( both horizontal and vertically through rotation(tipping backwards and raising the mass center)) to this torque. Thinking the flywheel- clutch dump is acting much like a spring release here.
 
Agree, the torque equation is a major player, but how to integrate the drive force vectors amplifying effect is still in need of some basic ball park analysis. ... Thinking the flywheel- clutch dump is acting much like a spring release here.
I know Neil talks about fully compressing rear suspension before Go in part to set the angle of the swingarm pointing down under the CoG, in order to encourage faster rotation. I've never been sure if I agree with the force diagrams he uses or not, but I've never cared either - in real life it works, that's all I really care about.
When the swingarm is in that position chain tension & forward drive will tend to hold it there, so release of the spring won't occur (or will be reduced) until chain load falls, which is pretty late in the process.
In fact I think I've seen video where the swingarm stays pretty compressed right until the wheel is going airborne, when it quickly extends out toward the obstacle. By that point the movement is doing absolutely nothing for producing lift.
 
Arduino development.
I've started a new thread dedicated to developing the Arduino throttle manager.
Arduino Virtual Flywheel Throttle controller

It's been very slow due to being ignorant about writing code for just about anything, let alone micro-controllers, but I've got one small part of the code in a form I'm happy enough to move forward with. Although untested on a running motor. Hooray.
So I'm opening up the GitHub Project e-trials_throttle

Currently there's very little in there, and what there is is very rough outlines.

The only bit that I think is more or less ready to incorporate is the tacho_hall.ino code. This just times between a motor Hall signal pulses. I don't need actual RPM, so just working with pulse timing is sufficient and minimises compute time. I fully expect the complete code to get pretty messy given my lack of skills & knowledge so I'm trying to save clock cycles wherever I can.

I've also got some code running on a Nano that's reading the hall throttle nicely. It's got some basic smoothing for applying to increasing throttle. I'll pull that into GitHub soon.

My next step is completing at least one branch of my flowchart so I can start building some of the flywheel algorithm. I've simplified it a bit from what I first thought through, and found some further complications to consider. Eventually I'll drop a flowchart into GitHub which should help people make sense of things.

I've never used GitHub before except to look at other people's work, so I've got very little clue what I'm doing in there.
The Dev branch I'm considering open season for all to contribute to (although I've no idea how that works!).

I'll make a new project for the chain tensiometer.
 
Last edited:
I think there's something interesting here about both flywheel and clutch design that I haven't seen made explicit, that is pretty unique to what trials demands. You have two controls (throttle and clutch) that are used to interact with the RPM state and the rate of change of the RPM of the motor. So it's hard to build a technical system to emulate that, because not only do you have variable control over two parts of a system with both the throttle and clutch, you are also effectively changing the behavior of the system based on the historical inputs.

The simplistic view is to say "I just need to be able to deliver "x pounds of force to the rear wheel", and I will have successfully emulated the system", but the practical view that a trials rider has is "based on the RPM, throttle position, if the motor is spinning up or spinning down, relative ground speed, and relative wheel speed, I can use a combination of the clutch, throttle, and rear brake to modify how the available power stored in the flywheel plus the available torque from the motor being connected to the rear wheel is delivered to the ground".

It's also worth noting that when you select a gear, you're also modifying the broad characteristics of the power delivery, while not reducing the available power from the motor at all. The clutch and the throttle can be viewed as ways to fine tune power delivery within the scope of the macro adjustment that the gearing allows.

Trials is interesting in this specific application because it is fundamentally about a level of control over the detailed application of power that basically no other sport or use case demands. A more powerful motor or more power output doesn't help you achieve the goal, the specifics of how you deliver that power is all that matters - and doing it while you're also actively riding the bike creates a very unique UX/UI challenge. It's also, I think, important to recognize that many of these decisions aren't about reaction time, it's about executing to pre-determined plan that is created by proactively identifying the state you want the bike to be in over a period of time, based on how it is likely to react to the obstacles you are putting it through, and you may cycle through intentionally having the clutch add power to the rear wheel, disconnect the rear wheel from the engine, or _reduce_ movement at the rear wheel (when the engine is moving slower than the rear wheel, it will actually decelerate, not accelerate, the rear wheel) at any given point in time.

I actually pulled the powertrain assembly from my EM and put it in a full size dirtbike chassis after my experiment with driving a welded together two stroke crank and 6 speed gearbox with a QS138 didn't work very well. The assembly was heavy, the power delivery off the low end of the controller was far too soft, and while the large amount of power was great once everything was moving, and the ability to modulate it via the clutch was good, the responsiveness was extremely poor. The ideal throttle mapping with a strong hit off the bottom for a hard enduro / trials application is functionally unusable for non-clutch applications, and you really need to minimize the amount of slack in the driveline or you lose massive amounts of responsiveness. I'll try it again at some point, but I really need to drive the clutch basket with the motor directly, and that's complicated due to packaging issues.
 
Last edited:
@ecstatic_subjectivity There's some wise words in there.
I completely agree about the basic premise that it's all about the level of control you have over the system.

Trials is interesting in this specific application because it is fundamentally about a level of control over the detailed application of power that basically no other sport or use case demands.
This sentence is the voice of someone who has a good grasp of the activity!

The rate of change stuff is a large part of what I'm having a go at working out in software at present. The virtual flywheel is completely driven by rate of change, and the throttle range by change in RPM. Maybe it'll work or maybe it wont, or maybe it'll be let down by other components in the system.
I still have very little belief that it will completely replace a real flywheel and clutch though.

It's no coincidence that you can spend weeks amongst trials riders and never hear anyone even mention how much power their bike has - it's irrelevant as long as there's "enough", and enough isn't really a lot. In fact about the only time I can think of when power was discussed recently was when people were saying they thought the latest Sherco/Scorpa engines were a bit too snappy.
In contrast you'll hear people talk about the "feel" of different clutches, or the specific differences in pickup off idle between brands.

What you say about reaction time is also generally misunderstood. There's a common misconception that because things happen fast then it needs fast reactions. Yes, there do need to be fast reactions but the really quick actions have to be pre-planned. Human reaction time is typically around the 4-500ms area, with the best trained performers sometimes getting down around 100ms. Studies of some of the best elite baseball hitters showed that they were quite incapable of reacting to the flight of the ball between it leaving the pitcher's hand and arriving at the plate. Their seemingly astonishing reactions were actually an astonishingly good ability predict what the pitcher was going to send by reading the body movements etc. Planned performance, not reactions. Interestingly the players themselves thought they had exceptionally good reactions (some of them had slower than average reactions in fact) and didn't even realise how they were achieving their performance.
This is where having a motor that spins up relatively slowly is actually important. If it spins up too fast it's harder to pick the point where the power and speed is about what you want. That's also where auditory feedback is so important - we respond faster to auditory input than visual, and our visual sense is already very occupied.

I've got my doubts that your experience with the QS 120 on the gearbox has a great deal of relevance really - not casting any aspersions on that project, it was great what you put together. The QS 120 must have been totally underpowered and under revved. Not a fair test.
Driving a Porsche with a VW Beetle engine fitted then saying Porsche are rubbish wouldn't really be fair!
The ideal throttle mapping with a strong hit off the bottom for a hard enduro / trials application is functionally unusable for non-clutch applications, and you really need to minimize the amount of slack in the driveline or you lose massive amounts of responsiveness. I'll try it again at some point, but I really need to drive the clutch basket with the motor directly, and that's complicated due to packaging issues.
This bit interests me.
I'm not sure what you intend by the bit about throttle mapping?
I'm currently heading much more down the path that I don't actually want a really strong hit off the bottom. I can give my TRS 300 a pretty hefty twist of the throttle at idle and it mostly just accelerates briskly - yes the front starts to lift pretty early on, but it's probably not as quick as my QS 138 powered bike, and I know which is the better bike! The key is that it will just hang on at low rpm, not that it'll accelerate.
Driveline slack hasn't ever been a big factor on ICE trials bikes, I'm guessing the primary drive might have been the issue?
Finally, I'm surprised at you wanting to drive the clutch direct. You'll have no flywheel inertia worth talking of, so the clutch becomes just an auxiliary control for motor power delivery.
I'll give you the hot tip from having a bike that I can setup that way - it sucks. Big time. You just don't bother using the clutch as it's pointless.
The motor RPM goes all over the place as you vary the clutch, so now you have to continuously balance the two against each other even as you're trying to actually focus on applying power to the rear wheel. Horrible. Better to just ride on throttle.
 
I'm surprised at you wanting to drive the clutch direct. You'll have no flywheel inertia worth talking of, so the clutch becomes just an auxiliary control for motor power delivery.
I was reading this as, "add flywheel mass" and drive direct. I think we all agree on flywheel mass being somewhat critical. Would be interesting to mod your existing no mass added setup this way to see how it changes things.
 
I was reading this as, "add flywheel mass" and drive direct. I think we all agree on flywheel mass being somewhat critical. Would be interesting to mod your existing no mass added setup this way to see how it changes things.
Except his previous drive via the crank had a bit of flywheel mass from the crank plates.
I've ridden my bike with a small flywheel, no flywheel & a big flywheel. No question whatsoever that big is best.
 
The rate of change stuff is a large part of what I'm having a go at working out in software at present. The virtual flywheel is completely driven by rate of change, and the throttle range by change in RPM. Maybe it'll work or maybe it wont, or maybe it'll be let down by other components in the system.
I still have very little belief that it will completely replace a real flywheel and clutch though.
I'll have a Stark around soon (going to a friend) and I'm curious to see how their "virtual flywheel" concept works out in application.
This is where having a motor that spins up relatively slowly is actually important. If it spins up too fast it's harder to pick the point where the power and speed is about what you want. That's also where auditory feedback is so important - we respond faster to auditory input than visual, and our visual sense is already very occupied.
I have noticed that this is one of the hard things about the EM - the flywheel spins up FAST and it is hard to modulate. It also spins down very fast, we'll see if the shorter final drive gearing helps it feel a bit snappier.
I've got my doubts that your experience with the QS 120 on the gearbox has a great deal of relevance really - not casting any aspersions on that project, it was great what you put together. The QS 120 must have been totally underpowered and under revved. Not a fair test.
Driving a Porsche with a VW Beetle engine fitted then saying Porsche are rubbish wouldn't really be fair!
This is a good point - I'd actually forgotten that the QS120 ended up being the motor I had to go with. I'm going to try a direct drive QS138 just for giggles and we'll see how that feels.
This bit interests me.
I'm not sure what you intend by the bit about throttle mapping?
I'm currently heading much more down the path that I don't actually want a really strong hit off the bottom. I can give my TRS 300 a pretty hefty twist of the throttle at idle and it mostly just accelerates briskly - yes the front starts to lift pretty early on, but it's probably not as quick as my QS 138 powered bike, and I know which is the better bike! The key is that it will just hang on at low rpm, not that it'll accelerate.
Driveline slack hasn't ever been a big factor on ICE trials bikes, I'm guessing the primary drive might have been the issue?
Finally, I'm surprised at you wanting to drive the clutch direct. You'll have no flywheel inertia worth talking of, so the clutch becomes just an auxiliary control for motor power delivery.
I'll give you the hot tip from having a bike that I can setup that way - it sucks. Big time. You just don't bother using the clutch as it's pointless.
The motor RPM goes all over the place as you vary the clutch, so now you have to continuously balance the two against each other even as you're trying to actually focus on applying power to the rear wheel. Horrible. Better to just ride on throttle.
I think the difference here is that I'm not really a trials rider - I'm a hard enduro / woods rider, although I loved my trials bike for cross-training, eventually the reason the motor ended up in the full size chassis is because I wanted to practice the awkward spots where my short legs don't reach the ground while I'm doing pivot turns and awkward direction changes. I ride a 250 2t in the woods and I'm constantly using the fast motor spin up and clutch to deliver bursts of power to the ground, and I find myself looking for more snap than it provides off the bottom.

I might have not been clear enough with my wording - the goal is to drive the backside of the clutch basket with a gear that has flywheel mass on it, much like the EM design. When you pull the clutch in, the basket and flywheel can spin up, not just the clutch itself! Agreed driving just the clutch would be an issue, although potentially you could retrofit more flywheel mass to the clutch assembly if you were building it yourself.

My assumption with the throttle mapping is that it has a "soft start" when the motor is stalled at zero RPM, which happened almost immediately when you pulled the clutch in. I want immediate flywheel response when I open the throttle, but that sort of response on your typical direct drive bike would require extremely careful throttle control to avoid a backflip. Me, I want the power there, I'll modulate it with the clutch, because sometimes I do want the bike to try to backflip when I'm trying to build momentum on a short runup to an obstacle, snap the front off the ground, etc. Woods riding is much less precise than trials riding, and using the motor to attack things with aggression and momentum often saves a lot of energy.

Except his previous drive via the crank had a bit of flywheel mass from the crank plates.
I've ridden my bike with a small flywheel, no flywheel & a big flywheel. No question whatsoever that big is best.

A 2t crank is actually quite heavy, the amount of flywheel mass was the best part of the build, to be honest. I just need to figure out how to get everything packaged at some point, I got frustrated with the build as it was and sometimes they need to sit and think about what they did, haha.
 
I'll have a Stark around soon (going to a friend) and I'm curious to see how their "virtual flywheel" concept works out in application.
I'd be interested to hear how that feels. I'm kind of guessing it's going to be a fairly rudimentary analogy to a flywheel. Maybe just a minimum rate of accel/decelerate on the motor RPM. If I remember correctly they have asymmetric accelerate and decelerate "flywheel" settings, so riders can set a reasonably snappy accelerate, but a much slower decelerate.
I'd be most interested in these two circumstances:
1. From flat or gentle upslope accelerate hard (ideally wheelie front wheel clear) in to an obstacle perhaps axle height, but ensure the throttle is closed before the back hits. A real flywheel will release lots of torque as the wheel hits and tries to stop. Unless the Stark flywheel has more smarts than I think then I expect it to kind of fall in a heap and not give that big torque surge. This move should also show up if the 'flywheel' response is moderated by the basic throttle smoothing or not. In fact if the throttle settings are set really soft & progressive it should make it easier to feel how the two (flywheel & throttle tuning) interact.
2. a normal splat style clutch dump.

I ride a 250 2t in the woods and I'm constantly using the fast motor spin up and clutch to deliver bursts of power to the ground, and I find myself looking for more snap than it provides off the bottom.
From my perspective what you're doing with clutch & rpm is the gold standard, looking for more snap off the bottom via motor response is a regression that will cause more problems than it solves. But I don't do your style of riding.
I love this quote from an ex-national trials champ rider who now rides hard enduro comps a bit. "Hard enduro is really just trials riding on inappropriate machinery" :ROFLMAO:

I might have not been clear enough with my wording - the goal is to drive the backside of the clutch basket with a gear that has flywheel mass on it, much like the EM design. When you pull the clutch in, the basket and flywheel can spin up, not just the clutch itself! Agreed driving just the clutch would be an issue, although potentially you could retrofit more flywheel mass to the clutch assembly if you were building it yourself.
I suspect you'll run up against the problem you refer to in the EM. If the flywheel is on the end of the shaft with the output and clutch then you either run out of space for a large diameter flywheel, or you end up with the flywheel hanging far out the end. The EM flywheel is anorexic and spins up/down so fast as to be next to useless. Making a flywheel out of Cu/W helps considerably as Cu/W is roughly 1.5 - 2 x as dense as steel. But it's not cheap.
Adding mass to the clutch basket would be a really, really inefficient way of adding inertia - the basket is spinning so slowly compared to the motor, you'd have to add enormous amounts of weight to make it useful.

Here's a thought for you that I've considered previously. In your QS/ICE crank build you geared the motor to the flywheel (crank) and then out to the drive. What if you drive direct off the motor, but gear the flywheel? So the motor sits where the crank shaft was (with a clutch) and the flywheel sits up above it all running off a gear (belt, chain, gear - whatever works). Now you lose some of the space constraints of hanging a flywheel off the end of the motor and you also gain the possibility of gearing the flywheel up to benefit from the exponential gain in energy with rotational velocity. Those QS motors and even the EM are pretty slow turning, so the flywheel has to be big &/or heavy to be really effective. Throw in a 2:1 step up and now your 4,000 rpm motor is spinning a nice little 8,000 rpm flywheel. Or go 3:1 and have a 12,000 rpm flywheel!
Torquey low rpm motor that makes final drive a bit more manageable combined with a high rpm flywheel. win - win.
My assumption with the throttle mapping is that it has a "soft start" when the motor is stalled at zero RPM, which happened almost immediately when you pulled the clutch in.
Did your EM not have the idle mode? That's a game changer - trying to coordinate picking up revs off zero and clutch just doesn't really work, which is why they have idle on all the better e-trials bikes now.
That's also where you come up against the limitations of controllers that only know about torque without any reference to RPM or load. That horrible characteristic of electric bikes to just spin up madly when there's no load. By the time you start to tame that by limiting the throttle response (really the rate of torque increase) then you can't get any snap out of the system. The control loop has to know about RPM to work the way we want it.
If the "soft start" you mention was a soft rpm rise, but not necessarily a soft torque increase, it would be a completely different feel. You could still get really solid power & acceleration out, but without the crazy runaway that uncontrolled rpm rise gives. At some point you'd hit the limits of the RPM rise rate, and that's when you'd need to be using clutch to step up the snap.
 
Back
Top