Mechanising the maths

[WaltzCee]

.
.
Hello MrVibrating,

Working backwards from first principles (deductive logic), is the only possible route to a solution; the only way out of the '1+1=3 ?' conundrum.

So it seems. This logic is irrefutable, until it is.

[JUBAT]

Is it just me or are you actually getting mechanisms that are increasing speed on their own? I know it's a sim, but well done on the ideas. Cool stuff!

[WaltzCee]

.
.

Is it just me or are you actually getting mechanisms that are increasing speed on their own? I know it's a sim, but well done on the ideas. Cool stuff!

in a round-about way, yes. Also, the tests aren't a SIM. I no longer use wm2d. I do my own maths. Feeds my delusions. :)

[WaltzCee]

.
.
Hello MV,
Sorry for berrying such an excellent post. I have comments yet I'll let others have a go @ it first. I like the piston/crank model.
.

Spent some time this morning investigating which type of mechanism may be optimal for kiiking under CF, as opposed to gravity.

Under gravity, the simplest solution reduces to a balanced variable moment of inertia, plus an unbalanced weight:



However the counter angular momenta of these swings seems likely to interfere with smooth application of OB torque from the OB mechanism.

One obvious problem may be the counter-momenta from swinging these weights in the first place - clearly, if a linked pair swing in the same angular direction each phase, their combined counter-momenta will have a significant effect on accelerating and decelerating the wheel. But even with counterposed angular directions, there's still hefty exchanges of angular momentum:



From a 1 rad/s push-start and then left to coast, speed almost halves from the swings' MoI variation.

An additional issue is that in order to optimise the excursion / stroke length under CF force, the radius of these weighted vMoI's needs to be half the wheel radius; this in turn means that as the weights swing upwards, they may begin to encroach on the center, where CF diminishes potentially to zero. All else being equal, this is likely to result in chaotic sync between multiple sets of swinging members as the system attempts to relax into its max-MoI, min-KE state:



With two pairs of counterposed swings the RPM's are more stabilised, but one pair ends up hogging more momentum than the other.

It looks like things could be stabilised further by gearing the two pairs to force sync; besides, these are just passive swings without vMoI's - actively pumping them, and then harnessing the resulting inertial torques to accelerate the rolling OB system, will add another layer of regulation.

However there are many different ways of 'kiiking', which simply reduces to controlling I/O ±G-time symmetry; spending more time under gravity's constant acceleration than deceleration per cycle, albeit reactionlessly; without applying force or torque to an external inertia or ground.

One alternative method could be to attach a weight with a high MoI to the edge of the wheel via a motor, then, as the wheel lowers the OB weight, spin it up so that the counter-torque slows the descent, increasing positive G-time. When rising again decelerate or brake it, thus accelerating the lifting phase and cutting negative G-time. The weight's spin thus oscillates, spinning and braking as it rises and falls, and causing the wheel to gain momentum from G*t each GPE cycle. Here's what that looks like:



So from a 1 rad/s push-start, all further momentum is gained from G*t, via this up vs down time asymmetry. That's all kiiking really is - performing some workload to purchase momentum from G*t, in an otherwise closed system of interacting masses. 'Kiiking' = 'gaining statorless momentum'.

But what works well under real gravity isn't necessarily optimal when operating under CF force; hence why i suspect kiiking with a linear action may be the way to go here:



This seems objectively better, insofar as eliminating the unnecessary angular component of the weight's motion. A single vMoI could be cranking two or more masses in and out on opposite sides of the wheel, and with two such sets for a total of four weights, the two shared vMoI's could counter-rotate, further minimising stray counter angular momenta from interfering with the rolling OB operation.

So the next problem to be solved is the issue of a ratchet and pawl mechanism; suffice to say i don't intend to model the clunky vagaries of a real one, so much as to simulate a simplified one-way bearing - a conditional constraint that clutches when torqued in one direction, and slips in the other. Once that's sussed i'll be ready to string together a complete mechanism, using inertial torques from pumping CF swings to progressively accelerate the OB system..

[MrVibrating]

Is it just me or are you actually getting mechanisms that are increasing speed on their own? I know it's a sim, but well done on the ideas. Cool stuff!

They're demonstrating different means of gaining momentum - from gravity and time, in an otherwise-closed system of interacting masses. In other words, this is only possible because gravity's there - otherwise, N1 would apply; all else being equal, you cannot alter net system momentum via the internal expenditure of work. Momentum of a closed system's constant, unless acted upon by an externally-applied force. But even then, N2 would apply - F=mA - implicitly precluding unilateral forces and hence implying some other external inertia against which to apply that force; N3 thus applies and this 'external' inertia is really internal and part of your new, larger closed system. Hence this ability to source or sink momentum from or to gravity and time, while a trivial trick we all learn on the park swings as toddlers, is actually an interesting edge-case scenario in the laws of motion. For similar reasons, OB torque is, in and of itself, dangerously close to a kind of reactionless torque. Again, a reactionless rise in momentum has the potential to be OU; throw a 1 kg projectile at 1 m/s without recoil while coasting on skates at 1 m/s and you've created 1.5 J of free energy. Unfortunately for us, G-time and thus the amount of acceleration and thus momentum gained per cycle decreases inversely to RPM under basic over-balancing schemes, and it is these diminishing momentum returns per GPE lift with rising RPM that effectively enforces CoE in these systems. Hence the goal of regulating per-cycle momentum gains independently of wheel speed.

John Collins was the person who first noted the Estonian sport by the name of 'kiiking' and it quickly grew on me as a useful catch-all term for this general principle of gaining reactionless momentum - there was no better term already in English i was aware of. So the variations shown here obvs aren't exhaustive; anyone can probably think up more that i've missed..

They're all powered however, just to be clear - when it comes to the real testing phase i'll be logging a shed-load of telemetry, input and output energies calculated and compared independently, until it either resolves to unity or shows some I/O anomaly, which then requires further analysis to eliminate the likely errors etc. So yep, it's cool gaining momentum in an ostensibly-closed system, but there's no suggestion of any energy anomalies yet..

[MrVibrating]

..got a bit further: the one-way bearing is basically just a clutch, so the switching logic for that shouldn't be too difficult; one further component that may be useful however is a sprung flywheel.

A flywheel comprised of a passively-sprung vMoI will automatically govern its speed, producing negative inertial torque to slow itself down when under positive applied torque, and vice-versa. As such it acts as a kind of capacitor for storing momentum and PE and smoothing over abrupt changes, but the real intended benefit here is that the speed of the vMoI's driving it will also thus be regulated, preventing the per-cycle input CF-PE from increasing beyond the flywheel's maximum design speed. Here's a quick demo of one in action:



10 N-m of torque is applied for the first 30 secs, then inverting to -10 N-m for another 30 secs. Note how the abrupt change in applied torque is smoothed over, automatically compensated by this reactive inertial torque.

That's the basic principle - you can obvs have more than two masses per wheel, and the masses, spring K's, radii and preferential RPM are all arbitrarily tunable. So one of these, under a high gear ratio, so that each power stroke of the vMoI's driving it translates to many rotations of the flywheel, maximising its effects. This can then drive the rolling OB system through a correspondingly-low gear ratio.

Without something like this acting as a buffer between the vMoI's and rolling OB system, their speed and thus input CF-PE will keep increasing, squaring as it does with velocity. The objective, remember, as far as embodying the maths that solve to OU, is accumulating momentum from G*t at fixed unit-energy cost, so preventing the per-cycle input CF workload from rising over successive input strokes will be key to that..

[agor95]

Hello MrVibrating

A nice and simple concept. Has anyone built this in that last 300 years?

We know a fast moving mass has zero weight at the top of the arch.
It is believed the bottom mass to be double it's weight. By the nature of it's swing.

So it's possible to used the double weight of the bottom mass to lift up the top mass by a greater distance than the bottom mass moves down.

How are you bringing in the top & bottom mass back towards the centre hub?

Regards

[Tarsier79]

We know a fast moving mass has zero weight at the top of the arch.
It is believed the bottom mass to be double it's weight. By the nature of it's swing.

We all know it isn't that simple. The swinging weight has to be decoupled from the weight it lifts. When it actuates the other weight to lift it, it loses energy and doesn't rotate as far, requiring itself to be lifted to a reset position.

There are ways to address many of the mechanical problems individually, like removing or multiplying CF. The problem is breaking the energy conservation barrier, if that is even possible.

I have seen the unintended "OB" in moving mechanisms like MrVs above, where the OB occurs as a secondary function of what we are trying to achieve, but then the OB (more gravity acting on one side) increases the energy in the system. The simplest Iteration of this was a weight on a string running through a fixed ring/pipe. You can pull and release the string to perpetuate movement and increase the speed. Ultimately you are moving the weight in an OB path.

[MrVibrating]

Spent yesterday sussing out how to sequence the vMoI actuators relative to its rotation; the usual trick of referencing x or y coordinates relative to the 0,0 origin at the wheel center can't be used when you have two coaxial wheels both at 0,0, one riding the other, since there's no clean way to subtract displacements of the lower wheel from the upper one purely by referencing x or y displacements when their rotations are asynchronous - sometimes the datum on the lower wheel will be +x while the one on the upper wheels is -x and so on; if the upper wheel is mounted anywhere other than coaxially to the lower one, the maths become simple, but when they're both at 0,0 you have a Cartesian conundrum..

In figuring it out i noticed the desired actuator motion was basically sinusoidal - slowing towards maximum extension and speeding up midway - and so the solution was remarkably simple; take the sin of the vMoI's rotation and for a circle with 1 m radius this gives a number that varies smoothly between 1 and -1 - exactly matching the x,y trace of a point circulating the rim. You can then subtract the rotation of the lower wheel from the upper one, to basically generate a stable rotating coordinate system using Pi and basic trig. Nice.

So, that out of the way, here's the result, kiiking under CF whilst coasting from a push-start:



..obviously conserving net system momentum there; i've already begun trying to use it to drive a simple GPE system, but this needs more work (wanna add that variable MoI flywheel first).. Busy with work the rest of this week but i'll keep tinkering and posting any updates..

[agor95]

Good Work - Keep the Faith.

Double checking the conservation LAWS are preserved has it's value.

However after testing for this on sub-movements you end up having to trust
the output of all the movements running at the same time.

There is more points but they can be offered later.

Regards

[MrVibrating]

error deleted

[MrVibrating]

..

[Tarsier79]

The last one looks like a bit of an inefficient way to increase rotational speed... It reminds me of a video I see occasionally on youtube, where someone cranks a wheel back and forth which causes the wheel to accelerate faster and faster regardless of its speed. I can't find this video :(

[johannesbender]

MRVibrating , you know the laws energy cannot be created nor destroyed , I'm sorry to sound negative here , I wish you find something , but I have my doubts and it is not doubts in you but doubts in violation of those laws , i get momentum is not KE though and KE is not momentum though but my misgivings come from where is the energy for the CF coming from though.

[agor95]

Hello MrVibrating

There is more to exploring 'The Quest' than people declare.

Some of the process is building a better understanding of our skills, tool,
devices and software modelling products.

I expect an accelerating device that increase rotation will appear as a breaker of LAWs at first.

For now we can only assist in building our ability to communicate with good graces
and help other in their development.

Regards