Gravity CAN do Work

[tinman]

mini-facePALM, actually.


Tinman, Finsrud's device has been explained by Finsrud himself. It works by essentially the same mechanism as a cuckoo clock: a slowly descending heavy weight drives an escapement mechanism involving pendulum regulators. The weight needs to be raised up every week or so to keep it running.

Well i have never heard that one befor?.I was unaware of any such weight within the device.

[fletcher]

Thanks for the mail Mondrasek - I'll reply in detail there asap.

I was clearing out some files recently, some from 15 years ago where I found this one.

I decided I would post it up here for others to look into if they wish - I did do a search here & couldn't find anything on the board about the 'Braess's Paradox' [or on overunity.com] so this may be new for at least a few.

It should be particularly interesting to members like Pete & Trevor who don't discount the possibility of springs playing a major role in a working wheel.

Links below & vids on You Tube of physical experiments with springs I found yesterday.

http://en.wikipedia.org/wiki/Braess%27s_paradox

http://www.youtube.com/watch?v=xiOEYNGV5P8

http://www.youtube.com/watch?v=nMrYlspifuo

Mike .. this is about as close to a "bootstrapping" device I think I've ever come across - it was nearly 15 years ago when I was a real newb, so I didn't give too much thought how it might be plied inside a rotating reference etc.


IIRC I had thoughts of using it similar to the 'rubber band motor' except the energy to shorten the radial was via releasing the connection & changing dual springs from in series to parallel etc as per Braess's Paradox, seen here in physical form - I naively thought that there would be better examples out there I'd find in time as I got more experience, so quickly moved on to other things.

But it did occur to me at the time that there would probably be an elctro-magnetic equivalent to Braess's Paradox that might be used effectively in some way to cause overbalance or asymmetric torques in a wheel [but I'm no expert in those areas].

If you study the sim you will see a useable increase in height gain just from changing from springs in series to parallel - it is a linear response so can be scaled - I give an explanation of why that is in the attached pic which you can deduce for yourself by studying the Output data in the sim - I guess a type of parametric oscillation.

Whether it is legitimate 'bootstrapping' or has any OU potential I leave you to decide - I do think it is an interesting study of principles.

[gyulasun]

Folks,  I have found this video http://www.youtube.com/watch?v=nMrYlspifuo  which includes a test with springs. The gain in height comes out in practice too.  Question is how it could be utilized advantageously... 
Wandering if height-gain means also energy-gain?

[AB Hammer]

It is an interesting effect. Now all you have to find is how to reset it automatically. 

[mondrasek]

I believe I have figured out the error with the sim.  There is an Advanced Accuracy parameter called Overlap Error that defaults to 0.01 mm.  My belief is that is a value for how far objects are allowed to interfere/overlap with others before causing some reaction in the sim (like motion) to relieve that condition.  The smaller this value is set the more accurate the sim becomes but also the slower it runs due to being more CPU intensive.

Here is my interpretation of the sim events during the "rise" portion after the weight was moved to the right.  The 0.01 overlap parameter was allowing the roller wheels to cross over the arms they are pushing on by a larger value more than that amount due to the greatly increased torque.  This was allowing the arm with the weight to DROP ever so slightly (also more than before the weight shifted to the right).  Once that overlap limit is met the sim reacts by moving the weight and lever arm back up slightly to alleviate that condition.  But it will then drop again.  This is repeated over and over in the calculations of the sim, but not visible in the video rendering due to being so miniscule.  It is the larger value of continuous dropping of the weight that caused the upward motion.

I had actually changed the Overlap Error parameter from 0.01 mm to 0.001 mm before making the video.  This was because the default value caused the sim to be a bit jerky and that change smoothed it out.  But by upping it to 0.0001 and then 0.00001 the motion became less and less.  Once below 0.000001 the upward motion of the sim in the second half stopped and in fact it would fall just like in the first half.

Broli may have come closest to pointing out the error early on when questioning the accuracy of the models.  Fletcher helped a great deal with his annotations and analysis.  The rest was ferreted out while trying to make the sim travel through a full cycle.

M.