Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

<Yawn> mornin' all.. <sips coffee>


No one repeated that measurement yet? Just drop two masses, pushing 'em apart vertically, while measuring PE:KE.. that's it.

No code, no maths, just drop, push and measure..

Equally, anyone have any thoughts on how an error might be arising in such a measurement?

[MrVibrating]

..just in case it interests, here's another variation i was measuring yesterday:



• in a system already rotating at 1 rad/s, two internal rotors are counter-spun against one anothers equal inertias (all 3 axes are 1 kg-m² MoI's) by 1 rad/s

• the two orbiting motors each apply a constant 1 N-m and -1 N-m respectively

• ordinarily, this should thus accelerate the 'positive' rotor up to 2 rad/s, while decelerating the 'negative' one down to absolute stationary; the central hub velocity never wavering from its constant 1 rad/s

• moreover, these displacements should resolve neatly to a 1 second period..

• at the same time, tho, the rotors are also pulled inwards, thus applying a positive inertial torque

• the central MoI is thus reduced by half, so doubling the speed; IOW applying a 1 rad/s acceleration

• this reactionless acceleration of the net system has thus caused a time-dependent asymmetric distribution of momentum between the two rotors from the mutual 1 N-m torque being applied internally between them

• net momentum is constant - can't be changed without recourse to gravity and time - but the objective here was to examine the effect sans gravity, under inertial torque instead; the results however clearly supporting the hypothesis, namely that an N3-respecting inertial interaction in an accelerating FoR causes an effective N3 break in the ground / static FoR

So once again, coming back to gravitating inertial interactions; if you can generate, in the ground frame, a +1 momentum and a corresponding -1 counter-momentum, you have the standard zero-sum per N3, whereas if instead you can apply an effective uniform acceleration to that internal relative mutual acceleration, the +/- balance of momenta may thus be skewed; you haven't made any extra, yet.. until you sum them back together in an inelastic collision, wherein an imbalance of say -0.99 : +1.01 leaves the small, but non-trivial remainder of +0.02: at this instant we thus do 'gain' momentum.. seemingly from time and inertia itself, but truly, from the time-dependent inertial asymmetry in the gravitating FoR..


ETA: the calcs shown in that last sim are from the 10 kHz integrals; the anim here's only at 1 kHz for speed of playback (and it's a slight energy loss, rather than gain, tho prolly not 'anomalous', and caused by the 'orbital/axial-motion' transition as they're pulled into the exact center)

[MrVibrating]

..noticing that controlling the motors for 'torque' there wasn't really accomplishing the intended interaction - since the hub's acceleration from the inertial torque overtook the internal relative accelerations, hence the actuators essentially performing work against the motors - here's the same thing again, only this time controlling the motors for 'acceleration':



..so that's 1 rad/s² and -1 rad/s² respectively, relative to the 'hub' FoR, which in turn is being accelerated out of the 'ground' FoR by the inertial torque / ice-skater effect.

The measurement here was made at max freq, ~8 kHz, the energy balance now slightly positive, tho too early to say if significant..

Note another recent measurement when controlling for 'acceleration' produced a false positive error.. haven't yet taken the T*a integrals here for comparison (just P*t), will post 'em when done, but this system's non-gravitating (it's turned off in the sim) so should be closed, you'd think, solving neatly to unity.. the intention here to affirm the inequivalence of inertial and gravitating systems as 'closed' vs 'open' to effective I/O F*t asymmetries..

Either way tho the focus for now remaining on gravitational acceleration; the anomaly there apparently 5x greater..

(ETA - soz the plots aren't in focus there but not much to look at regardless - just short linear traces. Data's all there tho.)

[MrVibrating]

One aspect of immediate note there is the instantaneous deceleration of the hub, from its initial speed of 1 rad/s, down to 0.333 rad/s:

• this deceleration appears to transpire in effectively 'zero' time - literally 'flipping' w/o decelerating between consecutive simulation frames at hi-freq

• this phenomenon is understood when considering that while coasting at constant relative RPM's, or when stationary, half of the central 'hub' MoI is constituted of the mass * radius² of the two opposing rotors, essentially just 0.25 kg point masses at 1 m radius..

• ..upon active angular displacement in each direction by the internally-applied mutual 1 rad/s² acceleration however, their own axial MoI's of 1 kg-m² each is instantly added to that of the hub's 1 kg-m², effectively tripling the MoI component of its initial 1 kg-m²-rad/s of starting angular momentum.. thus 'instantaneously' decelerating the ½ kg-m² MoI of the hub itself by a factor of 3.. (!)


Again tho, while fascinating, without gravity and time in the frame this is surely just tail-chasing..

..and in reality, i suspect 'instant' torque isn't a thing - always presumably necessitating an arbitrarily-short, perhaps, but unavoidably finite ramp-up period..(?)

[MrVibrating]

That last sim on the previous page - 'quadro' - should remain the current focus of attention; it's half a Joule hot, so this needs resolving or replicating, as a priority..

[agor95]

<Yawn> mornin' all.. <sips coffee>


No one repeated that measurement yet? Just drop two masses, pushing 'em apart vertically, while measuring PE:KE.. that's it.

No code, no math's, just drop, push and measure..

Equally, anyone have any thoughts on how an error might be arising in such a measurement?

Morning - How is the head Mister Codeine ;) Say hello to your liver from me.

Your research is interesting and it would be good for other Sim'ers to join in the analysis.

The technique that allows two falling masses the chance too collide is innovative.

Not having the software to sim with such rapid productivity one has to make the best out of what is available.

There is some similarities with the kinetic to my best hope.

Gravity increased velocity then a collision resulting is a non-symmetric end result.

I expect most members at some point have looked into such interactions.

All the Best

[MrVibrating]

ah it's all BS mate, i wouldn't pay too much attention, no idea WTF i'm doing..

Just re-ran the 'quadro' drop w/o the 'drop' bit - ie. with gravity disabled - and still got the PE anomaly, so.. WM sucks, basically.. dunno why a simple inertial interaction should render an I/O energy disunity, so this still needs further investigation if only for having some kind of stable noise baseline..

[ME]

<Yawn> mornin' all.. <sips coffee>


No one repeated that measurement yet? Just drop two masses, pushing 'em apart vertically, while measuring PE:KE.. that's it.

No code, no maths, just drop, push and measure..

Equally, anyone have any thoughts on how an error might be arising in such a measurement?

You usually react not well when I present you my calculus...
:-)

It's simple enough to do it by hand:
A system weighing 5 kg is in freefall for 1 seconds starting from a motionless situation.
After 1 second its velocity will be 9.80665 m/s
The freefall energy compared to ground is: ½·mv² = 240.42596 Joules (rounded to 5 decimals)

An actuator pushes these weights apart with 19.6133 N while in freefall (For getting us an energy value the orientation of this action does not really matter)

Relative to the Center of Mass the 1 kg will accelerate with 19.6133 m/s², until it goes 19.6133 m/s after 1 s and has (relative to the center of mass) ½·mv²=192.3408 J

Relative to the Center of Mass the 4 kg will accelerate with 4,903325 m/s², until it goes 4.903325 m/s after 1 s and has (relative to the center of mass) ½·mv²=48.0852 J

In total the actuator spends 192.34077 J + 48.08519 J = 240.42596 J
Thus in total there's 480.8519211 J in the form of Kinetic energy in this system.


The other method is where we just look at the absolute velocity relative to ground.
The 1 kg goes up with 19.6133 m/s - 9.80665 m/s = 9.80665 m/s. KE[1 kg]=48.08519 J
The 4 kg goes down with 4.903325 m/s - 9.80665 m/s = -14.709975 m/s. KE[4 kg]=432.76673 J
Thus in total there's 480.8519211 J in the form of Kinetic energy in this system.

Dunno why you have errors.
Some measurements don't always get registered well by WM2D and need to be checked manually.

Acceleration is such a suspicious factor in WM2D.
To keep it thematic with some other topic: Create an incline, drop a ball on it, measure its acceleration and velocity. The velocity vector gets the correct vector down the slope. Acceleration will first be derived from it Weight, and points straight down until WM2D decides to correct that vector down the slope too. Sure it's understandable from a physics point of view, but it can give you headaches when not paying attention.
When that's a/the problem, then the derived measurement are at least suspicious:Try to recalculate things (like actuator power) via another way.

[Tarsier79]

You could accelerate the masses inward using pulleys and a weight instead of an actuator.

[ME]

Not in freefall. You could use a spring though.

[MrVibrating]

<Yawn> mornin' all.. <sips coffee>


No one repeated that measurement yet? Just drop two masses, pushing 'em apart vertically, while measuring PE:KE.. that's it.

No code, no maths, just drop, push and measure..

Equally, anyone have any thoughts on how an error might be arising in such a measurement?

You usually react not well when I present you my calculus...
:-)

It's simple enough to do it by hand:
A system weighing 5 kg is in freefall for 1 seconds starting from a motionless situation.
After 1 second its velocity will be 9.80665 m/s
The freefall energy compared to ground is: ½·mv² = 240.42596 Joules (rounded to 5 decimals)

An actuator pushes these weights apart with 19.6133 N while in freefall (For getting us an energy value the orientation of this action does not really matter)

Relative to the Center of Mass the 1 kg will accelerate with 19.6133 m/s², until it goes 19.6133 m/s after 1 s and has (relative to the center of mass) ½·mv²=192.3408 J

Relative to the Center of Mass the 4 kg will accelerate with 4,903325 m/s², until it goes 4.903325 m/s after 1 s and has (relative to the center of mass) ½·mv²=48.0852 J

In total the actuator spends 192.34077 J + 48.08519 J = 240.42596 J
Thus in total there's 480.8519211 J in the form of Kinetic energy in this system.


The other method is where we just look at the absolute velocity relative to ground.
The 1 kg goes up with 19.6133 m/s - 9.80665 m/s = 9.80665 m/s. KE[1 kg]=48.08519 J
The 4 kg goes down with 4.903325 m/s - 9.80665 m/s = -14.709975 m/s. KE[4 kg]=432.76673 J
Thus in total there's 480.8519211 J in the form of Kinetic energy in this system.

Dunno why you have errors.
Some measurements don't always get registered well by WM2D and need to be checked manually.

Acceleration is such a suspicious factor in WM2D.
To keep it thematic with some other topic: Create an incline, drop a ball on it, measure its acceleration and velocity. The velocity vector gets the correct vector down the slope. Acceleration will first be derived from it Weight, and points straight down until WM2D decides to correct that vector down the slope too. Sure it's understandable from a physics point of view, but it can give you headaches when not paying attention.
When that's a/the problem, then the derived measurement are at least suspicious:Try to recalculate things (like actuator power) via another way.

Yes, actually solved it a couple of days ago and you're right, it's a 50:50 split - half the KE is from output GPE, half from the internally-applied force. Both metrics of F*d and P*t were producing the same error margin.

Having measured pretty much the same interaction multiple times previously, i wouldn't have given it a second look were it not for the need of tracking down every error - even if just half a Joule in 500.. 'case closed' being unity to millijoules, but yes, it's there now..

[MrVibrating]

Re. the previous look at controlling speed as a function of non-gravitating inertia, i've thought of a potential application with which to test it:

• make two basic 'classic OB' wheels (ie. w/ radial lifts by actuators), superimposed on the same axis

• both have identical I/O GPE / OB torque, but one has maybe two or four times the angular inertia

• interconnect them via a brake that pulses on and off

So both will be gaining equal momentum / unit time, but the lighter one will run faster..

The brake could be pulsed on and off, dissipatively, or else smooth / progressive braking with a sinusoidal negative torque..

..you only need apply negative torque tho - when the brake's released, the lighter one will be sped up again by gravity.

Rationale: that acceleration of the lighter wheel by gravity is 'reactionless' WRT the heavier wheel (ie. it's an interaction between each wheel and gravity, but not between the wheels themselves), whereas the braking phase is always an interaction between them..

To put it another way, the lighter wheel always accelerates unilaterally relative to the heavier wheel, while always decelerating in mutual interaction with it - again, if we can thus obtain say a -0.40L : +60L momentum asymmetry, that should recombine to a +20L gain each cycle..

Results when i get 'em..

[agor95]

I appreciate it is a pain to check.

However it needs to be done. Otherwise members may spend time on a design were there are others designs to be checked.

All the Best

[MrVibrating]

OK here's that interaction set up and ready to measure:



..gonna spread that 5 secs over all 32,765 frames, so a freq of 6553 Hz, with 1,000 i-s/f - will prolly take a while but trying to avoid a false positive on first attempt, for once.. don't need the drama..

Expecting GPE unity for KE + braking losses of course - ie. failure to launch a 'divergent FoR'.. but hopefully a slightly better handle on why..




ETA: lol it's currently calculating 2 frames at a time, every 3 seconds, so hope it's finished b4 bed (and unity at that, if i want any sleep)..

Results when i get 'em..

[MrVibrating]

Made one oversight in framing the last run - 1 collision / sec, for 5 secs, with a 4:1 inertia ratio..?

..ie. if it was decoupling I/O energies via a momentum asymmetry, its 'unity threshold' would be 4 + 1 = 5 cycles.. IOW it'd produce a unity result regardless; the p-c efficiency accumulator would be 20% so four cycles would reach 80% efficiency, and six, 120%.. but five would report 'nothing to see here', with an actuator P*t integral perfectly matching the KE rise.. (altho the brake losses would still be OU).. derp.

So ended up settling on the parameters below instead:



• since the OB torques here are constant:

• 10 Hz braking freq (10 asymmetric collisions / sec)

• minimising relative speed difference, and, thus, energy dissipated p-c

• maximal number of elapsed cycles - if each were consolidating even a very tiny momentum gain, it would rapidly accumulate to significance


..but hey wow surprise.. nothing doing.

Unity, as best i could make out - actuator P*t consistently > KE.

The 'braking' integral doesn't however produce good data - it's implemented by connecting the two wheels via a rotary joint and a motor controlled for 'velocity' and set to '0', then switching between their 'active when' conditions, such that the 'brake' activates when 90% of the selected 'braking period' has elapsed, applying the brake for the final 10% of the period, and switching back to the rotary joint for the other 90% of the time. However this causes WM to calculate the appropriate negative torque in a single frame - those spikes on the plot are single data points, not 'integrated' across any angle of displacement - ie. 'good' data should show some width between any excursions from and back to the 'zero' line; then you've bagged some data 'under the curve', with which to perform an integration upon. This is why spiky data is of poor quality.

A better 'brake' would thus apply smoothly-graduated negative torque, but the closest thing WM has in its preset toolbox is a 'rotary damper', which if you think about it isn't a 'brake' in the sense that you'd be in trouble if your car could only damp a preset percentage of KE..

So we could do with some reliable method of modelling clean, progressive braking / negative torque. Perhaps a simple servo-loop, where a motor applies negative torque as a function of relative angular displacement / time? Dunno, but will need to solve this at some point.

In this instance tho the results are convincing enough for me - it's not causing anomalous acceleration of the input FoR, and can't..

..the question is, why? What is the missing action or condition that would result in decoupling, but that this approach fails to accommodate..?

• we have a constant ten 'reactionless' accelerations and inelastic collisions per second

• the MoI-intrinsic G*t delta ensures 'green' only ever accelerates towards 'red', an effectively unilateral torque * angle

Given these points, why can't a PE:KE disunity proceed..?