MTM5

[Fletcher]

Well, you are doing the right thing - running everything down where you can, and then standing back for breathing space and applying the Classical Physics and Mechanics ruler against it ..

If it's a bug, it is what it is - but it would be good to know exactly what, where, why, and the how of it manifesting - to avoid future icebergs ..

[Fletcher]

MrV this may have some relevance and bearing to what you are finding in WM, or not .. the energies are not being metered correctly, and the rings not resetting original height correctly either, imo ..

https://www.besslerwheel.com/forum/view ... 22#p205522

[MrVibrating]

Well i'll spare everyone the pointless anims, but replacing the central motor with a pre-loaded spring kills the effect, scoring perfect unity.

However, unlocking the 'world' mass from the background and measuring the torques being applied to it, the negative torque curve being plotted by the motogen meter is also being applied to the planet. In other words the torque responsible for the gain is in full observance of N3; the motor is applying negative / braking torque to resist the main armature's acceleration, and that torque in turn is being correctly grounded by the motor to whatever it's attached to.

So the motor isn't making up the torque, and is commuting counter-forces between bodies correctly.

Although it's something i've checked countless times in the past, i tested a control case of simply pulling a mass inwards radially on a constant-speed rotating disc, again showing perfect unity. So the torque isn't, exclusively at least, the ice-skater effect from the diminishing radius - there's obviously a positive torque component from the inbound MoI, but that doesn't seem to correspond to the anomalous positive torque curve.

Furthermore the torque curve arises over a finite range of angle of the secondary armature - about 80° - the sim set to pause as it returns to the zero line. Since it doesn't correlate to purely rotational forces or the ice-skater effect from reducing radius, this only leaves translational forces; as i previously surmised, the torque curve must result from an interplay of rotational and translational forces and counter-forces, the translationals dominating..

This seems to implicate - by elimination - an anomalous inversion of translational counterforces at the secondary axis; the sim's not making up torque from thin-air, but applying a dubious reversal of counter-torque at the free axis.

My impression is thus that rather than an outright error, we may be looking at a kind of 'Hal 9000' bind of conflicting demands:

• The difference between a motor controlled for constant velocity or acceleration, versus a spring or just a heavy inertia, is that the latter still reacts, whereas the former - by design - drives on relentlessly at whatever the prescribed speed or acceleration rate.

• This reactivity, no matter how slight, is never non-trivial when it comes to calculating directions of counterforces at the free secondary axis.

In other words, prescribing, in a top-down way, control of speed or acceleration in any interaction in which those values would, in reality, be reactive, seems to throw a spanner in the works of how WM applies counter-forces. The anomalous torque curve would then be the sum of inertial torque from the MoI change, plus translational forces, plus the translational counterforces.

Inversion of counterforce at the free secondary axis would seem consistent with the noted symmetry between KE and PE gains..

Could be wrong about any of this of course but this is my current impression. Is it the same problem arising under CF as well as sprung tension? Presumably, but this needs further analysis.

Might the error nonetheless be implicating a real possibility - ie. does lack of reactivity at the central axis plausibly cause an inversion of counterforces at the secondary axis, in a manner that could be reproduced physically? The only test of this i can currently conceive of is the reactive flywheel concept i've tried previously, applying tightly-coordinated inertial torques from the ice-skater effect to resist acceleration or deceleration of the main axis, using linear actuators. The sticking-spot there was data quality took a hit from the actuators' reactive control loop. Yet even if this could be implemented using more succinct formulae, the result may simply be once again enforcing the same fault condition.

Ultimately, the version being accelerated by a rotary spring should be more or less identical to the one being accelerated by a motor, in terms of distributions of counterforces. In short, it appears that the translational counterforces from the 'lollipop' end of the flail are being inverted at its free axis with the driven main armature, and that the resulting feedback loop is producing the mirror-image KE and PE gains. I'll continue to mull it over, poke and prod at the various incarnations under different stacking forces (CF, gravity), and try to better understand what's happening and why, but all i see for now is red flags.

The original intention of checking the PE:KE efficiency of kiiking by torquing a satellite flywheel remains outstanding; i've established that the k-motor workload is always unity in its respective FoR, as intended, but not that its resulting KE value isn't being transposed by discounted velocity deltas from the full 360° kiiking cycle, since that efficiency is currently inextricably tied up with that of this dodgy N3 inversion..

So there's more follow-on yet to be done, and i've learned a few things such as how to deal with compound momenta.. It would also be reassuring to be able to plot the anomalous torque curve from first-principles, although i've not managed this yet (i've tried deducing it via N2 by multiplying the lollipop's MoI by its acceleration but this alone doesn't reproduce the curve, which obviously results from more-complex feedbacks). Controlling motors for 'torque' rather than velocity or acceleration also probably warrants further investigation..

[MrVibrating]

@Fletch - had a look, but accounting for dissipation is sketchy when it's constantly in flux; both disc and ring can bounce and skip somewhat, the latter apparently moreso, dissipating GPE to collisions rather than conversion to rotKE.

Even when dissipation rates are constant, such as applying a damper to a constant driven motion, you have to independently calculate the losses in parallel to the sim rather than integrate the forces detected by the damper, which produce junk results.. This is partly why i always try to avoid dissipative losses unless they're part of the plan, deducing rather than directly measuring them where necessary..

I remain of the opinion a real gain will present as a discounted torque * angle plot and that WM can and will plot this out correctly when we find Bessler's exploit..

[MrVibrating]

Just re-checked the CF version by replacing the k-motor with a rigid joint, and found unity at both a quarter-cycle and full cycle.

So in the CF version at least, the gain is dependent upon the satellite motor.

Unlike the sprung version.

The quarter-cycle result was this:

delta KE = 3.73210068
motogen T*a = 3.731423891

..which also thus leaves no room for the CFPE delta, which, as i'd suspected, is already accounted for in the motogen integral.

So is the CF version also inverting counter-torque from torquing the weight? And if so, legitimately or not?

I had doubts about the sprung version grounding momenta between the 'free' and controlled axes, whereas in the CF version the free axis remains inertially isolated, assuming perfect bearings. The differences between the two versions are evidently significant enough that they produce different results under ostensibly the same conditions.

More investigation's thus required.. presumably, replacing the motogen with a rotary spring will again kill the gain, but i need to re-check this, and then understand exactly why, if possible..

[MrVibrating]

Damn - i honestly thought i'd nixed it. I was seriously in the 'relief' stage where you're just glad it's all over. Ah well, i needed the rest..

So i've just done that last experiment; here, the central motor is only used for priming the initial velocity, disabling after the first frame, and replaced by a pre-tensioned rotary spring, thus accelerating the main axis using only sprung torque:



And the max-freq results:

delta KE = 300.98264596 - 6.25177460 = 294.73087136
k-motor T*a = -28.43643318
spring T*a = 259.762143
net out = 294.73087136
net in = 231.32570982
diff = 63.40516154
CoP = 1.274

Note that the spring is actually performing work against the k-motor now. The obvious implication is that the k-motor could also be replaced by a spring, and so i'll have to try this next.

It does appear however that there's an ongoing N3 break between the two axes..

I also performed a max-freq control run of the identical config, only disabling the k-motor and replacing it with a rigid joint:



dKE = 174.59813559 - 6.25137170 = 168.34676389
sTa = 168.3395521
diff = 0.00721179

..as ever, i can always trade CPU time for more zeros there but the system's obviously well-calibrated; the rotary spring appears to be insulated from the k-motor's counter-torque, essentially allowing it to undergo unilateral acceleration sans recoil.. as if the counter-torque's being sunk to CF force and time.

Again, i'm reminded that Bessler's hand-sketched addendum to the Toys page seems to implicate the upturned whistling top as the "children's game in which there is something extraordinary for those who know how to apply it in another way"..

[MrVibrating]

Realising that the wheel spring preload was supposed to be in radians rather than degrees, i switched it down to slightly less-aggressive values, and then swapped out the k-motor for another rotary spring:



..achieving similar efficiency to the semi-motorised CoP:

dKE = 26.62488862 - 5.75029063 = 20.87459799
kTa = -2.178697237
wTa = 18.69539729
net in = 16.516700053
net out = 20.87459799
diff = 4.357897937
CoP = 1.263

For a fairly-arbitrary and unoptimised initial config this seems a most satisfactory result; the proof of principle's there, it seems..

I'll update the sim accordingly, probably keeping the integrals as a safety-check but also adding the scalar EPE's which can thus be appraised at a glance or even summed against the KE delta right there in the sim for an instant CoP reading..

The basic gist however is that the central spring appears to be insulated from the satellite spring's counter-torques by the intervening CF force; the 'k-spring' wants to counter-rotate the free green axis, but CF force is causing it to co-rotate instead. The acceleration from CF force is thus adding to the absolute KE value of the k-spring output workload.

You can see how poorly-optimised the current results are in the velocity plots - ideally we'd want consistent acceleration on all three axes throughout the interaction; this could be tweaked via the springs, or simply by curtailing the net change in angle to catch it at a higher CoP before the velocities plateau and begin decelerating (there's no intrinsic reason it has to be a square 90°). Also, other brands of torque are available (spooled GPE's, pulley systems etc.)

Over 125% with a noise-floor down in the zeros, using three moving parts and two springs.. seems legit to me; it's basically buildable already as a single-shot experiment, given adequate measurement ability. The next obvious objective for simulation though is purely-mechanical closed-looping; we can already see that the central spring effectively rewinds the satellite spring, so all that's needed is harnessing the gain to re-tension the central spring.. Which can presumably be accomplished by simply allowing the wheel to continue its rotation, ultimately rewinding the central spring in the opposite direction..

[MrVibrating]

Currently, the CF-PE is constrained by the radius of the free rotor the weight's attached to.

Suppose instead that the CF-PE is delegated to a pair of balanced radially-sliding weights; as these are pulled outwards under CF force, they tug on a cord.. the cord spools off of a small-radius reel, spinning it up.. and finally a larger-radius flywheel is then torqued against that reel:

• this decouples the available CF-PE from the radius and speed of the secondary rotor, affording more overhead for sinking counter-torque

• it also however eliminates the inertial isolation condition; if this is critical to the gain condition then it won't work, yet i haven't tested this assumption

The next test should thus try actively torquing the green rotor against the base wheel, to see if we still harness a gain from CF force regardless.

If so, then i can proceed with trying the above modification. If not then it still needed verifying either way, so we're better informed on more plausible optimisations..

[MrVibrating]

For this test i simply left the rotor 'priming motor' running, at its constant 1 rad/s set speed, whilst logging its torque * angle:



dKE = 51.66266262 - 5.69647122 = 45.9661914
kiking spring Ta = -19.47433519
wheel spring Ta = 24.96669587
rotor motor Ta = 1.306394557

net in = 24.96669587 + 1.306394557 = 26.273090427
net out = 45.9661914 + 19.47433519 = 65.44052659
diff = 39.167436163
CoP = 2.491

Bit of a rough'n'ready test - i could've used another rotary spring but the motor was already there - far from constraining the gain however it's boosted it by a factor of six.. The velocity plots are more consistent too, showing constant acceleration on the other axes.


So this in turn paves the way for more-flexible embodiments, decoupling the CF-PE workload from the rotor speed; in principle, we can harness more CF-PE (using more weight over more radius) against which to sink counter-torque, while significantly increasing the speed of the green rotor and thus the velocity divergence of the flywheel spin-up..

For example, suppose a small travel of radially-sliding weights under CF force translates to many turns of the reel, upon which is attached the flywheel; accelerating the flywheel against the reel thus sinks the corresponding counter-torques to CF force and time - as here - except now, instead of accelerating from the wheel's base speed, we're launching off from the much-faster reel, and a 1 rad/s acceleration when already at, say, 10 rad/s is worth 100x the KE of the same acceleration from 1 rad/s, just as an off-the-cuff example.. This possibility now seems green-lit by the above result..

..which means it's time for a new version.

Simple plan:

• a pair of radially-sliding weights are slowly pulled outwards by CF force; their outwards-acceleration limited by torquing the reel, spinning it up

• a flywheel is attached to the reel via a motor or rotary spring, spinning it up whilst using the reel as a kind of reactionless launchpad

• counter-torques from this flywheel spin-up are thus sunk to CF force as before, except now we have an even larger velocity divergence..

If it works as intended then we should be able to achieve efficiencies much greater than the 2.5 CoP above..

[MrVibrating]

Here's a preview of what i have in mind:



..so that's a wheel currently being turned by a motor to generate CF force, thus dragging the two masses outwards. You gotta squint to see it, but they're spooling off of a tiny central reel (small radius = high gearing / speed).

That reel is the platform relative to which i'm going to torque a flywheel. So i'll probably start out with a motor and a flywheel with say an MoI of '1', attached to that central reel; as it spins up, i'll be torquing the flywheel in the same direction, the resulting counter-torque will thus be resisting the reel's acceleration from CF force pulling on those two masses.

The masses will thus be slowly dragged outwards instead of freely accelerating outwards. In the process, they'll be sinking counter-torque from spinning up the motorised flywheel that i'm going to attach to that reel.

The intended outcome is that the reel's CF-PE driven spin boosts the absolute change in velocity of the flywheel applied by its motor, transposing its KE value up the V² multiplier. If the gain's arising in the manner i think it is, this should supercharge the effect, giving even higher CoP's..

[MrVibrating]

Didn't work - sim attached but it's bare-bones and not worth more time. The gain condition thus isn't simply sinking counter-torques to CF force, at least, not in this way.

I suspect that interaction between translational and rotational components is critical - ie. weight moves left so wheel is displaced right - since the only substantive difference with radially-sliding weights seems to be the trajectories.

I guess the best option for now is to stick with the 5.3 config, and try to get more familiar with how and why it works by tuning it further. A 2.5 CoP from three parts and three springs is already blinding, but there's presumably more there, with a bit of tweaking.. Torquing the secondary axis has opened up this additional optimisation parameter that i'd wrongly assumed would be inimical to the effect, so it's probably worth spending some time logging trends and interplays there.. I'm gonna polish up that sim with summed EPE scalars so i can plot CoP in real-time and make the most of freedom from damn integrals, get some rapid-prototyping in..

[MrVibrating]

Might just have finally killed it; i re-used the k-motor integral when replacing it with a spring by simply changing the constraint number over. The X and Y axes had been inverted however to take account of the relative motor direction. That was fine when it was measuring the motor, but when i changed it to a rotary spring, the directions of the axes needed reverting. Correcting this shows unity for the 5.3 config under spring power.

Going back to the motorised version i then tried a calibration run, by setting wheel speed to zero and giving the green rotor a push-start as before; the k-motor code then spins up the weight as a function of the green disc's angle relative to the main wheel. With the main wheel stationary and thus no CF force, the counter-torque from spinning up the weight decelerates the priming velocity given to the green rotor, culminating in the green rotor also coming to a halt, the weight reaching a max speed of 2 rad/s, of the 12 rad/s it's set to attain upon the green rotor reaching 90° of rotation. This increases net KE from its initial value of 0.5 J from the priming phase, to a final value of 2 J. Taking the k-motor integral at this stage however only logs 0.7 J, even though there is no tenable reason for a non-unity result. Half the input energy simply hasn't been logged.

Controlling the k-motor for a straightforward 1 rad/s acceleration instead shows unity as expected, implying that the live run is producing faulty data on the k-motor integrals.

Maddening eh - each version of the interaction has indicated an N3 break, but due to differing fault modes. I'll keep prodding it to see if i can find any persistent anomaly, but it looks like it's a bust on all fronts for now..