Jump to content

[0.23.5] TweakableGimbal (V0.2.1 release: Jan 18, 2014)


HoneyFox

Recommended Posts

Hi, there're several types of gimbal extensions already, but i still write this little plugin and i think utilizing the tweakable system is good for users to have more control.

It provides:

Control coefficients on all three axes. Including reverse control. This allows single-axis gimbal to be achieved to emulate some of these vernier thrusters in RL, and allows roll control capability when using twin engines that have all-direction gimbals or with 4 single-axis vernier thrusters.

Max gimbal angle tweaking during flight.

Test capability in VAB/SPH.

RollControl.png

Roll control by these two engines.

TweakablesofGimbal.png

The tweakables. It has test capability so you can check if your settings are correct in VAB/SPH. (some new options are not displayed in this screenshot)

VernierThrustersYawCmd.png

Single-axis vernier thrusters. Yaw command is given and only two of them are tilting.

VernierThrustersCCRollCmd.png

The same 4 single-axis vernier thrusters. Clockwise Roll command is given. Watch how these thrusters turn.

VernierThrustersPitchUp.png

Two of these four vernier thrusters taking pitch-up action with the main engine that has no TVC capability.

Download link:

V0.2.1

https://www.dropbox.com/s/pzh84u9brz94ow7/TweakableGimbal%20V0.2.1.zip

Source:

https://github.com/HoneyFox/TweakableGimbal/

Light User Note

If you don't want so many options for tweaking, you can try the light-weight version of TweakableGimbal (it provides GimbalRange & ReverseControl function) comes within TweakableEverything mod made by toadicus. His/Her mod also provides lots of tweakable options in other modules like solar panels, docking port, etc.

Link is here:

http://forum.kerbalspaceprogram.com/threads/64711-0-23-TweakableEverything-For-all-your-part-tweaking-needs

NOTE of compatibility issue

Do NOT install both TweakableGimbal plugins in your KSP, choose the one you want and delete the other one.

If you choose to use my plugin while you still want other functionalities provided by TweakableEverything, toadicus designed his/her mod so that these are separated libraries for different types of PartModule. Thus you can pick the "TweakableGimbal" one out of them and delete it.

Changelog:

V0.2.1:

Fix a bug which occurs if you're not launching the rocket from VAB.

V0.2:

Change the coordinate system of attitude input/output so that it can now work well with symmetric parts.

Gimbal range becomes tweakable.

Reverse control becomes available if the related coefficient is non-zero during flight.

A README file containing several useful hints is provided. It can easily achieves: roll control & single-axis vernier thrusters.

V0.1:

Initial release.

This plugin uses Module Manager to automatically add the module into all parts that has "ModuleGimbal".

Edited by HoneyFox
Tested in ARM
Link to comment
Share on other sites

Does reverse control make puller-configuration engines gimbal properly?

Should be working if you set proper coefficients & reverse options into them.

Currently these tweakables are only available in VAB/SPH, i guess it might be better to allow user to control these "Reverse" toggles during flight too...

One more tweakable that i'm currently trying to add is the maxGimbalRange, which i think will be quite useful if user doesn't want over-steering when using some engine that has quite large gimbal range (like KOSMOS' engines, they normally have 3~4 degrees of that, quite big compared to stock engines'). And this will also be tweakable during flight because IMO this is just a constraint to the flight control system instead of engine's capability limitation.

EDIT: Ah, the TweakableEverything plugin seems to already have GimbalRange and GimbalLock as tweakables, I wonder if it's necessary to do that again.

Edited by HoneyFox
Link to comment
Share on other sites

This seems like a nice improvement over the stock engine control system. Though I'm curious what the difference is between the V coefficient and H coefficient. For example, what's pitch coefficient V vs pitch coefficient H? I looked through the readme, but sadly that didn't really answer my question.

Link to comment
Share on other sites

Just discovered a potential bug, or a couple, actually.

EDIT - This is wrong

1. The yaw/pitch axis is determined by whichdirection the craft is facing in the VAB, rather than the orientation of thecommand pod/root part. So if you rotate a craft in the VAB so starts in aposition to travel along the equator, pitch becomes yaw and vice versa. Isthere any chance you might make it consider the command pod or root partorientation, rather than the overall craft's position in the VAB when assigningaxis?

As anexample, I have a shuttle that I have oriented so I can simply pitch over immediatelyafter liftoff so as to avoid having to do a roll maneuver. However, since it'srotated in the VAB that results in the yaw and pitch axis switching places.

2. A number of engines have gimbal ranges that aren't rounded to the nearest tenths. For example, the KW Rocketry Vesta has a gimbal range of .75. Unfortunately, the way tweak ables works, it cuts off that final .05 and limits it to .7 degrees of gimbal range. This isn't huge, but it could probably be fixed by making the tweak able slider operating in .05 increments.

3. Also, it appears that there's a very good chance that the engine gimbaling won't function if you revert to the launchpad.

1. Okay, I figured out what's actually going on. I initially though it was based on the alignment of the craft relative to the VAB. In fact, it's actually relative the the engine's alignment to the craft. If you rotate an engine 90 degrees, for example, its pitch axis will actually become it's yaw axis, and vice versa. This isn't as bad as I thought initially, but it is something to keep in mind. I do think it might be better to have a fixed reference point for all engines, such as the root part's orientation. I'm also not sure how this affect's mirroring yet, since the engine orientation changes as you mirror.

Edited by Firov
Link to comment
Share on other sites

Just discovered a potential bug, or a couple, actually.

2. A number of engines have gimbal ranges that aren't rounded to the nearest tenths. For example, the KW Rocketry Vesta has a gimbal range of .75. Unfortunately, the way tweak ables works, it cuts off that final .05 and limits it to .7 degrees of gimbal range. This isn't huge, but it could probably be fixed by making the tweak able slider operating in .05 increments.

3. Also, it appears that there's a very good chance that the engine gimbaling won't function if you revert to the launchpad.

1. Okay, I figured out what's actually going on. I initially though it was based on the alignment of the craft relative to the VAB. In fact, it's actually relative the the engine's alignment to the craft. If you rotate an engine 90 degrees, for example, its pitch axis will actually become it's yaw axis, and vice versa. This isn't as bad as I thought initially, but it is something to keep in mind. I do think it might be better to have a fixed reference point for all engines, such as the root part's orientation. I'm also not sure how this affect's mirroring yet, since the engine orientation changes as you mirror.

Guess i should give some explanation about how it works.

First, the vessel receives the control input: yaw, pitch, roll, either from the flight control state during flight or the testing sliders in VAB/SPH. Note that these inputs are in vessel's reference system.

Next, each engine takes the yaw/pitch parts and convert it into its own local coordinate system.

e.g. suppose you have an engine attached at the bottom of the rocket and it's rotated 90 degrees along the longitudinal axis of the rocket, now if the vessel has pitch command received, for that engine, the converted result will be a yaw command instead.

After that, the engine will pick the command's yaw/pitch component to calculate local rotation modulated by these coefficients. hence there are four coefficients: yaw coeff H/V, pitch coeff H/V. They can actually be used as constraints: if you want a single-axis vernier thruster, you can set yaw coeff H to 1.0 with other three values to 0.0, so that it will only response to *local* yaw command and it will only turn the gimbal in its *local* Horizontal direction. That's why if you rotate your engine for 90 degrees, these parameters should be tweaked accordingly.

Finally, the local rotation is converted back to the vessel's reference system and set into ModuleGimbal. because the stock ModuleGimbal uses that coordinate system.

---------------

For the gimbal slider step increment, i will change that to 0.05, but i guess there might be display issue like... you get "0.499999" instead of "0.5" on the slider, it won' matter anything but it just looks uncomfortable.

---------------

OK. I will try to test that. You mean simply launch a rocket and then Revert to Launchpad and it won't function?

One thing i know is, not until the engine is activated *via staging* the stock ModuleGimbal's OnFixedUpdate() function won't be called and that will result to "Gimbals are not functional" phenomenon even if you use the context menu of the engine to "Activate Engine".

Are you using the normal staging process to activate the engines instead of using context menu / action groups to do that? I want to clarify the procedures so that reproducing the bug will be much easier.

Link to comment
Share on other sites

Hey HoneyFox,

There seems to be some compatibility issues with this plugin and the RCS Build Aid. As soon as I right click on an engine to start messing with the gimbal settings, the RCS Build Aid gets messed up and starts reporting the craft has invalid mass and dcom offsets. If I then trash that engine and bring it back in fresh it works again.

Link to comment
Share on other sites

Hey HoneyFox,

There seems to be some compatibility issues with this plugin and the RCS Build Aid. As soon as I right click on an engine to start messing with the gimbal settings, the RCS Build Aid gets messed up and starts reporting the craft has invalid mass and dcom offsets. If I then trash that engine and bring it back in fresh it works again.

Thanks for the information, I'll install that plugin and try to reproduce it. :)

EDIT: I took a quick look at RCS Build Aid plugin's GitHub sources before i can get back home and do tests.

It doesn't seem to access ModuleGimbal at all... and all my plugin does is accessing ModuleGimbal if it exists. Weird...

If you can check the "KSP_Data/output_log.txt" to find any exception about this and post here that will be much helpful.

Edited by HoneyFox
Link to comment
Share on other sites

Agathorn: pretty sure that's because you're using an engine that wasn't updated for .23. You need to create a cfg somewhere in GameData and put this in it. It will fix the issue for all unupdated engines.

//Starwaster
@PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]
{
@RESOURCE[ElectricCharge]
{
%isTweakable = false
%hideFlow = true
}
}

Link to comment
Share on other sites

Agathorn: pretty sure that's because you're using an engine that wasn't updated for .23. You need to create a cfg somewhere in GameData and put this in it. It will fix the issue for all unupdated engines.

//Starwaster
@PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]
{
@RESOURCE[ElectricCharge]
{
%isTweakable = false
%hideFlow = true
}
}

This was with Laz's SpaceX engines, which I thought were up to date, but i'll give that a shot.

Link to comment
Share on other sites

I've found a bug. When GimbalRange is set to above 1 (6 in my case) in config, then the plugin bugs out. Gimbals stop working and the log gets spammed with null reference exceptions. Could you change it so it can properly handle realistic gimbal ranges?

Link to comment
Share on other sites

I've found a bug. When GimbalRange is set to above 1 (6 in my case) in config, then the plugin bugs out. Gimbals stop working and the log gets spammed with null reference exceptions. Could you change it so it can properly handle realistic gimbal ranges?

Hi, I've also used this plugin myself with engines that have maxGimbal > 1, like those in my OP's screenshots.

Cn you provide the callstack information from the output_log.txt so I can check what these NREs are coming from?

Link to comment
Share on other sites

  • 3 weeks later...
Hi, I've also used this plugin myself with engines that have maxGimbal > 1, like those in my OP's screenshots.

Cn you provide the callstack information from the output_log.txt so I can check what these NREs are coming from?

Looks like you can reproduce those NullRefs if you are editing the gimbals not directly at the part.cfg but using MM instead.

Use this to reproduce it:

@PART[*]:HAS[@MODULE[ModuleGimbal]:HAS[#gimbalRange[1]]]
{
@MODULE[ModuleGimbal]
{
@gimbalRange = 5
}
}

Every engine with the new 5° gimbal will throw out NullRefs.

Edit: After further investigation i've found the culprit. If the gimbal change gets loaded AFTER the .dll, you get NullRefs, if it is loaded BEFORE you don't.

Edited by Chestburster
Link to comment
Share on other sites

  • 2 months later...
  • 1 year later...
  • 3 weeks later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...