Inertial Impulse Drive - "impossible" they said

[etherflow]

Etherflow, if this works as you think, what percentage of a single 360 degree rotation should the device experience a 'forward' thrust? I presume the math can tell you that. I'm thinking about the CIP, if it really has a 98% propulsion efficiency, that would mean that nearly all of the rotational energy is being converted into forward momentum. Or does your idea only work in 'pulsed-mode', where during only a percentage of a 360 degrees would the device experience a forward momentum? Of course if that was the case, wouldn't action/reaction come into play? Fascinating nevertheless, especially since reading about the CIP.

[sprocket]

Attached is a very rough-and-ready attempt at simulating this with WM2D, not meant to prove anything. Gearing doesn't work with this setup as it would in real life, so I've opted for 2 separate motors. The yellow circle has a 'slot-joint' which allows the rotating assembly the freedom to slide up or down. Stuff isn't working here as it would in real-life with WM2D - the main drive-motor in this instance. This should slide with the rotating assembly as well, but it doesn't.

[etherflow]

why a slot joint?

Attached is a very rough-and-ready attempt at simulating this with WM2D, not meant to prove anything. Gearing doesn't work with this setup as it would in real life, so I've opted for 2 separate motors. The yellow circle has a 'slot-joint' which allows the rotating assembly the freedom to slide up or down. Stuff isn't working here as it would in real-life with WM2D - the main drive-motor in this instance. This should slide with the rotating assembly as well, but it doesn't.

[sprocket]

I would have thought that obvious - to graphically display its forward & backword momentum in 'real-time'. The displacment in the 12 o'clock direction should (you've said) be greater than that which would occur when the main drive swings to the 6 o'clock position.

But rather than ask the obvious, why not tell me what you find wrong with this, and/or offer a suggestion. Better yet, knock up your own simulation on WM2D.

Edit:
I guess I should have checked the following beforehand, but in my defence, it's been years since I've used WM2D. Attached is the way the slot-joint behaves with 'Gravity' enabled on WM2D but with no main-drive motor attached - as you would expect! However under the same conditions (ie. with gravity enabled) but with the main-drive motor attached, the rotor assembly remains locked in place, entirely uneffected by gravity. Naturally, I had gravity disabled in the first video, but presumed that the rotor assembly would behave 'naturally' in the slot-joint with the motor attached - ie. allow itself be dragged in the direction of its momentum. This it does NOT do - it is locked in position once the motor is attached!!! So the first video is null & void. I guess a real-life build is called for.

[etherflow]

no slot joint is needed to "graphically display its forward & backword momentum in 'real-time'".

I would have thought that obvious - to graphically display its forward & backword momentum in 'real-time'. The displacment in the 12 o'clock direction should (you've said) be greater than that which would occur when the main drive swings to the 6 o'clock position.

But rather than ask the obvious, why not tell me what you find wrong with this, and/or offer a suggestion. Better yet, knock up your own simulation on WM2D.

Edit:
I guess I should have checked the following beforehand, but in my defence, it's been years since I've used WM2D. Attached is the way the slot-joint behaves with 'Gravity' enabled on WM2D but with no main-drive motor attached - as you would expect! However under the same conditions (ie. with gravity enabled) but with the main-drive motor attached, the rotor assembly remains locked in place, entirely uneffected by gravity. Naturally, I had gravity disabled in the first video, but presumed that the rotor assembly would behave 'naturally' in the slot-joint with the motor attached - ie. allow itself be dragged in the direction of its momentum. This it does NOT do - it is locked in position once the motor is attached!!! So the first video is null & void. I guess a real-life build is called for.