Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

Notwithstanding that i ain't exactly the first to think of it, this is an audacious yet remarkably-simple interaction, if it can be pulled off..


Again, consider the expected result with and without gravity enabled; if it can be sequenced such that the beam is always lifted against gravity, then every stroke will accelerate the wheel more than the beam, thus pumping more and more conserved momentum into the main axis, accumulating it..

It's a potentially-working 'chicken run' interaction, i think:

• if rotor and stator always begin at zero relative velocity

• a relative 1 rad/s acceleration between two 1 kg-m² inertias costs ½ J

• if only one undergoes absolute acceleration, because gravity

• a subsequent braking / collision redistributes that gain in L

• because equal MoI's, optimal net accel. of whole system

• thus back to zero relative speed & nominal input costs..

• ..inside a now-accelerated 'zero-momentum frame'


Auto-acceleration of the ZMF literally transposes the KE value of our input work by the velocity divergence:


• per ½Iw² the nominal cost of each 2 kg-m² / ½ rad/s acceleration of the net system is ½ J

• thus after spending 10 J we'd have 2 kg-m² at 5 rad/s

• per ½Iw² 2 kg-m² at 5 rad/s has 25 J

That assumes smooth / conservative relative decelerations; if they have to be lossy / inelastic then mech. efficiency decreases but net of heat plus KE is still OU, and assuming 50% loss per cycle at say 20 J of input work we'd have 2 kg-m² at 5 rad/s and thus 25 J - 5 J KE clear - despite losses.

You're just not supposed to be able to take your stator along with you for the ride.

If you want to gain speed, you're supposed to gain it relative to the stator.

That way, the input energy cost of momentum squares, along with its KE value.

Bessler was subverting that. "EMGAT". MT 137 may be an ideal encapsulation of the exploit..

[MrVibrating]

This may be a stupid idea, forgive me if it is the case.
Is it posible to put the rotor motors on the ends of the beam?
By activating and dissaactivating what they apply force to, they could continue working in empty space during their movement.

Possibly the stroke of genius we need...

..gotta go spend the rest of the eve slinging pizzas tho so back later..

[Wubbly]

My attempt at using rigid joints as locking mechaniams resulted in abysmal failure so I abandoned it, but that was before I realized that Simulation Accuracy -> Integration Step needs to be set to Variable.

Using scripting it's easy to asign a point of a constraint to a body that is not aligned with the point. Here's a function to accomplish it. Point(1) attaches to body1 and the local x, y and angle are relative to the FOR of body1. Likewise, Point(2) is attached to body2 with their local points and angle. You have to set AlwaysActive to False before you do this because if the points and bodies are not aligned, WM2D will try to align them and you get a "trying to assemble" error. You would have to store the bodies in an array so you could assign the ActiveWhen statements in the main subroutine. One of the difficulties is getting all of the point angles to align correctly. I usually use some global zero angle to align them to.

Once you got the correct activeWhen logic, there's no guarantee that WM2D would not find some other reason to fight with you.

I abandoned this approach with a simple one lock on a single weight but maybe you'll have more luck with it than I did.

[MrVibrating]

Dude i do not understand a line of that code - ain't touched scripting yet bar running other people's, so need to work through some tutorials there..

I'm generally wary of using variable integration steps as opposed to simply increasing the number or frequency tho, because of data quality - my understanding is that it effectively shortcuts through the details where the devils are; i'd always rather root 'em out even if it means 1 frame / minute..

It's too late and i'm too shot now to do much, just gonna drink me nightcap and watch a Das Boot ep. Gotta be at work for 10 am.

Robin's idea is all i need, i think, to work within my current skill set - i can make it work, i think, since switching a rigid joint connecting either motor (plus beam) to the wheel base won't care about alignment to the wheel body - WM will just display a red line showing where the joint should be, but it'll still function without throwing an error, i think, touch wood..

eta: plus it's just two motors instead of 12. Smart move, a problem aired etc. etc.

Back at this tomorrow eve, hopefully with progress..

[MrVibrating]

Figured out the easiest way is to just attach a motor connecting each end of the beam to the wheel..

..set both motors to the same constant velocity..

..and then simply switch their 'active when' conditions on and off, every time the opposite one's completed another 30° of rotation..

..so i need a formula that will detect these 30° rotations - how should one go about that? Determine if elapsed rotation in degrees is divisible by an integer multiple of '30' or something?

FWIW i've managed a few steps around already and it's not looking so promising, but determined to see it through..

[Fletcher]

Try this, or a variation.

https://www.besslerwheel.com/forum/view ... 091#167091

[Robinhood46]

The beam may well be progressing around the wheel, but i would have thought that the interactions are happening in a relatively constant place in space. If this is the case, can the commands not be controlled by activators fixed to the rim, which are triggered by something fixed to the frame/ground?

[MrVibrating]

..OK got it:

Deleted all the rotors and motors.

Stuck one motor on each end of the beam, both set to a constant velocity of 1 rad/s.

Made the a/w conditions of one:

• Mod(constraint[10].dp.r*180/Pi,60)<30

..and the other (obviously):

• Mod(constraint[10].dp.r*180/Pi,60)>=30

..you can see how it works; referencing one motor only, since the inactive one is still being rotated along with the beam, so every 60° is a 'full cycle' of two 30° rotations, hence:




Et voila.. and it'll happily do that all day, with just one line of code plus a slight modification on it.. (plus a Robin (good call there)).

See what i mean about not being very impressive eh..

Perhaps the motor activations can be applied a bit more judiciously? As in, a bit more over-balancy, type situation?

Whatevs, will start layering it up with meters tomoz, get a better handle on the prospects..

[MrVibrating]

Try this, or a variation.

https://www.besslerwheel.com/forum/view ... 091#167091

Yes mate, got it in one - i knew that function was there, never really needed it before (or thought to use it anyway).

The function i intuitively wanted to use was a BASIC "for n=1-30, next n" - to simply generate a number that cycles through a given range on a loop; there's 101 different ways of expressing it in different languages but it's a programming staple that seems conspicuously absent in WM.. always trying to work around that issue.. you can take a signal from the clock of course then apply manips to that, or likewise hide a rotating mass and reference that etc., but kludgy..

This time however the Mod function filled in nicely.. cheers for the pointer..

[MrVibrating]

The beam may well be progressing around the wheel, but i would have thought that the interactions are happening in a relatively constant place in space. If this is the case, can the commands not be controlled by activators fixed to the rim, which are triggered by something fixed to the frame/ground?

You're thinking too practically for a sim, but yes, could do it that way..

..as you can see i'm the same way - start out with a long parts list then (with a 'lil nudging) got it down to just two..

Is it buildable as-is? Nope. All that matters to the initiative tho is measuring its efficiency - that is, if there's any accumulation of momentum at all, currently somewhat questionable but as i say, i'll start metering it up and tweaking the timing tomorrow night..

Eek before i forget, sim's attached..

[MrVibrating]

..lol be a piece of piss to add more levers tho eh.. might make a fully-animated MT 137 in authentic style..

[Robinhood46]

Is it buildable as-is? Nope. All that matters to the initiative tho is measuring its efficiency - that is, if there's any accumulation of momentum at all, currently somewhat questionable but as i say, i'll start metering it up and tweaking the timing tomorrow night..

I'm pleased to see that it is possible to get the "walking around" effect with a sim. I haven't yet mastered Algadoo, so it will be a while before i progress to real sims. The comparison is like playdough and meccano, they are not really at the same level.
It will be interesting to see what sort of calculations turn up with different configurations. I don't think you will get a positive outcome, but as i have already said a few times, i hope to proven wrong.
What i do find promising is the leverage that can be used, at little cost, to cause another mass, or masses, to move favourably.
I definitely think it is a step in the right direction.

[MrVibrating]

..really comes down to the per-cycle momentum yield; presently it's over-and under-balancing about equally, so the momentum's constant over time.

The desirable outcome would see the beam counter-rotating the wheel only for the first few steps, before both were turning in the same direction, with the wheel speed increasing by an equal amount each stroke. Hence the beam would keep walking at say 2 rad/s or whatev, while the wheel speed rose significantly above that..

So i need to hone the sequencing, to try and leverage gravity / OB to wring the maximum degree of inertial asymmetry from each stroke.

The maths of OU, remember, requires ideally that each stroke consistently only accelerates either the beam or the wheel, but not both; further, each stroke must end in relative stasis between the two parts, which i've currently left no explicit provision for - both motors are applying constant angular velocity and are switched in consecutive simulation frames, hence zero pause, or, thus, any way to check per-cycle momentum yields.

• Asymmetric-inertial interaction --> redistribution / accel. of net sys. --> repeat

That's the objective, over 'walking' per se..

My expectation is that this will be possible - it's been achieved in most previous attempts already, however in those cases, either the required input work still increased in line with RPM, or else the amount of momentum gained per cycle fell off with RPM, in either case perfectly tracking the ½Iw² standard (so no successful acceleration of the input FoR).

The magic only arises when every internal stroke causes the same rise in net system velocity / momentum for the same work done - input costs thus simply summing with cycle no. / speed, while rotKE squares up, per usual.

So later i'll begin measuring and breaking down the interaction - one of the first meters being 'net angular momentum', which atm i suspect's hovering around zero..

[MrVibrating]

OK so i left the switching conditions as-is, and just refined the motors' velocity control to meet two conditions:

• the motors will only apply torque on the descending side of the wheel

• they'll lock once each 30° angular displacement's completed

The 'velocity' inputs for each motor are thus now:


• if(and(mod(constraint[7].dp.r*180/Pi,60)<30,point[6].v.y<0),input[11],0)

• if(and(mod(constraint[10].dp.r*180/Pi,60)<60,point[9].v.y<0),input[11],0)

(where points 6 & 9 are the 'upper' motor halves, attached to the beam)

..so exactly the same logic, just a bit more discerning in application.


The rig thus now accumulates angular momentum from gravity and time:



..note that the internal speed ('pace') is constant, invariant of rising RPM.. we're not having to increase its speed to keep accelerating the wheel.. so if that detail alone don't give you a boner you ain't got yer head in the game.. per-cycle input work doesn't appear to be increasing with RPM..

But what of the momentum yields wrt RPM - if we're performing equal work each stroke, but for diminishing yields (inevitable beyond some threshold RPM), then nothing doing / no PE-KE symmetry break.

I'm gonna add one more input, to set a given initial RPM, since the wheel begins in a balanced state but the trigger condition for the motors is their respective descents, so a slight push-start's required (above i just assigned the wheel a small initial RPM).

Then it's measuring time:

• i'll combine both motors into a single meter, plotting T*a and P*t per usual

• then take integrals as a function of elapsed strokes, comparing net PE to KE at various stages into the run

As ever, temper your expectations, it'll most likely remain symmetry bound at all times, just like every previous attempt..

..but the above behaviour is initial reason for cautious optimism, i suspect.. could the efficiency be non-linear here..?

Also of interest will be step heights on the momentum plots as a function of RPM..

And as ever, since it is just a sim, we could further refine the 'walking pace' with an RPM multiplier, either increasing or decreasing it as a function of wheel speed, to see how this changes the p-c L yield..

[MrVibrating]

Just a minor update, but it's time i conceded Wubbly's point re. variable integration steps:

• accurately locating precise 30° displacements across a changing range of wheel RPM would, in principle, require infinite sim frequency

It's literally a case of slicing time-intervals ever-finer, until reaching such a high time resolution that a perfectly-round '30°' (or any given displacement) is reached upon resolution of a single given frame..

Whereas in practice, the nature of serial computing in finite time when simming variable mechanical speeds is that you can only really aim to come within some finite range of the target displacement; it's not impossible to get a lucky bullseye, you just can't rely on it consistently.

And as noted already, any variation in locking angle would accumulate radial creep, with the beam crawling around radially on the wheel, overlapping here and there if not climbing clear and ejecting..

And it is in these situations where variable integration step comes to the rescue - achieving a given target displacement precisely no matter the given sim freq., i think..

Hence i could sync up the walk perfectly by going to MHz freqs and spending a week getting 30 secs of data..

..or just use VIS and model at 200 Hz, then sampling at max freq as usual for 'HQ' runs..

Additionally, i was previously in the habit of setting all the precision steps to 16 digits (so '1e-16' for overlap and assembly errors, w/ 16 sigfigs)..

..this causes VIS to run at a crawl; the above sim instead simply set all the integrator precision settings to 'auto', and the sim works out the details for itself..

So if i'm following this correctly, all i need to do is max out the freq for a given run period, and data quality should be optimal..

Only now am i really beginning to appreciate just why those controls are exposed, rather than "max precision" simply being automatically applied under all conditions.. it seems to perfectly tailor the integrations to whatever the required ranges..