Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

Well first off, here's that easy option in action:



..so the small orange pendulum is just swinging naturally under gravity; this would be hidden - it's purely there as a signal gennie - and this solution has certain undeniable merits:

• the reference pendulm's hung from a motor controlled for 'torque' but with the value set to zero; so it's just a passive swing

• the 'active' lever is controlled for 'rotation' (angle), with the value simply set to that of the orange one's inactive motor

• the active one's thus still applying counter-torque to the background, and would likewise do so if attached to a wheel..


So.. it'd work, and also produce clean data.. it's a bit of a cop-out on the old engineering maths tho, right?

Yet how could i reproduce that same rotation profile from 1st principles..? Without using a hidden 'physical' reference motion?

[MrVibrating]

The function -Pi+mod(t,2*Pi) would produce a number that began at -3.14 and rose up thru zero to +3.14.. or whatever range of angle desired..

..likewise i could combine some input-set or variable multiplier to the value of 't' (time) to increase or decrease speed..

..then use basic logic functions to invert it back down from positive to negative values (at present it just climbs up then flips instantaneously back to its min value).

Something like this, then?

I'm sure any engineer who works with pendulums or oscillating actions would be face-palming at all these ideas thus far.. (i know i should be employing sin/cos functions here, but how?)

[MrVibrating]

I think - just in the interests of getting the flip on with it and accomplishing the objective - the hidden physical signal generator is the better option for now, no?

Since we know if the motor controller code's anything less than exquisitely simple, the resulting work integrals are likely to solve to spurious measures of OU, just right off the bat, you can almost guarantee it..

[Georg Künstler]

Hi MrVibrating,

the ground problem is hidden in the indirect impact.

A collision of the frames will cause the pendulum to build up potential energy.

So the collision which is described from the eyewitness is an essential construction element.

The next step what has to be considdered is that both frames can move in the same direction with differnent speeds.

So depending on the speed difference we get an upswing of the pendulums.

It was described that the wheel was self accelerating.
So the wheel is using the speed difference from the internal construction to the external construction to drive the wheel.

The first indirect impact will lift he pendulum weights as most.
During the acceleration of the outer wheel the speed difference is reduced until the wheel is running with its natural frequency.

[MrVibrating]

..not sure what you're on about re. 'indirect impact' - from your illustration it seems you're thinking about accelerations applied to a pendulum's axis? As a means of adding energy / momentum to it?

FWIW i'm only considering using a pendulum here as an external signal generator to shape a torque profile - instead of using a longer equation that will likely fall foul of WM2D's inherent bugs.

So i'm going to set up a wheel containing weighted levers / armatures that will be positively torqued at their axes, not swinging passively. Whereas a 'pendulum' is applying no counter-torque at its axis, just passively swinging, i specifically want counter-torques - it's the whole point of swinging the proposed weight levers. So, lever is torqued one way, wheel is counter-torqued in the opposite direction.

I've only delayed to give myself or anyone else a chance to think up a cleaner solution; i can take the clock signal and modulate it into a number that varies between a given range, that range could be user-set by an exposed input multiplier and thus used as an input-selectable range of swing angle, and likewise, i could then take that range of angle and modulate it to produce a number that tends to zero at the apices, again exposing a separate input-set multiplier to select peak speed midway between those apices.. IOW programming what looks like a 'pendulum swing', but which is actually producing counter-torques back to the wheel (which a real pendulum does not).

Past experience however suggests this equation would be too complex for WM's flaky integration accuracy - so it'd work fine functionally, producing the desired motions and counter-torques, but while introducing significant inaccuracies in the logged data. Typically, these errors are small on a per-frame basis, but thus accumulate to significance the more frames per unit time are used.. IOW, the higher you raise the supposed 'accuracy' controls, the greater the degree of introduced error, so a sim running at say 200 Hz with 1 integration step per frame may produce a half-decent accuracy, but trying to improve it by going to 10 kHz with 100 integration steps per frame will result in a monster error.

Because you expect a sim to produce accurate data, this kinda undermines the whole point - a false positive just means a shed-load more work, hours and pages of running the same interaction at different precision settings, just chasing down what was always destined to be a unity outcome.

Thus the idea of using a 'real' pendulum as a signal generator - not mechanically interacting with the system at all, just off to the side doing its own thing but outputting reliable data. I can then simply read off its changing angle, and re-input that 'pure', simple angle data to the weight levers in the actual mechanism under investigation, thus without using any equations at all to control their motion, and hopefully maintaining maximal precision whatever the sim frequency.

In short it's not enough to merely be animating spinny things for the sake of it - the whole point is measuring I/O energy efficiency, so clean data is the sole purpose and no. 1 priority.

This is the only reason and context in which i'm considering applying a 'pendulum' here - not as part of the machine, but purely as a passive, inert signal generator..

[MrVibrating]

To put it another way, in Georg's system, any accelerations applied to the 'frame' will affect the swing (that's his whole point).

In my proposed system, the swing will be completely unaffected by any accelerations applied to the frame (my whole point).

We will see changes in the torque * angle profile of the motor controlling the swing however - again, the whole point of the experiment - just without altering the swing itself relative to the wheel it's mounted to.


ETA: again, to recap - i'm investigating the implications of the fact that, as literally-depicted, the hammer toys in MT 138 - 141 are each swinging their hammers in the same angular direction on each shift phase.

So the upper toy rotates both levers clockwise, say, 90° later the lower toy swings both of its levers anti-clockwise.

The interactions of the resulting counter-torques being applied back to the wheel, in conjunction with the effects of gravitation of the lever weights, is the focus of my current curiosity, which for now is entirely speculative and investigatory, not chasing any particular expectation or exploit, besides the ultimate objective of stabilising the energy costs of momentum from gravity and time, invariant of some range of rising RPM per the maths detailed on previous pages.

[MrVibrating]

Tried all 4 combos of lever sync (equal vs opposing directions), as well as a range of startup RPM's..



..and it's a wobbler.

No net acceleration.

Like Georg says, some kind of collision would be necessary. No idea what, where or when tho.

This is stupid. Screw you guys, i'm going home..

[Georg Künstler]

Hi MrVibrating,
you still get not the point what I liked to show you with the indrect impact.

A pendulum has a mass M which hanging on the frame.
During the indirect impact the weight on the frame is multiplied.
The pendulum is beeing shot upwards against gravity.

Depending on the indirect impact speed, the pendulum can also rotate.
But that is not used in Besslers wheel, he only need a rising of about 45 degrees.

So if a body is heavy or light is depending on the moving direction of the body in the gravity field.

With the indirect impact I move,lift a body against gravity and therefore the force downwards is higher.

[MrVibrating]

I suspect i've not given you sufficient credit sir, however i can only formulate the problem and potential solutions in terms of momentum and energy equations, in relation to frames of reference; the fundamental problem of breaking input / output energy symmetry being a reference frame issue, and all reference frames being effectively interlinked to the same 'super' reference frame (or absolute frame) by the effects of Newton's 3rd law; because of N3, I/O metrics are using the same FoR to enumerate things like 'velocity' and 'height', and furthermore any seeming appearance of an effective N3 violation vanishes when we zoom out one level; thus what may have seemed an 'open system' is seen to remain part of a larger system that remains closed.

Please don't take offence - i'm the biggest idiot out there, with no better results than anyone else - but have become resigned to accept that any proposed interaction that isn't addressing decoupling of I/O FoR's is just faffing around on the periphery, not addressing the core problems, and thus doomed to failure.

In short, anything other than grabbing the bull by the horns - ie. the fundamental causes of 'unity' - is futile. Anyone not singularly focused on the underlying causes of over (or under) unity has little chance of achieving either. If your frame of reference for 'velocity' and 'distance' or 'height' are both the same thing (ie. the ground / earth) then the system's closed, momentum's conserved, and output energy = input energy minus losses.


Almost everyone here wants to describe their proposed ideas in their own terms, in what they see as the relevant concepts, with scant regard to the fundamental physical principles above. Everyone and his dog. But the opportunities of time and effort, for all of us, are a scant resource. So for instance while i have the highest regard for say, John Collins and all his work in researching and publishing Bessler's biography and the documentary records of his witnesses, i have zero time for geometric puzzles or any mechanical speculations based therein, least of all 'secret' knowledge (ie. gnosis & esoterics). The only real 'players' are those planted in the realities of the reference frame issue / causes of unity / momentum & time symmetries. Mention N3 or N1 and you may pique my interest, otherwise you're probably just kicking around N2 and thus irrelevant to me or any potential solution.


Moreover, after forming hypotheses, 'science' involves testing them; anyone can daydream or sketch ideas, the real science is actually measuring things; it can be maths, sim or experiment, but anyone not producing measurements simply doesn't care to join the game proper. It's just aversion & distraction, excuses in place of results.

And even then; 'goto 10' - if someone's not addressing decoupling I/O FoR's then any anomalous measurements are almost certainly in error.

It ain't poker - all cards on the table, and 'showing your hand' = plugging the numbers. If those numbers are enumerated against the same FoR then comparing I/O energies is just playing snap.

My arm's almost healed, so i'm back to work in the next few weeks, and will have little free time for anything else, so have been spending almost every waking hour lately just working the problem, and remain serious in my commitment to actually solving it..

[MrVibrating]

Possible epiphany moment:

• instead of using a vMoI to directly gain the velocity component of momentum, what if we went for 'height' instead..?

• IOW, because gravity is an effective acceleration rather than a physical one, perhaps we should rather be attempting to gain 'potential' momentum..?

Physical example / potential experiment:

• suppose you're riding a rising elevator

• the elevator is lifted by a vMoI, from which the cable is spooled

• thus, whilst traveling upwards at constant speed, inside the lift car we raise a weight..

• ..this applies an additional downforce to the car per N3, now compensated by the vMoI, which maintains the lift speed regardless


I can test this in fairly short order by repurposing the previous 'back2basics' sim from the other week..

..all i need to do is reverse its direction, so instead of dropping the weight and using the vMoI to hold the drop speed constant, the 'weight' becomes a 'lift car', rising at constant speed (ie. 1 m/s), inside which we perform an additional GPE input, raising say 1 kg relative to the lift car.

Gimme an hour or so and i'll hopefully have it set up..

[MrVibrating]

So here's the setup:



Basically the same rig as before, only instead of using negative inertial torque to maintain drop speed, we're now using positive intertial torque to maintain lift speed; the former dead-weight now replaced by the lift cage.

As such the starting speeds are simply inverted, -1 rad/s and -1 m/s, the cage thus rising 1 meter in one second.

Net KE and net momentum are declining not because of deceleration, but simply because MoI's decreasing.


So all that's left to do is program the red actuator; ideally i suppose we want it to begin and end the run stationary relative to the cage floor, so that after the cage has risen the 1 meter the internal lift has been completed.

I'll also probably want to expose another input so that a variety of internal lift speeds (and thus relative lift heights) can be tried.

For now, the red actuator's P*t integral is incorporated with the same meter as the vMoI actuators; i'll seperate 'em out if the result's non-unity, just making more work otherwise.

(Just for clarity, in its present state the gain in GPE is expected to be equal to the drop in KE plus the work done by the vMoI actuators - little point checking it now unless the 'live' run doesn't resolve to unity, but there's no reason to expect any anomaly at this stage.)

Because the interaction period's just 1 second, the max freq is simply 32,765 frames divided by 1 sec = 32,765 Hz. Currently using 10 integration steps / frame.

Give it another half hour or so and should have the results..

[MrVibrating]

..still running the sim, but just thought of a pithy way of describing the premise: instead of using a vMoI to soak up recoil for an effective 'reactionless acceleration', here we're basically trying to perform a reactionless lift - so we're still using the vMoI to absorb recoil forces, but those from the internal GPE input, incorporating both its acceleration and deceleration phases (as the weight begins and ends stationary relative to the lift floor). A 'reactionless GPE input', in a rising FoR, type situation..

Results soon-as..

[MrVibrating]

OK here's the preliminary results:



• red actuator applies the input accel value for the first half-second, then inverts it for the final half-sec

This neatly brings it back to relative stasis at the final frame, although does cause a high internal force when it instantly flips sign at the halfway mark..

A cleaner solution would probably be to accelerate it up to some preset speed over a given time or height, so that it's no longer still accelerating when the deceleration phase begins; this would take more time to formulate tho.. in the meantime, this alone shouldn't account for the present I/O discrepancy:


@10 i-s/f:

GPE rise = 60.799 J

KE drop = 4.854 J

Acts P*t = 93.828496


@1 i-s/f:

GPE rise = 60.795 J

KE drop = 4.854 J

Acts P*t = 86.038802


..so two runs there (anim's from the latter run), both at max freq; big difference between the two net actuator integrals tho.

And so the debugging begins.. first off i'll separate the red / green actuator integrals, to see how they measure up individually.

We've obviously lost 4.854 J of KE either way, and gained nigh-on 60.8 J of GPE.. but 4.854 + 86.039 = 90.893 - 60.795 = 30.098 J under..

Decoupled I/O, or "bloody WM" again..?

If the former, since we're currently at over 2G internal acceleration, if we quarter that to about half a G, say 5 m/s², will we get an 'over' result..?

More likely of course it's just "bloody WM" again, tho..

Give it a bit more time and i'll see how the vMoI and internal-lift integrals solve separately.

The vMoI actuators are obvs. the more suspect of the two since they're running a reactive 'servo' loop - basically using any deviation from the preset wheel speed and running it thru a high multiplier to produce compensating changes in radial velocity of its radially-sliding masses. The higher that multiplier, the greater the compensating MoI changes and so the more tightly it holds the preset rotation speed.

The internal-lift actuator is just holding a constant acceleration value that flips sign halfway thru the lift, so should be that much more reliable.

Either way, measuring 'em individually should show where the discrepancy's arising..

..if we're lucky, most of the discrepancy is actually from the red actuator, which would lean towards it not being error, so much as a genuinely-interesting result (IE. successful I/O decoupling)..!

Most likely tho it's the damned vMoI integral and just in error; typically accumulating on a per-frame basis (so higher sim-frequency and/or i-s/f = greater error margin)..

But c'mon - perfect unity first try would just be dull; it's all about the craic, right?

[MrVibrating]

1 kHz @ 2 i/s-f:



GPE rise = 60.794 J

KE drop = -4.854 J

vMoI acts = 5.3071815

Lift act = 48.8927495

__


48.8927495 + 5.3071815 + 4.854 = 59.053931


60.794 - 59.053931 = +1.740069 J over..


Beginning to firm-up then.

I suppose i should measure up a baseline 'dry' run, without the internal lift activated, however note that as the lift enters its deceleration phase, the deceleration of the 1 kg weight is actually pulling the lift floor upwards, causing the vMoI to start to expand again, applying negative torque to prevent the rotation from accelerating..

Besides which, because the vMoI is reacting to the changing loads from the internal lift, solving it to unity without the lift mightn't be eliminating the error source, in which case we'd still get a bum reading upon reactivating it..

What we really wanna see of course is perfect unity at a high accuracy setting, so i'm thinking what if, instead, i set the vMoI actuators to just dumbly retract at 1 m/s constant radial velocity for the full 1 second of the interaction, thus only ever applying positive inertial torque?

By eliminating the active feedback loop, the vMoI integral should be that much more reliable..

..i could then just focus on the internal lift, trying different acceleration values.. dunno, may give that a shot..

[MrVibrating]

Well, tried the aforementioned refinements:



• the 'reel-in' input is now ignored / deprecated; instead the vMoI retracts at a constant -1 m/s, applying positive inertial torque the whole time, and the angular velocity and reel-in height are simply allowed to rise to whatever

Nothing else has changed, aside from the results of course:


@ 32,765 Hz, 1 i-s/f:

vMoI acts = 20.137599

lift act = 66.223887
__

total in = 86.361486 J



GPE rise = 71.186

KE rise = 25.174
__

total out = 96.36 J

+10 J over


So just to recap:

• there's no reactive feedback loops here; no controller logic at all

• the vMoI actuators are just set at a constant -1 m/s velocity

• the lift actuator accelerates at 20 m/s² for ½ sec, then decelerates at the same rate for another ½ sec

• and of course the system begins in motion, coasting at -1 rad/s and -1 m/s for the angular and linear speeds respectively (can't have inertial torque w/o some initial spin)

• 'net KE' is simply displaying the output of "kinetic()"


Under these conditions, i would normally expect perfectly-reliable resolution, ie. to within mJ's of unity.

We seem to have that sub-mJ agreement between the input integrals and output scalars.. plus precisely 10 J extra..

So if this is real, that 10 J gain must still correlate to something - ie. it must break down into some kind of force * time differential, and the inspiration here was that - perhaps - we might be able to buy GPE that is subsequently worth a given amount of acceleration, more cheaply than we could buy that acceleration itself directly; again, in a nutshell, a reactionless GPE input rather than a reactionless acceleration per se, thus chopping out the extra distance over which the 'stacking force' would need to be applied. Hence, if this is actually paying out as anticipated, then the 10 J gain is equal to that there differential.. ie. input costs summing with height instead of squaring. Cut-price GPE, effectively, via anomalous (N3-busting) acceleration of the input FoR.

7 am now and i've a telephone appointment at 10 am, so little point trying to go bed, even if i could sleep.. instead i'm brewing up some nice Costa Rican blend and ploughing on; for starters, how will halving the acceleration factor affect the gain?

(last sim attached)