Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

OK so i'm immediately measuring OU:



..so that is nice, just for an arbitrary 5 secs of startup.

If real, then note in that final frame that the beam is still mid-rotation; the KE must be equal to the velocity divergence of the input FoR: the wheel speed basically adding to the effective work being done by the currently active motor..

Gonna keep adding more meterage, momentum and F*t etc. etc., also breaking down the sim period to follow the efficiency one stroke at a time..


*as regulars know too well, i usually find OU on the first run these days, it don't mean shit, if i heat me coffee mug in the MW it's OU, if i fart it's OU, etc., caveat emptor and i'manidiotâ„¢ etc. etc.


eta: starting energy there was precisely ¼ J..

[MrVibrating]

Idea: set the sim to pause using the same switching conditions as the motors. Or the 'zero velocity' (locking) condition.

Take the integrals then hit 'run' and do the next stroke..

This should reveal the gain as a function of the motor's accelerating FoR..


Or the error. Whatevs.

[MrVibrating]

Increased run time to 10 secs.

Made beam into a lighter wooden piece, with a weight on each end.

Added a 100 ms startup sequence (subtracted from the clock) to allow for variable starting speeds.



• startup KE = 1.2185 J

• beam motors P*t = 58.525517 J

• final KE = 68.1580 J


Still too early to say much.. need to check the T*a integrals..

eta: note however in that final frame the beam's already stopped relative to the wheel, so the KE gain isn't only apparent when it's still rotating.. which is what we'd want to see if we're accumulating discount momentum..

oh and sim attached

[MrVibrating]

I made a start on frame-by-frame analysis, however it gets more complex over successive strokes as OB torque starts to mix in; although the beam starts out in a low center of gravity, could the KE gain be a function of its descent speed after climbing? Dunno. But trying to correlate the input PE to the motors with the output KE as a function of motor work and OB torque is tricky; hence simply resorting to I/O efficiency over time seems clearer-cut..

Also need to measure dissipated energy, cuz if we're losing some every time the motors lock then net of heat plus KE's even higher..

[MrVibrating]

OK i refined the motor switching condition to base it on the rising of the opposite beam end (ie. the inactive motor), as opposed to the descent of the active motor..

So now it'll only apply torque if that's also raising the inactive beam end (currently a 1 kg mass on each end), thus ensuring counter momentum is sunk to gravity..



• again, startup energy is just 1.2185 J

• final KE after 10 secs = 63.7686 J

• motors P*t = 22.3330308 J


~3x.

Mad eh?

Will cross-check T*a's next..

[MrVibrating]

Eek motor 1 (the first to go) T*a = 52.03488882 J..

Motor 2 T*a = 57.02501421 J.


Well that wiped the grin off..

So have they done 22 J of work, or 109 J?

I've come to expect small discrepancies between P*t and T*a, but this is a corker..

Either of those T*a's would get us most of the way to unity, but both together..? Could ~50% really have been dissipated?

Think i may re-try with fixed i-s/f.. 'variable' must be part of the cause here?

[Wubbly]

I found that sim impressive. You got it to run and sync up those hand-offs. Gonna take a while to pick that one apart and see exactly how you did it.

The motors are raising the PE of the rod and the mass on the other end because they are being lifted up.

[MrVibrating]

Well the objective wasn't simply to perform the interaction but to measure its efficiency - and doubtless it's square unity like all the others - but for now one metric says OU and the other UU, when they should agree to mj's..

I suspect this discrepancy is largely caused by variable i-s/f.. but either way i need to be able to run it in fixed i-s/f just to rule that out..

..which is inevitably going to mean reworking the logic from scratch.

I've already tried switching the last sim to 10 i-s/f @ 1 kHz, which seems to perfectly catch the '30°' target angle (at least for the first few steps i've tried), however this causes a new problem - instead of simply drawing a red line denoting where the motors should be attached to the wheel, it's actually physically jumping the beam to those initial starting locations on every step.. so 'catch and rotate' still works, but position's screwed..

..i didn't even expect that much tho (i thought the beam would just immediately fall away, unable to locate the precise 30° within the available range of time / speed intervals), so was already considering fresh options..

I think the best route to guarantee a perfect 30° each time is to control for 'rotation', which necessitates producing a number that climbs from 0-30 as smoothly as possible. This should be within our abilities, but i need quality head-time to make progress and currently have none - took Tuesday off cuz the ball seemed to be rolling but lost me retainer because of it, thus working for peanuts rest of week. I'll prolly duck out another day next week, soon as i figure out a tenable path forwards, one step at a time eh..

There's always controlling for 'torque' using reactive feedback ("apply as much + or - torque as necessary to achieve the given displacement" - but this too has a tendency to produce PE / work-done discrepancies (tho not usually as large as this).

For now there seems little point in trying too hard to rationalise either integral - we've the obvious bias to want gain, and i don't see ~50 J being dissipated in the current plots, so neither metric can be considered credible. Only when they near-as-damn match is the interaction resolved..

So, prolly another dud - the 'maths of OU' is legit and axiomatic far as i'm concerned; it's all self-evident - but whether or not this rig is embodying those variables any better than previous attempts is currently unknown..

We'll get there tho..

[MrVibrating]

Still not got to a day off i'd need to continue with a clear head, but considering just reverting back to the tried and tested force feedback techniques - basically simulating servo control to "apply whatever +/- torque required to achieve the given displacement / time"; knowing it's error-prone, and how the error can accumulate with freq and i-s/f, it's a known quantity, right? Likewise we can discern when it's decreasing with lower freqs etc.; bottom line, it's fairly manageable.. so long as you know your noise floor..

This should be sufficient - at least with the above kind of debugging - to get half-decent agreement between T*a and P*t. Couple of mj's here or there won't mean nu'in, but if they're both to within a few mj's yet substantially less than KE + heat, that'd be interesting..

I'd still be perfectly happy with 12 motors and 24 precisely-sequenced rigid joints, if i could only figure out how to program it - PITAS to set up, but should run fine in fixed i-s/f.

That's gotta be the practical measure of 'success' tho - whether or not i can friggin' measure it at all..

[MrVibrating]

Bumping my own BS but haven't had any other reason to re-post it again in the last week, so just for the sake of keeping eyes on the prize:




Of all the sims i've ever knocked up, this un's the one to watch..

Only 25% efficient. Fully 75% of all input energy dissipated.

But find an arrangement that can accomplish this four times in a row - accumulating the resulting momentum rises - and you hit unity; you now have as much KE as PE spent.

Unity.. ignoring all that heat generated anyway.

A fifth such cycle makes 125%.

150% at the sixth.

175% at the seventh.

200% at the eighth.

And so it goes on; another 25% more efficient every elapsed cycle.

Both the above configs are too simple - as momentum accumulates, so does the drop rate, successively shortening the time available each cycle for sinking counter-momentum to gravity's constant acceleration (or deceleration, in this case).

Can MT 137 break that mold, and climb at least some way up the slippery slope?

Such a simple interaction; a cod could follow it!

[MrVibrating]

Spent a few hours on it this eve, throwin' in the towel as can't progress..

Been trying to control for torque, and also for rotation (taking a signal from the clock to generate a smoothly increasing angle, a la "mod(time,30/180*Pi)"..

Both methods work well for incrementing the angle by 30° each step, producing usable torque * angle data..

..the problem, as before, is attaching rigid joints to future body alignments.. it's frickin' impossible using the GUI.

I've reverted back to having 12 rotor-motors, and trying to pass the beam between 'em with switching rigid joints, but it's defeating me..

The interaction is still fascinating, and i'm desperate to measure its efficiency.. but first it needs sequencing, using fixed i-s/f..

If anyone has any brainstorms here, don't be shy..

[MrVibrating]

..just 'cos it don't require any mental effort, i'm gonna try squeeze a bit more outa the variable i-s/f rig, since it's already working.. half the battle etc..

Setting all the precision multipliers to 1e-16, with 16 digits internal, max-freq over a single full turn, then two turns etc., see what falls out..

[MrVibrating]

Wow, finally seeing agreement between the input metrics, check this out:



This is for one full turn, again with a starting energy of 1.2185 J.

• KE = 21.9267

• net motors P*t = 25.69258233

• motor1 T*a = 17.66791241

• motor2 T*a = 8.022404215

• net motors T*a = 25.690316625


...so this is interesting; T*a and P*t are within a millijoule, and less than KE.

So there's two possibilities here, as i see it; either:

• we're on the ladder, tho currently UU, below the unity threshold

Thus progressing a bit further to two whole turns, efficiency may increase, confirming the first P*t indication of OU with the T*a integrals.. or else:

• if i were also logging dissipated losses i'd find unity, and maintain it whatever the number of elapsed turns..


So, is it unity incl. losses, or are PE and KE actually decoupled per 'the plan'..?

Gonna try squeeze in a second turn before bed..

Variable i-s/f seems to be vindicated tho for now.. seems that restarting from scratch at fixed i-s/f was a bit rash before i'd tried maxing the integration precision..

[MrVibrating]

Mind, i ain't checked GPE yet either, so, not just losses to consider..

To wipe out any question of GPE change i'll stop the next sim as the beam returns to its starting position.

Then if the input metrics are still > KE, the difference is presumably losses and i'll measure those too for full resolution.

However, being a slightly longer run, if it is doing the business and the inputs agree at less than KE, then we're already OU, and combining the losses will simply make us even moreso.

Fun times..

[MrVibrating]

• KE = 41.4686

• net motors P*t = 41.13517786

• motor1 T*a = 25.24378924

• motor2 T*a = 15.88743856

• net motors T*a = 41.1312278

Note that the MoI's are not currently matched - the beam is 1.9 m long with a 1 kg weight on each end, whereas the wheel is a 1 kg disc MoI with the additional 2 kg weight of the beam attached - hence we couldn't expect a perfect 25% accumulator even if it was working as intended..

However whatever the current MoI ratio, the initial OU sim was for a 10 second period - twice as long as the above run..

..so, maybe with any GPE change out of the equation it's unity, or else maybe we've just hit the unity threshold and continuing further will see efficiency increase..

Thus one more run's in order, once again sustaining for around 10 secs, but also this time stopping only when the beam's back to its starting height.

If we're again OU in spite of no GPE change, then bingo..