MTM5

[MrVibrating]

Real world build:

I recently destroyed what would have been a perfect frame to test this.... that always seems to be the way. Had I kept it, it would have just gathered dust and got in the way.

Getting power to the moving arm, although annoying, isn't the biggest problem. A stepper motor is not efficient. Unless there is a mechanical equivalent action to replace the motor, we will need to install some sensors and control system, again Arduino is easy. Each time we get to a problem, it costs in energy. So it would need to be driven by 2 efficient motors (95% is a pipe dream here), then we might lose some efficiency on the bearing/power transfer, then we need some extra power for the sensors and drive circuitry. So what we need is a configuration in sim world that already maximises COP.

The other problem is efficient motors cost $$$... so there has to be some confidence on my part before I would spend thousands of dollars on a build. (do it once, do it right).

I think as far as motors go, it would be better to have two equal and electronically synced "flails" to balance forces on the main axle. And also to balance the mechanism with gravity (if we are not going to try to use gravity in the interaction.) Gravity could offer an opportunity to harvest energy. I am thinking the main disk as a flywheel, initially spin it up to operating speed, then use the energy gain to spin the wheel/ Gravity will try to accelerate and decelerate the main wheel.

The main motor on the big axis i've taken to labelling 'motogen' but in reality of course there's no off the shelf component that fits that bill.. which is why i think we should be looking at other options such a rotary springs, which will both accelerate and brake conservatively, or even that self-regulating flywheel principle i've shown where radially-sliding weights stretch springs, effectively governing rotation speed - also conservative - or else a GPE load or whatevs.

I appreciate that two motors and some controller code is little challenge to the modern hobbyist, but i don't doubt anyone's abilities to replicate the apparent motions, so much as the causative principles causing the gain..

The point of using folding planar linkages instead of wheels is purely functional - it's more easily adjustable for the purposes of learning the lay of the land - but it does also mimic the appearance of the familiar flailing motion, which is a trigger word for us lot due to its reference in AP.

So to be absolutely clear, it is not a flailing action, flailing works because of CoM not in spite of it, and its resemblance here is both circumstantial and potentially highly misleading - so if anyone's thinking about trying to coordinate flails, that's not this and IMHO not going to work.

• a flail is freely rotating about its axis

• the exploit here is a form of kiiking (harnessing angular momentum from a force * time asymmetry) that involves sinking counter-angular momentum to CF force and time, slowing the weight's descent or downswing, and increasing the drop's momentum yield.

• thus the small axis rotates around the tip of the longer axis not because its passive momentum has carried it around, but rather because it spun up for the first half of its drop, and was spun down during the second half of its drop, dumping its momentum into the green axis and so accelerating it; then it spins up the other way and back down again whilst rising.

The point is that the blue axis is rotating around the green axis not because it's passively flailing (even though it looks kinematically similar) but because its motion is being driven by these angular accelerations about its own axes, and their resulting counter-accelerations induced on the green axis.

To put it another way, it's important to recognise that this 'flail' is being driven not by rotating the long axis, but by spinning and despinning the weight on the end of the short axis, which is never flopping around but is actually controlling its relative rotation around the green axis - it's literally the green axis that is flopping around in response to the constant accelerations and decelerations on the blue axis. Flail-drives-thresher, if you will..

So it's not the flailing aspect that needs replicating, so much as the kiiking principle causing it, which is best observed and considered from within the rotating reference frame causing the CF force - as if kiiking under gravity. This is why the gain is arising. It's juggling momentum in a way that a simple flailing action cannot..

Sorry, don't mean to lecture or moan, just don't wanna see anyone wasting time and effort from getting the wrong end of the flail.

[MrVibrating]

Anyone able to take integrals, my best single-cycle efficiency so far is 194% - teasingly close to that nice round number, but honestly, trying to drag it upwards is like pulling teeth; you get one variable seemingly optimised, then changing anther one throws it out of whack again. There's a key interplay between things like weight, its MoI and its spin-up speed, for instance, that CoP is sensitive to.

It's easy to go large and just pile on the mass and radius, but obviously better to wring the max potential from the given mass and size first. It's tedious, time-consuming, but informative in getting a feel for the gradient and relevant dynamics.

This is all i'm planning to do for now anyway.. whenever i get the time, i'll be tweaking for CoP and a better grasp of the interaction..

[Tarsier79]

So it's not the flailing aspect that needs replicating, so much as the kiiking principle causing it, which is best observed and considered from within the rotating reference frame causing the CF force - as if kiiking under gravity.

yes, I must have been thinking this over in my sleep, because when I woke up it seemed reasonably clear.

If the green arm was a wheel and we increased its MOI or weight, does it enable us to put more energy in per cycle?

[Tarsier79]

194% means to me that we could use cheaper motors...

[MrVibrating]

So it's not the flailing aspect that needs replicating, so much as the kiiking principle causing it, which is best observed and considered from within the rotating reference frame causing the CF force - as if kiiking under gravity.

yes, I must have been thinking this over in my sleep, because when I woke up it seemed reasonably clear.

If the green arm was a wheel and we increased its MOI or weight, does it enable us to put more energy in per cycle?

Minimising that particular MoI was a key performance variable - if you have any carbon fibre lying around.. Obviously, the transfer of conserved angular momentum from the higher MoI on the de-spinning weight will result in a big acceleration kick, and the gain margin seems to appreciate this..

But practical reality will be a matter of strength and how much force it can handle, vs lightness.

For now however i haven't given much attention to tweaking either the relative or absolute radii - i've just been tuning MoI's to weight and spin-up speed, for a given radius ratio and RPM. The current radii are thus a bit arbitrary, and there might be a bit more CoP available there at least, it's on my list the next opportunity i get to spend time bashing integrals.. I currently get three-day weekends so that'll be my next chance to deep-dive.

I have every expectation we'll nail the distilled gain dynamics in short order, which ratios are best for what and why etc.

But yes, nigh-on 200% makes for a viable prospect - and remember, that's just for the single-cycle; the CoP accumulates over successive cycles as the green axis gains speed. Or, likewise, presumably, as more mechanisms are added..

[MrVibrating]

Back in the previous MTM thread i showed a self-governing flywheel principle which may be useful here. I'll briefly describe it again:

• make a flywheel with weights being pulled outwards radially by CF force, thus stretching springs

• CF force squares with angular velocity, and the elastic potential energy stored in a spring squares with displacement per Hooke's law..

• ..thus they both mutually square as the system gains angular velocity, converging asymptotically towards some finite maximum speed and radius

The result is a flywheel that will continue to absorb and store more energy, yet without gaining any more speed, or growing appreciably wider in radius.

When the applied torque to the wheel is reversed, attempting to slow it down, any deceleration eases back on the CF so allowing the springs to begin retracting the masses back inwards; this however incurring the ice-skater effect wherein reducing mass radius and thus MoI causes compensatory acceleration to maintain net angular momentum..

..hence once up to its sweet-spot speed - obviously, over the knee of the curve of the converging CF and EPE plots - this flywheel resists both acceleration and deceleration, storing and releasing EPE as the CF force varies in response to the sign and magnitude of torques applied to it.

Watching our little robot arm friend swinging his thing there, this self-governing flywheel seems the perfect compliment - it can replace the 'motogen' and perform exactly the same job of maintaining speed, whilst fully conserving all energy.

What we would thus expect to see is the EPE levels increasing over successive cycles, instead of the present KE rise and negative work done against the motogen.

As an additional bonus, EPE can be metered in real-time, dispensing with the need for an integral on the output energy.

This would still leave the kiiking motor awaiting a better solution, but it gets rid of the dumbest of the two motors, which simply has to hold speed and conserve energy.. It seems obvious at this stage that it's the perfect partner both for regulating RPM and for practical harnessing and metering of the gains..

I think i'll make this my next goal:

• design a self-regulating flywheel that, once fully energised, obstinately refuses to budge from a convergent 2 rad/s target speed

Then it's simply a matter of revving it up via a motor until the radius and CF plots are on the horizontal stretch of their curves, at which point we can replace the motor with one of these armatures, sit back and watch the EPE plot climb steadily and constantly. The flywheel will effectively act as both regulator and rectifier, and as an accumulator for the gains.

Tell me this ain't a match made in heaven..

[agor95]

Hello MrVibrating

... energy stored in a spring squares with displacement per Hooke's law ...

Most people think it scales linearly. Unless you are implementing a leaf spring or SB spring;
where the 'K' changes with displacement.

Your concept has similarities to the physics present in the attached animation.

Regards

[MrVibrating]

You say "Hookes law" i think "kx²". But WM also offers x³ as a realistic option, which serves even better for resisting acceleration.

I've just spun up some tests, and i daresay this is going to work excellently..

What it apparently boils down to is acceleration curves; in principle it's not necessary to have a monster-heavy flywheel under high sprung preload, nor indeed a smaller, lighter one spun up to dizzying speed via gearing - what really matters is the relative acceleration curves; so long as the flywheel accelerates more slowly in response to the torques from the armature than the armature itself, by my reckoning it should progressively begin to rectify gain and regulate system speed.

In sim-world at least, this should make a neatly-closed system of the main axis. Doubtless there'll be resonance issues and wotnot to sort out, but the basic dynamics are there.. the flywheel can be prepped in the priming phase for a stable start already at-speed, then it's just sit back and watch the EPE climb..

[MrVibrating]

Just hit on another possible innovation - because the radially-sprung masses are prone to bouncing in and out in response to accelerations, inducing wild inertial torque resonances, i'd initially been using dampers, which are lossy and difficult to meter for those losses (better calculated independently).

However a fully-conservative solution would be to buffer out those resonances not with a dissipative damper, but simply another flywheel, perhaps mounted coaxially, or a pair of balanced flywheels mounted to the sprung flywheel, whatevs - basically relying on the additional on-board angular inertia of these sub-flywheels to conservatively smooth out those resonances..

It's just that you can easily foresee the varying torque sign on the main axis playing havoc with radial bounce in the sprung weights, setting up a performance-sapping resonance via the ice-skater effect..

[MrVibrating]

Hmm. Going back to the 5.3 rig, the last version still using discs, i set a high MoI to the base wheel then set the motor to off once primed, the main axis thus coasting, obviously expecting to see the wheel's high inertia begin to buffer gain and accelerate..

..but nada, it just oscillates, while the green axis continues accelerating. This would seem to shoot down my reasoning that rectification's simply a matter of relative acceleration curves..

The sprung flywheel concept does still accelerate, its rate of acceleration just decreases with RPM, but can never actually reach zero, hence in principle a really heavy MoI should do about the same job, no? Yet if that doesn't work, why should this?

Or perhaps it's something to do with reactive feedback and inertial symmetry / N3 or summink - the motor prevents any acceleration at all, whereas the flywheel speeds up and slows down the same amount over a full cycle, no matter how small the increments as a function of MoI..

More testing needed here..

[agor95]

You say "Hookes law" i think "kx²". But WM also offers x³ as a realistic option, which serves even better for resisting acceleration.

Hookes Law is F = Kx

So 1 metre of distortion times by 'K' generates the force present in Newtons.
Distort 2 metres then double the force.

No power 2 or 3

That is what I see when searching the web on Hookes Law.

A leaf spring may have a variable 'K' spring stiffness that will give you the effect you want.

Now the Force available can accelerate a mass.

Regards

[MrVibrating]

It squares or cubes because the constant 'k' is changing as a function of loading - ie. as the amount of available displacement or 'x' (or elastic 'give' in the spring) is used up.. ie. so in practical terms at double the spring tension it presents four times the resistance or whatevs.

WM actually offers six different formulas for k - k, kx, kx/2, kx/3 as well as kx² and kx³.

The actual EPE formula i type into a meter to measure the energy is ½kx² - again, double the displacement, 4x the PE.

Don't worry i've been measuring EPE for years without any issue.

My more immediate concern is getting a better grasp on the gain dynamics, harvesting constraints etc. etc.

[MrVibrating]

Possible idea for alternative harvesting of the PE gain via a rotary spring:

• my standard practice these days when mounting a motor on an axis is to also add a pin joint, in the expectation that i might want to switch off the motor at some point, thus immediately enabling the pin joint in the next frame; WM complains if two or more joints are active on the same axis ("redundant constraints"), so i'm used to enabling and disabling 'em on the fly without issue..

• why not try this with a rotary spring on the wheel axis; disable the motor in the last half-stroke - the inbound stroke carrying this apparent PE gain - switching to the spring, collect the energy and stop back at TDC to measure what i've caught..

To avoid spikes i could match the spring torque to that of the motor prior to the switchover; it's kludgey and only possible in sim-world, but just as a sanity check and temporary alternative to the motor harnessing method, it might be worth a try..

[Fletcher]

Yeah .. I pin (rotating hinge/axle) to background before I place the driving motor over top .. then as you say if the motor is deactivated/switched off the background body (and OFFED motor) doesn't fall off the page or fly away etc .. I ignore the redundant constraints message because it doesn't affect the sim integrity ..

Sounds like it is worth a try with the rotational spring element instead of a pin joint ..

[MrVibrating]

Killed it.

Confused by the fact that my earlier idea of relying on the wheel's own MoI to regulate and rectify the gain didn't work, tonight i've come back to the same kinds of experiments:

• i upped the main wheel MoI to planetary scales; primed to its default 2 rad/s, there's nothing you can do on the rig that's gonna accelerate it in the slightest, it just holds that interminable speed as you'd expect. Result: no gain from the interaction cycle..

• retaining the same planetary-scale MoI, i then added the motor back onto the rig and repeated the interaction. Result: the gain returned, just as before.

• finally i gave the main wheel nearo-zero MoI and respun the interaction: again, the gain remained unchanged..

These results are irreconcilable with reality - if the work being done against the motor was performed by the inbound weight as appeared to be the case, then raising the wheel inertia high enough would render the MoI variation caused by the inbound weight negligible, it'd be down in the noise if even detectable. We'd literally be talking a net wheel MoI variation of 1e-5%. F=mA (or its angular equivalents) - seeing that trace recur despite there being no significant acceleration of the wheel for the motor to even compensate in the first place implies it's some kind of ghost in the machine.

Similarly, when making the wheel light as a feather, the ice-skater effect from moving the 1 kg weight inwards should give a massive kick to the system, requiring more corrective torque over angle from the wheel motor.. Yet instead we get exactly the same 'excess free energy' in the wheel motor plots as when the wheel's as heavy as a planet and so should be impervious to such a relatively piddling torque..

Basically my thinking earlier was legit - if the gain were real, the wheel motor could be replaced by a very heavy inertia - this would be functionally identical in terms of holding constant speed whilst progressively accumulating the gains - and the instant that test failed i began to see this whole thing unwinding.

It's a false positive. And a bugger of an example - it's clear now that there is no legitimate reason for that wheel motor plot to be showing anything at all when the wheel has a planet's MoI and is already spun up to speed prior to the interaction, it should be accentuated by minimising the wheel's MoI yet it isn't.. the gain simply has no right to be there.

The fact that it is there, and that it responds in a repeatable way to tweaking of other parameters, makes it a really pernicious software bug. There's nothing extreme about the original config, with everything set to '1' by default or '2' if that were too low to see its effect - nothing under duress, i did nothing abusive, hacky or non-standard in the sim design.. what can i say.. Damned ghost in the machine.

Anyone disagree with my conclusions? It's over, isn't it?