Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

OK so in the system below, classic 'over-balancing' torque is being generated by lifting weights radially and dropping them circumferentially.

The system duly accelerates, gaining angular momentum:



Believe it or not, this is actually just another form of kiiking, in essence:

• the weight being lowered tangentially / circumferentially is spending more time subject to the gravitating condition (ie. being accelerated or decelerated by gravity), compared to the one rising in the predominantly-radial plane (which is still receiving some angular lift too), and this up vs down 'time-spent-gravitating' asymmetry is directly proportionate to the yield of unidirectional momentum so gained from gravity

Thus the momentum gained from simple, Classic OB - albeit at energy unity, here - was always the same essential principle - the same momentum-gain mechanism - as kiiking.

Yet look closer at the above demonstration, and you'll notice something is a bit different here:

• MoI is constant! We have two equal masses changing radius, yet MoI remains pegged at 2 kg-m²-rad/s!

• In other words, zero work is being done against CF force!

This has been accomplished by carefully controlling the relative radial speeds of the weights - they have to slide in and out at different speeds relative to one another, and that ideal speed variation follows a curve; we can either vary both radial speeds to track that curve, or else hold one constant whilst varying the other. In the example above, 'MoI' is being used as reactive feedback to control this radial speed variation.

The net result is, as you see, continual OB / 360° kiiking, yet without doing any work against CF - let alone more with rising RPM. We've just done away with the whole CF game entirely..

So whereas a standard kiiking mechanism gains momentum from gravity by performing work against CF force - the rotKE increase is equal to the net work done against CF force, with zero net work done against gravity - here we've flipped the input workload over to gravity-only; the rotKE rise is now equal to the net work done against gravity, with zero net work done against CF force.

Instead, now the only input energy is GPE, and obviously, GPE is speed-invariant - it costs the same input energy per cycle regardless of RPM.. or, to put it another way, the actuator's workload is in an inertial FoR, so can diverge, in principle, if the momentum yields could be held up; under such conditions, a given actuator input F*d / GPE would cause a greater rise in output rotKE..

So speed-invariant input energy per cycle isn't a goal unto itself; the whole point is the progressing energy cost of momentum, remember, so fixing the input energy is only really productive if the momentum yield is also fixed - or at least, not reducing at a rate that matches ½mV²..

..yet here, unfortunately, that's exactly what's happening: as previously noted, per-cycle momentum yields are diminishing as RPM's climb (not currently plotting momentum but it's just MoI times RPM, so implicit already)..

..the ratio of the asymmetry is constant and RPM-invariant, however the absolute magnitude of the momentum yield is still decreasing along with the net 'exposure time' to gravity per cycle. These diminishing returns perfectly track unity; the rise in rotKE is precisely equal to the work done against gravity. GMH = rotKE.


So the next objective is to try one or more of these systems in orbiting axes; as before, torquing the central axis against them using motors, and so raising 'orbital' angular momentum of one sign, and equal axial angular momentum of the other.

Then simply employ the above OB cycle in reverse, sinking the counter-momentum to gravity. Brake the rotors back together after each cycle, so the orbiting motors always restart each cycle from the bottom of the V² ladder, hence paying only ½ J / kg-m²-rad/s regardless of current RPM. No net work is done against axial CF, no net work was ever done against orbital CF previously, so touch wood, this could be the cheapest momentum possible - paying only ½ J per kg-m²-rad/s..

The amount of counter-momentum that can be sunk to gravity per-cycle - and thus the resulting momentum yield - will probably still decline with rising RPM; the main difference will be that the principle source of torque becomes the orbiting motors, rather than OB torque, which instead will only be sinking counter-momentum.

So i'm thinking, as before, to try maybe a pair of these mounted to a larger wheel, with gravity enabled.. plot input energy in terms of motor torque * angle and actuator F*d, and compare their sum to the output energy in terms of net KE..

The broad picture's akin to spinning up a turntable by standing on its edge and counter-spinning a smaller rotor in your hands, and then dumping that counter-momentum to gravity and repeating. Simple concept, but how do the various constraints on its efficiency pan out?

ETA: sim attached

[MrVibrating]

..hmm i've just intrigued myself there - suppose i stand on the edge of a turntable holding a heavy flywheel, then spin it up in the horizontal plane, applying equal counter-momentum back to myself and the turntable..

..then i rotate the spinning flywheel's axis 90°, and brake it to a halt in the vertical plane; this applies a precessional counter-torque back to Earth and also dumps the counter-momentum to it, but leaves the system with a gain in momentum, surely?

Why couldn't i just repeat that cycle, of accelerating myself using counter-torque in one axis, while dumping the opposing momentum in an orthogonal plane? Yes it's not dolphin-friendly, but it also looks like a speed-invariant energy-cost-of-momentum, too..

Shame that can't be simmed in 2D, but i'm curious now why this isn't an inherently-OU process..?

[Georg Künstler]

Hi MrVibrating.
with the correct speed you will get the roll curve of the weight which you had supposed.
We get the fast up, slow down function of the weight.
In my construction I had chosen a metal plate which you can see in the picture.

The gaps in the chain allow a swinging of the eccentric mass.
You always use a rigid connection, that will not work.
The construction must be allowed to breath.

[DrWhat]

Thanks for posting. I'm reading with interest.

[MrVibrating]

@Georg - cool build; just to be clear tho, a rising vs falling speed difference is useless if the speed-variation relies upon N3 - that is, a force applied internally between the weight and the wheel: for example, trying to slow a weight's descent by pushing it back up against the wheel's inertia is also going to push the wheel down and around, transferring momentum around but without changing the net total.

It's important to understand that it's principally a time symmetry that must be broken to gain momentum from gravity; speed itself is almost incidental, it's the resulting 'time-spent-gravitating' that decides the net change in momentum per stroke. The exposure times, up vs down. 'Soak' times.

This is why i was initially using inertial torque - the 'ice-skater effect' - to cause these speed variations; it's reactionless, so we can slow a weight's descent without applying counter-torque back to the wheel, thus gaining momentum from gravity in the weight, independently from the wheel, which is then shared back with the wheel via a collision, but which requires powering this CF workload, and since CF force rises with RPM, so does the energy cost of momentum sourced by this particular means of payment.

Which is not to say CF workloads won't have their place.. just maybe not here.


I'm now switching to GPE-only - the 'curve' i refer to is the geometric function that describes the change in distance between the two weights as they change radius and swap sides, without causing a change in the system's MoI. So far i've only determined that it's a function of the radius multiplied by the square root of two - if that is all there is to it, then i expect a simple system of planar folding linkages could accurately trace out the curve, and so obviating the very CPU-intensive 'reactive feedback' method used above, wherein one of the actuators during each stroke moves at constant speed whilst the other 'hunts' - adjusting its speed relative to the other one, to keep MoI constant.. 'cos if this is useful (eliminating CF work), Bessler would've needed a clockwork Arduino to implement it this way..


The whole 'up vs down time asymmetry' thing distills to a few simple points:

• It costs input energy.

We pay some energy to do some work, applying some force over some displacement, that results in a weight spending more time on one or other leg of its full GPE cycle, and so yielding a non-zero change in system momentum.

Normally we pay energy to buy momentum by generating equal counter-momentum, but the energy cost of momentum bought this way squares with the more units bought. Twice as many units = four times the cost.

But momentum bought from gravity instead obviates this usual need to generate counter-momentum. It is no longer a foregone conclusion that its cost of purchase needs to square up, the more we buy. I've described various scenarios in which we can consider a speed-invariant energy-cost-of-momentum, the lower limit set by the standard KE equations being ½ J per kg-m²-rad/s. Again, the maths are exquisitely simple, it's just KE=½mV²; using two 1 kg-m² inertias, 10 purchases of 1 kg-m²-rad/s at ½ J each costs a total of 10 * ½ = 5 J. Yet 10 kg-m²-rad/s divided by two 1 kg-m² MoI's gives them 5 rad/s each, and so 12.5 J each, 25 J total. So the efficiency after ten cycles would be equal to whatever the input energy, squared.

Bottom line: gravity's a time-rate-of-change of momentum, up vs down 'soak time' variations thus cause net momentum changes, which can be exploited to continually increase the momentum of an otherwise 'closed' - statorless - system, purely by the internal expenditure of work, and whereas the standard cost - and value - of momentum sourced a la N3 squares with the number of units bought, the cost of reactionless momentum is already inherently decoupled from those same limitations.. so, provided we don't put them back in anyway (all too easily done), there's no logical reason we shouldn't be able to implement a mechanism that simply doesn't 'know' it's rotating / accelerating; the input workload is effectively in a 'rest frame', and each and every power stroke is subject to the same starting and ending conditions, and thus energy-cost-of-momentum.

We don't even have to accumulate the stuff at constant energy cost; basically any rate that isn't ½mV² is a total win..

[MrVibrating]

..hmm i've just intrigued myself there - suppose i stand on the edge of a turntable holding a heavy flywheel, then spin it up in the horizontal plane, applying equal counter-momentum back to myself and the turntable..

..then i rotate the spinning flywheel's axis 90°, and brake it to a halt in the vertical plane; this applies a precessional counter-torque back to Earth and also dumps the counter-momentum to it, but leaves the system with a gain in momentum, surely?

Why couldn't i just repeat that cycle, of accelerating myself using counter-torque in one axis, while dumping the opposing momentum in an orthogonal plane? Yes it's not dolphin-friendly, but it also looks like a speed-invariant energy-cost-of-momentum, too..

Shame that can't be simmed in 2D, but i'm curious now why this isn't an inherently-OU process..?

..still stuck on this: How is it not OU? The per-cycle torque * angle and momentum yield are both RPM-invariant!?

Assume equal MoI's for both axes and it's at unity after two cycles and 133% of unity after the third cycle?

How crazy is that? The precessional torque just gets earthed, without affecting the momentum already put into the turntable each cycle.. you can just rotate the axis of the counter-momentum, brake it back to stationary, flip it back parallel to the turntable and torque 'em up again.. same T*a, same cost, same momentum and counter-momentum magnitudes... the input energy cost / work done doesn't increase with RPM!!!

But the flippin' output KE does!

Lil' help, anyone?

[eccentrically1]

What mechanism is spinning, rotating, and braking your flywheel?

[Georg Künstler]

Every eccentrical Mass With some Space to move will do that. you will get extreme forces.

[MrVibrating]

What mechanism is spinning, rotating, and braking your flywheel?

A motor, bearing and brake.

It's OK, i've just solved it tho:

From stationary:




From 2 rad/s:

Relative:




Absolute:



TL;DR - after the first cycle, it ceases earthing counter-momentum and begins earthing positive momentum instead. The 'relative vs absolute' FoR's / momenta don't survive rotation into perpendicular planes, and i'm still an idiot..


Whatevs, it was just a stray tangent - using an inverted OB cycle to sink counter-momentum in an orbiting axis is what i really wanna focus on right now.. probably equally useless, but either way i need closure..

[MrVibrating]

So that last result also seems to scupper the prospects for using a reversed-OB cycle to sink counter-momentum, since it, too, would start sinking positive momentum instead once actually rotating.


This occurs because each cycle must begin with the rotors stationary relative to one another, and thus with the same real rotation relative to the world outside. Hence, counter-torquing the axial rotor will be de-spinning it, rather than spinning it up in the opposite direction..

So applying a 1 rad/s acceleration from the motor when the system's already at, say, 3 rad/s, will accelerate the orbital velocity to 4 rad/s, by decelerating the axial velocity down to 2 rad/s - so the axial rotor just has less positive momentum, instead of actual 'counter-momentum' in the opposite direction, which only arises in a standing start..

Obviously, if we went ahead and sunk that 2 rad/s on the axial rotor to gravity anyway, we'd have 2 kg-m²-rad/s less positive momentum left in the system.. so, going from a diminishing per-cycle momentum yield, to a negative one.. Not progress.


But there's also a simpler logic behind this that i've failed to take heed of..

• Obviously, duh, any scheme attempting to wipe out counter-momentum - whether by sinking it to gravity, dragging it into the center or whatever - has to actually generate 'counter-momentum' in the first place.

This point thus seems to preclude the possibility of deploying counter-rotating momentum sinks in the same plane as the positive momentum, generally - ie. we can eliminate a whole class of prospective exploits here.. any higher ground is some progress eh? Don't wanna be like the OB guy who attributes failure to "wrong lever types" rather than "closed loops thru static fields"..

So, putting me thinking cap on and straining til i'm red:

• If Bessler depended on sinking or destroying counter-momentum, then it must've been embodied in a plane other than co-axial.

Thus we could try considering alternative planes / dimensions that might accommodate a counter-momentum, which could then somehow be nulled / inverted or whatever..


In principle, we might still try a co-rotating 'stator' in the coaxial plane such as the weight so applied in the OP, since we'd only be relying on gravity to absorb counter-momenta instantaneously as torques are applied to the main axis; however this has its own limitations in terms of the diminishing per-cycle momentum yields with rising RPM, as covered already..

..or else, we could focus on a form of N3 break that simply does away with the need to generate - or thus dispose of - counter-momentum in the first place.

We already have one or two examples, such as kiiking, and 'classic OB', both of which reduce to the same core mechanism, of manipulating 'up' versus 'down' soak times - applying the 'ice skater effect' to cause a falling weight to linger in its descent, so getting 'wetter' with momentum-from-gravity, or conversely, expediting its ascent, so minimising its 'drying out time'; either way, manipulating 'exposure time' to gravity's constant time-rate-of-change of momentum.. and so providing a means of applying asymmetric inertial interactions - and resulting momentum yields / reductions - that bypass the need to generate counter-momentum in the first place.

Furthermore, we've established two viable payment options for buying such unidirectional momentum; work done against CF force, or else, work done against gravity (ie. GPE).

The former currency is speed-dependent - the input workload is in a non-inertial reference frame, so the energy cost of the momentum rises with system RPM..

..and remember, many different iterations of that scheme have been tried already, without success; invariably, either the CF workload - and thus input energy - increased with RPM, or else, even when per-cycle input energy could be rendered RPM-invariant, momentum yields still deprecated by half the inverse square of rising RPM, IOW tracking unity / ½mV².

Which is not to say the possibilities for CF workloads as a currency are exhausted, or that they might not have utility in quite separate respects (for example, as a means of harvesting KE gains later in the game). The axial CF loads upon orbiting rotors are unaffected by orbital CF (to put it another way, the net (per day or year) CF force we feel here on earth is purely a function of its spin rate, and invariant of our orbital velocity about the sun), so this remains a potential exploit - could we maybe pay for momentum rises on one axis with reduced CF workloads on the other, effectively decoupling the momentum yield from the V² multiplier? ..ain't managed it yet, but not sure i've eliminated the possibility either..

..however we also have this other option, now, of payment in the form of GPE, instead of CF work.

As discussed already, a simple planar-linkage should be capable of accurately reproducing the radial acceleration curves required to generate OB without doing any net work against CF force at all.. at any RPM..

..and as we all know, GPE is speed-invariant. Thus, if we're not doing any net work against CF force, then our per-cycle input energy is going to be constant, regardless of rising RPM. So, this immediately seems like a potentially-easier currency to work with..

..however it still faces the same challenge, or declining momentum yields with rising RPM.

As discussed in the OP, this trend seems an inevitable outcome of sequencing the cycle to the external reference frame - our fundamental, instinctive approach to divide a prospective mechanism into sectors relative to the clockface, or Cartesian coordinate space, or angle in degrees or radians relative to the ground, etc.

Yet, this is also an inevitability of any scheme reliant on per-cycle alignment to the gravity vector, surely? So on the one hand, our per-cycle input workload may not be rising with RPM, but if our net 'soak time' rising or falling is necessarily decreasing then so is the p/c momentum yield and thus energy-cost-of-momentum.

What we'd really want is some way of also sustaining the momentum yield from the weights we're raising, regardless of RPM. At least, across some limited range of RPM.

In a statorless system the only such option would seem to be mounting the GPE interactions to orbiting axes, whose speed of rotation could thus be independent to that of the system axis; however, this also seems to necessitate that the 'angle' component of their 'torque * angle' integrals is going to increase along with the rising angular speed difference, so robbing Peter to pay Paul..

"..in a true PMM, everything must, of necessity, go around together!"

..not least, whatever inertia is constituting 'the stator' against which angular momentum is being raised! The only way to physically substantiate a 'KE gain' is to short-circuit the 'V²' multiplier in 'KE=½mV²', thus decoupling input F*d or T*a from output KE. Everything must go around together. EMGAT.

We know there is a solution..

Finite state-space. Only so many permutations..

I've considered retrying something like this:



..using the 'GPE sans CF work' trick; so whereas previously the per-cycle momentum gain was equal to the net work done against CF force, it would instead be equal to the net work done against gravity, with zero net work done against CF force.. but that's a lot of effort if it's simply failing to heed lessons already learned; the bait leading me on there is that knocking the per-cycle momentum gains from the axial into the orbital axis might sufficiently decouple orbital speed & momentum from axial speed and thus per-cycle 'soak times', sustaining the per-cycle momentum yield above what it would otherwise be for a given orbital RPM & thus 'banked momentum'.

If there's no reason for per-cycle input energy to rise with RPM, and the per-cycle momentum yield is also decoupled from main system RPM, then maybe the output 'orbital KE' can diverge from the input 'F*d / GMH' and so successfully buying cut-price momentum..

As ever, will give it some time to try solve it in me head first, lotta effort to go to for a face-palm result..

[MrVibrating]

New axial-to-orbital rig: gaining momentum-from-gravity with 'pure' overbalancing GPE in the axial axes - doing zero work against CF force - and banking it in the orbital axis.

Because GPE is speed-invariant, this should render per-cycle input energy constant, regardless of RPM.

The per-cycle momentum yield still decreases as a function of rising axial angular velocity - so the same input GPE is buying less momentum per-cycle as RPM's increase; a seemingly-inescapable consequence of syncing the internal action to the system angle relative to the external reference frame / gravity's vector..

..however the hope is to mitigate that inevitability just enough to bag a small excess of momentum regardless; by bumping the momentum gains into the larger orbital axis instead, allowing axial speeds to remain lower and thus prolonging momentum yields as a function of time-spent-gravitating per cycle.

Expectations remain low, for now: as in previous 'axial-to-orbital' rigs, efficiency will likely either converge towards unity, or else the loss being dissipated every time the axial rotors are braked against the central axis. However if it could manifest OU, it'd be on that central / orbital axis..






Just to reiterate - no OB torque's being induced directly to the orbital axis there, which remains balanced at all angles throughout. Momentum's only collected on the axial rotors, then knocked into the orbital axis by momentarily braking them against each other after each drop.

I haven't yet figured out a planar / folding linkage to sequence the radial actions, although it looks like one's possible because the distance between the masses varies by a function of sqrt2, implying some kind of crank & conrod or compound lever could simplify the motion..

For now, reactive feedback's still being used, controlling inbound actuators for length as a function of angle, and outbound ones for velocity as a function of the resulting MoI, and i haven't previously tried taking integrals when mode-switching like this; i can always revert to calculating radial loads from first principles if they start coming out wonky, but if this turns out to be a useful exploit then working out how to do it purely mechanically would be the better way forwards.. for run times as much as data quality.

Braking torque's also a reactive function of the relative axial / orbital speed difference; this too can be ditched if it proves problematic..

So, now i just need to start pulling integrals off it.. maybe try varying the axial-to-orbtial MoI ratio, as a function of orbital radius and/or mass, since this is the prospective area of advantage / confusion, whichever it is this time..

..as ever, if it can't break unity then the secondary objective's to identify exactly why not, and thus what possibilities remain..

Next up, numbers - gonna tune the frequency of the 19.2 s run above to use all available memory, maximising data resolution, and solving down to the millijoule (nowt' special about "19.2 s", it's just where the relative angles and GPE return to their starting positions, which helps simplify the calcs).

[MrVibrating]

Same sim, finalised and tuned to freq = 32765 frames / 19.2 secs:

Net KE rise = 1166.500953 J

Net actuator P*t = 1286.369047 J

Difference = -119.868094 J

Brake T*a = -57.1009692 J

Remainder = 62.7671248 J


As feared, the 'net actuator P*t' integral appears too dirty to use.

The interference is caused by the mode-switching trick being applied. This 'mode-switching' is a workaround for overcoming some of WM's intrinsic limits:

• Controlling actuators for 'length' when applying acceleration changes to them causes inconsistencies in the resulting F*d plots, resulting from 'length' being constantly recalculated (derived, from whatever the applied equations) at varying mechanical speeds relative to the fixed sim frequency, and thus available computation cycles / integration steps across a given range of acceleration / displacement; over and under-estimates inevitably creep in, causing discontinuities between consecutive frames - essentially, judder - where the 'length' is effectively dithering instead of changing smoothly and progressively, hence the resulting F*d trace goes 'round the houses instead of plotting the simplest line integral.

Using this method, you can accurately place masses where you want them to be at a given time and/or location in a cycle..

..but WM's calculations of the corresponding per-frame F*d increments in moving them to that position are marred by this 'simulated time vs real compute time' dependency, so it's constantly re-correcting mass positions as the error margins and rounding errors vary in magnitude between simulation frames.


Conversely:

• Controlling actuators for 'velocity' causes WM to invert the relevant formula, resulting in per-frame increments which accurately integrate for force over time, without producing the same 'temporal aliasing' effects..

..however this just shifts the imprecision back to positional calculations of exactly where a mass is intended to be, as a function of its velocity-over-time, which again accumulate rounding errors.. only now, they're not being corrected, since we're only controlling for speed, not 'length' or, thus, explicit position.. hence precise velocities which should result in a mass being at a given location at a given time, instead cause it to over or under-shoot, depending on this internal deficit between 'simmed time vs compute time'.

Using this method, you can take clean, accurate F*d integrals... only, over inaccurate displacements, which can cause significant accumulations in change of 'rest' position and thus rapidly-exploding mechanisms..



So for accuracy (and thus resolution / closure on a given measurement), it'd be desirable to control for 'length' when it's practical to move at constant speed, but switching to 'velocity' when a motion requires variable speed.

Unfortunately however WM doesn't seem to support switching controller modes on the fly like this; they're locked for the duration of a sim.

Hence the workaround:

• attach two distinct actuators to each mass, one set to either control mode, and alternately disabling / enabling them in consecutive sim frames following each stroke

• inbound masses move at constant velocity, using actuators controlled for 'length' and so maintaining positional consistency between min / max mass radii, and hence stabilising their combined MoI (a key criteria for the measurement objective)

• upon arrival at dead-center (exactly 2 meters from the rim), the 'length' actuators are effectively replaced by different ones controlled for 'velocity', which move them back out to the rim at whatever speed is required to hold their combined MoI at '2' as the other mass comes back in from the rim, providing a clean integral of the force over whatever that (now imprecise) displacement..


And this is the source of the spikes in the 'net actuator P*t' plot - notice those in the upper half are taller than those below; these are related to the over or under-extension of the 'velocity' actuators when returning the masses out to the rim, hence the very first load upon the 'length' actuators the moment they're activated is in correcting that position error left over by their 'velocity' counterparts; moving the masses to exactly 2 m radius from the center, in a single simulation frame.. tiny distances, but huge accelerations..

Additionally, there may be opportunity for radial KE leakage when switching actuator control modes if radial velocity is not exactly zero at the moment of switchover..

To mitigate these effects, a high number of integration steps per frame are required, and also a high frame count / frequency. Insufficient processing time per required increment of simulated time on either count causes rising radial judder as RPM's increase, rapidly crescendoing to spontaneous disassembly..

..yet, while allowing the system to work mechanically, it appears this isn't mitigation enough for clean data acquisition.


'Closure' means getting rid of this under-unity result, because genuine non-dissipative losses are the same phenomenon as anomalous energy gains; conclusive resolution requires confirmation it's a 100%-efficient motor-heater; the difference between input F*d and output KE rise being equal to the T*a dissipated by the brake.


After all, if the input integral's wrong, we can only guess the degree of error.. the true efficiency might yet be of interest. Not that it looks promising - i fully expect it should be unity - but then i don't need a sim to make assumptions; the whole purpose here is millijoule-accuracy.

So, that 'net actuator power' panel needs replacing with something more robust..

Instead, a plot of CF-force-over-radius for each mass could be summed together, and combined with a plot of radial GPE input.

Calculating radial GPE would presumably mean accounting for that portion of each lift accomplished by the rotation of the axial axes - so, the weights partially 'coast' back up and around, returning some of the rotational KE they gained on the way down directly back to GPE, rather than being raised exclusively in the radial plane by the actuators.

Since CF/CP force and gravity should be the only forces determining the input workload across the 2 m radii, their summed integrals should resolve to the net KE rise.

On the one hand, any substitutions of the sim's internal metrics risk defeating the purpose of 'simming' anything, other than for animation purposes; raw data recorded directly from the interaction - as by attached sensors - being the whole objective. Applying one's own formulas to what is now effectively just an animation is like taking a packed-lunch to McDonalds. Home-made Big Macs, but with authentic ambiance..

..that said, it's just CF and GPE work integrals, and we're already used to solving both; a unity result's expected, so it's hardly pushing the boat out..

..on the other hand, the whole compute-time bottleneck could be neatly circumvented whilst still taking direct data, if only the actuator programming were replaced by a simple physical mechanism. There's evidently a perfect geometric function describing the ideal acceleration or position profile of one mass in relation to the other's constant radial speed or position, so some kind of simple crank or lever system (maybe eccentric?) should be able to accurately regulate their respective radial speeds..

With an appropriate planar / folding linkage in place, a single actuator could be attached to one mass, operating at consistent speed with respect to angle / RPM, automating the acceleration curve of the other mass and providing a clean, neat integral for both strokes.

Will have a think about which is the best way to proceed.. the latter option seems preferrable tho..

I'm thinking, on a non-rotating disc (for now), if i use one actuator to move one mass at constant radial speed, then i could attach a second actuator between it, and the other one.. since we already know the gap between them needs to increase from a value of 2 m when fully up or down, to a peak multiple of sqrt2 of that distance as the masses pass equidistant radius, then reversing back down to 2 m again on the other side.. it should be possible to reduce that to a much less CPU-intensive function, that also obviates any need for alternating control modes..

..in principle, the eight actuators currently moving the masses could be replaced with a single one mounted to the central ('orbital') rotor, pulling cords thread through the axial axes.. or even mounted externally, feeding the cord through the orbital axis first. But if i can get it down to just two per rotor, working in fixed control modes, that should suffice for clean data..

[MrVibrating]

..for thoroughness, gonna try re-run that last sim at the max poss. no. of integration steps per frame.. it'll take hours on my ancient Phenom II, but if it gets rid of the loss it saves further effort..

[MrVibrating]

..a quick pep for weary eyes inured to the ongoing litany of failures:

• Remember, we are, already, playing with woo: cyclically accumulating momentum from gravity, without applying counter-torque back to the axis!

• We're only stuck on exploiting the potential input-energy discount of this momentum source.

• The make-or-break condition for gaining energy is the phenomenon of divergence of an effective inertial frame (so it could be a kind of 'pseudo-inertial frame' rather than a strictly non-accelerating one); an inertial interaction in such a reference frame performs the same amount of work each cycle, displacing the same amount of mass by the same distance, only, without satisfying N3 - so the balance of momentum and counter-momentum changes in each direction are, somehow, rendered unequal.

Accumulation of the resulting per-cycle momentum difference over successive cycles, and borne by the reference frame itself (ie. all masses in the system accelerating together), amplifies the external value of the 'V²' multiplier in the ½mV² equation, relative to all other external reference frames.. as such, 1-Joule of input work in the internal reference frame could cause a KE rise in the external reference frame of arbitrary value - much more or less than 1 J - depending only on the accumulated speed difference between the divergent FoR and the rest of the universe.



So you might reasonably be wondering, can this whole axial-to-orbital geometry even manifest OU in the first place - is it even dimensionally feasible, or is this like trying to collect rainwater in an upturned bucket?


Thus, in the interests of morale, here's the exact same rig again, but with the masses locked to their rotors at fixed radius; instead of OB torque, they're now spun up by a motor, but whilst applying an effective N3 violation that prevents any counter-momentum being commuted back to the orbital axis:



..as before, each reactionless acceleration is consolidated with an inelastic collision, sharing back the axial momentum gains to the orbital axis.

FWIW there was no overriding reason to stop it there at 3 seconds - could've let it run all day, but as-is it's basically a white hole.. given sufficient supply of livestock anyway.

Per-cycle input energy is just torque times angle, and constant throughout. We're paying ~0.5 J per kg-m²-rad/s of momentum, consistently, irregardless of rising RPM..

..yet the KE value of that T*a is, well, ½mV²..

Just eyeballing the plots, it appears momentum yield is constant per-cycle - the size of the steps ain't shrinking..

..we also see that the axial and orbital speeds and momenta are not going their seperate ways, but climbing together. Because in a true PMM, everything must, of necessity..

..finally, we can see that the KE value of that stable momentum yield is appreciating, the more we accumulate - the size of the KE steps is increasing!

Let's go ahead and take the motor's torque times angle integral:

• Motor T*a = 28.4687 J

Net KE rise however is 111.2242 J.

111.2242 J / 8.4687 J + the eternal essence of 1 chicken = 13.13x OU.

We have 31.5509 + 28.0023 = 59.5532 L of angular momentum, so we've paid:

• 28.4687 J / 59.5532 L = 0.47 J/L

..actually slightly less than the presumed 'minimum' of 0.5 J / kg-m²-rad/s per ½mV²! Talk about a killing..

So.. in case anyone was wandering whether i'm chasing my tail here..


The purpose of this isn't to tease or titillate, so much as let the dog see the rabbit.. lil' reminder of what we're all fighting for, type stuff. Yes, it's gake and fay, but it's an authentic visual reference for what mechanical OU looks like - and a demonstration of how readily available it is.. if we can effectively circumvent N3 symmetry.

It shows how the acceleration of the motor's rest frame amplifies the KE value of its work, breaking the symmetry of input PE to output KE.


"Mechanical OU" = speed-invariant per-cycle input energy, and/or speed-invariant output momentum yield. This means exploiting the V² multiplier in the KE equation, which in turn means the momentum must somehow be 'reactionless', so in defiance of the usual outcome of N3..

Point is, the so-called "impossible thing" really ain't rocket science.

It has self-explanatory conditions, implicit in its very conceptualisation. Meet those conditions, and the system pays out, just like it promises in the small-print..

Study those plots well, appreciate the importance of the key relationships - and where all the failures are going wrong, by comparison.

A successful rig might not look anything like this, but at a fundamental level, this is what it'll have to be accomplishing..

[MrVibrating]

Yay! That HQ sim's just finished - 10,000 integration steps per cycle!

• Net actuator F*d = 1298.086843 J

..so, even more than the 1286.369047 J measure at 100 integrations per cycle.. it's defo wasting KE due to the mode-switching escapade.

So i guess the thing to do now is sit back, and compare this failure to the above 'chicken run', to see if those fundamental differences can be resolved, hopefully without all the noise and mess..

Resolving those discrepancies should point to a new kind of rig design, that overcomes the constraints of synchronisation to the gravity vector..