Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Rotor Dynamically Unstable

Discussion in 'Gameplay Help' started by warriorheadlol, Oct 15, 2017.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. warriorheadlol Trainee Engineer

    Messages:
    4
    Ok first post in 570 hrs of play. Love SE but hate how things constantly go wrong, spend hours building something for them to then explode on you.
    My current problem is that the rotors appear to be dynamically unstable at the moment when motion is perpendicular to the axis of rotation.
    I have a rotor, aligned so that the axis of rotation is horizontal with some solar panels attached. A command is given to move the rotor to track the sun, by changing the velocity, then the rotor velocity is set to zero to stop. However the rotor head (and attached parts) starts to bounce vertically, at first just a little, then it quickly builds to the point of destroying everything and exploding. I have experimented with changing the torq settings but this does not seam to matter, nor should it. This motion is perpendicular to the axis of rotation. I can lock the Rotor to stop the movement but once unlock the bouncing starts up again. In fact the effect is worst after safety locking the rotor. In reality this system should not continue to amplify in magnitude but find a new equilibrium where the rotor, if so kind to move perpendicular to the axis of rotation, bent downwards.
    Does anyone have any suggestions to fix this in my design or is this something else that keen has failed on?
    Has someone made a mod rotor that doesn't have this useless dynamic behavior and is locked to motion in the rotor's axis only?

     
  2. Sinbad Senior Engineer

    Messages:
    2,788
    rotor deflection (and pistons as well) is a problem. generaly it means you have overloaded the part. while I agree that a 1meter wide shaft just shouldn't bend, and 2 meter bearings shouldn't wobble, the way the physics and game engines interact is kind of strange. the physics engine supports joints. it manages them by getting an attachment location and an allowed plane or axis of motion from the game engine. it then looks for initial position information on the moving part. the game engine can then send force requests to the physics engine asking it to apply torque to an axis or linear force to a plane. any forces applied to the moving part that doesn't originate from the game engine on other axis or planes is passed on to the root object. this works very well and allows for complex objects with multiple constrained joints all acting on each other, all with very little direction from the game engine.
    what it seems ksh has done is to use unconstrained joints in rotors and pistons, and instead of letting the physics engine do its work they have the game engine do all the motion calculations. they then send position updates to the physics engine rather than force requests. so what happens with your rotor is the game engine tells the physics engine there is a joint at x,y,z. then it tells it there is an attached object at xyz and XYZ orientation and it has mass. the physics engines deosnt see any constraints on the joint, so it applied outside forces like gravity and acceleration, this makes the attached part sag. the game engine sees the sag and updates the position and orientation of the object, which the physics engine then applies gravity to...
    the constraints seem to coming from the game engine in the form of position updates rather than the physics engine as a property of the joint. this wouldn't be so much of a problem if the calculation steps were seamless. but they are not. the three engines, game, physics, and graphics run their calculations 60 times a second of in game time. that means the physics engine applies 1/60th of a second worth of gravity and aceleration induced motion. the higher these forces, the more motion is applied. the deflection you are seeing is the result of this as the physics engine runs after the game engine but before the graphics engine. basically: object placed, object falls, object rendered, object replaced in original position, object falls, object rendered. over and over. when the game engine corrects the position back to where it should be for a constrained joint the motion is forceless. thats where the strange phantom forces come from that can send a ship with a rotor on it spiraling into the void. there is a recipocating motion that applies force in only one direction, but we can't see both positions because of the order of execution.
    its not an easy fix. it would need a re-write of the way the game engine utilises the physics engine so its not micromanaging the location of every object.
     
    • Informative Informative x 2
  3. ViroMan Senior Engineer

    Messages:
    1,123
    I have the exact same problem... my solar panels kill themselves or me if I get close. :(
     
  4. Sinbad Senior Engineer

    Messages:
    2,788
    A work around fix is to spread the load over multiple rotors. I usualy make a wishbone for joints that dont need to go 360deg.
    Alternatively, make more than one solar array. Keep them small enough that you dont have an issue.


    How to wishbone:
    1 stack 2 blocks on top of each other, like a stumpy post.
    2 put a rotor on one side of the top block
    3 put a second rotor on the other side of the top block, remove its head
    4 power it, or increase the braking torque of the first rotor.
    5 add a block to the head of the first rotor
    6 put two more blocks on top of the last one, so its a 3 block tall stick pointing up
    7 from the top block of the stick you just built, add 4 more blocks going back over the top of your stumpy post
    8 from the last block of the last step, add two blocks downwards so it lines up with the second rotor
    9 add a rotor head (from the g menu, not the button in the system panel) to the inside of the last block you placed.
    10 on the first rotor, adjust the offset to the minimum value
    11 on the second rotor (should be the un attached one) set both torque sliders to zero
    12 also on the second rotor, click attach then immediatly set the offset to the minimum value
    13 thats it. Rotor one drives the joint, rotor two just shares the weight.
    14 you may want to set up upper and lower limits on rotor one to stop your panels crashing
    For a small grid version, use an offset of 7mm (right click the slider and enter it manually)
    Ive got one of these sitting on top of an azimuth rotor to align it east to west. A rate of 0.0083 rpm will follow the sun on a 2 hour day setting (default). You do need to send it back to the start before morning though, but if you have the limits set up you can use the increase/decrease rpm setting on a button or timer as it will keep the sun tracking rate and just add or subtract 3rpm to it, you wont be able to get it back to zero rpm with the increase/decrease rpm settings, though you can with reset.
    The other option is to script it.
     
  5. warriorheadlol Trainee Engineer

    Messages:
    4
    It is currently run by using a script. I think that I may need to code that not only does the velocity change but that after a move the rotor safety lock comes on.
     
  6. warriorheadlol Trainee Engineer

    Messages:
    4
    Thanks to Sinbad for the descriptions of the inner workings of SE, true or not it helped a lot. I decided to fix the project by including safety locking within the code. Now the rotor is unlocked, moved and then locked again. This doesn't remove the instability but hides it. So if for some reason the program was stopped and the rotor unlocked. The array would still destroy itself. However now it doesn't. Note that in the video I added alot of mass blocks to the end to see how far I could push it. Compared to the first video, its a big improvement. Now the rotor is starting to reach the point that it can't move such a large mass.

     
    • Like Like x 1
  7. ViroMan Senior Engineer

    Messages:
    1,123
    I forget if grav gens work in planet gravity. It could be nice if you could plop down 4 grav gens pushing up, attach a few mass blocks, and use them to prop up massive solar panels.
     
  8. REDSHEILD Junior Engineer

    Messages:
    888
    They work on the moon, but not on any of the planets.
     
    • Informative Informative x 1
  9. warriorheadlol Trainee Engineer

    Messages:
    4
    ViroMan, Ill upload my code when I'm happier with it. Probably in a month after exams. It has a few other features and I'm trying to make it a bit more automated in setting up. The way I write the code is with lots of smaller methods so it's easy to pull apart and use for other things.
     
    Last edited: Oct 24, 2017
  10. ViroMan Senior Engineer

    Messages:
    1,123
    [​IMG]
    mlp because nothing starts flames better then mlp.
     
    Last edited: Oct 24, 2017
Thread Status:
This last post in this thread was made more than 31 days old.