Ep. IX: An Even More Newer Hope..

[MrVibrating]

After consulting my dedicated think tank (AKA a soak in bath), i've washed off the disgrace of recent failures and pulled together some recent ideas with some older ones, to come up with something even more stupider. Probably.

When i became a regular poster here a few years back, my initial focus was that the force exerienced while riding the rim of a vertical wheel is a variable sum of gravitational and inertial vectors - the CF/CP force signs alternate relative to gravity's, each full cycle.

If we assumed CF/CP = 1G, then at 6 o' clock BDC a mass will experience 2G, because here CF and G are equal in direction and magnitude.

While up at 12 o' clock TDC it is subject to zero vertical force - CF and G are equal and opposite.

So initially i tried dropping the mass when it was heavy, and lifting it when it was light.. only to find that this lowered the center of gravity of the wheel, and that rotating the mass back up to TDC cost equal energy to any so gained.


End of.

Later, i had another idea, a concept i called "pods" - the aim was to insulate the wheel's CoG from that of the displaced masses, so that each pod had equal weight regrdless of its internal CoG.

But stupidly, i then figured i needed gravity to rotate the pods upside down, to automatically reset them. Which of course, again, costs equal energy to any so gained.

But in light of my most recent concepts (brainfarts notwithstanding), such as using gravity to freely reverse the sign of an applied force, i may have abandoned the idea too early..

For a quick mental image, here's two such pods on a pulley, strung across a balance beam:



One's up, the other's down, but everything remains balanced.


And that's basically it - the reason i started a new thread.

What i'm thinking is, rotate that system about its central axis, but connect the hanging pods togeter with a heavy flexible chain or similar mass.

This acts as an internal stator - like an artificial horizon; something that always hangs below the wheel's CoG.

If we now place the mass inside one of our pods on a weighing scale, it gets heavier travelling along the lower half of the wheel, where CF and G combine, compared to when coming around the top half of the wheel, where CF and G vectors subtract from one another.

These radial displacements would alter the system's MoI, except we have equal and opposite ones - so the net MoI remains constant. As one weight drops at BDC, another is lifted at TDC. The distribution of mass hasn't changed, but we've gained more energy from dropping the mass in the lower pod, than we've had to input to raise the mass in the upper pod.

Apparently, all that's needed is a suitable transmission system between the pod's internal energies and the wheel's....

[MrVibrating]

Here's a more reasonably proportioned impression:



...balancing in both vertical and horizontal positions, and without the unnecessary pulley.


If we consider the net forces at precisely the instant the system is in the vertical position:

- in the lower pod, the weight is effectively heavier than the identical mass in the upper pod, because CF and G vectors are equal below, but opposite above

- if we drop the lower mass while raising the upper one, we appear to have an excess of energy.



The system remains balanced while rotating, hence doing so freely resets the sign of CF relative to gravity, thus repleneshing our PE gradient.

[MrVibrating]

Seems like the perfect job for scissorjacks..

[sleepy]

This is an ingenious concept.I see so many applications.It appears that when the main shaft is vertical,it can be balanced,and yet either top heavy or bottom heavy depending which weight is where.This warrants further investigation,and thanks so much for sharing something new and mind blowing.

[MrVibrating]

Cheers mate but early indications are that, for now, the force isn't awakening, let alone getting up on the right side of the bed..



...the weights are currently locked to the center of the vertical struts. If they're unlocked, they'll slide up and down their respective struts.

So it's basically a parallelogram, and its motion effectively rotates the vertical struts - and the sliding weights on them - against CF force, while keeping them always aligned to gravity.

However as can be seen, the force acting on the masses appears to be constant..!

As a sanity check i also stuck a mass on the edge of a vertical wheel and spun it at a constant rate - again, measuring constant force acting on it.

However this force reading remained unchanged whether gravity was enabled or not. The force does change with mass and radius, but seems oblivious to gravity... so either it's not actually measuing the "Total Force" it claims to be, or i'm making some very basic conceptual errors...

[MrVibrating]

Just a quick recap:

The hypothesis was that, from the pods' point of view, the direction of the CF vector flips 180° every half cycle.

So the G vector is always oriented downwards, relative to the pods. But the CF vector alternates between "up" and "down".

When the two force signs are equal, the net force goes up, so the masses in the pods get heavier, and when they're opposing the net force goes down so the masses get lighter.


So why isn't this happening (yet)?

Possible oversights:

- the sim seems impervious to gravity, showing the same net force with it enabled or not.

- perhaps i need a way to monitor CF independently of CP - even though one's the corollary of the other, their sums obviously balance, so perhaps this is why the total force doesn't seem to be wavering?



...mostly likely the sim's accurate and i'm being an idiot... but i need to understand how and why...

[ME]

But gravity has no effect because it acts equally on both sides...

[rlortie]

Cheers mate but early indications are that, for now, the force isn't awakening, let alone getting up on the right side of the bed..

Whether The pods slide up or down on what can be explained as pendulum rods is irrelevant. The force of the weights is being felt at the symmetrical pivot points and not at the location of the masses.

[MrVibrating]

But gravity has no effect because it acts equally on both sides...

The data field is supposed to measure total force (at least that's what it's called), on each mass individually.

To double check, i placed a single mass on one side of a vertical rotor, and spun it at constant speed, with gravity enabled - again, the sim gave the total force as constant:




So counterbalancing doesn't seem to be the issue...

[ME]

Your motor gives the mechanism the proper amount of <whatever> to maintain constant velocity.

F (centripetal) =m * r * w^2
or just
Fc = m * ac

w in [rad/sec]

[MrVibrating]

Cheers mate but early indications are that, for now, the force isn't awakening, let alone getting up on the right side of the bed..

Whether The pods slide up or down on what can be explained as pendulum rods is irrelevant. The force of the weights is being felt at the symmetrical pivot points and not at the location of the masses.

Yes - the whole point of suspending the rising and falling masses in pods is that the system's center of gravity remains constant.

Overbalance isn't intended or required, at this stage. It's just a test rig, designed to measure forces. The wheel is turned at constant speed by a motor. The hypothesis was that the sum of centrifugal and gravitational forces experienced by the masses would vary around a full 360° rotation; combining additively around the lower 180° arc, but subtractively around the upper arc.

Hence if we were riding inside a pod holding a weight in our hands, it would get heavier then lighter in turn, and we could drop it when it was heavy, and pick it up when it was light, gaining energy without ever affecting the balance of the system.

Stupidly simple... but is it stupid enough?

[MrVibrating]

Your motor gives the mechanism the proper amount of <whatever> to maintain constant velocity.

F (centripetal) =m * r * w^2

w in [rad/sec]

Yes, intentionally so (its input is "velocity"). But i'm thinking that the forces acting on a body are there independently of its motion, and not merely in response to it, so enabling gravity should raise the net force acting on the orbiting mass.

If it's only measuring inertial force then it's not testing my hypothesis..

But if it is factoring in gravity then i can't understand the absence of a corresponding change in net force with it enabled or disabled.


ETA: as a further cross-check i've just verified that the sim does give the correct gravitational force acting on a static lump... yet rotate it in an orbit and gravity seems to be ignored. Weird.

[Fletcher]

Hi .. I think the geared Roberval Balance used in previous examples would also serve you well Mr V. That way the pods always stay in the orientation given (vertical in this instance).

Also you don't have CoR crossing problems that a real build would have using actual parallelograms which can act erratically in sim world when they close completely then push thru the other side whilst rotating.

Also I suggest you click on an object in your sims and then go to the menu "Define" > "Vectors" > tick the ones you want e.g. velocity, acceleration, total force, grav. force etc.

This gives a vector in your sim so you can see at a glance what is happening during each part of a rotation. I find this visual feature pretty useful for analysis most of the time.

P.S. turn on menu View>System Center of Mass.

To find out the Cf/Cpf in any part of a rotation you will probably have to build a specialist Output box (I'll talk you thru the long way which you can shorten considerably once you have the idea).

e.g. Say start with an ordinary Mass Input. Then click on the object and measure Velocity etc for an Output. Then connect a rod element from the CoR to the mass, make it inactive, then make an Output for Rod length (this is your radius).

Make a copy of ANY Output you have and rename it using Window>Appearance. In y1 make a formula such as Input[1]*Output[2].y1^2*Output[3].y1 to give you Cp/Cf = Mass x Velocity^2 x Radius.

The short way is to load all three previous outputs into one Output box [xyz]. The the 4th field is the Cp/Cf formula you make e.g. Output[xyz].y1*Output[xyz].y2^2*Output[xyz].y3.

[Fletcher]

Here are some pages of interest.

Also a generic suggestion of the previous post you can adapt as required.

[ME]

yet rotate it in an orbit and gravity seems to be ignored. Weird.

I tried it myself, A lightweight disc with an attached weight.

Weird no.1 (just for fun)
*What happens when an unstoppable object (constant velocity) meets an unmovable object.
- pin some rectangle in its path
- expectation: the motions stops, the force would be constant, or perhaps rising.

An inconsistent constraint.
Please press <yes> to continue, that's fun - breaks the system (virtually)

Weird no.2
*What happens when the system is not pivotted in place, but hangs on a rod, while the motor is activated a bit later.
- Motor, active when: time>10
- expectation: the system swings around and start to rotate while swinging.

First: the whole system dances around as might be expected (weight starts at far right)
The motor activates, and the dancing is simply stopped and it quietly rotates at the given velocity..
-It's possible the motor needs a pivot to be attached to, and a rod-end is not such pivot: thus the background is chosen.


EditToAdd:
Weird 2b
A disc attached to some rod, another disc pinned to this disc, a weight attached to this disc, and a motor attached to the pin..
Same result...