Toad Elevating Moment

[MrVibrating]

I call on delusion.
Meresburg illustration show weight not for dropping to spin wheel, weight shown for lifting demonstration.

Method used for spinning lollipop need back energy. Must come from lollipop.

Easy build. Lollipop and drop weight. If lollipop lift weight same height, call patent office.

Yes, ostensibly it shows an external view of a demonstration wheel. However, if Bessler was using this asymmetry then its resemblence to a flywheel on a swing arm mightn't be coincidental - it could be a depiction of the main internal components, 'hidden in plain sight'.

My delusion would not be that this possible similarity is the basis of a solution - it's just a potential consistency with my psychosis, which is founded on the manic conviction that rotating a balanced beam doesn't change its GPE, and the king of the custard people is stealing my thoughts.

But feck it - it's been 5 weeks now of procrastination with little progress, so i've sent a little teaser email to Steorn. Hopefully they'll just bin it with all the other crank mails but if they do express interest, i'll try get 'em on board (although if they want money then all bets are off)..

[MrVibrating]

@Dunesbury - and yes you're right seems like a simple test rig, but there's still potential hurdles in the way, depending on which tests are tried:

- If we try using positive torque for the lift, applied via a drop weight, then it would be preferable to ensure that the transmission system cannot torque the beam itself - ie., that all of the 'lift' is performed by the angularly-accelerating weight balancing its own downforce, hence proving that the GPE gained on the ascent is truly free.

If instead the drop weight is directly pulling the beam upwards, regardless of the attempted pure moment, then the data gets messy - it might still work since full cancellation isn't required - the gain will be proportionate to the degree of counter-balance achieved. However i don't want to launch into a bout of compromised, questionable measurements... If i can find a way to eliminate stray beam torque from the drop weight then i'll go for it, i have all the materials and tools to hand...

- the other way is to use negative torque; spin up the wheel and then make it climb by braking it. Here, a consistent braking force has to be applied throughout the lift - i want to be able to measure out the torque (although this can still be infered from 1st principles) as predictably as possible. If the brake is also operated by a drop weight then the previous consideration also applies re. stray torque to the beam.

So in principle they're very simple tests, with just two moving parts. But in practice there's certain nuances and pitfalls to any measurement and here it's torque control.

Steorn are experts in this type of rig, with state of the art lab kit. They have high quality sims, and years of experience handling symmetry breaks. This is their bread and butter. They're probably the closest thing we have to a s'Gravesend or Leibniz right now, so i'm calling in the cavalry.

If in the meantime anyone can think of a surefire Mecanno rig then i'm ready to build it...

[MrVibrating]

Got V8 WM and playing around with pin friction, i notice it's really just applying torque - which of course is all we want from our friction, however it's fundamnetally no different to torque of any other kind, whether using the dedicated 'torque' constraint (as it appears to do anyway) or via the motor constraint.

Torque is torque, is torque. Who cares where it comes from. Not me, that's for sure...

In light of this, i think my suspicions that the motor constraint could've been adding energy were ill-founded - i was just clutching at straws to find any alternative explanation to an asymmetry. It was only inputting negative torque, hence under the bonnet it was braking the wheel in exactly the same way as pin friction in the sim Fletcher provided - it was applying exactly the same force in precisely the same manner.

All this wrangling over what is, ultimately, mere semantics, is completely redundant if one can simply accept that a pure moment can perfectly balance a beam, and that a perfectly balanced beam experiences no change in GPE when rotated.

Even if these two points weren't already axiomatic, i've confirmed them anyway with multiple sims.

Whatever generates our negative torque - a motor or a brake or just a formula - torque is torque; its effect is to reduce the RKE, removing energy from the system.

Hence i think my brake tests were perfectly valid, and the results meaningful.



Coming back to the Mereseburg illustration again - this one in particular - a number of consistencies can be noted:

Top left corner: beam 4 is suspended from a bearing - the only such bearing in the image, and for some reason copied over from this image, causing a glaring occlusion error - if the horizontal strut were really for the pendulum to hang on, as ostensibly it is aligned to do so, then why does it terminate in a bearing? This is only consistent with beams 4 forming a swingarm - the out-of-place bearing could mean nothing else..

Also: Could a pendulum drive the alternating flywheel torque, replacing motors and brakes in one fell swoop? It'd still need to apply its effort between the flywheel and beam in order to generate a pure moment - it wouldn't work if you just attached the pendulum to the flywheel directly, or if the pendulum was the flywheel - but the crank and conrod assembly depicted would accomplish this, levering the rotor around against the stator, beams 4.

Perhaps Bessler tried both variations - applying torque via a drop weight and pulleys in one machine, and via pendulums in another...

The lock 24 - in the above print, the right-side lock number is inverted to 42... again, this deliberate error would be consistent with a hint at torque reversal. Also, 4 is the beam's number, and 2 is the wheel's... it's crucial that torque has to be applied between them, so maybe "24" represents positive torque, and "42" negative?

Tenuous isn't it - but that's the beauty of confirmation bias i guess. Works for me anyhoo..

Finally, quadrants.. I'd been wondering what's the significance of the upper-left window quadrant in the Meresburg illustrations? But if it's illustrating all the compoents of a pure moment exploit (as i'm suggesting) then perhaps it's a reference to the 90° operating arc of the beam - the rope or water going through one quadrant of the window could be a metaphor for one 90° cycle.


And FWIW if the stampers have any special cryptic meaning i'm currently stumped as to what... the demonstrations did feature stampers though. But no witnesses record seeing the pendulums. Or the main posts being suspended from a swing bearing..

Steorn haven't got back to me yet. I'll give 'em a week then try a different channel...

But yeah... if i'm making some crass error here i'm still not seeing it.. which is almost as terrifying as it is tantalizing.. All i know is i am going to feel SUCH an idiot if this interaction isn't doing what i currently think it is...

[MrVibrating]

OK dead simple argument:

RKE is a function of RPM and MoI:

http://en.wikipedia.org/wiki/Rotational_energy

We can invert that formula three ways... upshot is if MoI is higher, RKE for a given RPM is also higher.

But if the objective variable is MoI rather than RKE then higher MoI at lower RPM can give us equal or less RKE, too.

Hence higher MoI at lower RKE and RPM is perfectly consistent with the terms...


This only concerns the reducing input required as MoI increases - again, this isn't the symmetry break, just a bonus consequence...

[MrVibrating]

Finally understood Ed's advice re. moment control in WM object properties - i thought "shell" was for collision detection... duh.. it's moment, as in MoI...

Selecting shell turns a disc into a toroid, as far as MoI is concerned. Which is neat because it doubles the energy density of the config - MoI for a disc is 1/2MV^2, but for a toroid it's the full MR^2.

And it's now that i notice the input energy is a 1:1 inverse linear function of moment.

Which is utterly butterly because it means increasing the flywheel radius by a factor of ten decreases the input energy by the same amount.

Plus i'm not seeing evidence of the convergence i was getting before when using solid discs... making the wheel 100 times bigger reduces the input energy by a factor of 100. How nuts is that?


ETA: aha - at last i think i understand why the convergence arose - as a solid disc gets ever-wider, the proportion of mass being spread out further from the axis adds onto that already comprising the central area of the disc.. type stuff.. in other words, if we double the disc's area for the same mass, it contains within it the original MoI of the half-sized disc, and so on and so on for each doubling. A 10 meter disc will have to accelerate mass at 1 meter from the axis, and 2 meters, and 3, 4, 5 etc. as would any other solid disc at those sizes or above.. thus the 'new' area being added as the disc gets larger simply adds onto the previous MoI instead of entirely replacing it, as occurs with a toroid, and thus the results eventually begin to converge, with diminishing returns for ever-larger discs.

With a toroid this problem is entirely avoided - thus doubling the radius actually doubles the moment of the entire mass being accelerated, and no convergence will ever arise!

This is all really great news, and means a build attempt can be far more ambitious than i'd previously hoped for..

[MrVibrating]

Another result - found that the time to apply the brake is not upon descent, as only a few percent of the flywheel's RKE gets transferred back to the beam this way.

Rather, the brakes should slam on at precisely BDC, which in turn applies an equal opposite pure moment as the pendulum swings back the other way, balancing the beam again and thus gaining another free load of GPE.

Lesson learned.. only accelerate or brake while ascending... not while descending.


So, currently looking at a pendulum, then. Alternate the torque sign on the up-swings, coast on the down-swings.

The size of the flywheel and input energy required remains decoupled from the output translational - so however small and energy-hungry the flywheel, so long as its energy is conserved and kept in play, there's little effect on efficiency.

Obviously smaller faster flywheels will also have a higher proportion of frictional losses, and larger ones require so much less energy in the first place that it would seem preferable continuing with larger ones, for now..

However i remain convinced that the lower RKE to trans ratio found with larger flywheels is incidental to the core asymmetry, which is simply due to the balancing of the beam during ascent. Requiring such small input energies makes things simpler in some respects, but it's a beneficial side-effect of the asymmetry rather than the core exploit. It just so happens that the differential is so large the RKE could be dumped rather than recycling, without significantly impacting practicalbility...

In other words, if we had to input 1 J rot to gain 10 J trans (not unrealistic BTW), then we could recycle that 1 J on the back-swing for another 10 J gain, for a total of 19 J out for 1 J in, or we could just dump the 1 J to heat and still come out 9 J ahead...

Not that you'd probably wanna do this for a fully-optimal config, but it means that for a mere proof of principle we can afford to be really sloppy - only drawing half the available output energy we'll still be 9 x unity.

[MrVibrating]

Just realised another angle on convergence: since the beam's KE remains constant as a function of flywheel moment, but flywheel rotKE is inversely proportional to moment, the total input energy will converge towards the constant net KE of the beam the smaller the flywheel rotKE gets (ie. the larger its moment). In other words net input energy will get ever-closer to the net beam KE without ever actually reaching it, because the additional input RKE incurred as the MoI gets ever-larger is ever-smaller.

If that makes sense. :)

[MrVibrating]

Out of curiosity, i decided to determine the flywheel-to-beam radius ratio that produces a net output equal to input...


Turns out that for near-perfect unity, the flywheel has to be around 2.29 times the beam length. This is for a hollow cylinder moment. So if we weren't recycling the RKE, and are using say rolled lead flashing as a flyweight, the beam would need to be less than 2.29 times shorter than the FW radius before gain could be measured.

Below this ratio it'll be "under-unity" (in scare quotes as this isn't a non-dissipative loss, we're just intentionally wasting RKE to heat via friction). Above this ratio though we're thermodynamically OU - we can waste the RKE to heat and still gain on the output translational KE.

Presumably this ratio is dependent on the beam's properties, so may vary with it, will keep an eye on it if things change.

[MrVibrating]

A penny just dropped...

- net input energy converges towards the beam's net energy, since the wheel's gets infinitessimal with sufficiently-high MoI

- output translational remains constant - a fixed function of MGH

Therefore a single cycle comprising one lift and one fall (ie. vertical to horizontal and back) can yield a theoretical maximum efficiency of (output transKE) divided by (input transKE), for one ascent and descent. This seems to work out to 1.744 x unity.

A single cycle comprising two lifts and two falls (ie. a forward-swing followed by a back-swing, recycling the RKE by alternating the torque sign) can have a maximum efficiency of 3.48 x unity.

So that's nice.


ETA: update; just verified these ratios across a range of scales (+/- factors of ten)..

[MrVibrating]

Tried using pendulums as torque controllers. Getting the periods synched is a bitch but things don't look promising initially - using the Meresburg / Kassel illustrations as a guide to proportions, it seems unlikely a pendulum could generate a self-balancing pure moment in any wheel at those relative scales... the wheel would need to be much smaller, i think...

Still haven't sussed how to do drop tests without torquing the beam... will have to crack this before i can progress i think..

[MrVibrating]

Update: a week's gone by and still no word back from Steorn, so i'm gonna try enlist the help of Earthtech.. fingers crossed eh.

Also, i've now successfully tested the principle with springs, completely removing gravity or indeed any external force from the system. Obviously, this enables significantly greater energy densities to be achieved, so that's nice.

Using the previous config (2 meter x 25 mm beam, 393 gram rotor) i replaced gravity with a 2 kN/m spring attached between the rotor axis and BDC; as before, with increasing MoI the input rotor KE converges towards the input translational energy - here, 5957.499 Joules, in a lift period of just 27 miliseconds.

The output transKE remains a fixed function of the beam radius and sprung tension; 7298.437 J in 26 ms.

This gives us a yield of 1340.938 J clear in a 53 ms cycle. That's 18.9 Hz, times the energy yield equals 25.3 kW for 418 grams net mass of beam plus rotor. Allowing for springs, bearings and any other small essentials, we're looking at around 50 kW per kg limited by nothing more than that fairly arbitrarily-decided sprung tension (i was aiming for around 1,000 x gravity, using a 500 mm spring).

Suffice to say this blows internal combustion out of the water on power density alone. The possibilities are limited only by material limits..

[Ed]

How about removing simulation out of the system?

[MrVibrating]

Which is why i'm actively seeking capable replicators. I haven't built a rig yet as i still haven't solved how to apply torque accurately. Besides, a battery powered wobbly meccano pendulum isn't going to convince anyone, no matter how much i think it's measuring an anomaly.. you know the coo, i'll look like every other idiot who doesn't know how to use a multimeter properly.

This won't be an issue for a professional outfit with proper lab kit. They'll be able to apply and measure torque accurately, perform calorimetry, run Cedrat and other sims.. They'll have top notch scopes and DAQ....

And they're not gonna commit to a validation unless they're 100% sure.

If you're feeling a bit handy it's just a beam, a wheel, a linear force and some torque. I'll assist any build attempts anyway i can with, uh, more sims, and stuff... beyond that, i don't know what more i could do...

[cloud camper]

MV - glad you're back.

You may have missed discussion of a concept using your accelerating/decelerating flywheels in Triplock's thread "Elephant in the Room"

The idea would be to use a pair of parallel ferris wheel setups that would switch accelerating/decelerating subwheels (flywheels) from one wheel to the other at 12:00 and 6:00 positions.

The countertorque for the accelerating subwheels would cause the ferris wheel to rotate CW until the 6:00 position is reached where the accelerated subwheel would then be mechanically switched to the parallel
ferris wheel where it would begin decelerating.

The countertorque from the deceleration force would then spin up the second ferris wheel CCW until the subwheel reaches 12:00 once more when it is switched back over to the first ferris wheel.

Now we have both ferris wheels spinning in opposite directions so the total angular momentum is zero yet each wheel by itself contains sizable momentum and we have conserved energy spinning up and slowing down the individual subwheels.

Many details to work out but a simple elliptical chain sprocket could cause one subwheel to spin up while it's mate spins down. And of course we really only need two subwheels as a minimum.

Get's tricky but at least a good thought experiment!

OK Chris - I haven't had time to study this idea yet.

But what blows my beanie is that you would move on to a configuration that is a guaranteed non-runner due to fictitious forces being employed when we had your previous ferris wheel with sub wheel idea combined with MV's accelerating and decelerating flywheels employing real forces and a certain overbalance driving the wheel at all times (and with what looks like decent torque to boot!).

This idea has no obvious problems. Could be others that develop later but at first observation looks workable (ignoring 1st law considerations of course!)

And your logic here is --------- ???

Well, this is embarrassing but I now have to call bullshit on myself as I made a major physics error in this statement. At least I caught the error before anyone else did!

The accelerating subwheels from 12:00 to 6:00 will cause the mainwheel to accelerate due to the acceleration countertorque applying a reaction force downwards against the mainwheel spokes.

The error is on the deceleration side from 6:00 to 12:00 where the slowing subwheels will then apply a braking torque to the mainwheel. This results in an overall rpm of zero to the mainwheel after deceleration of the subwheels.

The mainwheel would indeed accelerate as long as the subwheels were. But decelerating the subwheels from 6:00 to 12:00 brings the mainwheel rpm back to zero.

One would require the subwheels to continually accelerate in order to maintain acceleration of the main wheel. I lazily got the sign of the countertorque backwards during the decel phase.

An interesting solution would be to commutate (switch) the accelerated subwheels to a second parallel mainwheel at the subwheels point of maximum rpm (6:00 position)

Now applying deceleration to the newly switched spinning subwheel would begin accelerating the newly added parallel mainwheel. The parallel main wheel does not know what the subwheels are doing, it only experiences the reaction (countertorque) force from accel or decel of the subwheels.

Now when the subwheel is fully decelerated back at the 12:00 position, the parallel main wheel has achieved maximum rpm and the subwheel is commutated again over to the original main wheel.

This is interesting as we have conserved energy spinning up and slowing down the subwheels, but we now have both parallel main wheels spinning at max rpm (but in opposite directions).

This is starting to look a lot like the Keenie (Keno Wheel)

OK, someone call bullshit on this idea as well!

[MrVibrating]

Hiya mate - i did try to find a way of doing this - basically playing 'pass the parcel' with angular momentum... i tried using cranks / conrods to make one wheel accelerate as another decelerated, keeping the momentum in play, and this was spurred by the need to do something with the surplus RKE other than waste it.


However i've pretty comprehensively given up on the whole scheme - there's still one last test i needed to do, where an accelerating or decelerating flywheel balances itself horizontally, and the other end of the beam with the pivot is allowed to fall - basically as sketched here, however the only reason i haven't done it yet is because i expect it to be unity... i think the motor might as well be driving the axle directly...

But most of all i've had very little time lately.. all work and no play... still spend every spare moment thinking about different possibilities, but last few weeks i've mostly been focused on trying (and failing moserably) to find something special about scissorjacks...

Basically though if the total change in angle between rotors and stators is taken as input energy, then i don't think any of these flywheel schemes will pan out. My whole inspiration was that a pure moment could act as a counterbalance that doesn't need dropping and re-lifting. If however its cost of operation is equal to dropping and raising a real counterbalance then there seems little point continuing with it...

And really, it would leave lots of clues i place high stock in high and dry - pairs of weights alternating inner / outer positions, all that stuff. It's these clues i'm currently trying to resolve with some kind of scissorjack action. But nothing worth writing up yet. Still, probably won't be long before i'm back to my usual manic self...

Cheers for sharing though..!