Sjack Abeling Gravity Wheel and the Worlds first Weight Power Plant

[Cloxxki]

@Dusty:
While I think that acceleration at the top is very cool as do you, I am wondering whether there could be too much of a good thing.
Accelerating the weight more than it needs to, might drain too much energy from the other weight doing the work for it?
I was thinking maybe slots with a larger radius, or a shifting radius. The slingshot action will be there anyways, but "too" much might stress the system overly in that "hot" spot, and cause more clunking than necessary.

Good luck with that huge build!

[ruggero]

124 pages in 4 weeks, but not one post overnight from the newer side of the Atlantic? Must be a really reply-unworthy idea then... Anyone in Europe, please?

Well....I'm from Denmark, Scandinavia,... that's Europe, that's Vikings, that's Lego, B&O and Maersk.

ruggero 

[Cloxxki]

Well....I'm from Denmark, Scandinavia,... that's Europe, that's Vikings, that's Lego, B&O and Maersk.

ruggero 

I was on the wrong track, at least for the invention at hand, but someone could have told me :-)
For the heck of it, I may simulate or build my idea one day anyways, perhaps that as long as the weights leave the wheel 6-9 o'clock, it will work just as nicely. Leaving the wheels seems to be what makes this equasion work, after all.

@Dusty:
May be obsolete to state here, but better sure that sorry. Have you investigated whether a weight rolling up the ramp will be clean of touching the wheel, pushing or being pushed (wide cut-out) to allow it to reach a good heght before the wheel catches up with it? Using the weight to push the wheel up early in the "up" phase seems a waste of inertia. I suppose there will be an ideal slot shape which will have the wheel gently building up the push after 9 o'clock. Starting-stopping the weight may cancel out from an inertia standpoint, but it does add to stress, friction and noise.

[mondrasek]

See, the question is why this iterative "resonance" is favorable at only one particular disposition of the same elements and all the rest the same? As for the turning of the balls when they shouldn't, it's also observed with 0.0001m integration error.

The turning balls are a clear sign that the wheel is experiencing some unresolvable computational error.  In this case, I don't think you can get away from it by reducing the time step, only minimize it somewhat.  It is due to the nature of the design.  Likely the sim is calculating the change in position of the wheel due to the influence of one ball.  That change in position of the wheel causes collisions with all the other balls.  As the sim continues with the calculations for the second ball, these same issues arise with the other seven again.  This is repeated 8 times in this model.  And as balls in certain specific portions of rotation rotate violently compared to others, it appears that the particular angles of the slots and guides, as well as possibly the distance of the ball from the main wheel axis, create worse conditions than other locations.  But the movement is still obviously an iterative "resonance" and not some new force.  Moving the guides a bit to one side does not stop the balls from spinning.  It may stop the wheel from rotating, but this only means the errors are canceling this time and not creating a net torque on the wheel.  Nothing more.  And it definitely does not mean this sim is showing any tendency toward providing power.

If left to itself, the wheel in this sim is a balanced wheel with a keeling effect.  It will find the position where the weights settle the best and stop moving.  If the guides allowed for no slop, it should become a balance wheel without a keeling effect and would balance in any orientation.  And the closer you get to a balanced condition, the more problems you will have with an iterative simulation.  This is true in the real world as well where we find that balanced systems may oscillate or fret around the balance point due to the tiniest of outside influences and actually wear faster than a system that is loaded to one side and thus held in place by a force. 

You can try making a pendulum that faces straight up in WM2D.  It will almost always fall to one side eventually.  Change the time step and integration error and it will fall again, sometimes to the other direction.

A couple of other simple tests for this sim:

1)  Increase the weight of one ball slightly.  You will find that the wheel runs in the expect direction and then rock back and forth with that ball seeking the lowest point.  This takes the wheel out of balance but shows the motion when at balance to be just a software abberation.

2)  Spin the wheel by placing another weight on top of only one ball and turning on collision.  This will give the wheel a spin just like you would by hand.  The wheel will slow to the same abberant rotational speed.

All of these things show that the weird movement of the sim is an error due to the iterative nature of the software, and not an indication of the design wanting to run.

I'm reluctant to decrease the set of elements because that particular set may be the one that brings about the essence of the effect. Also, introducing external torque to substitute for the missing elements doesn't seem to me as an acceptable approach. I'd rather play with the parameters and compare different placements of the same elements. We have to see if the program can handle that, otherwise we should just drop it because the conclusions we draw by using it, either way, will be unreliable.

I did not say to introduce external torques.  I was trying to explain that in a symmetric gravity wheel that it must be able to run with only two weights (or movements) at 180 degrees apart.  The only purpose in adding more weight pairs is to increase the output.  Likewise if two weights do not create a net torque, adding more pairs only further decreases performance as witnessed by decreasing rundown times from a given start RPM.  So testing with only two weights is valid.  It also allows the sim to avoid the 8 x iteration error and 4 x calculation problems in this particular sim.  Try it.  It is very quick, easy, and allows the sim to run much faster and without the abberant movement.

[ruggero]

Using the weight to push the wheel up early in the "up" phase seems a waste of inertia. I suppose there will be an ideal slot shape which will have the wheel gently building up the push after 9 o'clock. Starting-stopping the weight may cancel out from an inertia standpoint, but it does add to stress, friction and noise.

You're so very wellcome, Gloxxki..

Anyway...I agree with you, that we have to build up the push. BUT perhaps the buildup period can be very very short...like a katapult!
I made some changes to Dusty's design (se drawing):

The major point here is, that gravity will do a maximum push on the ramp at 06:00....why don't we harvest that energy?

I suggest that the Dusty's ramp could slide to the left, pushed by gravity by the weight at 06:00.
The ramp push another catapult (spring) mechanism to the left.
When there is no more push force, the catapult will shoot the weight at 11:00 over the top.
And the ramp slide back to start position.

(the catapult mechanism could also turn around the axel as a CW counterlever...)

Request!
Could anyone of you WM2D experts make a sim of this?

I would just love to se Dusty try this on his 'little' wheel set-up...

ruggero