Success..?

[MrVibrating]

..well fuck me sideways - positive result!

The solenoid gain is not at the expense of the actuator workload!


it's free and clear!!


Data to follow...

:)

[MrVibrating]

3rd time's the charm eh:



actuator = 0.378631362

solenoid = -0.320586999

motor = 0.499796942

net input = 0.557841305

KE rise = 0.75190

diff = +0.194058695

0.75190 / 0.557841305 = 1.35x unity




135%, folks..




Clear-cut OU, right off the bat!


Finally!


OK, so - 2nd derivative CF-PE from a constant-MoI system is free energy, folks!


So long as the axis is accelerating whilst CF-PE is being harnessed without changing MoI, that output is decoupled from both the rotKE and input torque * angle driving the acceleration, as well as the actuator driving the radial translation!


I also can't currently see how this might cause an asymmetric inertial interaction with the planet; gravity's off here, so nothing whatsoever to do with the gain principle; there's no accumulation of momentum sans counter-momentum... it looks totally sustainable..


Now we're ready to start designing perpetual motion machines!

[MrVibrating]

..so, Fletch... any more o' dem there suggestions? Credit where it's due eh..

And where's Grimer - he ought to be all over this..?

Or wasn't he on about third-derivative Ersatz gravity? Whereas this is only 2nd-derivative.. Hah busted you mate, you were completely wrong, by one whole derivative of motion... egg on your face eh?



In all seriousness tho; how to go about taking a slice of this? The gain's there and already harvested in the final freeze-frame above, but what's gonna be the least-clunky way of taking it mechanically? Some kind of stop-start mechanism inside a rotating one?

Is there an obvious way to incorporate it into a basic OB system - ie. radial lifts w/ angular drops?

Again, do bear in mind that the MoI-control trick doesn't require both masses to be moving in the same linear plane - their paths could be orthogonal, or at any relative angle.. so could involve over-balance..

But doing it mechanically will first require cracking the MoI control routine - it obviously can be simplified to an automatic mechanical process, it's just a matter of figuring out how to do it neatly and efficiently.. 'cos force-feedback's obviously only good for an electro-mechanical build..

[MrVibrating]

Still need to run the 'coasting-only' control, just for completeness - already clear it'll be unity (just from the initial gravitating run), but will do it tomorrow anyway.

The gain's occurring - or, more accurately, the output field is thermodynamically decoupled - because CF-PE is being extracted without raising MoI, whilst the axis is accelerating. This is causing a corresponding rise in the CF force acting to pull the masses apart (CF force squares with angular velocity).. but because that radial displacement isn't increasing the system's MoI, that output CF-PE workload is isolated from the input motor workload, with zero transference of torque, or, thus, work / energy.

Fuck-all to do with gravity...

..and fuck-all to do with accumulating reactionless momentum either!

Did not see it coming.

At least, not from that direction..

Shot. Bed. Work in a few hours...

[Fletcher]

Try turning it thru one whole revolution !

[MrVibrating]

..mate, moving 'em back out destroys energy..


..we've spent the last two months staring at an interaction that creates and destroys energy on every full radial translation of the masses..

..it's been persistently creating slightly more energy than destroyed, apparently as a function of the constant acceleration..

..and all this time we've been staring at it, in high-def, poking it with pointless spin and brake cycles and repeatedly finding they actually produce worse OU efficiency than the 'control' runs with constant-MoI OB-only, all we had to do was simply eliminate the entirely optional 'destruction' phase..


Which is what we're now looking at.


So now we're doing just the gain phase only.

There's absolutely no reason whatsoever to perform the destruction phase.

We don't need to make more energy than we've destroyed!

We don't need to destroy any energy in the first place!!


So what you're looking at above is a complete gain interaction, from start to end.

From that ending position we can do absolutely anything we like..

..but choosing to immediately destroy a near-equal amount of energy is obviously a step backwards..

So instead of considering the system as the potential basis for a wheel, instead think of it as a stop-start interaction that is accomplished repeatedly inside a wheel, ie. about another axis..


..or else, if we want to design a wheel based around that same axis, then we need to move the weights back to their starting positions without maintaining MoI lock / destroying energy..

In short, the reset stroke only needs to be at unity.. but there's no inherent reason it has to be under-unity.


Get it? Both the under and over phases are entirely optional and voluantary. The gain's free and clear - already harvested - in the final frame above. There's no reason at all we have to follow it up with an equal opposite destruction phase..

..that was the whole point of this experiment. That was the big 'Eureka!' moment the other night.. why i was itching to get home from work, and why i stayed up till 5 am.

It's why i just told my boss i need a day off today.. (think i deserve it!)..

We're now past the point of potential error, i believe.

This is real, and happening..

[MrVibrating]

Just realised the effective N3 break (cos there had to be one if it's real):

• It's in the fact that the output CF work integral presents no load upon the motor, even though it is the motor's acceleration causing the CF PE gain!

The motor only sees a constant 1 kg-m² MoI under smooth constant torque and acceleration. Not so much as a blip on its torque * angle plot from the output CF workload!

IOW it's not a decoupling from the actuator workload that's causing the gain, but rather, from whatever the source of the angular acceleration causing the transient CF increase - here, the motor, but previously, OB torque..

Right, coasting-only test, up next..

[MrVibrating]

Translating while coasting at 1 rad/s:



actuator = 0.501679406

solenoid = -0.560187969

total in = -0.058508563 J

KE rise = 0.25090 J of radial KE

In other words, we've got that same 58 mJ gain as from the gravitating preliminary run..

..that is, our net input energy is effectively negative 58 mJ..

..with which we've purchased 250 mJ of radial KE.


So the motor was off, and we paid a small amount of negative energy (ie. we gained energy) in order to gain a shit-load more energy.


To put it another way, i'll give you 58p if you'll let me give you £2.50, type deal. So, you don't even have to give me the 58p.. i give it to you, plus the £2.50 you're buying with that negative cost. Cheap at half the price!

So next i think i'll try a full 360°, switching off the motor when the radial gap's closing, and back on again whenever it's opening..

..expecting that the CF PE gain from when the motor's on should accumulate each radial translation cycle..

..might be able to keep that radial KE gain in play with radial springs, too?


Will the efficiency of the solenoid integral stay at 134%, or else increase with RPM?

And how the flip did i not pick up on this back in June last year when i was first playing with it? Obviously, i went straight to using reciprocal pairs in 90° phase, so was destroying almost as much energy as being created for any given range of rotation.. still, that small net gain must've always been there.. my objective at the time being constant OB torque, for uniform axial-orbital momentum exchanges.. but no excuse, we could've had this six months ago.. Damn.. all that time and effort wasted..

Back later with a full 360°, switching the motor torque as a function of widening vs narrowing gap distance..

[Fletcher]

Wanna ask a technical question, might seem silly.

Watching the MOI plot. It stays steady on 1.0 for weights 1 + 2 as the system rotates CCW thru 90 degrees (1/4 turn).

Initially weight 1 is at 1.0 radius (at the rim) and weight 2 is at 0.0 radius (at the CoR). MOI of the pair is 1.0 ( 1.0 + 0.0 ).

About 8.30 weight 2 begins moving from the CoR out towards the rim on its radial. It’s MOI should be increasing as its radius increases. Weight 1 stays at the rim.

About 7.30 weight 1 begins moving from the rim towards the CoR on its radial. Both weights 1 and 2 stabilize and end their run at about 1/3 radius (equal distance from CoR) with a combined MOI = 1.0.

The point is that between about 8.30 and 7.30 I would expect the MOI plot to show a discernible blip because weight 2 moved outwards from CoR before weight 1 began transitioning towards it ?

[MrVibrating]

Just to keep it methodical, here's outbound-while-coasting:


ignore the "GPE cycles" counter - deprecated from earlier version, needs removing..

actuator = -0.517036335

solenoid = 0.560220808

total in = 0.043184473

KE drop = 0.25088


Pretty much what you'd expect - moving back out while coasting costs the same few dozen mJ in net input work - this time positive, even tho it's peanuts - as it paid out on the way in.

Compared to the CF PE gain from moving in under motor torque, the reset stroke's basically a zero-sum..


So if the motor's only applying torque when the masses are moving in, we should clear a nice CF PE rise every 180°..


..so now it's time to try that out - one full 360° should perform two complete gain cycles..

[MrVibrating]

Wanna ask a technical question, might seem silly.

Watching the MOI plot. It stays steady on 1.0 for weights 1 + 2 as the system rotates CCW thru 90 degrees (1/4 turn).

Initially weight 1 is at 1.0 radius (at the rim) and weight 2 is at 0.0 radius (at the CoR). MOI of the pair is 1.0 ( 1.0 + 0.0 ).

About 8.30 weight 2 begins moving from the CoR out towards the rim on its radial. It’s MOI should be increasing as its radius increases. Weight 1 stays at the rim.

About 7.30 weight 1 begins moving from the rim towards the CoR on its radial. Both weights 1 and 2 stabilize and end their run at about 1/3 radius (equal distance from CoR) with a combined MOI = 1.0.

The point is that between about 8.30 and 7.30 I would expect the MOI plot to show a discernible blip because weight 2 moved outwards from CoR before weight 1 began transitioning towards it ?

Reasonable question:

- you can see that the MoI calc is built by taking the radii as the distances between centers of mass of each mass and the wheel, using the 'Length()" command; so what's being plotted is literally mr².. so this simply cannot be wrong..


What's actually happening is simply the result of mr² - the mass leaving the center has to travel much further in order to cause the same change in MoI as the mass already at max radius.

If you'd like, i could knock out a version metering the mass radii, then we could check that those values squared equalled the current displayed MoI at all times..

..or you could just do it yourself - the masses are bodies 12 & 16, the wheel's body 1, so a meter displaying length(12,1) on the .y1 output and length(16,1) on the .y2 output should reveal all - you could then copy & paste that meter and add the "^2" to the length outputs to get each MoI, or their sum etc.

Also, bear in mind that a small amount of mass is allowed for the solenoid / the keyed slot carriage it slides on, and also the 'beam' turned by the solenoid (looks like another rod but isn't) - these small masses are included in the MoI calc, so may throw off the weight radii from expected values..

To that end, you could try restricting the MoI calc to just the masses 12 & 16, and then their radii should be pixel-perfect to your calcs..

Currently, the solenoid control is simply ((output[35].y1 - 1) * 8e8) - so referencing the MoI meter, subtracting the target MoI and applying an FFB multiplier. So you could leave the MoI meter intact, and just plug the MoI calc for the two 1 kg masses directly into the solenoid control field, as in the v2 rig..


You can also see a small change in angular velocity in the two coasting runs above, indicating that the MoI calc may be seeing an error in the -1e5 range as the radial speed increases - but this is only even detectable because we're seeing 6 decimals displayed; if we went down to 3-4 digits it'd be below noise..

The broad picture's unmarred, tho - the solenoid gain's real, and orders above noise. It's an output of CF PE, sans MoI change, and because of this, harvesting it while its under acceleration presents no load upon the motor driving that acceleration - an effective N3 violation.

Obviously, taking out CF PE under any normal circumstances would necessitate an increase in MoI, which would in turn increase the load on the motor; it'd then have to increase its torque to maintain velocity / acceleration, or else we'd see a speed / acceleration drop in direct proportion to the MoI rise, from inertial torque / the ice skater effect..

Here however the motor sees a constant (as damn near anyways) MoI, undergoing constant acceleration for a constant torque.. even as we're pulling an extra 35% from CF PE!

It seems we're surely past any possibility of error.. the hypothesis finally matches the results..

Since CF force squares with angular velocity, i now want to see if the per-cycle energy gain likewise increases with RPM..

One thing i still don't quite get is the CF plots, which say that both masses undergo equal opposite CF work integrals... yet the forces the masses are exerting on the solenoid are mostly negative on the way in, positive on the way out.. and these can only be inertial forces, so.. it's either CF PE, or linear KE gain from an effective N3 break, maybe caused by CF biasing the linear / radial inertial interaction..?


Dunno.. either way, CF squares with velocity, so i wanna know if only the amounts of gain will rise with RPM but at a constant 135% or whatevs, or else, whether that OU efficiency itself will increase over successive cycles..

Will hopefully find out later..

[Fletcher]

Ta .. I don't use the 'Length' command.

Usually I attach a massless Rod from the center of the weight to the axle pivot. I turn off the active when. Now it changes length with no impediment. I then measure its length in an output. Say 1.0 less Length of Rod. And in a field under that do a straight MOI calc (mr^2) where r = 1.0 - Rod length etc.

Not too hard to set that up as a cross check tho I have no doubt that Length works too.

Still, I would expect to see some hump in the MOI Output plot because weights 1 & 2 transition at different times and angles.

[MrVibrating]

Like i say, MoI = mass * radius squared, so the inner mass has to move that much further to cause the same MoI change as the outer one. Once they pass the central balanced position their acceleration curves swap over again..

..you can see why it's so tricky to automate the transition without using adaptive feedback... it's obviously physically possible, just an engineering challenge.. doubtless, with an elegant solution, tho god knows it's eluded me thus far..

I also previously used inactive actuators for trickier MoI calcs, still use 'em for radial velocities sometimes too.. handy tip..

The radial acceleration curves are certainly fascinating, but i take no credit for 'em - it's the maths doing it, and as for how they work, it's currently a case of "very well, thank you"..

..but if the MoI was varying, we'd expect to see that in the velocity / momentum / KE plots, and as you can see, the variation's down in the -1e5 range..

Likewise, if the motor were controlled for speed or acceleration instead of torque, it would also reveal any variation in MoI.. so another potential check there.. i'm happy with it tho, all seems legit so far..

[MrVibrating]

OK, not quite as planned, but still fascinating:



actuator = -0.250883466

solenoid = 0.522160321

motor = 1.000027823

total in = 1.271304678

KE rise = 1.00004

diff = -0.271264678


Quarter Joule of input energy just vanished. No brakes, no collisions, no gravity.. it just disappeared!

It's a radial translation and a motor spin-up. Yet CoE no longer applies.. we've broken it simply by moving two masses radially - and losslessly - whilst also applying motor torque, to a constant MoI. Quarter Joule just MIA. MoI locked to six digits. Absolutely SFA to show for 270 mJ..


You can see in the plots that the asymmetry's bouncing around between the actuator and solenoid workloads - it gets shuttled from one to the other, and also seems to alternate in sign...

..to try enforce a little more symmetry, how about reversing the sign of the motor torque, instead of just switching it off every half-cycle?

So we'd be looking at a basic start-stop rig, that would accelerate up to 1 rad/s (or whatevs) and then brake back down to stationary upon returning to its starting angle - same torque up as down, just inverting the sign, so recouping the rotKE as output torque * angle on the same motor..

..then we should get the same asymmetry every cycle..

Or else, am i simply applying the motor pulses at the wrong intervals?

Maybe the mass positions should freeze once the gain's bagged, then decelerate the wheel back to stationary and reset them before the next spin-up cycle?

[MrVibrating]

I think it's an error.

Raising sim frequency should only shave zeros off a result, increasing precision.

The motor definitely only inputs 0.5 J (accelerating 1 kg-m² by 1 rad/s), so is not in question.

Simming the interaction at 1 kHz produces the following result:



act = 0.376001505

sol = -0.14149503



..but at 10 kHz, this result:




act = 0.376127433

sol = -0.319971166

..the actuator integral gets more accurate, as does the motor's (tho omitted here)..

..but the solenoid's more than doubles.

The lower figure's to within 2 mJ of unity.

Both runs achieve the same 6 digits of MoI lock, so the same radial displacements have occurred to within micrometers..

..only the area under the curve's changing, as a function of the number of frames the interaction's distributed across..


The FFB process is obviously introducing unmetered torques, on a per-frame basis.

Soz folks, but it looks like a phantom..