Decoupling Per-Cycle Momemtum Yields From RPM

[MrVibrating]

For any other simmers interested, please find attached the 'counter-force-to-gravity' example i keep using, just for getting a feel for the proposed 'reactionless acceleration' principle..

Obviously this example's too basic to be able to accumulate a useful per-cycle momentum rise - the attempt to find a mech that does so sequentially is what this thread's been all about..

[MrVibrating]

Also perhaps worth mentioning that i cannot currently map this scheme to the Toys page interaction - which seems to be clearly denoting twice as much torque from left-to-right as back the other way..

..whereas this scheme aims at equal positive torque every stroke, with i-don't-know how many strides per rotation but not seeming very reminiscent of the 2-CW / 1-ACW torque sequence in MT 138-141..

Thoughts anyone?

[Georg Künstler]

Depending on which wheel type, the one or the bi-dircetional wheel.

you can assume that the bi-directional wheel will make 8 strokes per revolution when running in constant rotation of 26 rounds per minute.

This information you will get from the eyewitnesses.

[MrVibrating]

The question i was pondering was, how to match the proposed lever's walking strokes to the torque sequence denoted by 'A' & 'B' on the Toys page / MT 138-141.

I expect the no. of strokes per cycle in a working wheel to be a variable function of RPM..

[MrVibrating]

Using IrfanView for fine rotation and GhostIt for window alpha:



..the original image was created with a 46° angle. Perhaps 45°, allowing for warping in the imaging process. Presumably this was simply an incidental detail when it was printed since there's nothing else in the image against which to reference angle / direction. The actual wood plate was probably cut 'true' as oriented above..


So i'm gonna try walking a single beam around those juncture points.

At each juncture will be a small motorised rotor that receives the beam, then rotates it over to the next one and hands off to it in an automatic, self-looping logical sequence.

You can already imagine that with gravity off, N3 will dominate, with no net momentum change from one stroke to the next, the wheel rotating at equal speed by equal angle each stroke, in a pulsing motion with zero accumulation.

Now run that same course at the same constant speed, only with gravity on; will it thus begin accumulating momentum?

Probably, you'd think.

How will the per-cycle momentum yield vary as a function of RPM, is the real question..

[MrVibrating]

If any smart bunnies out there can help out formalising the logic; it can be neat and lean, or long and convoluted, whatever works, but knowing me i'll be working backwards there..

Gonna need to use AND conditions - one for catching, another for handover. What are the key switching conditions, and how to implement them?

These peripheral 'rotary solenoids' (basically high-torque, accurate angular actuators) probably need controlling for angle / 'rotation' - in which case we'll need to use the 'mod' function to keep our relative angles within a looping 360° range.. or is that obviated when working in radians? Dunno..

"receive it, rotate it, let go" in as succinct a logic as possible.

Then we can tweak by incorporating things like speed dependence per RPM etc.

Currently still working two full-time jobs so only doing this when i should be sleeping or getting ready for work.. precious little cogent thinking time atm..

[MrVibrating]

..running lfw but suppose the beam's tipped with little squares; we can monitor the distance between them and the solenoids using the 'Length(a,b)' function, to check whenever its nearo-zero.. that's gotta be summink to work with eh..

[MrVibrating]

Most of the parts are there now:



..as i say i may add a further small body to each tip of the beam, just for detecting distance from the rotors.

So all that's needed now is this pesky logic loop.

It would be nice if all the rotary solenoids could be driven by identical code; then the input of each could just be set to "output[1].y1", referencing the same universal controller code..

..more likely tho i'll end up with something that needs 12 different versions of the same code, whatevs, so long as it does the job..



So if it was gonna start from the displayed position, then rotor 9 is going to rotate the beam ACW, having just received it from rotor 4, and pass it on to rotor 2..


.. then r2 will pass it back to r7, which will pass it on to r12, then 5, 10, 3 etc. etc.


So can we do this all with one, universal code.. or is it gonna take 12 or 24 or more discrete variations?

[Fletcher]

You're gonna have to build it the long way, then sleep on it. You might be able to chop out some redundancy based on relative position (x,y) in the grid.

I've used that technique in the past. First create an Output for position of an object (and maybe a Datum) then use that as the trigger for an Input with an IF (AND, OR) Statement etc.

Best !

[MrVibrating]

How's this for a plan

• beam connects to rotors via switchable 'rigid joint' elements

• rigid joints activated by detecting proximity of beam ends

So the beam could be tipped with tiny point masses, just to locate its ends in relation to the center of each rotor..

Since detecting a distance of 0 would require infinite frequency, instead a threshold proximity that can be reliably detected across some speed range at a given freq could be applied, with an exposed UI input for tuning.

• joints can be deactivated by the activation of their respective successors

Thus only one's ever active at any one time. This is at least 12 discrete codes already just for the grabbing and releasing tho..

• the angle between each rotor's 30°


If the rotary solenoids are controlled for 'rotation', then we need to produce a number that smoothly increments from 0 to 30 each stroke, or else smoothly increases by +30 from its preceding value. Can't be jumpy here, we want clean integrals!

Alternatively we could just control them all for 'velocity', setting them all to an exposed input variable (say 1 rad/s or whatevs), and switch between their 'active when' conditions.

We could control successfully for 'torque', but to be practical this would require an active feedback loop, to automatically detect how much torque to apply to achieve the desired displacements; the issue here is that we're only really interested in the interaction's efficiency, not making a pretty animation, and the quality of output data when using these techniques error-prone (the software's liable to apply unmetered torques).

I like the velocity-control solution the best, using the same 'active when' switching conditions as the rigid joints..

Still very rough though isn't it?

For one thing, just for data clarity, it would be desirable to soften the rotors' accelerations and decelerations, rather than just slamming the beam around at fixed relative speed, no? Otherwise each integral's gonna start and end with a big spike.. when what we'd really like is smooth curve beginning and ending on the 'zero torque' line..

One way to achieve this might be again to reference the distance between the beam ends and the rotors, so that it's gradually approaching nearo-zero speed as proximity from departure / arrival, and only reaching top speed halfway through each stroke..

Basically using the proximity of the beam ends to the rotors as a multiplier for the solenoid velocities..


So is that a workable plan then or am i setting meself up for strife?

[MrVibrating]

..damn, just seen the potential error source there; any imprecision in locating the exact triggering angles is going to cause radial creep of the beam over successive strokes..

That's not gonna last long eh, be surprised if it survived one full rotation at 1 rad/s with 10 kHz..


A better approach is needed for it to run automatically and stably..


We already know it's a perfect 30° rotation each time, and this will precisely position the beam between strokes, eliminating the possibility of any radial drift..

..so the task is to control the rotary solenoids for a perfect 30° of smooth angle change each stroke! More lateral thinking required there..

[MrVibrating]

You're gonna have to build it the long way, then sleep on it. You might be able to chop out some redundancy based on relative position (x,y) in the grid.

I've used that technique in the past. First create an Output for position of an object (and maybe a Datum) then use that as the trigger for an Input with an IF (AND, OR) Statement etc.

Best !

Well there's always the first way i mooted; literally stitching the interaction with frame-stamped or time-stamped triggers; if using the former then the sim's only usable at its design freq; with the latter it still gets more precise with freq, but only if the timestamps are sufficiently accurate in the first place, which may require careful sequencing as if it were an animation..

That'd still leave the issue of syncing the motors, and then getting clean data..

As you can see there's nothing to the parts list, it's just a matter of designing the control code with a view to data quality..



Gonna be fascinating to see what it does once it's spinning tho.. if, as hoped, it falls into a sync where the lever's always being lifted against gravity, then i can't see why this shouldn't be easy OU - we'd be getting the same momentum rise each stroke, for the same input work done, thus summing over cycles, while system rotKE squares..

Give it a few more days and we'll see. No days off on the horizon unfortunately and working 10am-midnight 5 days plus w/e eves 6-12, so it's a few hours tonight, and tomorrow afternoon before work, then just a few stolen hours thru the week here and there.. shite life that i have.. thank God i have this to keep me sane and motivated..

[Wubbly]

First create an Output for position of an object (and maybe a Datum) then use that as the trigger for an Input with an IF (AND, OR) Statement etc.

I ended up doing something similar on the Kuenstler simulation. Put the orientation of the weights in output meters with mod statements, and use those numbers to trigger the ActiveWhen on the Rod lock/unlock constraints.

[MrVibrating]

Soz i'm being a bit thick here - i'm just trying the fast'n'dirty technique of switching rigid joints on and off with time or frame triggers..

..so the sim begins with an active rigid joint attaching the left end of the beam to rotor 9..

..rotor 9's motor is set to a constant velocity..

..after n seconds or frames, the right end of the beam intersects the center of rotor 2..

..at this instant the rigid joint to rotor 9 deactivates, and the one connecting the other end to rotor 2 needs to activate..

It's that final step i'm stuck on; you can't use the standard GUI to attach these later rigid joints, only the first one, since the beam needs to be already-aligned to whatever rotor i want to set a rigid joint for..

• rigid joints are made from two point elements, one for each of the connecting bodies

• in principle then we could overcome this practical GUI restriction, if only we could set the parameters by hand

IE. the point elements making up each rigid joint need assigning to the correct rotor bodies, and because of the sequential nature of the GUI you can only set those joints once the bodies are already aligned, but edits in-progress re-zero the clock thus destroying any prior time / frame refs in preceding joints..

So it looks like i either need to edit the .wm2d file manually (is that possible), or else find a way of scripting it or something..?


Or is there another way of doing it?

It would seem ideal if the beam itself could run some kind of autonomous logic that would grab and release at each end automatically, after each precise 30° rotation by the solenoids. 'Organically' and unscripted..

However i just can't currently see how to pre-specify a series of rigid joints between future body alignments...

!?

[Robinhood46]

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.