Rotation Servo M-25 fails to move

[fulgur]

Note the discrepancy between Target Angle and Current Angle. It has been like this for a while now. This is stock (both DLCs) and the output log accessed from [ALT] + [F12] shows nothing.

(The ship has the working title of the Kenlinstar Awesum if you were wondering)

[HebaruSan]

Do you have Kerbal Joint Reinforcement installed?

[AHHans]

Or did you use autostruts onto or across the servos?

(Autostruts to "grantparent" that don't touch or go across a moving part seem to work fine for me.)

[traisjames]

I have a similar problem with hinges not moving when they should.  Autostruts turned off on all parts.

[AHHans]

On 6/23/2019 at 1:46 PM, AHHans said:

Or did you use autostruts onto or across the servos?

FYI: The autostruts issue should be solved in the latest version (KSP 1.7.3, BG 1.2). When a robotic part is not locked, then the struts stop at the part (and the part can still move), but when the part is locked then the autostruts can traverse the robotic part (like it was a normal, non-robotic part).

If it doesn't work for you that way, then you may need to let SQUAD know about that.

[traisjames]

On 8/14/2019 at 2:45 AM, AHHans said:

FYI: The autostruts issue should be solved in the latest version (KSP 1.7.3, BG 1.2). When a robotic part is not locked, then the struts stop at the part (and the part can still move), but when the part is locked then the autostruts can traverse the robotic part (like it was a normal, non-robotic part).

If it doesn't work for you that way, then you may need to let SQUAD know about that.

Yea I am still having trouble with it...even going vanilla...I thought this was how you let SQUAD know

[AHHans]

1 hour ago, traisjames said:

Yea I am still having trouble with it...even going vanilla...I thought this was how you let SQUAD know

A) Not good...

B) Well, adding a posting to a thread that was started before a major patch of the issue is less likely to be noticed than either a new topic, or - even better - a new issue on the bugtracker. It would help even more if you could supply a craft that reliably shows this problem.

Edit: You can find the bugtracker here: https://bugs.kerbalspaceprogram.com/

Edited August 31, 2019 by AHHans

[traisjames]

17 hours ago, AHHans said:

A) Not good...

B) Well, adding a posting to a thread that was started before a major patch of the issue is less likely to be noticed than either a new topic, or - even better - a new issue on the bugtracker. It would help even more if you could supply a craft that reliably shows this problem.

Edit: You can find the bugtracker here: https://bugs.kerbalspaceprogram.com/

Ok, posted a bug at https://bugs.kerbalspaceprogram.com/issues/23492.  There are two craft that reliably show the problem...especially the first one.

[AHHans]

15 hours ago, traisjames said:

Ok, posted a bug at https://bugs.kerbalspaceprogram.com/issues/23492.  There are two craft that reliably show the problem...especially the first one.

. o O (Not the most streamlined crafts to show that issue, but fine.)

O.K. I spend the odd hour trying to figure out when the damn things freeze up and when they do not. The short answer seems to be that if there is no autostrut set on a robotic part then it also doesn't freeze up. I.e. if you only set autostruts on non-robotic parts, then you should be fine. (Which explains why I haven't encountered this bug earlier.) When you do set an autostrut on a robotic part then there is a chance that it freezes up:

• if there is another not-locked robotic part between it and the root part of the vessel, then it will freeze up.
• if there is no non-locked robotic part between it and the root part of the vessel, and the autostrut goes in the direction of the root part, then it will not freeze up
• if there is no non-locked robotic part between it and the root part of the vessel, but the autostrut goes to a "heaviest part" on the "other" (non-root) side, then it will freeze up

That last part can get really complicated, because the decision which part is actually the "heaviest part" gets more complicated than I want to explain here...

[BlondMartinez]

i’m seeing this too; working to try and use servos to rotate jets to make a VTOL SSTO. They either spontaneously disassembly immediately on loading, or the servos won’t turn (or, my favorite, one of the servos won’t turn). Super frustrating.

[DanielKernoulli]

I am still having this issue. Has anyone found a fix yet? I have autostrut off on everything and I can only get one of the servos to turn even after disabling symmetry. It seems to work when I allow full rotation but when I set a rotation limit one works fine and the other won't turn at all. Super frustrating.

[Gavin786]

Confirm that there is a bug with rotation servos.

 

Was about to come on here and make a similar post to OP.

 

Bug is repeatable.  Steps : 1. On any surface, place a rotation servo with Mirror Symmetry.  2. Change the servo from "full rotation" to a restricted rotation(0,90) for example.  3. Run the design.  4.  Change "target angle" on the ship.  One of the servos will not turn its full rotation(or not at all).

 

Can confirm designs built/updated on 1.8.1 still work, and symmetry works as intended.  New robotic designs that require symmetry can no longer be built.

 

Gavin786

 

EDIT: I can see ppl are confusing this bug with the autostrut bug, they are NOT the same bug, two separate bugs, so I am going to make a new post now.

Edited June 11, 2020 by Gavin786

[AHHans]

1 hour ago, Gavin786 said:

One of the servos will not turn its full rotation(or not at all).

Yes, that seems to be a new(-ish) bug. But a workaround is also rather straight-forward: set the servo-limits to be symmetric around 0. E.g. instead of (0, 90) do (-90, 90). Then both servos will rotate the full range.

[Gavin786]

36 minutes ago, AHHans said:

Yes, that seems to be a new(-ish) bug. But a workaround is also rather straight-forward: set the servo-limits to be symmetric around 0. E.g. instead of (0, 90) do (-90, 90). Then both servos will rotate the full range.

Thank you man, if that workaround works, its gonna save me so much.  I suspect it will.  Maybe the reason my 1.8.1 designs worked, as they ARE symmetric around the 0.0.  I have been crawling round the craft files checking for differences between the two versions and could not find anything.  This looks like the right solution/work around.

[AHHans]

24 minutes ago, Gavin786 said:

Maybe the reason my 1.8.1 designs worked, as they ARE symmetric around the 0.0.

Well, my 1.8.0 VTOL has servo range of (0, 90) and still works fine. So that is not the reason that old designs work.

[Gavin786]

7 hours ago, AHHans said:

Well, my 1.8.0 VTOL has servo range of (0, 90) and still works fine. So that is not the reason that old designs work.

I did find another solution to the problem : edit the craft file, and make these changes : 

EDIT: There does seem to be a workaround to this if you edit the craft file.  Change the ModuleRoboticRotationServo section and mirrorRotation from True to False, and inverted from False to True.  Parts then work correctly in the editor also.  Make sure you choose the right robotic part if you do this, editing craft files is not for beginners.
MODULE
    {
        name = ModuleRoboticRotationServo
        isEnabled = True
        softMinMaxAngles = (0, 90)
        allowFullRotation = False
        targetAngle = 0
        inverted = False   <- Change from True to False
        mirrorRotation = True <- Change from False to True
        traverseVelocity = 90
        hingeDamping = 100
        previousTargetAngle = 0
        servoIsLocked = False
        servoIsMotorized = True
        jointParentRotation = 0,0,0,1
        servoMotorIsEngaged = True
        launchPosition = 0
        servoMotorSize = 100
        servoMotorLimit = 100
        lockPartOnPowerLoss = True
        servoTransformPosition = 0,2.2382096E-15,1.36598084E-08
        servoTransformRotation = 0,0,0,1
        useMultipleDragCubes = False
        stagingEnabled = True

There are probs with this, that if ever the servo needs to be moved and placed again, the bug will re-appear.  There are also problems with attached parts to the servo jumping around after re placing the servo.  IF it is left alone after placement, should work tho.

Even with this, it is a serious pain in the ass, and for anything serious that needs more complex symmetry(like pretty much all of my designs), can pretty much forget it, need to go down to previous version(which is prob my best bet), or wait till SQUAD fixes it(which I *HOPE* they will, the debacle of KSP2 notwithstanding).  

Had a swing-wing variable geometry space plane been playing with for a while and going to put my new plane making skills to, looks like that is on hold now.  It is just too frustrating making each wing out of symmetry + there is some kind of imbalance somewhere and seriously hard to hunt down even with RCS build aid.

Was also going to make an ornithopter.  No ornithopter for me now I guess :-(

Please fix it SQUAD, pretty please with sugar!  Kerbals are counting on you!

And there is still the mystery of why older designs work.  I have scoured the CRAFT files now, for a long time and can see absolutely nothing that might indicate a relevant change between versions, except maybe the meta header?  I can keep hunting it down, but prob would need the working + non-working versions installed simultaneously, so I can find the change that makes the difference.  Probably something very subtle somewhere.  Would be *MUCH* better if its just fixed in 1.9.2.  

Gavin786

[Douba]

On 6/12/2020 at 2:02 AM, Gavin786 said:

I did find another solution to the problem : edit the craft file, and make these changes : 

EDIT: There does seem to be a workaround to this if you edit the craft file.  Change the ModuleRoboticRotationServo section and mirrorRotation from True to False, and inverted from False to True.  Parts then work correctly in the editor also.  Make sure you choose the right robotic part if you do this, editing craft files is not for beginners.
MODULE
    {
        name = ModuleRoboticRotationServo
        isEnabled = True
        softMinMaxAngles = (0, 90)
        allowFullRotation = False
        targetAngle = 0
        inverted = False   <- Change from True to False
        mirrorRotation = True <- Change from False to True
        traverseVelocity = 90
        hingeDamping = 100
        previousTargetAngle = 0
        servoIsLocked = False
        servoIsMotorized = True
        jointParentRotation = 0,0,0,1
        servoMotorIsEngaged = True
        launchPosition = 0
        servoMotorSize = 100
        servoMotorLimit = 100
        lockPartOnPowerLoss = True
        servoTransformPosition = 0,2.2382096E-15,1.36598084E-08
        servoTransformRotation = 0,0,0,1
        useMultipleDragCubes = False
        stagingEnabled = True

There are probs with this, that if ever the servo needs to be moved and placed again, the bug will re-appear.  There are also problems with attached parts to the servo jumping around after re placing the servo.  IF it is left alone after placement, should work tho.

Even with this, it is a serious pain in the ass, and for anything serious that needs more complex symmetry(like pretty much all of my designs), can pretty much forget it, need to go down to previous version(which is prob my best bet), or wait till SQUAD fixes it(which I *HOPE* they will, the debacle of KSP2 notwithstanding).  

Had a swing-wing variable geometry space plane been playing with for a while and going to put my new plane making skills to, looks like that is on hold now.  It is just too frustrating making each wing out of symmetry + there is some kind of imbalance somewhere and seriously hard to hunt down even with RCS build aid.

Was also going to make an ornithopter.  No ornithopter for me now I guess :-(

Please fix it SQUAD, pretty please with sugar!  Kerbals are counting on you!

And there is still the mystery of why older designs work.  I have scoured the CRAFT files now, for a long time and can see absolutely nothing that might indicate a relevant change between versions, except maybe the meta header?  I can keep hunting it down, but prob would need the working + non-working versions installed simultaneously, so I can find the change that makes the difference.  Probably something very subtle somewhere.  Would be *MUCH* better if its just fixed in 1.9.2.  

Gavin786

Thank you so much!
This will teach me to not use symmetry when attaching moving parts in the future.

In my case, I had to change three instances of True/True to False/False to make it work. Logically, both should result in the same rotation direction, but it resulted in a non-moving servo.

While the "inverted" parameter corresponds to the "Invert Direction" toggle in the editor, there doesn't seem to be any editor representation of the "mirrorRotation" parameter. I suppose it is set on part attachment with symmetry to prevent problems with mirrored symmetry on parts like wheels where expected dynamic behaviour is not to be mirrored. Removing parts from symmetry does not affect this parameter.