..may just have found something; will need to check it out properly tomorrow..
But briefly; so far i've only showed examples in which the weight axes remained free and un-torqued.
Consider instead though what will happen if the brakes on those axes are engaged; the weights will thus also be forced to rotate along with the OB axis..
..if the brakes remain locked, the weights will continue rotating at equal speed with the OB axis they're pinned to..
..if they're only locked whilst falling however, then unlocked again whilst rising, then a potentially-interesting condition arises:
• during descent, gravity was performing work upon two equal MoI's (the OB axis is 1 kg-m², and so is the net MoI of the weight axes, at 0.25 kg-m² each)
• upon rising whilst unlocked however, the half of that momentum gain residing on the weight axes is left to coast, and is not gravitating during this phase - only the other half of the momentum gain, that was induced to the OB axis, is repaying momentum to gravity on the way back up..
So there's a kind of 'valve' action going on; gravity equally accelerates two identical MoI's as GPE is output, but then when GPE is being put back in again, only one of those MoI's is shedding momentum back to gravity, whilst the other simply coasts, the weights rolling around their own, balanced axes until they reach 12 o' clock and the brakes engage for the next drop..
..since the OB axis is still accelerating even whilst the rising weights are coasting about their own axes, when the brakes lock at TDC the collision is accelerating the weight axes, and decelerating the OB axis. However despite being the slower body, the weight axes are contributing back their 50% share of the momentum, that hasn't been tapped by gravity - unlike that of the OB axis - and hence rendering a directional asymmetry and effective N3 break / net rise in momentum..
Now that's what i'm talking 'bout - bit more objective than 'suck it and see' eh?
This should be a piece of piss to set up - 'brakes on' when vertical speed is negative, 'off' when positive, and carefully confirm each step of the above observations:
• that the output momentum from each drop is split exactly 50/50 between the OB and weight axes
• that whatever axial momentum the weights have at 6 o' clock, they still have at 12 o' clock
• verify that this conserved quantity is accumulating on a per-cycle basis
• note how this affects the energy evolution / momentum yield vs RPM etc.
Plan..
Decoupling Per-Cycle Momemtum Yields From RPM
Moderator: scott
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
..so here's a LQ version of the above interaction:
..obviously i'll run with much higher precision settings for taking data.
Since only two of the weight axes are subject to OB torque at any one time, their total MoI (net of all four) has been doubled, so that the remaining half is equal to the OB axis, thus maintaining momentum parity between them. May also try alternate ratios if anything interesting falls out.. (ie. why just skim off 50% - why not 75% or 90% etc.?)
So yeah, that's basically the gig i was on about, anyway - the weight axes are being torqued by gravity on their way down, but not being un-torqued by it on their way back up, type situation..
..so with any luck, they're accumulating momentum from gravity each cycle that would otherwise have been repaid to it..and 'effective N3 break' yadda yadda..
So, now that it's doing the thing.. measure the thing.. (yawn)
..obviously i'll run with much higher precision settings for taking data.
Since only two of the weight axes are subject to OB torque at any one time, their total MoI (net of all four) has been doubled, so that the remaining half is equal to the OB axis, thus maintaining momentum parity between them. May also try alternate ratios if anything interesting falls out.. (ie. why just skim off 50% - why not 75% or 90% etc.?)
So yeah, that's basically the gig i was on about, anyway - the weight axes are being torqued by gravity on their way down, but not being un-torqued by it on their way back up, type situation..
..so with any luck, they're accumulating momentum from gravity each cycle that would otherwise have been repaid to it..and 'effective N3 break' yadda yadda..
So, now that it's doing the thing.. measure the thing.. (yawn)
re: Decoupling Per-Cycle Momemtum Yields From RPM
.
Last edited by silent on Mon Oct 04, 2021 6:26 pm, edited 1 time in total.
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Sir these are not build designs!
I fully appreciate that everyone wants to see a design for a PMM they can build - me too - but what i'm doing is simply designing novel interactions, and then measuring them.
I'm doing this to look for ways of implementing the 'maths of OU' mechanically - trying to distill the fuel for the fire, rather than designing the engine.
Without sim software, none of this would be getting done. Although i'm taking painstaking care not to invoke anything non-physical, we are talking 'spherical cows' - sims can be idealised and 'purified' of real-world practical constraints, to focus in on the precise questions of interest; so for example in the above sim you'll notice that the two OB mechs only have MoI's of just under 0.5 kg-m² - so their net is 9.998 kg-m²... the remaining 0.002 kg-m² is made up from mass that is neither radially-translating nor gravitating - basically the net mass of the wheel body and actuators; obviously in a real-world build the amount of inert mass would be much greater, and yet, on the other hand, in sim-world we could set the amount of inactive mass to 'zero' - so those rotating weights would constitute all of the system mass, the momentum and energy of which is ultimately all we want to know about..
..in fact, what i'd normally do is keep the amount of inactive mass below the margins of displayed digits - so for example i use 16 digits internally, whilst only displaying ~5, so could fully calculate the effects of the inactive mass to 11 significant digits, whilst only showing a 'perfect' MoI down to 5 digits in the meters... then, each mech would appear to have an MoI of exactly '0.5' but then, some particularly astute observers (ie. Fletch) would caution that i appear to be using zero-mass bodies, even tho the sim wasn't throwing an error (which it does whenever a zero-mass body is invoked), even tho i'm actually not (and never have!)..
..so, setting the inactive mass to 2 mg isn't strictly being 'non-physical' - and neither would hiding it below the noise floor, like i normally do - but it's beyond practical constraints, even if building with carbon fibre and aerogel etc..
So no, you're right - you probably wouldn't wanna try implementing any of these interactions in R/L.
If you did, they'd inevitably be much messier.
And even then, the whole point here is getting data (they're measurement apparatus, not product designs) - so, how do you get the data off a R/L rig?
By contrast, just look at all the telemetry i can pull here..
A R/L rig can't tell you its MoI - you still need to measure it. The measurement in question is the amount of mass, times its radius squared. And in most of these rigs, it's changing on the fly...
Answer: you'd have to set up a computer - a laptop, say - connected to a Hall sensor or laser tacho and filmed with a high-speed camera then sifted thru frame-by-frame measuring angles and lengths and calculating velocity changes as a function of frame timestamps..
So how would i go about building such a model on my computer desk here (all the workspace i have), and then getting umpteen digits of data solid enough to solve the whole interaction down into the millijoules? It just ain't gonna happen is it?
Look at this result for example from the weekend:
It's just a baseline calibration run, but check out the speed:
• the system's under a constant OB torque of 2.45 N-m, however the 'torque' meter there is simply applying N2 (T=MoI*rad/s²) since there's no way to measure reactionless torque directly (OB torque's reactionless); the meter reads near-zero for most of the interaction because gravity's pull is being perfectly cancelled by inertial torque (the ice-skater effect (also reactionless))..
• the speed thus converges to precisely 1 rad/s - of its own accord (no stator!) - a physical consequence of the selected MoI-control condition, which is being enforced to at least the 5 sig figs displayed, by converting the difference between 'target' and 'actual' MoI's into 'radial velocity' data, thus perfectly locking the MoI rise to the momentum rise, and thus the angular velocity, even while the system continues to gain momentum under gravity's uniform acceleration with unbroken continuity - again, from the 'momentum' trace alone all you'd know is that it looks like a system in free-fall (which it is) - with not so much as a glitch to betray the fact that the system suddenly switched from 'faster' to 'fatter' momentum-gain modes..
Honestly? I doubt a Swiss watch-maker could rig up this interaction half as usefully - just perfectly cancelling any variation in MoI caused by the OB trajectory would be a hell of an achievement, but then perfectly cancelling the resulting OB torque using only inertial torque (ie. without recourse to a stator) to lock the speed at a desired RPM?
If i may say so, this is frickin' mastery of a GPE interaction.. i can accurately control and meter every component aspect of the system; planned out in advance, implemented and measured - methodical, objective.. 'Victorian science'.. with sims. As such, i'd hazard you may even be witnessing 'new science' if only insofar as these are simple, fundamental (nay elementary) interactions that nonetheless mightn't have seen light of day before - if only due to being so tricky to implement.. and that's before even getting to the motivations to try; everyone knows the ice-skater effect works because of conservation of angular momentum, and everyone thinks GPE interactions are likewise momentum-conservative.. so the fact that they're manifestly not when both are combined together seems to have skipped everyone else's attentions.. and everyone and his dog knows PMM's are impossible, so for what reason on God's green Earth would anyone who even had the wherewithal to consider such interactions, actually proceed to try implementing them? It's just classical mechanics FFS - 'everyone knows' it's been nigh-on 'complete' for two centuries - it literally was all finished up by the Victorians.. now book-ended by quantum and astro, condensed matter and high-energy physics etc. etc..
Nobody - no one who thinks they matter, anyway - is going to have the remotest interest in trying to 'decouple per-cycle momentum yields from RPM', even if it is mankind's greatest physical challenge that nobody knows about, and the means to both save and destroy us..
So, soz bud, but for now, what you're stuck with, in this dept. at least, is poxy friggin' sims me old matey. Until one of 'em starts racking up more momentum than it's strictly paid for, you're probably not gonna wanna try building any of 'em.. but even if you could, the results would be inferior in every way to the maths you can plot out on a scrap of paper, let alone animate on-screen..
In a nutshell, simming excises out that whole quagmire of extracting / abstracting the data of interest from the test rig in question; it means the rig itself can be leaner (indeed, ideally so, with maximally-simple, irreducible complexity), and the data taken precisely without recourse to 'external' measuring implements (ie. without having to eye-ball ruler and angle markings etc.), which, in a real-world rig, would still require data analysis.. and i'm pulling 32,000 data points per run here.. all that data needs crunching through a spreadsheet to pull the integrals, regardless of whether it came from a real rig, or one drawn on a beer mat..
Let's find the fuel, work out how to refine it, then think about designing a practical engine / motor to harness it..
I know it's beguiling to watch an OB mechanism being animated, but pretty-much everyone here already fully understands that closed loop GPE interactions can only ever yield zero net energy, so the practicalities of building such a rig should be pretty far from anyone's mind; all that matters - the only issue of interest at all - is energy in, vs energy out, and so the only SANE reason to be implementing such interactions is to frickin' measure them... and so that's all they're designed for, from the bottom up. Getting the data. Getting answers. Isolating options, eliminating the futile, and whatever's left must be the truth.. Objectivity, methodology, measurement.. that's the M.O. Without sims, all you'd have to look at would be pages of calcs.. sorry for the rant but i'm constantly having to fend off this complaint from folks who don't seem to understand what i'm trying to do, which is simply to work out how to actually implement mechanical OU, from first principles - to literally 'make' energy in the form of its component variables, by using the conservation laws (esp. Newton's & Noether's) instead of just ignoring 'em and hoping for the best.. which, to be fair, we've all seen enough of already..
..soz, easily triggered here...
When i first started OU research, i did go and stock up on Meccano, and built lots of test rigs using it and other materials. I recorded results using practical measures - rulers, protractors, scales & cameras etc. - eye-balling increments, old-skool style-e... but then i realised a sim is like the ultimate 'constructor set'.. on steroids.. and every home should have one.
So it really is what it is, or else it just wouldn't be..
As for the current state of the rig, i very much doubt it's OU yet, but the intention was only to trace what happens to that portion of the momentum gained from gravity which is subsequently shielded from it during the lift - currently set at 50%, but it could be any percentage - to see if it might be useful in gaining more momentum than a given RPM would otherwise enable.
If successful - and if it's not OU already - then the next step is, once again, trying to harness enough momentum this way, at low enough energy cost, to cause an effective N3 break / reference frame divergence / KE gain over input PE..
TL:DR
..it's still a 'physics challenge' more than just an engineering one.. but if 'the possibility' is there, it cannot evade an objective, methodical elimination of all possible permutations of 'mechanical interaction' - of force, mass, motion and gravity.. everyone else thinks this shit's impossible precisely because classical mechanics doesn't offer sufficient complexity in the first place; but if it DOES, regardless, then i'm going to use that same finite-ness of the problem-space to home in on the solution - 'it's an eminently tractable problem'; that's the spirit in which Bessler approached it:
I fully appreciate that everyone wants to see a design for a PMM they can build - me too - but what i'm doing is simply designing novel interactions, and then measuring them.
I'm doing this to look for ways of implementing the 'maths of OU' mechanically - trying to distill the fuel for the fire, rather than designing the engine.
Without sim software, none of this would be getting done. Although i'm taking painstaking care not to invoke anything non-physical, we are talking 'spherical cows' - sims can be idealised and 'purified' of real-world practical constraints, to focus in on the precise questions of interest; so for example in the above sim you'll notice that the two OB mechs only have MoI's of just under 0.5 kg-m² - so their net is 9.998 kg-m²... the remaining 0.002 kg-m² is made up from mass that is neither radially-translating nor gravitating - basically the net mass of the wheel body and actuators; obviously in a real-world build the amount of inert mass would be much greater, and yet, on the other hand, in sim-world we could set the amount of inactive mass to 'zero' - so those rotating weights would constitute all of the system mass, the momentum and energy of which is ultimately all we want to know about..
..in fact, what i'd normally do is keep the amount of inactive mass below the margins of displayed digits - so for example i use 16 digits internally, whilst only displaying ~5, so could fully calculate the effects of the inactive mass to 11 significant digits, whilst only showing a 'perfect' MoI down to 5 digits in the meters... then, each mech would appear to have an MoI of exactly '0.5' but then, some particularly astute observers (ie. Fletch) would caution that i appear to be using zero-mass bodies, even tho the sim wasn't throwing an error (which it does whenever a zero-mass body is invoked), even tho i'm actually not (and never have!)..
..so, setting the inactive mass to 2 mg isn't strictly being 'non-physical' - and neither would hiding it below the noise floor, like i normally do - but it's beyond practical constraints, even if building with carbon fibre and aerogel etc..
So no, you're right - you probably wouldn't wanna try implementing any of these interactions in R/L.
If you did, they'd inevitably be much messier.
And even then, the whole point here is getting data (they're measurement apparatus, not product designs) - so, how do you get the data off a R/L rig?
By contrast, just look at all the telemetry i can pull here..
A R/L rig can't tell you its MoI - you still need to measure it. The measurement in question is the amount of mass, times its radius squared. And in most of these rigs, it's changing on the fly...
Answer: you'd have to set up a computer - a laptop, say - connected to a Hall sensor or laser tacho and filmed with a high-speed camera then sifted thru frame-by-frame measuring angles and lengths and calculating velocity changes as a function of frame timestamps..
So how would i go about building such a model on my computer desk here (all the workspace i have), and then getting umpteen digits of data solid enough to solve the whole interaction down into the millijoules? It just ain't gonna happen is it?
Look at this result for example from the weekend:
It's just a baseline calibration run, but check out the speed:
• the system's under a constant OB torque of 2.45 N-m, however the 'torque' meter there is simply applying N2 (T=MoI*rad/s²) since there's no way to measure reactionless torque directly (OB torque's reactionless); the meter reads near-zero for most of the interaction because gravity's pull is being perfectly cancelled by inertial torque (the ice-skater effect (also reactionless))..
• the speed thus converges to precisely 1 rad/s - of its own accord (no stator!) - a physical consequence of the selected MoI-control condition, which is being enforced to at least the 5 sig figs displayed, by converting the difference between 'target' and 'actual' MoI's into 'radial velocity' data, thus perfectly locking the MoI rise to the momentum rise, and thus the angular velocity, even while the system continues to gain momentum under gravity's uniform acceleration with unbroken continuity - again, from the 'momentum' trace alone all you'd know is that it looks like a system in free-fall (which it is) - with not so much as a glitch to betray the fact that the system suddenly switched from 'faster' to 'fatter' momentum-gain modes..
Honestly? I doubt a Swiss watch-maker could rig up this interaction half as usefully - just perfectly cancelling any variation in MoI caused by the OB trajectory would be a hell of an achievement, but then perfectly cancelling the resulting OB torque using only inertial torque (ie. without recourse to a stator) to lock the speed at a desired RPM?
If i may say so, this is frickin' mastery of a GPE interaction.. i can accurately control and meter every component aspect of the system; planned out in advance, implemented and measured - methodical, objective.. 'Victorian science'.. with sims. As such, i'd hazard you may even be witnessing 'new science' if only insofar as these are simple, fundamental (nay elementary) interactions that nonetheless mightn't have seen light of day before - if only due to being so tricky to implement.. and that's before even getting to the motivations to try; everyone knows the ice-skater effect works because of conservation of angular momentum, and everyone thinks GPE interactions are likewise momentum-conservative.. so the fact that they're manifestly not when both are combined together seems to have skipped everyone else's attentions.. and everyone and his dog knows PMM's are impossible, so for what reason on God's green Earth would anyone who even had the wherewithal to consider such interactions, actually proceed to try implementing them? It's just classical mechanics FFS - 'everyone knows' it's been nigh-on 'complete' for two centuries - it literally was all finished up by the Victorians.. now book-ended by quantum and astro, condensed matter and high-energy physics etc. etc..
Nobody - no one who thinks they matter, anyway - is going to have the remotest interest in trying to 'decouple per-cycle momentum yields from RPM', even if it is mankind's greatest physical challenge that nobody knows about, and the means to both save and destroy us..
So, soz bud, but for now, what you're stuck with, in this dept. at least, is poxy friggin' sims me old matey. Until one of 'em starts racking up more momentum than it's strictly paid for, you're probably not gonna wanna try building any of 'em.. but even if you could, the results would be inferior in every way to the maths you can plot out on a scrap of paper, let alone animate on-screen..
In a nutshell, simming excises out that whole quagmire of extracting / abstracting the data of interest from the test rig in question; it means the rig itself can be leaner (indeed, ideally so, with maximally-simple, irreducible complexity), and the data taken precisely without recourse to 'external' measuring implements (ie. without having to eye-ball ruler and angle markings etc.), which, in a real-world rig, would still require data analysis.. and i'm pulling 32,000 data points per run here.. all that data needs crunching through a spreadsheet to pull the integrals, regardless of whether it came from a real rig, or one drawn on a beer mat..
Let's find the fuel, work out how to refine it, then think about designing a practical engine / motor to harness it..
I know it's beguiling to watch an OB mechanism being animated, but pretty-much everyone here already fully understands that closed loop GPE interactions can only ever yield zero net energy, so the practicalities of building such a rig should be pretty far from anyone's mind; all that matters - the only issue of interest at all - is energy in, vs energy out, and so the only SANE reason to be implementing such interactions is to frickin' measure them... and so that's all they're designed for, from the bottom up. Getting the data. Getting answers. Isolating options, eliminating the futile, and whatever's left must be the truth.. Objectivity, methodology, measurement.. that's the M.O. Without sims, all you'd have to look at would be pages of calcs.. sorry for the rant but i'm constantly having to fend off this complaint from folks who don't seem to understand what i'm trying to do, which is simply to work out how to actually implement mechanical OU, from first principles - to literally 'make' energy in the form of its component variables, by using the conservation laws (esp. Newton's & Noether's) instead of just ignoring 'em and hoping for the best.. which, to be fair, we've all seen enough of already..
..soz, easily triggered here...
When i first started OU research, i did go and stock up on Meccano, and built lots of test rigs using it and other materials. I recorded results using practical measures - rulers, protractors, scales & cameras etc. - eye-balling increments, old-skool style-e... but then i realised a sim is like the ultimate 'constructor set'.. on steroids.. and every home should have one.
So it really is what it is, or else it just wouldn't be..
As for the current state of the rig, i very much doubt it's OU yet, but the intention was only to trace what happens to that portion of the momentum gained from gravity which is subsequently shielded from it during the lift - currently set at 50%, but it could be any percentage - to see if it might be useful in gaining more momentum than a given RPM would otherwise enable.
If successful - and if it's not OU already - then the next step is, once again, trying to harness enough momentum this way, at low enough energy cost, to cause an effective N3 break / reference frame divergence / KE gain over input PE..
TL:DR
..it's still a 'physics challenge' more than just an engineering one.. but if 'the possibility' is there, it cannot evade an objective, methodical elimination of all possible permutations of 'mechanical interaction' - of force, mass, motion and gravity.. everyone else thinks this shit's impossible precisely because classical mechanics doesn't offer sufficient complexity in the first place; but if it DOES, regardless, then i'm going to use that same finite-ness of the problem-space to home in on the solution - 'it's an eminently tractable problem'; that's the spirit in which Bessler approached it:
..arguably, the only 'proven' approach on record..Bessler wrote:I would have success in my project! The right path is there - the thing is somewhere in Nature's laws.
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
..besides, simming's just a fun computer game in it's own right - same basic gameplay as Subnautica - mainly, exploration, and base building..
Each base, no matter how ambitious the locale, needs the same basic components: fabricator, scanner room, MoI meter, grow-room and F*d integrals etc. You can go anywhere, do anything - half the game's always in your imagination - you can zip round the map fast but not really investigating anything, or get all scientitious with the alien containment systems and effective N3 breaks etc. (install a bioreactor to power a tank full of peepers, and the peepers will power the reactor and the rest of the base - OU fish sauce!)
Subnautica has more up-to-date graphics, but WM still has my most-logged hours..
Been playing a lot of Subnautica tho.. Yeah it ain't gonna save the world.. but a lot less likely to destroy it, too..
:|
Each base, no matter how ambitious the locale, needs the same basic components: fabricator, scanner room, MoI meter, grow-room and F*d integrals etc. You can go anywhere, do anything - half the game's always in your imagination - you can zip round the map fast but not really investigating anything, or get all scientitious with the alien containment systems and effective N3 breaks etc. (install a bioreactor to power a tank full of peepers, and the peepers will power the reactor and the rest of the base - OU fish sauce!)
Subnautica has more up-to-date graphics, but WM still has my most-logged hours..
Been playing a lot of Subnautica tho.. Yeah it ain't gonna save the world.. but a lot less likely to destroy it, too..
:|
re: Decoupling Per-Cycle Momemtum Yields From RPM
I find dumping Microsoft and it's software is the best method to prevent MS directed virus from getting hold.
I ignoring the user above has it's looks like a sales pitch for an old software product supplier.
Anyway if there are any Elite player out the from the 1982 - 1986 i recommend the software 'oolite'.
p.s. Apology for posting in the thread. Hopefully other will stop and get on topic.
Regards
I ignoring the user above has it's looks like a sales pitch for an old software product supplier.
Anyway if there are any Elite player out the from the 1982 - 1986 i recommend the software 'oolite'.
p.s. Apology for posting in the thread. Hopefully other will stop and get on topic.
Regards
[MP] Mobiles that perpetuate - external energy allowed
re: Decoupling Per-Cycle Momemtum Yields From RPM
agor... It's highly unlikely those links will activate whatever they advertised, and instead "activate" your computer for something that's not beneficial for you and your computer.
Really, it's spam at best.
Really, it's spam at best.
Marchello E.
-- May the force lift you up. In case it doesn't, try something else.---
-- May the force lift you up. In case it doesn't, try something else.---
re: Decoupling Per-Cycle Momemtum Yields From RPM
Hi
I agree and it's good you warn members so clearly.
Regards
I agree and it's good you warn members so clearly.
Regards
[MP] Mobiles that perpetuate - external energy allowed
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Re: re: Decoupling Per-Cycle Momemtum Yields From RPM
Elite is, hands down, the. best. computer. game. ever.agor95 wrote:I find dumping Microsoft and it's software is the best method to prevent MS directed virus from getting hold.
I ignoring the user above has it's looks like a sales pitch for an old software product supplier.
Anyway if there are any Elite player out the from the 1982 - 1986 i recommend the software 'oolite'.
p.s. Apology for posting in the thread. Hopefully other will stop and get on topic.
Regards
Except of course the deformed bastard that is Elite: Dangerous (it's NOT remotely 'Elite' in any way, shape or form, avoid avoid).
Played the BBC Master version to death back in the day (still have all the kit and boxed 5.25" disc and cassette versions).
I still play Frontier: Elite (just such an awesome game!) - YT won't let me upload any more vids cos of the background radio tunes i usually listen to, but there's a load here: https://www.youtube.com/channel/UCrny-y ... shelf_id=0
Oolite i could never get into - in fact i'd describe Elite: Dangerous as more a sop to Oolite than traditional Frontier: Elite - without the physics, the whole thing just seems a bit silly, to me anyway.. In particular, the way the old 8-bit game handled was inextricably tied to the hardware constraints it was pushing up against, whereas with modern PC's it's just impossible to fly and aim accurately like you can on the classic hardware - at least when using keyboard..
I use Beebem when i want to play the old game, and FFED3D when i want to enjoy a bit of actual spaceflight with my pew-pew...
Still holding out for an authentic sequel, one day.. it's obviously not going to be coming from Frontier or Breadbins tho.. (oh how the mighty have fallen)..
re: Decoupling Per-Cycle Momemtum Yields From RPM
Lets hope the Oolite improves to have the qualities of Frontier without the bugs.
As I believe the Elite brand has spun off into the commercial online only universe never to return.
P.S. fascinating simulation demo
As I believe the Elite brand has spun off into the commercial online only universe never to return.
P.S. fascinating simulation demo
[MP] Mobiles that perpetuate - external energy allowed
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Right, been spending a fair bit of time staring blankly at the Toys page lately, just slowly refining the interpretation...
Just wanna share where i'm at, as others working the same clues may find this interesting..
'A' + 'B'
No real changes here - it's showing a series of 5 reactionless accelerations.
Here's how to read it:
• from bottom to top
• the vertical 'chain links' represent torques, or, more specifically, momenta, with respect to their angular directions
• ..so there's two links running from right to left, but only one link going from left back to right sides
• ..thus, three torques or momenta per 360° cycle; two 'positive' ones for the first 180°, but only one 'negative' one for the second 180° of each cycle
• ..hence each full cycle is an asymmetric inertial interaction, gaining equal momentum each cycle, from gravity
• ..since there's five in the series, apparently concluding in "something extraordinary", it seems certain we're looking at what i call a 'gain trajectory' (an efficiency evolution rather than a spatial path) with a '25% accumulator'; that is, each cycle accelerates a pair of masses / inertias whilst sinking the corresponding counter-momenta to gravity; assuming two equal interacting masses / inertias in this asymmetric inertial interaction (because the unity threshold's equal to the sum of their ratio), this means that half of the momentum that would've been generated is lost to gravity per cycle...
..and this is what causes the 25% accumulator.
Because if the exploit instead involved simply reversing or inverting the sign of counter-momentum - ie. preserving all of it, as a constant per-cycle unidirectional momentum rise - then the 'unity threshold' is reduced to its absolute theoretical minimum of 2 cycles; that is, two 1 kg or 1 kg-m² inertias in a cyclic asymmetric inertial interaction will give a 50% energy loss after one cycle, but will reach unity by the second cycle.. and 150% over-unity at the third, 200% at the fourth etc. etc.
Yet the Toys page is showing us a 5-cycs-to-OU sequence...
...and this is the next best solution to the 3-cycs-to-OU one; now, instead of inverting or reversing the sign of our counter-momentum and collecting all of it as a unidirectional velocity rise, we just assume complete cancellation / destruction of counter-momentum - basically, sinking it to gravity or 'the void' or whatever..
I've shown several variations on this interaction before, but just for example, suppose you apply a vertical 9.81 N force between two 1 kg masses whilst they're dropped into free-fall; what happens is that the upper mass hovers in mid-air, whilst the lower one plummets at 2 G.. if you can re-raise that mass whilst shedding only half the gained momentum back to gravity, then doing that 5 times in a row nets you a 125% KE gain.. So, same basic concept, but in a rotating rather than linear / static reference frame..
Basically when we simply 'destroy' all counter-momentum by effectively expunging it from the system, whilst accumulating the remaining 'positive' momentum gained per cycle, then we get a 75% loss from the first cycle, dropping to 50% on the second, and 25% on the third... then we hit unity at the fourth, and 125% of unity at the fifth..
• the asymmetric 'fork' atop 'B' indicates there's twice as much 'clockwise' as 'counter-clockwise' angular momentum.. (the left fork has half the angle of the right one, relative to the vertical)
So that's 'A' and 'B' tied up; it's a physics puzzle with a physics solution: P=mV and KE=½mV², assume 1 kg masses / inertias.. piece of piss to verify on the back of an envelope, and thus unequivocal that the 'vis viva dispute' had been conclusively solved, by Bessler, some time prior to 1712.. but that is was also a crucial part of his IP! It would likely have astonished him that we, today, possessing and depending upon our full and concise understanding of the p/KE relationship, have yet to rediscover his full solution!.. but like i say, human stupidity is the only IP protection that genuine OU requires... you cannot give it away..
'C' and 'D' correlate to MT's 30 - 42, and 133 - 135... amongst others.
'C' - the upper hammer toy - is a lightweight pair of weights, connected with rigid braces per MT 40 et al..
..in fact, MT 40 is, pretty much, the same mech as represented by the Toys page. Ditto its many variants.
So, why a pair of small masses, rather than a single central one (since it's their center of mass that gravitates, after all) - the only purpose served by having a big air gap between them is to maximise the MoI variation, relative to the GPE variation!
So, the upper hammer toy 'C' represents weights that cause an MoI variation. As they leave one resting spot on one side of the wheel, MoI is decreasing, so work is being done against CF force. As they pass mid-center, that CF force then pushes them back out to the max-MoI position again. So, there's a positive-negative sequence of inertial torques each time they swap sides.
Note that in the original scans we can see that some instances of the letter 'A' denoting parts of mechanisms are embellished with a downwards-pointing chevron, whilst others are left uninflected...
These differentiate between 'inputs vs outputs', 'driver' vs 'driven', or sources / sinks; basically, input workoads, versus output ones...
So for example, look at the original scan of MT 40:
• the 'A' figures denoting the diameteric weight levers in the wheel are outputs - that is, they're raised upwards by the descent of the two weights 'D'... and not the other way around!
Think about it - why would we want to convert some GPE into more GPE, minus losses? Zero-sum game, no over-balance, just, pointless...
But those weighted levers have axes, so their motions are angular, and this IS a meaningful transformation of work... a linear, radial drop of GPE, also producing positive then negative inertial torques, and converting to a pair of large, heavy angular inertias...
..so, those diametric weighted levers are obviously optimised for generating maximal angular inertias within the available space; high MoI's, but with small angular displacements...
...and so this is where the scissorjack comes in!
It's there to convert that lightweight, high-displacement radial GPE / MoI translation, into a pair of high-MoI, low-displacement angular momenta!
'Well duh', eh!? So frickin' obvious innit!? It all does exactly what it says on the tin - it's not even that abstract!
But how can we be sure that the "flat A" denotes 'outputs' generally? Look at the box-out, showing the lever-operated jack - an inflected letter 'A' is used for the lever... because now it's being applied as an input!
Now check out the scan of MT 41 - notice anything new..? This is why the mech's doubled up! - each half operates in opposite directions, ie. one's a radial lift with angular drop.. the other's an angular lift with a radial drop..! Cool huh?
The other detail shown in MT 40 is that the system is also subject to OB torque... so, we have a confluence of inter-reactions occurring; a transformation of GPE into a reciprocal pair of +/- inertial torques, coupled with a pair of opposing high-MoI, low-displacement angular accels / momenta, all whilst overbalancing to the left..
So, 'D' on the Toys page is that oscillating pair of low-displacement, high-MoI angular inertias.
Their alignments to 'A' and 'B' show that they're oriented at 90° to 'C' - again, as depicted in MT 40 etc. - and again, the inertia / displacement ratio between them relative to 'C' is the reason they're connected via the scissorjack.
(Incidentally, for anyone simming - you can simplify a 'jack' by using a pair of opposed linear actuators, controlled for 'length' and inputting the length of the one jack multiplied or divided as required into the equation field of the other, so you have reciprocal equations in each and thus a 4:1 leverage ratio or whatever).
'D' is explained in more detail by MT's 133 - 134 - the weight levers / high-inertia / small angle displacements may be radial or diametric:
• In MT 133 the input denoted by an inflected 'A' is the vertical beam that passes through the axle, hence the lever arms 'F' are, again, outputs, not inputs - we're being shown a conversion of radial GPE into a pair of heavy angular momenta with small displacements - ie. maximising momentum yields from an ensuing inertial asymmetry...
The lower detail, 'G', is showing their interaction reversed (ie. weight levers drop, raising 'H') - ie. as inputs rather than outputs.
MT134 also shows them being used as inputs (denoted by the inflected 'A'), so raising the vertical beam 'B'.. i suspect the lower section 'E' is intended to emphasise their angular, over linear, components of motion.. but again, the 'sawtooth' pattern on the weights i suspect correlates to the '4-cycs-to-unity' dynamic (ie. 'four quarters' = unity), but hell, MT 134 is even weirder than the Toys page, so maybe more will become clear in time..
So what i'm doing now is playing with that interaction - converting radial weight drops into opposing small angular displacement, high-MoI motions.. whilst gravitating / over-balancing / and whilst factoring in these +/- inertial torques caused by the weight transitions..
Remember, the two-way wheels "began to accelerate as an internal weight was heard to begin falling"... so a non-OB weight, then, nonetheless causing torque.. hence implying that the torque resulted from an inertial interaction of some kind..
More convinced now than ever that a 'Bessler wheel' is basically a gravity-assisted 'chicken run' from a few pages back - using gravity to sink counter-momentum, instead of animal cruelty. That's why it's 5-cycs-to-OU rather than just 3.
The confluence of OB torque, +/- inertial torques and the conversion of a high-displacement, low-weight GPE into an opposing pair of low-displacement, high-MoI angular momenta is the de facto recipe for netting constant per-cycle momentum gains.
Findings in this thread have proven, pretty conclusively i think, that the asymmetric inertial interaction has to be between angular rather than linear inertias - per the chicken run example, only when using angular inertias can we gain equal quantities of momentum per cycle, invariant of rising RPM. With linear inertias, momentum yields must necessarily decrease by the inverse square of rising RPM, as there's progressively less time available to accelerate each cycle. Using angular inertias successfully decouples the period of the inertial interaction from that of the GPE interactions..
..the fundamental problem, then, remains:
• when using gravity to sink counter-momentum, the KE gain is (thus far) always equal to the net GPE output.
What happens is, the faster the system rotates, the greater the height covered by the weight whilst it's being used to sink counter-momentum... or else, the more GPE cycles each inertial interaction needs to be spread across (ie. with asynchronous cycle periods / frequencies).
The trick to overcoming this constraint must involve this conversion of a high-radial-displacement, low-weight GPE, into paired high-MoI, low-angle momenta. Ie. the scissorjack / storksbills - and specifically, the leverage ratio / power conversion they represent - must be the key to resolving this thread topic, of paying the same amount of input energy, to buy the same amount of unidirectional momentum per cycle, invariant of rising speed across some useful RPM range...
Just wanna share where i'm at, as others working the same clues may find this interesting..
'A' + 'B'
No real changes here - it's showing a series of 5 reactionless accelerations.
Here's how to read it:
• from bottom to top
• the vertical 'chain links' represent torques, or, more specifically, momenta, with respect to their angular directions
• ..so there's two links running from right to left, but only one link going from left back to right sides
• ..thus, three torques or momenta per 360° cycle; two 'positive' ones for the first 180°, but only one 'negative' one for the second 180° of each cycle
• ..hence each full cycle is an asymmetric inertial interaction, gaining equal momentum each cycle, from gravity
• ..since there's five in the series, apparently concluding in "something extraordinary", it seems certain we're looking at what i call a 'gain trajectory' (an efficiency evolution rather than a spatial path) with a '25% accumulator'; that is, each cycle accelerates a pair of masses / inertias whilst sinking the corresponding counter-momenta to gravity; assuming two equal interacting masses / inertias in this asymmetric inertial interaction (because the unity threshold's equal to the sum of their ratio), this means that half of the momentum that would've been generated is lost to gravity per cycle...
..and this is what causes the 25% accumulator.
Because if the exploit instead involved simply reversing or inverting the sign of counter-momentum - ie. preserving all of it, as a constant per-cycle unidirectional momentum rise - then the 'unity threshold' is reduced to its absolute theoretical minimum of 2 cycles; that is, two 1 kg or 1 kg-m² inertias in a cyclic asymmetric inertial interaction will give a 50% energy loss after one cycle, but will reach unity by the second cycle.. and 150% over-unity at the third, 200% at the fourth etc. etc.
Yet the Toys page is showing us a 5-cycs-to-OU sequence...
...and this is the next best solution to the 3-cycs-to-OU one; now, instead of inverting or reversing the sign of our counter-momentum and collecting all of it as a unidirectional velocity rise, we just assume complete cancellation / destruction of counter-momentum - basically, sinking it to gravity or 'the void' or whatever..
I've shown several variations on this interaction before, but just for example, suppose you apply a vertical 9.81 N force between two 1 kg masses whilst they're dropped into free-fall; what happens is that the upper mass hovers in mid-air, whilst the lower one plummets at 2 G.. if you can re-raise that mass whilst shedding only half the gained momentum back to gravity, then doing that 5 times in a row nets you a 125% KE gain.. So, same basic concept, but in a rotating rather than linear / static reference frame..
Basically when we simply 'destroy' all counter-momentum by effectively expunging it from the system, whilst accumulating the remaining 'positive' momentum gained per cycle, then we get a 75% loss from the first cycle, dropping to 50% on the second, and 25% on the third... then we hit unity at the fourth, and 125% of unity at the fifth..
• the asymmetric 'fork' atop 'B' indicates there's twice as much 'clockwise' as 'counter-clockwise' angular momentum.. (the left fork has half the angle of the right one, relative to the vertical)
So that's 'A' and 'B' tied up; it's a physics puzzle with a physics solution: P=mV and KE=½mV², assume 1 kg masses / inertias.. piece of piss to verify on the back of an envelope, and thus unequivocal that the 'vis viva dispute' had been conclusively solved, by Bessler, some time prior to 1712.. but that is was also a crucial part of his IP! It would likely have astonished him that we, today, possessing and depending upon our full and concise understanding of the p/KE relationship, have yet to rediscover his full solution!.. but like i say, human stupidity is the only IP protection that genuine OU requires... you cannot give it away..
'C' and 'D' correlate to MT's 30 - 42, and 133 - 135... amongst others.
'C' - the upper hammer toy - is a lightweight pair of weights, connected with rigid braces per MT 40 et al..
..in fact, MT 40 is, pretty much, the same mech as represented by the Toys page. Ditto its many variants.
So, why a pair of small masses, rather than a single central one (since it's their center of mass that gravitates, after all) - the only purpose served by having a big air gap between them is to maximise the MoI variation, relative to the GPE variation!
So, the upper hammer toy 'C' represents weights that cause an MoI variation. As they leave one resting spot on one side of the wheel, MoI is decreasing, so work is being done against CF force. As they pass mid-center, that CF force then pushes them back out to the max-MoI position again. So, there's a positive-negative sequence of inertial torques each time they swap sides.
Note that in the original scans we can see that some instances of the letter 'A' denoting parts of mechanisms are embellished with a downwards-pointing chevron, whilst others are left uninflected...
These differentiate between 'inputs vs outputs', 'driver' vs 'driven', or sources / sinks; basically, input workoads, versus output ones...
So for example, look at the original scan of MT 40:
• the 'A' figures denoting the diameteric weight levers in the wheel are outputs - that is, they're raised upwards by the descent of the two weights 'D'... and not the other way around!
Think about it - why would we want to convert some GPE into more GPE, minus losses? Zero-sum game, no over-balance, just, pointless...
But those weighted levers have axes, so their motions are angular, and this IS a meaningful transformation of work... a linear, radial drop of GPE, also producing positive then negative inertial torques, and converting to a pair of large, heavy angular inertias...
..so, those diametric weighted levers are obviously optimised for generating maximal angular inertias within the available space; high MoI's, but with small angular displacements...
...and so this is where the scissorjack comes in!
It's there to convert that lightweight, high-displacement radial GPE / MoI translation, into a pair of high-MoI, low-displacement angular momenta!
'Well duh', eh!? So frickin' obvious innit!? It all does exactly what it says on the tin - it's not even that abstract!
But how can we be sure that the "flat A" denotes 'outputs' generally? Look at the box-out, showing the lever-operated jack - an inflected letter 'A' is used for the lever... because now it's being applied as an input!
Now check out the scan of MT 41 - notice anything new..? This is why the mech's doubled up! - each half operates in opposite directions, ie. one's a radial lift with angular drop.. the other's an angular lift with a radial drop..! Cool huh?
The other detail shown in MT 40 is that the system is also subject to OB torque... so, we have a confluence of inter-reactions occurring; a transformation of GPE into a reciprocal pair of +/- inertial torques, coupled with a pair of opposing high-MoI, low-displacement angular accels / momenta, all whilst overbalancing to the left..
So, 'D' on the Toys page is that oscillating pair of low-displacement, high-MoI angular inertias.
Their alignments to 'A' and 'B' show that they're oriented at 90° to 'C' - again, as depicted in MT 40 etc. - and again, the inertia / displacement ratio between them relative to 'C' is the reason they're connected via the scissorjack.
(Incidentally, for anyone simming - you can simplify a 'jack' by using a pair of opposed linear actuators, controlled for 'length' and inputting the length of the one jack multiplied or divided as required into the equation field of the other, so you have reciprocal equations in each and thus a 4:1 leverage ratio or whatever).
'D' is explained in more detail by MT's 133 - 134 - the weight levers / high-inertia / small angle displacements may be radial or diametric:
• In MT 133 the input denoted by an inflected 'A' is the vertical beam that passes through the axle, hence the lever arms 'F' are, again, outputs, not inputs - we're being shown a conversion of radial GPE into a pair of heavy angular momenta with small displacements - ie. maximising momentum yields from an ensuing inertial asymmetry...
The lower detail, 'G', is showing their interaction reversed (ie. weight levers drop, raising 'H') - ie. as inputs rather than outputs.
MT134 also shows them being used as inputs (denoted by the inflected 'A'), so raising the vertical beam 'B'.. i suspect the lower section 'E' is intended to emphasise their angular, over linear, components of motion.. but again, the 'sawtooth' pattern on the weights i suspect correlates to the '4-cycs-to-unity' dynamic (ie. 'four quarters' = unity), but hell, MT 134 is even weirder than the Toys page, so maybe more will become clear in time..
So what i'm doing now is playing with that interaction - converting radial weight drops into opposing small angular displacement, high-MoI motions.. whilst gravitating / over-balancing / and whilst factoring in these +/- inertial torques caused by the weight transitions..
Remember, the two-way wheels "began to accelerate as an internal weight was heard to begin falling"... so a non-OB weight, then, nonetheless causing torque.. hence implying that the torque resulted from an inertial interaction of some kind..
More convinced now than ever that a 'Bessler wheel' is basically a gravity-assisted 'chicken run' from a few pages back - using gravity to sink counter-momentum, instead of animal cruelty. That's why it's 5-cycs-to-OU rather than just 3.
The confluence of OB torque, +/- inertial torques and the conversion of a high-displacement, low-weight GPE into an opposing pair of low-displacement, high-MoI angular momenta is the de facto recipe for netting constant per-cycle momentum gains.
Findings in this thread have proven, pretty conclusively i think, that the asymmetric inertial interaction has to be between angular rather than linear inertias - per the chicken run example, only when using angular inertias can we gain equal quantities of momentum per cycle, invariant of rising RPM. With linear inertias, momentum yields must necessarily decrease by the inverse square of rising RPM, as there's progressively less time available to accelerate each cycle. Using angular inertias successfully decouples the period of the inertial interaction from that of the GPE interactions..
..the fundamental problem, then, remains:
• when using gravity to sink counter-momentum, the KE gain is (thus far) always equal to the net GPE output.
What happens is, the faster the system rotates, the greater the height covered by the weight whilst it's being used to sink counter-momentum... or else, the more GPE cycles each inertial interaction needs to be spread across (ie. with asynchronous cycle periods / frequencies).
The trick to overcoming this constraint must involve this conversion of a high-radial-displacement, low-weight GPE, into paired high-MoI, low-angle momenta. Ie. the scissorjack / storksbills - and specifically, the leverage ratio / power conversion they represent - must be the key to resolving this thread topic, of paying the same amount of input energy, to buy the same amount of unidirectional momentum per cycle, invariant of rising speed across some useful RPM range...
-
MrVibrating
- Addict
- Posts: 2877
- Joined: Sat Jul 31, 2010 12:19 am
- Location: W3
Re: re: Decoupling Per-Cycle Momemtum Yields From RPM
Yep ED = shameless cash-in. Which wouldn't matter, if only it were capable of basic spaceflight...agor95 wrote:Lets hope the Oolite improves to have the qualities of Frontier without the bugs.
As I believe the Elite brand has spun off into the commercial online only universe never to return.
P.S. fascinating simulation demo
I mean, an Elite in which you're not allowed to control your own ship? How TF does that even belong in the Elite stable? Just trashes the whole marque..
No ship in ED - no matter how highly 'engineered' (i don't know whether to laugh or cry) - can replicate a single actual mission that's ever flown, since Sputnik. No ED ship can even surface-launch into orbit around anything bigger than a dustball. Earth to the Moon in a Frontier: Elite ship takes around 20-30 mins - that's real-time, no time-acceleration, just using full throttle all the way and rotating 180° at the halfway point (like the way ships fly in The Expanse, and real life, and when applying basic logic). The same journey in the 'same' ship in Elite: Dangerous (an Eagle, say) would take at least 15 hours... in Frontier: Elite, there's no 'space speed limits' - just varying thrusts / masses / delta-V's.. in ED you're stuck at a 'max speed' relative to the coordinate space itself... at maybe a few hundred m/s if you're lucky... basically marooned, stationary to all intents and purposes and going nowhere... or else going at 2,000 C in that god-awful 'supercruise' lockup-transition-fest.. "orbital cruise"... "glide mode"... "critical attack angle"... (on airless worlds?) it's all just complete tripe. Good God - "optimal mass" - just WTF is "optimal mass" as a ship performance parameter? It's all utter gobbledeygook for idiots. Disney's Black Hole had more respect for its subject matter, and audience..
Whichever degree mill Breadbins got his astrophysics Ph.d from, he paid too much..
re: Decoupling Per-Cycle Momemtum Yields From RPM
Hello MrVibrating,
This is a very long thread. I was wondering if you might in 50,000 words or less :-) explain the principle of your idea. Some of my understanding is that you are taking momentum from one frame of reference and applying it to another frame of reference. Is this true. Like a feedback system.
Is this something like particle entanglement? I know some PhD candidates at a diploma Mill and they might be curious about this idea. They can get their hands on a particle accelerator that's practically 2 miles long. This seems like something that they might be interested in. I'd like to invite them to this thread but it would be good if you could post a summary / conclusion of your idea to get them up to speed as quickly as possible.
Thanking you in advance.
This is a very long thread. I was wondering if you might in 50,000 words or less :-) explain the principle of your idea. Some of my understanding is that you are taking momentum from one frame of reference and applying it to another frame of reference. Is this true. Like a feedback system.
Is this something like particle entanglement? I know some PhD candidates at a diploma Mill and they might be curious about this idea. They can get their hands on a particle accelerator that's practically 2 miles long. This seems like something that they might be interested in. I'd like to invite them to this thread but it would be good if you could post a summary / conclusion of your idea to get them up to speed as quickly as possible.
Thanking you in advance.
........................¯\_(ツ)_/¯
¯\_(ツ)_/¯ the future is here ¯\_(ツ)_/¯
Advocate of God Almighty, maker of heaven and earth and redeemer of my soul.
Walter Clarkson
© 2023 Walter W. Clarkson, LLC
All rights reserved. Do not even quote me w/o my expressed written consent.
¯\_(ツ)_/¯ the future is here ¯\_(ツ)_/¯
Advocate of God Almighty, maker of heaven and earth and redeemer of my soul.
Walter Clarkson
© 2023 Walter W. Clarkson, LLC
All rights reserved. Do not even quote me w/o my expressed written consent.
re: Decoupling Per-Cycle Momemtum Yields From RPM
I would like to thank you MrVibrating for your post I do not mined doing the work to learn from your interpretation.
This is the type of post we look forward to on this site.
P.S. anyone can post a discordant note - time to strum a proper tune.
This is the type of post we look forward to on this site.
P.S. anyone can post a discordant note - time to strum a proper tune.
[MP] Mobiles that perpetuate - external energy allowed