Success..?

[MrVibrating]

OK, last night i removed all aerogel from then re-measured the 06/19 rig at just 1 i-s/f: it came within 0.05 J of unity (just over), so pretty much zero..

Encouraged that it seems fairly reliable (it's significantly simpler than the 'V1_2' rig), i gave it a 'sprung timing wheel', and then re-tested different combos of spring constants and timing wheel MoI's..

Nada. It does nothing interesting. All tests showed unity, to within that 0.05 J margin (mostly to within two or three zeros).



OF course the purpose of baselining the sprung timing wheel mod was to calibrate the veracity of the s&b cycle efficiency.. ie. we want, and expect, a unity result when the s&b cycles are disabled, before we can pay any heed to 'gains' from cyclically sinking counter-momenta to gravity, which remains the thread objective..


So the next step is to try retaking the s&b efficiency, whilst keeping it barebones enough to maintain the current accuracy.

This probably means overriding the 'input' fields for the currently-exposed variables - just get rid of 'em, and input the desired values directly into the control fields of the actuators and solenoids; thus minimising risk of inadvertent div-by-zeros or whatever..

Current prospects then, for the s&b cycle efficiency actually showing anything interesting, are pretty much back to square one; at least until the sim versions built in this thread are producing reliable control runs..

Back later..

[MrVibrating]

The control code for the solenoids already couldn't be simpler; it works like this:

• calculate the MoI of that solenoids weight pair, per mr², subtract half the target MoI from it, and multiply that number by the 'FFB multiplier'

The solenoids are hitherto controlled for 'torque', so each solenoid is exerting torque equal to the difference between the current MoI, versus whatever the target MoI, multiplied by whatever the FFB multiplier, thus:

• when the difference between current and target MoI's is zero, torque is zero

• when the difference is positive, torque is proportionately positive..

• ..and when it's negative, torque's proportionately negative.

So basically the solenoids autotune themselves to lock the MoI of their respective weight pair to half that of whatever the target MoI, thus their combined MoI is always equal to the target MoI.

Pretty basic stuff. The only further simplification we could make to the equation is to manually enter the FFB multiplier in the solenoids' equation fields, instead of referring it to the exposed input field - which is what the 06/19 version did.

So there's definitely no room for any errors there - it obviously works, so should be applying the 'correct' amount of torque at all times, as evidenced by the fact that the MoI's locked to six digits, and the clean, sure lines of the various solenoid plots..


However if you think about it, exactly the same solenoid control code - basically the MoI difference, amplified into a self-zeroing control signal - could be applied to control them for other properties, besides 'torque'..

..so for instance, we might try for 'angle' instead; as before, if the current-minus-target MoI difference turns negative, so would the angle of rotation of the solenoids by a corresponding amount, and vice versa if it's positive..

..or likewise, we could control for 'velocity' instead; again, no change to the control code's required here, since as before, if the MoI's on-target then the solenoids' angular velocity would be 'zero', if it's negative, so's their speed, and likewise if it's positive.. only the value of the multiplier ending the equation needs adjusting..!


So, i'll retry baselining V1_2's OB system - with s&b cycs still disabled - whilst controlling the sols for 'velocity', first off - if that seems to improve accuracy then i'll proceed to trying s&b cycles too; otherwise i'll try controlling for 'angle' instead..

Sticking with 100 i-s/f for now, more haste less speed...

[Fletcher]

If you want to fine tune run it off Acceleration positive or negative !

[MrVibrating]

PS. FWIW, i did try variable i-s/f as suggested; however the FFB multiplier's sensitive to the i-s/f value, which effectively means FFB is impossible with variable i-s/f enabled - the split instant WM decides it's safe to drop to a lower value, the sim explodes..

The reason why is that higher i-s/f = higher optimum FFB multi.. so higher forces are being generated at each integration step, but averaging out to a more accurate MoI lock frame-by-frame. For example, at ~6 kHz and 100 i-s/f, optimum FFB multi is ~1e11 - that's 100,000,000,000..

..Hence, if i-s/f suddenly reduces mid-interaction, the previous frame is likely to contain solenoid control data of up to 100 billion times whatever the current-vs-target MoI difference, yet WM no longer has sufficient integration steps within the current frame to smooth over that spike, and kaboom!


I stand by my opinion that variable i-s/f is only useful when you want the quickest-possible answer to the simplest-possible query, but even then.. you'll always be better off waiting the full minute for a 1 kHz @ 1 i-s/f result. And if the result's anomalous, you'll definitely want to recheck it with a 10 kHz 100 i-s/f minimum...

..and obviously, if you want to know the precise area under a curve, then you want to be slicing it into as many, regular-width vertical slices as possible; you get the max-possible freq. from the exact time period (to at least 5-6 digits) of the interaction, then divide the max number of frames per sim (32, 765) by that number of seconds, and then enter that entire number, along with all its decimal places, into the 'frequency' dialog box in the accuracy settings. This gives you the maximum number of vertical 'slices' for each integral in the sim, and so optimal resolution & accuracy to the solution.

Thus for data acquisition, variable i-s/f completely defeats the purpose.. the integral solution can only be less accurate..

[MrVibrating]

If you want to fine tune run it off Acceleration positive or negative !

I have controlled for 'acceleration' successfully in the past, but it's very tricky to get right. If you wanna talk about 'explodey' techniques, right up there..

The main difficulty is that the accuracy of time-step derivatives to spatial coordinates is subject to rounding limits in both fields; in short, if you're controlling for 'acceleration' then the interaction will only maintain consistent parameters for finite time, depending on your accuracy settings.. but sooner or later, parts will start to over-shoot their intended locations..

Obviously, if we just left the current 'MoI-delta * FFB multi' equation in place but switched to 'acceleration', then when the current-vs-target MoI difference was zero, solenoid speed would be constant... not necessarily 'zero'!

So the equation would need significant re-arranging, but it's possible..

Let's see how 'velocity' works out, if it's still noisy i'll try 'angle' / rotation, but i omitted to mention 'acceleration' cuz that one scares me..!

[MrVibrating]

OK here's the results when controlling for solenoid velocity instead of torque:



Acts = 159.5327866

Sols = -0.241690961

Total In = 159.291095639

KE Rise = 159.534083

EPE = 0.008592

Total Out = 159.542675

Diff = +0.251579361


Perplexing, and a PITAS - unless it's real of course - but still showing a quarter Joule discount on the solenoids' workload..


I was hoping it'd be unity, then i could switch back to using the sprung timing and re-check, then add the s&b cycles and check once more..


Physical differences between this rig and the 06/19 one remain, for example that one only had an MoI of '1', whereas here it's over 8.. could this be a factor?

Back at it tonight...


Sim attached, but this control mode needs even more CPU time to work cleanly so it's slow.. only fun for data acquisition..

[MrVibrating]

..So here's exactly the same interaction again, now controlling once more for 'torque':



_____________________

acts P*t = 159.5134942

sols P*t = -0.307554733

total in = 159.205939467

KE Rise = 159.530365

EPE = 0.008592

total out = 159.538957

diff = +0.333017533 J
_____________________


..so the gain's still there, just slightly larger.

The solenoid torque plots look a little different this time - now the torque actually returns to zero as the masses alternate directions, whereas when controlling for velocity this didn't happen:



..also you can see that the amplitude of the solenoid plots is greater in tonight's run..

..plus, note that the OB torque curve is plotting a thinner line, too - in last night's run it was obviously shaking somewhat..

So 'torque' control seems superior to 'velocity' control on every count - results seems more physically consistent, and it runs cleaner and faster..

..even tho the gain's still there!

Notwithstanding that one minor detail, the integrity of the data seems OK..

Also note the indifference of all the other plots - it's an identical interaction, of which this is definitely the better measurement, and the gain's up from a quarter-Joule to a third..

..so what's causing it?

The whole point of metering up to the gunnels is to eliminate as much of the guessing game as possible, so we should be able to see the causes already..

Let's look at those solenoid T*a plots:


_____________________

sol1 T*a = 17.30419008

sol2 T*a = -17.61795697

diff = -0.31376689 J
_____________________


OK so there it is - it's the difference between the two solenoid workloads over one full turn..

..why are they different?

Well, they're 90° out of phase..

..and the system's accelerating!

So solenoid 2 is ending in the vertical alignment, where the gap between its masses is at its maximum (=sqrt(2)*wheel radius, FWIW) - so each full rotation begins with sol2's masses drawing closer together, and ends with 'em getting farther apart..

..conversely, at the same time sol1's gap begins each cycle widening, and ends shrinking..


..this leads us to a rather interesting proposition (tighten the head-bras and consecrate on this!):

• over one full cycle at constant RPM, both solenoids would see equal workloads..

• ..but because the system's accelerating,, and the maxima and minima of each mech's energy states are effectively 180° antiparallel, sol2 will always gain more energy over a full cycle than sol1 expends!

How friggin' mad is that!

Logic trap for nature? Is this the real solution?


So perhaps MoI-locking is kinda incidental to the gain mechanism here, which might be better optimised by a wildly fluctuating MoI, so long as each mech's respective CF maxima and minima are orthogonally-oriented over a full cycle?

Kinda like time travel innit - energy from 'the next' cycle is co-extant with - and inexorably greater than - the energy of 'the previous' cycle, as they share this dove-tailing 50% overlap...

Anyone feeling me here - is this not the repeated lesson of pretty much every sim in this thread? How many times do we need to remeasure the same thing - sol2 consistently gains more than sol1 spends, and the difference is a per-cycle net energy gain, where the first half of one mech's cycle is subsidising the second half of the other's, type deal..!?



So perhaps we should start trying to rub some funk on that MoI-control function - stop even considering it a matter of 'MoI control', as CF-PE staging - counterposing high and low energy states in the same cycle, in an accelerating rotating FoR..


Will need a little time to meditate on this to decide how best to proceed..


And still, one question nags - if this hypothesis is going anywhere, why does the 06/19 version not seem to confirm it? This will obviously need revisiting.. Why's this perfectly-plausible sounding explanation only apply here, and not there? What else has changed?

[MrVibrating]

..well, it'd seem consistent with the boost we saw from the sprung timing mod, wouldn't it? It quite possibly - and randomly, mind - widened the discrepancy between the two mech's CF-PE maxima and minima, so if we re-enable it (switch back to controlling actuator lengths as a function of it's angle, rather than theirs), maybe we can correlate the difference between each solenoid's workload - ie. the per-cycle gain - to the timing variation?

Then it wouldn't be quite so 'anomalous', at least..

[MrVibrating]

Just noticed - if this new hypothesis is correct, then:

• we've been staring at the real gain dynamic since page 6, when the solenoid T*a plots were first added

• quarter-turn runs of the system, spanning one full GPE interaction, are only exercising half of a full solenoid cycle, hence leaving solenoid 1 with more energy than solenoid 2 - which swaps around again at 180°, and then again at 270°, then 360° etc.; thus 1 full turn should probably be the minimum testing range to get the full picture of a cycle


...all we need to do is understand exactly how and why the two solenoid integrals are unequal over a given range of system angle, and we can really begin optimising it!

This may well mean we can ditch the solenoids and just use linear actuators.. or, ultimately, scissorjacks! 'Rotary solenoids' (motors) provide better fine control when the intention is to nail a target MoI, but if that objective is incidental to the real gain mechanism then we probably don't need micron-accurate radial translations..

The hypothesis seems consistent with a good few Bessler clues too, dunnit?

[MrVibrating]

OK let's have some fun.. test some of these predictions:

• let's try taking the above, known, run, as four discrete measurements at 90° intervals

As noted, i suspect that the solenoids are alternating between relatively higher vs lower energy states every quarter-turn, so let's take a look at how that 300 mJ evolves over the course of a full revolution; so for each sim, i'll be taking:

• actuators P*t

• discrete F*d for each solenoid

..and comparing these against net KE + elastic PE in the spring.

Each sim will cover 90° of system angle, at maximum frequency and 100 i-s/f (so might not complete all 4 this evening)..

Should be able to knock out 1 or 2 before bed tho..

[MrVibrating]

1st 90° @100 i-s/f:

acts = 39.87543338

sols = -0.00000272743

KE rise = 39.876778

diff = +0.00134734743 J



@ 1 i-s/f:

acts = 39.87072578

sols = +0.001890055

KE rise = 39.875834

diff = -0.006998275


The 100 i-s/f result takes around 4 hours..

..@1 is-f it's like 30 mins..

..but both results are about as close to unity as you can hope to get... the difference is still on the 'gain' side, but not enough to call it above noise..

This config, remember, was reporting a 300 mJ gain on a full cycle, so either it has to arise in the next 270° somehow, or else by spreading each 90° over all available memory we're eliminating the error..

Which will be great - then i can get on with some spin'n'brake tests - but let's see how the next three 90° runs pan out..

Starting the next one now, looks like it's gonna be one 90° run per night at this rate, but worth it for the accuracy..

[MrVibrating]

2nd 90° @ 1 i-s/f:

acts = 40.08801719

sols = -9.598998647

KE rise = 39.883967

diff = +9.394948457

F'ckin' nuts eh? How'dat happen!?

So do i continue, in the hope the next 90° will destroy that 9.4 J?

Or is the next 90° gonna create even more energy?


This is the same config that gained 0.3 J on a full turn..

..and when the first 90° of that same sim were zoomed in using all 32 thousand frames, it gained 0.1 millijoules...

..and now when the next 90° of that same sim are likewise spread across all 32k frames, we're seeing over 9 J pop out.

180° in, so far..

God only knows what the next 90° are gonna throw up..

Looks like reactive feedback has reached its limits at these freqs, at least for multiple integration steps per frame - you can see the rig vibrating if i-s/f > 1, and the plot lines are thicker - obviously dense vertical zigzag - however it still produces smooth fine lines for 1 i-s/f..

..and 9 J gains.

What the fuck's happening, folks?

The only difference between the last two runs is RPM's - the second picking up where the first left off - and sim frequency; the first 90° took 1.13 seconds, while the second only spanned 0.46 seconds, but both used all 32 thousand frames..

Did the first 90° settings hit some kind of accuracy sweet spot? Maybe i should try re-using that exact sim, re-enabling the sprung timing, and then, the s&b cycles? Will keep it on ice for now.. wanna see what the next 180° does..

[MrVibrating]

Right, i've only previously tested full turns, and quarter turns... never tested 180° until now..

So this run that made almost nothing the first 90° and then 9 J on the second 90° - forgetting for a moment what might happen in the next 90° - what'll happen if i just sim that run through 180° in one go?

Obviously, if that same 9 J falls out, that'd be insane, but at least self-consistent, right?

Trying it out now.. not holding me breath tho.. this has to be an error..


ETA:

OK here it is:

180° @ 1 i-s/f:

Acts = 79.75863493

Sols = -0.018780845

KE Rise = 79.760147

Diff = +0.020292915



So that 9 J was definitely error, and the rise in RPM cannot have been the source, leaving only the increase in sim frequency as the determining factor..

Obviously accuracy should improve with frequency, so the error is being cause by the MoI-control routine, and accumulates on a frame-by-frame basis, hence spanning the same range of angle over more frames increases the error, instead of decreasing it.

Bollocks eh.. is there a way to manage this error and still get some data from the spin'n'brake tests? Like, if i establish a baseline error for a given frequency with OB-only as above, and then run s&b tests at only that frequency, i should be able to deduct the known error from the results, no?

Or maybe do it the other way around - run the s&b tests, then disable them and re-run with OB-only, and then deduct the latter error from the former..?

This'll only bring any resolution of course if the result's negative - if instead it appears to gain significantly more energy than the OB-only baseline, we'll still have no way of knowing if we're looking at the same error, a different one, or a legit output..

A simpler MoI control routine would solve all this headache and uncertainty, but what's the form of that solution?

[johannesbender]

mrv. i never really looked at your sim before recently , but i downloaded the last one you uploaded.

i am not experienced enough to take serious with this sim , but it might be of value or not to mention that ,

i saw a coinstraint , pin , to the rim of the circle , that comes over from the right ,

when zoomed in , that does not seem to stay at its required relative location during rotation.

by the way what is the accuracy settings you think require , i might try out running on my pc if possible..

[MrVibrating]

The posted sims should be run at their default frequency - if you change frequency or number of integration steps per frame, you need to change the FFB multiplier accordingly or else they will not work.

Most of the sims posted are examples used for producing the maximum amount of data - ie. for intentionally running at the slowest-possible speed..

..so to run one at higher speed (so you can actually watch it in motion), try these examples:

• at 200 Hz and 1 integration step per frame, in 'FFB Multi' type '1e4'

• @ 1,000 Hz and 1 i-s/f, 1e6

• @ 10 kHz and above @ 1 i-s/f, 1e8 to 1e9

Raising i-s/f isn't recommended. Variable i-s/f especially..

Some components, incidental to the interaction, are intentionally hidden - such as four inactive actuators being used to meter the radial velocity of the weights. The 'sprung timing wheel' is the same size as the main 'OB axis' wheel, and overlaid coaxially. Navigating down through the layers requires using ctrl-f and ctrl-g to send bodies to back / front. Keep both the 'Properties' AND 'Appearance' windows open from the 'Window' menu, and click on any item to see what it is, what its appearance properties are (such as hidden or not), or else scroll through the drop-down list in the 'Properties' window, keeping an eye on the corresponding 'Appearance' settings for each item - it tells you which bodies any constraints are connected between, what constraints any 'point elements' belong to, etc.. Happy to answer any questions on specific items..

NB: also don't forget to increase the x-axis range of the meters if you raise 'no. of turns' - best to set them all to 'Auto' when playing around, and then reset them all back to "1" or whatever (y-axes too) when making any changes..