Gotmachine

[1.7] MandatoryRCS 1.7 & Part Pack 1.4 - Reaction wheels nerf, SAS & rotation persistence

Recommended Posts

19 hours ago, Gotmachine said:

Any plugin that use its own attitude PID controller and disable the stock SAS (MechJeb, TCA, KOS...) will cause reaction wheels to be permanently in the "realistic very low torque mode".
Unfortunately adding support for all those plugins would require a lot of hacking into their code at runtime, which is a lot of work and is likely to break anytime those plugins are updated.
Moreover the plugin is fine-tuned against the stock PID controller to prevent the torque output variations from making the algorithm act too weirdly, that would have to be done differently for each custom PID.

kOS uses KSP's own API call to query "how much torque can the vessel do right now if you pushed the controls to their max Yaw?  How about their max Pitch?  How about their max Roll?"  KSP has such a built-in API call that runs through summing up all the torques of all sources, such as reaction wheels, rcs blocks, and gimbals (multiplied by current engine throttle, so the gimbal is properly nerfed if throttle is low right now).  Then kOS uses the result of this to choose what PID gains to use.

So hypothetically it should work okay with your mod, provided your mod alters the reaction wheel's abilities in a manner that KSP's own API call can "see", trough tweaking the stock variables to new values.

(One place where KSP's API call is screwing up kOS is that when someone sets a reaction wheel to "SAS only mode", then it's NOT available to the autopilot control scheme, but *is* available to KSP's own internal steering with SAS, so their API call claims that torque is available for use (it is available, for *them* but not for us), causing kOS to choose bad values for its PID gains under the assumption that torque was usable.)

Share this post


Link to post
Share on other sites
5 minutes ago, Steven Mading said:

kOS uses KSP's own API call to query "how much torque can the vessel do right now if you pushed the controls to their max Yaw?  How about their max Pitch?  How about their max Roll?"  KSP has such a built-in API call that runs through summing up all the torques of all sources, such as reaction wheels, rcs blocks, and gimbals (multiplied by current engine throttle, so the gimbal is properly nerfed if throttle is low right now).  Then kOS uses the result of this to choose what PID gains to use. 

Indeed KOS (and others) will work fine, as in "they won't throw errors or become inaccurate".

3 minutes ago, Steven Mading said:

(One place where KSP's API call is screwing up kOS is that when someone sets a reaction wheel to "SAS only mode", then it's NOT available to the autopilot control scheme, but *is* available to KSP's own internal steering with SAS, so their API call claims that torque is available for use (it is available, for *them* but not for us), causing kOS to choose bad values for its PID gains under the assumption that torque was usable.)

That is the point. MandatoryRCS override the reaction wheels torque output (and consequently the "what torque is available ?" API call) based on the stock SAS selected mode and the control inputs. Basically, the "full torque" is only available when the SAS is in a specific state.

The reason is that the reaction wheels should only be in full torque mode when the PID controler (SAS) is killing the angular velocity (stabilizing the vessel), and in low torque mode when there is an attitude input request either from the SAS, the pilot or any other plugin playing with the inputs.
To achieve that, I need to know the state of the PID controller, specifically the orientation it is currently trying to achieve. In stock I'm doing that by reading the SAS mode and checking if the request orientation is "near".
To support others PID controllers, I would need to detect when they are active and read their own implementation of the "attitude modes". For KOS, I could probably read the value of "expression" when the "LOCK STEERING TO expression" instruction is used, but it would likely introduce new balance considerations that I'm unwilling to deal with.

So for now, deactivated stock SAS = reaction wheels always in low torque mode.

Share this post


Link to post
Share on other sites
1 hour ago, Gotmachine said:

To support others PID controllers, I would need to detect when they are active and read their own implementation of the "attitude modes". For KOS, I could probably read the value of "expression" when the "LOCK STEERING TO expression" instruction is used, but it would likely introduce new balance considerations that I'm unwilling to deal with.

Yes but does it achieve that "low torque mode" by actually adjusting the torque value the reaction wheel claims to have when the API asks?  The kOS PID is constantly re-checking the vessel torque every FixedUpdate to see if it changed.  (It has to because, for example, fins have less effect when the air gets thinner, and engine gimbals have less effect when the throttle is lower.  It needs to keep re-checking and picking new tuning values again and again.)

It could be possible to expose the "angle error" value in kOS.  It's an angle between the desired direction and the current direction, which a script can read, so we could put that into an API.  It could also be possible to simply expose the most recent result of the lock steering expression as it was calculated to be on the most recent FixedUpdat.  That result would be a Unity Quaternion describing the desired orientation (with the resulting "Z" axis of that rotation being the way to point the vessel nose and its "Y" axis being the way to point the vessel "roof".  Using that result you would know how far off the error is and you could use that to decide what you want to do with the torque wheel.

Share this post


Link to post
Share on other sites
8 minutes ago, Steven Mading said:

Yes but does it achieve that "low torque mode" by actually adjusting the torque value the reaction wheel claims to have when the API asks?

I already responded, yes. ITorqueProvider.GetPotentialTorque() will return the torque as adjusted by MandatoryRCS. Otherwise the stock SAS PID would also have a very hard time

As a matter of fact I already tried adding support for MechJeb (which can optionally use the same PID controller as KOS) and TCA and that's why I'm confident when I say that supporting others PID implementations is problematic.
The thing is : the KOS PID controller don't like huge swings in the available torque. In many situations it simply is not able to handle it, resulting in an uncontrollable vessel.
This is an even bigger problem than with others "fixed mode" controllers because it's very likely that it is used by continuously updating the desired orientation, which mean that those torque swings will be "perpetual".
And also, this simple fact make the whole strategy used by MandatoryRCS inapplicable. For the nerf to work, I need to know the angle error, but also the "final intention" to differentiate a slow attitude change control output from a stability correction control output. In both case, the angle error is small.

In comparison, the stock PID fares much better because it don't rely much on the ITorqueProvider.GetPotentialTorque() results. The "torque nerf" is fine-tuned against it : I'm actually lerping the torque changes and I use a few tricks to avoid issues, but it still is quite negatively affected.
As for the MechJeb PID controller, it is very efficient in most situations (it can be slightly better than the stock one) but it can struggle to achieve a stable state in many cases, and it also struggle in aerodynamic intensive situations.
The (new) TCA attitude controller performs very well in every situation, it's probably the best non-specialized PID code.

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, Gotmachine said:

And also, this simple fact make the whole strategy used by MandatoryRCS inapplicable. For the nerf to work, I need to know the angle error, but also the "final intention" to differentiate a slow attitude change control output from a stability correction control output. In both case, the angle error is small.

What does "in both cases, the angle error is small" mean?  It sounds like we're talking about two different things entirely, since the angleerror I'm talking about would be small in one case and large in the other.  (Small if pointed at the "final intention" already, or large if not yet.)

One thing that *would* be a problem would be that you couldn't detect what the *script* is doing.  It might instruct kOS to steer in a successive series of slightly altered steering targets.  (i.e. lock steering to some expression that gives a slightly new value every update, like lock steering to heading(90, 90-0.5 * elapsed_time)). If the script does that, then kOS wouldn't even know it was doing it, so it could fool your algorithm into thinking it was doing "Stability assist" the whole time because each FixedUpdate the new direction isn't very different from the previous one.  While you absolutely could detect kOS's "final intention" (steering target), you couldn't detect what the *script's* final intention is when it keeps slightly nudging kOS's steering target a little at a time.

Edited by Steven Mading

Share this post


Link to post
Share on other sites

Yes, that is what I was talking about. I can't predict the logic implemented by the user and that could make the nerf rules inconsistent.
But now that I'm thinking about it, it's not that much of an issue as those small increments would still probably always be in a station keeping intent, even if the station keeping is using a slow-moving reference.
After all the mod currently allow it when using the various stock SAS references.

The real issue is that the KOS PID controller is not very good at achieving a stable state. Combined with the fact that it very sensitive to available torque changes, I'm pretty sure that would lead to major stability issues.
At least this what I remember from the testing I did way back using the MechJeb version of the KOS PID controller.

Share this post


Link to post
Share on other sites

Theorycrafting is fun and all, but wouldn't it be more informative to just.. let kOS perform rotation towards a SAS vector and then see if it 'snaps' to the SAS marker like it does without kOS? If it works as desired then kOS won't really be able to move the ship much towards that vector without RCS, but when it arrives, it'll 'magnetically' snap towards it.

Share this post


Link to post
Share on other sites
On 5/23/2019 at 4:57 PM, Gotmachine said:

There are definitely some bugs when using the latest version (1.5)  in KSP 1.6, and even more with KSP 1.7.
I will try to properly update the plugin (and the part pack) someday, but for now I have other things on my plate.

In the meantime, you can try to replace the dll in GameData/MandatoryRCS by this one : MandatoryRCS-1.5-HOTFIX-KSP-1.7
It's just a recompile but I know it fixes (some of) the nullref spam, and a few other quirks.

Checking back in: Got another 10.000+ NullRefs during re-entry just now so the recompile didn't fix that one. I'm not sure of how to reproduce it since a probe I sent up and re-entered did so just fine. The only thing the two nullref floods had in common was staging multiple times and several probecores on board.

Output log: https://www.dropbox.com/s/r61lgadiw8qalzm/output_log.zip?dl=0 (if it matters)

I got several nullrefs before the re-entry as well, still looking what caused those, nullrefs are a bit of a common occurence for some reason..

Share this post


Link to post
Share on other sites

@JogntPlease try the latest release. And thanks for your log, although I can't reproduce the issue it helped in figuring what was (probably) happening.

Share this post


Link to post
Share on other sites

Is there a way to tell the persistent rotation module of this mod to stop when in atmosphere all the time (like with early sounding rockets)?

The spin never stops until the upper stage finally touches the ground.

Shouldn't there be kinda friction to the atmosphere?

 

Or is this so stock that this mod can't do anything about it?

Share this post


Link to post
Share on other sites

This is correct behavior. If you spin up a cylinder in atmosphere without any kind of bearing, it will keep spinning. At low RPM, the skin drag is small. Check out "levitron" magnetic levitation toy. They have no bearing friction, so they can spin for a long time. Same applies to a sounding rocket payload, unless it's falling by parachute.

Share this post


Link to post
Share on other sites

Well, when the whole thing is braked down by chute deployment, the spin still occurs and also the orientation of the spinning cylinder like it's a powerful reaction wheel / gyro.
So the cylinder is going downwards, but still oriented somehow sideways. And this with let's say 30 rpm.

Share this post


Link to post
Share on other sites
Posted (edited)

@Gordon Dry This is stock behavior. MandatoryRCS has zero influence on atmospheric flight physics. It only apply angular velocity to vessels that are in space in non-physics timewarp.

Edited by Gotmachine

Share this post


Link to post
Share on other sites
Posted (edited)

I seem to have found either a bug or some sort of conflict.. Command Pods seem to be unaffected by that feature that makes them not listen to SAS/input as they still stop moving just fine if I enable stability mode.
Before I give you a log filled with a several hours long session; Any specific actions you would like me to take?

Edited by Jognt

Share this post


Link to post
Share on other sites
On 5/4/2019 at 5:05 PM, KSPrynk said:

@Gotmachine,

I've confirmed the RV-105 Variant cfg files are pointing to a dead end for their textures.  KSP 1.7 did away with the old LinearRCS subfolder and now there are two new RCS Block subfolders.  The Squad revamped RV-105 is in one folder, but they also created a new folder with the old part, presumably in deprecation.

A quick fix is to edit all the RV-105 Variant cfg files with the following in the MODEL section:

texture = rcs, Squad/Parts/Utility/rcsBlockRV-105/rcs

This points to the old rcs.dds file in the new path name for the deprecated part.  As far as I can tell, it works just fine with this edit.

Just for fun, I tried pointing to the new part's diffuse texture, but it turned into an unholy mess.  The long term fix is all the RV-105 Variants likely need to be redone to match up with the new textures and effects that come with the revamped Squad model.

I tried this but it doesn't seem to work at all :(

Share this post


Link to post
Share on other sites
Posted (edited)
On 6/27/2019 at 3:29 AM, Jognt said:

Command Pods seem to be unaffected by that feature that makes them not listen to SAS/input as they still stop moving just fine if I enable stability mode

Stabilization when in stability mode is always available, even for command pods, this is intended. What is not available is pilot or SAS attitude changes, but even stability keeping when already "locked" on a SAS target (like prograde) is always available. The intent is to force you  to use RCS for orientation changes while benefiting from the reaction wheels for stabilization.

17 hours ago, subyng said:

I tried this but it doesn't seem to work at all :(

Maybe you are using ReStock ? I just released version 1.3 that should fix ReStock compatibility.

Edited by Gotmachine

Share this post


Link to post
Share on other sites
Posted (edited)

I dont see a wheel authority slider and my cockpit can orient itself (torque) without the rcs enabled. its weired. I have the mod installed on ksp 1.7.1

I dont even want the wheel enabled and I dont see how can I disable it. I thought this mod would allow that given its name but oh well...

Edited by Agustin

Share this post


Link to post
Share on other sites
On ‎7‎/‎13‎/‎2019 at 9:12 AM, Gotmachine said:

Stabilization when in stability mode is always available, even for command pods, this is intended. What is not available is pilot or SAS attitude changes, but even stability keeping when already "locked" on a SAS target (like prograde) is always available. The intent is to force you  to use RCS for orientation changes while benefiting from the reaction wheels for stabilization.

Maybe you are using ReStock ? I just released version 1.3 that should fix ReStock compatibility.

 I am using Restock but I am also using  the latest version of this mod. 

Share this post


Link to post
Share on other sites

Hi Gotmachine....

I am enjoying your parts pack and mod.

I'm using sounding rockets mod currently and noticed that there is a missing part that would be super helpful.

A 0.35m mono-propellant tank that is in line would be great.

If you update the parts any time could you add one in at the same time on the parts tree as the mini thruster blocks for those more slim rockets?

Cheers...

Thanks for all your good stuff.

Share this post


Link to post
Share on other sites

Love the mod @Gotmachine! Thanks for your hard work.

On smaller vessels I find myself missing a four-way micro RCS block, i.e. a micro equivalent of the RV-105, or following the naming of your other parts, a part that would be named 025T_2xlateral_1xup_1xdown. Is there a reason this part was omitted?

On some craft it makes sense to have one set of RM-025-IL at one end of the vessel, and another set rotated 180° at the other end. However for smaller probes I'd prefer to just have a set of four-way RM-025 around the COM.

Hope this makes sense. Thanks!

Share this post


Link to post
Share on other sites

Looking for feedback from users - anyone tried running the 1.7.x version in 1.8? Any crashing, nullrefs...?

Share this post


Link to post
Share on other sites

@fourfa using 1.7.0.0 on KSP 1.8.1 without issues so far - but ofc could need a recompile as every mod does because of the Unity change.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.