Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

Realised i could do substantially better than two digits accuracy on the MoI control, so now got it down to -9 / billionths of a kg-m²... while still running smoothly at a good clip:



Will prolly only be displaying 4 to 6 digits max, so MoI will be effectively constant.

I'll divide the same 1 kg-m² between however many weight pairs are used - with enough, they might get down to a few hundred grams each, and so providing very smooth OB torque.. you saw that slope - constant diagonal rise, no variation with time..


..that's gonna be where the fun starts - when i stick a motor on it and start perfectly cancelling that OB torque with counter-torque from spinning up an equal, balanced MoI in the same direction..

..and then braking it back to a definition of 'stationary' that's actually getting ½ rad/s faster every cycle.. perpetually resetting the torque * angle cost of momentum to ½ J / kg-m²-rad/s each time.. while raising its resulting KE value ever-higher..

Hmm, 'staircase plot' = "Jacob's ladder"..?

[unstable]

Hi MrVibrating, very interesting design. Thanks for sharing :-)

[MrVibrating]

Interesting.. so we get constant torque from just two OB mechs with a 90° offset:



..constant torque, constant MoI and thus constant acceleration! From looking at the plots alone you'd have no idea how many GPE cycles had even happened..

..and neither will the motor+rotor i'm gonna mount to it next.. 'Far as they're concerned, they'll think they're stationary! ;)


Should have data by the w/e at this rate..

[MrVibrating]

Hi MrVibrating, very interesting design. Thanks for sharing :-)

..well i'm having fun even if no one else is..

..this OB wheel is just the foundation for 'the design' tho - wait til i start using it as a rolling 'stator' with which to cyclically accelerate and brake a second rotor; a blank disc with equal MoI to the OB rotor..

[MrVibrating]

..attached is that last sim for anyone interested:


Notables:

• the rotary solenoids are being controlled for 'torque', so produce consistent reliable integrals

• the linear actuators are controlled for 'length', but all accelerations are being effectively damped by the actions of the rotary solenoids, hence there's no spikes in the plot / radial KE losses from slammin' 'em in and out, like.

..ain't taken no integrals yet as no reason to suspect anything other than unity..

[Georg Künstler]

Hi MrVibrating,
maybe you should also think reverse.
think of an ABS system in the car. where is this Energy, against what, lost.
it is an acceleration/deacceleration in the same direction.
why do we have 3 Formulars for Energy ?
Einstein With E=m*c*c
or E=1/2*m*v*v, where is the other 1/2.
and E=m*g*h.
I will Pass to you the internal construction of the device which i had already posted here in the tread.

[naksh31]

Excellent thread..!!!

[Georg Künstler]

Hi MrVibration,
the sliding from one side to the other you had already.

I cannot find my original drawing constructions, so I have to draw the pictures again.

Now you see my internal construction of the picture I already had send to you.

The construction was a metal plate with 2 inline skater rollers with an offset of 180 degrees.
the metal plate had an long hole, so that the metal plate can be shifted by a distance of 1 cm.
The complete system has therefore the possibility to oscillate in the specified range.

We can drive this construction to high speed, nothing will happen, the centrifugal force will bring this construction in a stabile rotation.

But now the second system. this second system disturbs the movment of the first system.
When system1 is faster than system 2, then the mass is shifted agaist gravity.
So system1 accelerates system2, this will be repeated again and again.

A modified ABS system with a feedback to, with gravity.

[MrVibrating]

I'd been intending to plonk the second rotor + motor in the middle of the OB one, like this:




..so that new dark blue rotor would have the same MoI as the OB rotor. Pretty straightforward, however, it's increasing the net weight of the system..

..whereas, note that the system already contains an unused internal axis; that of the weights themselves! So, why not just use that instead - increase the radii of the weights so that their summed MoI's are equal to to that of the main axis? Like this:




Whilst slightly more visually complex, it's physically leaner & more elegant..

So now, each weight still has a mass of 0.125 kg, but also a radius of sqrt2 meters, giving each an axial MoI of 0.250 kg-m² (per MoI=mr²)... so a net MoI of '1' in both the over-balancing and 'spin-up & brake' axes, and obviating the need for the extra weight of a dedicated second rotor..

If the end results prove negative, i'll maybe re-try using a dedicated second rotor after all, since more mass for a given speed means more energy.. (ie. i might've just inadvertently eliminated a key gain condition there, but we'll see.)

It'll now need four motor + brake sets instead of just the one, but they'll all run exactly the same instructions in perfect sync, so it's no more complex to sequence. Also, note that the masses and MoI's of each motor's 'stator' and 'rotor' halves, along with those of the 'brake discs' and 'calipers', can be included into those of the present masses and MoI's - so the motors and brakes themselves need add no additional mass or inertia.

• This same point applies to the MoI's of any switches / wires / sensors / nuts & bolts etc. in a real build - if 'everything must go around together', then everything with mass is contributing MoI.. but so long as the net ratio of the two interacting MoI's in the 'accelerate & brake' cycle is 1:1 (whatever their individual compositions), that's the shortest, neatest route up the OU ladder.. assuming a successful N3 break of course.


So, the next step is to add the four motors & brakes, plus their meters, then set the target relative speed with an input control field or slider (lower relative target speed = faster 'spin-up & brake' frequency and vice-versa, interesting dynamic to play with), and we should be good to go..

..as an afterthought, it might also be worth including an input control field / slider for the ratio or percentage of applied motor torque relative to the constant OB torque, to allow for runs with partial counter-torque cancellation instead of just fully cancelling..

..also, the previous "acceleration" plot wasn't particularly useful info on its own; 'OB torque' would be better, but WM cannot measure the OB torque at its axis because.. it's not there! It's coming from gravity.. so WM has no means to meter it directly (or, thus, any corresponding counter-momenta).. so i've now applied N2 to get the OB torque over angle instead (per F=mA, T=MoI*rad/s²). So now it's possible to measure and compare the T*a work integral actually output by gravity, with the rotational KE rise as a function of half the MoI of the OB axis times its speed squared, and in relation to the actuator and rotary solenoid input integrals.

As an additional benefit, this instantaneously-derived 'OB torque' value can be fed back to the motors, so their applied counter-torque will always be perfectly matched / scaled to it..

Finally, before progressing straight to the spin-up & brake cycles, it'd probably be worth just checking that the system as-is can solve reliably to within a millijoule or so of unity (ie. not because there's any chance of an anomaly, but precisely because there can't be). Call it a baseline 'dry run':




..and aside from the tiny implied 'gain' on the rotary solenoids (almost certainly noise from the reactive feedback process caused by coarsely-tuned multipliers), it's nigh-on perfect.

So the system's ready to start making KE.. by cyclically spinning up and then braking the weights themselves!

As ever, the question is not whether the four motors will show OU - we already know that's guaranteed - but whether or not the 'gain' will be equal to the input energy drawn by the OB system..

[raj]

MrVibrating, your sim presentation is WOW, mindblowing!
I cannot dispute nor comment.

I hope your build will be half as good.
Then, surely, I can make some comment.

Raj

[MrVibrating]

Hi MrVibration,
the sliding from one side to the other you had already.

I cannot find my original drawing constructions, so I have to draw the pictures again.

Now you see my internal construction of the picture I already had send to you.

The construction was a metal plate with 2 inline skater rollers with an offset of 180 degrees.
the metal plate had an long hole, so that the metal plate can be shifted by a distance of 1 cm.
The complete system has therefore the possibility to oscillate in the specified range.

We can drive this construction to high speed, nothing will happen, the centrifugal force will bring this construction in a stabile rotation.

But now the second system. this second system disturbs the movment of the first system.
When system1 is faster than system 2, then the mass is shifted agaist gravity.
So system1 accelerates system2, this will be repeated again and again.

A modified ABS system with a feedback to, with gravity.

Contact between rotor and stator - ie. between the parts we want to accelerate, and the 'world outside' - facilitates the system's exchange of momentum with the environment and so precludes the possibility of KE gains from an accumulating velocity..

Almost ANY system will involve radial and angular translations.. they're superficial similarities.

GPE interactions are inherently energy-symmetrical.

They're usually also momentum-symmetrical - and the potential energy costs of thwarting this particular symmetry is the singular focus and design criteria here.. it's "asymmetric inertial interactions with gravity, and the efficiency of accumulating the resulting momentum gains". The thread topic is investigating means for running asymmetric inertial interactions asynchronously to the GPE interactions that are sinking their counter-torque to gravity.

Thanks for sharing anyway, like i say it's an impressive build..!

[MrVibrating]

Excellent thread..!!!

Ta mate... the issue's one of those kick-yourself obvious one's that's been staring me in the face for years, but i've never really grappled with it before, mostly assuming it was an inviolable limit, intrinsic to the nature of rotating in a gravity field...

..and maybe it is, and all such attempts to overcome it are predestined to fail, the energy-cost of the GPE interactions will always equal the 'OU performance' of the internal accelerations, and i'll need to backtrack and find some other trail to beat..


..ultimately tho, like i keep saying, "excess KE" is a misnomer or oxymoron; a given inertia at a given velocity has a given KE relative to a given FoR, no more or less, thus a discounted energy-cost-of-momentum is, by simple proof of elimination, the de facto form of a solution.. and B. only ever showed vertical wheels.. so obviously he was using gravity to cause asymmetric inertial interactions, accumulating 'reactionless' momentum and so 'transposing' the value of its internal accelerations by the standard KE=½mV² value relative to the external (ie. ground) FoR. In short, the only mechanism in the universe for "making KE" - and the only one we'll ever need - is the standard friggin' KE equation; that, plus N3... and nu'in else. To put it another way, if we wanna 'scam KE' then we're wasting our time going for the KE directly; instead, we wanna manipulate the very terms that substantiate, enumerate and 'qualify' it in the first place - the very units and dimensions underwriting it..

eek nosebleed... s' OK i'm fine..

MrVibrating, your sim presentation is WOW, mindblowing!
I cannot dispute nor comment.

I hope your build will be half as good.
Then, surely, I can make some comment.

Raj

..not gonna rant not gonna rant.. (ahem)

Thank you Raj, you're far too kind sir.

Obviously, these are just simmed test rigs for measuring the efficiency of accumulating momentum from gravity - the conditions they're designed to fulfill are self-defined by the clear setting-out of the desired objectives and the systemic obstacles in the way achieving 'em, so there's not really that much room for creative flair or imagination.. it's really just box-ticking down the implicit "OU" checklist as set by the fundamentals of mechanics, in the certain knowledge that there is a way forward, that it's conceptually straightforward but mechanically complex, depends upon statorless vertical rotation, involves collisions, depends upon OB and masses changing radius, yet OB itself is not the exploit... etc. etc.

So "what to look for, and where" isn't really open to that much interpretation.. mostly just dogwork, linin' em up and knocking 'em down. Do it methodically enough and success is pretty much guaranteed. Idiot-proof reverse engineering from first principles. That's the brief. OK small rant.

Wanna try get data off this before the weekend's out... it's the not knowing that really compels me... just driven by damned 'ignance, bashically..

[MrVibrating]

I really need some reliable way to increment a value in WM.

Its core logic is structured like BASIC, however the way youd've gone about this back in the day would've looked something like this:

Code: Select all

 10  X=0                ## initially define / introduce the variable to be manipulated
 20  X=X+1
 30 print X
 40 if X < 100 goto 20, else end

..or just:

Code: Select all

 10 for X=0 to 100; print X; next

..or what-have-you...


So, in WM, we can employ meters as 'variables'. They can be hidden to reduce presentation clutter if we don't need to monitor their outputs. Thus "X" in the above example could be substituted with say "output[1].y1" - a blank meter we can fill in with equations.

So what i want to be able to do is store a value in that meter, and increment it by a fixed value (say, "1"), upon a given trigger event. So instead of "X=X+1", something like "output[1].y1 = output[1].y1 + 1"..

The reason i need this is simply to count the number of 'spin & brake' cycles being applied. I don't have to, just to get it up and running.. but it'd be contructive to be able to thus plot, say, the developing ratio of GPE cycles to s&b cycles for instance; or just to be able to pre-set a desired number of sequential s&b cycles for a run, so that the rotor can be left running a while after they've ceased, thus allowing the OB axis time to return back to its starting angle (because of their asynchronous phase), just for getting clean integrals..


The 'solution' i applied in the 'chicken run' was to note that the velocity of the system was increasing by ~½ m/s increments per cycle, hence dividing the instantaneous velocity by "2" gives the number of discrete accelerations that have summed to that velocity.. the "ceil" and "floor" operators can then be used to round up or down to whole-number increments, and voila, it 'counts' the number of s&b cycles.. kinda flaky and prone to rounding error accumulations tho..

I could re-try applying that principle here - basically 'deducing' the number of transpired s&b cycs by dividing the net velocity rise by the per-cycle velocity rise increments..

..but then i also wanna expose input controls for things like "target relative speed" and "ratio of motor torque to OB torque" - just the basic permutations / variations for full clarity and closure on the results..

..and these additional variables would need factoring into the derivation of "elapsed s&b cycs as a function of speed, for the given input torque ratio and given target relative speed".. - add in the fact that now the whole system's gravitating - and my maths are shite...

It's a bit like trying to design an inertial compass innit? There's gotta be a simpler method - a simple BASIC-like operation?

Each time the motors or brakes engage - thus signaling the start or end of a s&b cycle - i want to just increment the cycle count accordingly... how hard can that be?

[MrVibrating]

...possible solution:

• pin a small wheel to the background somewhere, and hide it - leaving it unconnected from the system in any way

• apply accelerations to it, mimicking those being applied by the rig's on-board motors..

• ..but omitting the braking phases, or any complications of gravity over time..

• ..thus its velocity will always be an exact multiple of the number of elapsed spin-up phases that it has been subjected to.. regardless of how the speed of the system develops in response to the same inputs + braking + gravity..


..bloomin' kludgy even if it works, but 'needs must..'

[MrVibrating]

..hmm - if the s&b period / frequency proves very predictable as a function of set 'target speed' and 'cancelling torque percentage', maybe that can be factored in relation to the 'elapsed time' on the clock to derive the no. of elapsed cycles, invariant of the actual system speeds?

Ie. if both the OB and input motor torques are 1 N-m, then the 1 kg-m² MoI's 1 m/s relative speed difference will be achieved in 1 second per cycle..

If the braking torque's identical, and there's no delay between phases, then a complete spin & brake cycle takes 2 seconds, and the number of elapsed cycles is equal to whatever the elapsed time, divided by two.. irregardless of the system speeds and angles etc. (anyone else smell burning?)

So it'd simply be a matter of scaling that metric to the 2.46 N-m of OB torque - just multiplying by it, basically..

Sorry, would spare yuz the desperately-boring minutia, but open to suggestions on this 'un.. a simple "upon Y, X=X+1" would still be the ideal form of solution..