[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[TranceaddicT]

 

 

 

2

3 hours ago, kcs123 said:

I have maybe over engineered library script and wrote comments for easier tracking if I have made mistake somewhere. For that reason, file is bigger than need to be. It is clearly disadvantage.

There is always the kOS compile() func. 

[kcs123]

5 hours ago, kcs123 said:

When I started to test, my previously working rocket started to explode on staging. I think it is KJR next culprit, since it is only mod updated since yesterday.
But, that is different kind of animal that I need to tacle down. kOS script prepared to be used as library is under spoiler:

That issue encountered is confirmed to be due to KJRn beta version- With that one removedm script does job well enough for smooth steering. However, provided setpoints are not optimised, at some phase of ascent craft may steer too much from prograde. That can make kaboooms. But as said, it can be easy customized, either by editing library for more general ascent points that work for most crafts or adjust it trough man script for each craft as you need it.

[FloppyRocket]

On 5/17/2019 at 4:14 AM, Drew Kerman said:

I didn't consider this a factor since the control surfaces were not being overworked at all at these points in the flight. When it came off the pad the gimbal lock dropped its heading from 45° to 20° and it was able to snap roll over back to 43° in under two seconds, but then it was also starting to pitch over and took its time getting to 53°

thanks, I will keep that in mind. My first fix attempt tho will be as you also suggest and as I surmised - get a more stable heading off the pad

I've created a rocket similar to the one you posted, and using the steering method from CheersKevin video. It has a parachute on the top of a MK1 pod, rather than a launch escape tower.

I set the reaction wheels in the command pod to "SAS only" mode, so that the first-stage steering is only via four "Delta Deluxe Winglets".

The kOS script uses locked steering. It steers smoothly through the first stage burnout, without any oscillations. After the 1st stage loss of thrust, the kOS script stages, unlocks the steering, and enables SAS Prograde control.

I didn't modify any of the built-in PID steering constants.

I didn't encounter any problems.

I wonder if the launch escape tower on your rocket is creating some drag-related oscillations.

[Drew Kerman]

24 minutes ago, FloppyRocket said:

I set the reaction wheels in the command pod to "SAS only" mode, so that the first-stage steering is only via four "Delta Deluxe Winglets".

Do your launch again and completely disable the reaction wheels. I don't use reaction wheel torque - at least no torque that's any stronger than what is needed to hold a satellites pointing (using MandatoryRCS mod)

Also you didn't mention if you weren't experiencing the gimbal lock issue I identified as the main suspect. If you're pitching right off the pad then you probably have a good heading right from the start. I let my rocket clear the tower before enabling guidance and in those 3s the nose can point straight up and cause the heading to jump around. In the example I gave above the heading jumped from 45° to 20° when guidance kicked in and the nose began to lower. If it had stayed 45° and only needed to make a small correction to 53° things may have been smoother overall

 

[Dunbaratu]

12 hours ago, FloppyRocket said:

I set the reaction wheels in the command pod to "SAS only" mode, so that the first-stage steering is only via four "Delta Deluxe Winglets"

https://github.com/KSP-KOS/KOS/issues/2455

Is it that issue?  Maybe the kOS steering doesn't know that torque wheel isn't really available for use, so it assumes it contributes to the overall torque ability of the ship (Which is used to set the PID tuning.  kOS queries KSP and asks it "hey, KSP, how much torque is this ship capable of at this very instant?", and calculates PID gains from that.  It is possible that KSP is reporting the torque wheel as if it was usable by kOS when it isn't because it's SAS only.  (For KSP's own internal purposes it's fine with thinking it can use that torque.  Because it *can* - it's steering *IS* the SAS.))

 

[Flibble]

I've just moved my whole game and mod set up to 1.6.1 and I am now getting an odd issue. I'm not sure if this is kOS or something in real fuels. When I list fields for ModuleEngineRF the first field has no name, but does have a type (boolean) and value. I think this is supposed to be the "pressureFed" field as it was working before. Oddly though, the field shows as expected in the PAW.

Any idea what would break kOS field lookup but wouldn't break the PAW?

 

EDIT: a bit of testing shows that field.guiName is empty, but field.name is valid. Is this expected? I can easily work around it, but it seems a bit odd that this has changed.

EDIT2: I've added a bug and PR with fix for this over on github.

Edited May 20, 2019 by Flibble

[Drew Kerman]

here's a video of that guidance issue I mentioned:

So right at launch the cooked steering is locked to heading(54,89) for the first 500m before the quadratic fit function kicks in, and the whole time the heading remains 54°. Coming off the pad the rocket rolls and points 50°, then at around 2.6km it kicks over to 54-55 and seems to really start to pitch over. I added a field to my telemetry log to calculate the current pitch that the quadratic fit function is telling the steering to turn to - here it is +500m compared to the actual pitch:

Now, I would suspect a PID tuning problem if the rocket were having trouble finding 54° but it doesn't waver about 54° it rolls straight to 50° and holds it until the snap to 54-55°

What is that all about?

[kcs123]

4 hours ago, Drew Kerman said:

What is that all about?

Uh, you are going too fast while being at low altitide. 371 m/s at 3180 m and dynamic preassure 53147 kPa. That is quite a lot. FAR apply heavy aerodynamic forces and steering manager have struggle to keep it flying straight. And you have wide crosssection area on top that makes craft even more unstable.

Try with lower TWR on starting stage, like 1.4 or 1.6 to see if it will improve.

EDIT:

371 m/s at 3180 m that is mach 1.1
That is transonic flight (0.8 mach to 1.2 mach) where drag and lift is very non-linerar curve. You can always expect unstable craft behaviour on those velocities.

Edited May 21, 2019 by kcs123
more info

[Flibble]

That's a good point, you're at nearly 5 degrees AoA there so it's not surprising the pitch control isn't great.

You could try pitching over much lower so you're not trying to make large adjustments once you're at significant speed. I find 50 m/s a good starting point for pitch over, for a fast rocket like that I'd be tempted to start pitching pretty much as it clears the tower.

Also you're seeing 50 degree heading when your pitch is almost vertical, at that point heading is largely academic as you're going straight up.

Edited May 21, 2019 by Flibble

[FloppyRocket]

On 5/19/2019 at 12:06 AM, Steven Mading said:

https://github.com/KSP-KOS/KOS/issues/2455

Is it that issue?  Maybe the kOS steering doesn't know that torque wheel isn't really available for use, so it assumes it contributes to the overall torque ability of the ship (Which is used to set the PID tuning.  kOS queries KSP and asks it "hey, KSP, how much torque is this ship capable of at this very instant?", and calculates PID gains from that.  It is possible that KSP is reporting the torque wheel as if it was usable by kOS when it isn't because it's SAS only.  (For KSP's own internal purposes it's fine with thinking it can use that torque.  Because it *can* - it's steering *IS* the SAS.))

 

Interesting point. I have no idea if it is the same issue. How would I test for that (i.e. whether kOS is actually using the reaction wheels?)

On 5/18/2019 at 11:57 AM, Drew Kerman said:

Do your launch again and completely disable the reaction wheels. I don't use reaction wheel torque - at least no torque that's any stronger than what is needed to hold a satellites pointing (using MandatoryRCS mod)

Also you didn't mention if you weren't experiencing the gimbal lock issue I identified as the main suspect. If you're pitching right off the pad then you probably have a good heading right from the start. I let my rocket clear the tower before enabling guidance and in those 3s the nose can point straight up and cause the heading to jump around. In the example I gave above the heading jumped from 45° to 20° when guidance kicked in and the nose began to lower. If it had stayed 45° and only needed to make a small correction to 53° things may have been smoother overall

 

I'm not sure how to "completely disable" the reaction wheels. In the MK1 pod, the only RMB options are Normal, Pilot Only, and SAS Only. I could try putting something on top of the rocket that doesn't have reaction wheels.

I should also say that the test rocket I"m using behaves totally fine if it just does a gravity turn without any kOS script running and with SAS off. The fins do their job even without a script running.

So i don't really have a lot of evidence that my kOS launcher script is actually doing anything useful. It does roll the rocket to a 90 degree heading, and deflects the pitch control surfaces.

The launch script does this to get off the pad:

lock throttle to 1.
//lock angle to 5.37e-8*alt:radar^2 - 0.00361 * alt:radar + 89.6.
lock angle to 90 - (sqrt(alt:radar) / 3.14).
lock steering to heading(90,angle).
stage.
wait 3.

The rest of the script manages staging and throttle control to avoid excessive atmospheric drag and circularization.

I can use either the quadratic or the sqrt() profile, they behave very similarly.

Since steering is locked, the wait 3" doesn't do anything useful.

 

 

[FloppyRocket]

Re: "disabling the reaction wheels': Maybe set the Wheel Authority to zero? And then add some RCS thrusters to get pointing control for the circularization burn.

 

[FloppyRocket]

9 hours ago, Drew Kerman said:

here's a video of that guidance issue I mentioned:

(link removed)

So right at launch the cooked steering is locked to heading(54,89) for the first 500m before the quadratic fit function kicks in, and the whole time the heading remains 54°. Coming off the pad the rocket rolls and points 50°, then at around 2.6km it kicks over to 54-55 and seems to really start to pitch over. I added a field to my telemetry log to calculate the current pitch that the quadratic fit function is telling the steering to turn to - here it is +500m compared to the actual pitch:

 

Now, I would suspect a PID tuning problem if the rocket were having trouble finding 54° but it doesn't waver about 54° it rolls straight to 50° and holds it until the snap to 54-55°

What is that all about?

I'm just seeing "An error occurred" when I try to play the video.

[Flibble]

7 hours ago, FloppyRocket said:

Re: "disabling the reaction wheels': Maybe set the Wheel Authority to zero? And then add some RCS thrusters to get pointing control for the circularization burn.

 

You should have a button labelled "toggle torque" that can be used to disable the reaction wheels.

[Drew Kerman]

On 5/21/2019 at 4:48 PM, kcs123 said:

steering manager have struggle to keep it flying straight

I may not be getting your meaning but I'm not seeing any evidence of struggle in the control indicators. After the initial snap-roll at launch to the wrong heading, they are stable and the pitch indicator is smoothly working downwards until the "bump" and then continues a smooth progression. Even after that relatively large pitch movement the control indicators do not bob up and down at all

On 5/21/2019 at 4:48 PM, kcs123 said:

Try with lower TWR on starting stage, like 1.4 or 1.6 to see if it will improve

I do this with my larger 1.25m rocket using the same steering code and the same sudden pitch over happens prior to the rocket reaching Mach 1 (at around Mach 0.6). There's an example of this in this video.

On 5/21/2019 at 4:55 PM, Flibble said:

That's a good point, you're at nearly 5 degrees AoA there so it's not surprising the pitch control isn't great.

It seems less an issue of pitch control to me when you look at the control indicators and see how little they are working. It very much looks to me like the rocket is doing what it thinks it is supposed to be doing instead of trying to do something it's finding difficult to do. This belies an issue with the guidance code not the rocket

19 hours ago, FloppyRocket said:

I'm just seeing "An error occurred" when I try to play the video.

Even when you try to view it on YouTube?

On 5/21/2019 at 4:55 PM, Flibble said:

Also you're seeing 50 degree heading when your pitch is almost vertical, at that point heading is largely academic as you're going straight up.

If the steering function is ignoring heading properly until a certain angle then it's doing so ambiguously, which doesn't seem right. The rocket in the video I embedded made the heading correction at 86° pitch but the rocket in the other video I linked in this post made the correction at 84° pitch. Really at 89° pitch the heading should no longer be ambiguous - even 1° off at launch will put you a measurable distance downrange in one direction or another by the time you hit a few hundred meters

Correlation to altitude of 2.6km

I've been looking into this a bit more since I last posted and there is something strongly related to all the controlled flights that see this behavior - it happens at 2.6km regardless of speed or pitch. You can see it happen at that altitude in both videos I linked to and I've seen it watching 3 others. not sure what it would be related to however

[TranceaddicT]

3 hours ago, Drew Kerman said:

Correlation to altitude of 2.6km

Could this be an atmospheric "boundary" inherent in the aerodynamic model?

[Flibble]

6 hours ago, TranceaddicT said:

Could this be an atmospheric "boundary" inherent in the aerodynamic model?

The first boundary should be much higher than 2.6km.

 

The graph above does look like a PID tuning issue - the correction term doesn't build fast enough so it's not catching up, then the integral term builds and it overshoots miles.

I wonder if this might be related to the tuning being set on the ground and not adjusted in flight as the control surface authority changes. At low speed you need a fairly aggressive response as there is little authority, as speed builds the response should dial back to avoid massive overshoot, then the response needs to dial back up as the flight progresses and you lose air pressure.
It might be worth doing some tweaking of the PID tuning using dynamic pressure. Also you'll probably need to just tune pitch to avoid the heading going crazy.

[Drew Kerman]

I'm going to study the PID section of the docs more closely. I've had experience with using similar rocket steering methods in older versions of KSP and kOS and this is the first time I've had to tune the cooked steering so it's all new to me in that regard. But then again I do recall kOS cooked steering getting a major overhaul during the period where I was rebuilding the KSA to the point where it uses steerable rockets

[TranceaddicT]

33 minutes ago, Drew Kerman said:

I'm going to study the PID section of the docs more closely. I've had experience with using similar rocket steering methods in older versions of KSP and kOS and this is the first time I've had to tune the cooked steering so it's all new to me in that regard. But then again I do recall kOS cooked steering getting a major overhaul during the period where I was rebuilding the KSA to the point where it uses steerable rockets

You might want to try an external PID controller to compare results.

https://github.com/KSP-KOS/KSLib/blob/master/library/lib_pid.ks

 

The library scripts are 4yo; so, they probably need some refactoring and updating.

Edited May 23, 2019 by TranceaddicT

[kcs123]

17 hours ago, Drew Kerman said:

may not be getting your meaning but I'm not seeing any evidence of struggle in the control indicators. After the initial snap-roll at launch to the wrong heading, they are stable and the pitch indicator is smoothly working downwards until the "bump" and then continues a smooth progression. Even after that relatively large pitch movement the control indicators do not bob up and down at all

Sorry, "struggle" might not be the best term, please note that english is not my native language, so don't take everything written literaly. When I said first time that steering manager have "struggle" to steer rocket, I was not mean that it have lack of authority. I was thinking about unproper set of Kp, Ki and Kd of internal steering manager PID controlers. I apollogize that I didn't elaborate it better first time. Basicaly, what @Flibble said:

7 hours ago, Flibble said:

The graph above does look like a PID tuning issue - the correction term doesn't build fast enough so it's not catching up, then the integral term builds and it overshoots miles.

But, things are slightly more complicated. I'm writting following from top of my head, I have found some info about it in kOS documentation, some info on this formu, some from other web pages, etc. Can't really recall all exact details. But, IIRC, steering manager use not one, but pair of two PID controlers for each axis: yaw, pitch and roll. Furthermore, it use some self-adjusting algorithm, to set apropriate Kp, Ki and Kd for PID controler. Over time, based on passed results it re-adjust itself. I'm not sure when steering manager re-calculate Kp, Ki and Kd during flight, but I know that it does.

Now, at the begining of flight, influence of aerodynamic forces are neglectable, compared to gravity and other forces. And when aerodynamic forces started to build up, lift and drag coefficients are almost linear. Steering manager was set Kp, Ki and Kd for PID based on data from first seconds on flight. Suddenly when Cl and Cd become more curvatore, previous set of Kp, Ki, and Kd was no longer apropriate for whole craft steering system. It was not reacting quick enough when Cl and Cd rapidly bumps up and down and become more linear again. Now, I was talking about non linear Cl and Cd as most common issue of unexpected change in steering PID loop craft system. It may also be influenced by to steep momentum when you set different pitch angle or heading or any other outside force that was not exist previously when steering manager calculated Kp, Ki and Kd values.

IIRC, @hvacengi have worked on steering manager for kOS, he might tell more accurate details how it works.

Try to put mach velocity on the graph you posted above. Also grab screenshot of FAR velocity sweep graph from 0 to 2 mach and for AoA 0 and 5.
For each craft Cl and Cd is diffrent and become non linear sooner or later. So, aproximation of 0.8 up to 1.2 mach for transonic flight may not fit to all crafts. On your second video, pitching and heading is more stable, but you have heavy roll oscilation on transonic flight. You need to compare flight records (mach and AoA) with FAR graphs from VAB/SPH for velocity sweep to see when you can expect unstable transonic flight regime.

Based on represented data, it is nothing wrong with steering manager in terms of some software bugs involved. It attempts to do it's job best as it can, but it is not always perfect and you can't expect perfect ascent path as you desire. Considering how much variables are involved, kOS steering manager does it's job pretty well.

As much as I can recall from kOS documentation, it is possible to set different Kp, Ki, and Kd to steering manager if default settings does not give desired results. Also, other option is to not use build in steering manager, but to create your own with your own PID object and raw controls.
I tried this long time ago and realized that built in steering manager doing it's job much better than I was able to accomplish with separate PID controlers and raw control inputs.

[Drew Kerman]

1 hour ago, kcs123 said:

I'm not sure when steering manager re-calculate Kp, Ki and Kd during flight, but I know that it does

1 hour ago, kcs123 said:

it is possible to set different Kp, Ki, and Kd to steering manager if default settings does not give desired results

What I'm going to try to do is take these two statements and put them together - as in, see if I can extract the PID adjustments from flights and re-apply them over the course of additional flights to better tune the system for the rocket in question

[kcs123]

52 minutes ago, Drew Kerman said:

What I'm going to try to do is take these two statements and put them together - as in, see if I can extract the PID adjustments from flights and re-apply them over the course of additional flights to better tune the system for the rocket in question

This page in kOS document might be good starting point. Try to enable SHOWSTEERINGSTATS first, to see what you will get in terminal. I wasn't investigated much of steering manager suffixes, what is readable only what thing can be set and what not. But, I remembered pieces of those info when steering manager received coding overhaul several versions of kOS and KSP ago. I can't help you much more on this topic, but I hope it will be good for start.

[RizzoTheRat]

Can anyone give me some pointers on part modules and operating stuff in the right click menus?

I want to arm an Advanced Grabbing Unit, but can't work out the relationship between the part and names of the modules/variables that sit below that.

From a rummage through the persistent save file I thought this would do it

set PartList to ship:parts.
for Parts in PartList {
	set part to Parts.
	if part:name = "GrapplingDevice"{
		print "Klaw fitted".
		part:getmodule("ModuleGrappleNode"):setfield("State",True).
	}	
}  

But it tells me there isn't a field called state, so I'm a bit stuck.

[Dunbaratu]

25 minutes ago, RizzoTheRat said:

		part:getmodule("ModuleGrappleNode"):setfield("State",True).

But it tells me there isn't a field called state, so I'm a bit stuck.

The error message could be a bit better here.  It looks for a **SETTABLE** field called "State", and can't find one.  There could very well be a read-only field called "State", in which case this will claim it "doesn't exist", because the SETFIELD() command doesn't "see" the unsettable read-only fields.

The rule of thumb is this:  If the GUI doesn't allow the manual, non-scripted player to directly set the thing with a button or slider or something, then kOS won't let a script do it either.  This is so that kOS doesn't end up giving other mods surprises that introduce bugs.  (Any other modder's code (or even SQUAD's own code) with an assumption that "this field can't change unless my code changes it" could get very broken if kOS "cheats" by altering the fields in ways a player normally couldn't.)

 

[Flibble]

Try printing allfields on the part, it should give you a list of everything. You'll probably need to call an event or action called "arm".

[RizzoTheRat]

4 hours ago, Steven Mading said:

The error message could be a bit better here.  It looks for a **SETTABLE** field called "State", and can't find one.  There could very well be a read-only field called "State", in which case this will claim it "doesn't exist", because the SETFIELD() command doesn't "see" the unsettable read-only fields.

The rule of thumb is this:  If the GUI doesn't allow the manual, non-scripted player to directly set the thing with a button or slider or something, then kOS won't let a script do it either.  This is so that kOS doesn't end up giving other mods surprises that introduce bugs.  (Any other modder's code (or even SQUAD's own code) with an assumption that "this field can't change unless my code changes it" could get very broken if kOS "cheats" by altering the fields in ways a player normally couldn't.)

 

It's the "Arm" button on the right click menu I'm trying to use, so presumably it should be available.

1 hour ago, Flibble said:

Try printing allfields on the part, it should give you a list of everything. You'll probably need to call an event or action called "arm".

 

I've tried printing :allfields, :allevents and :allactions for the ModuleGrappleNode

It returns no fields, 1 event (control from here) and 3 actions (release grapple, decouple node and control from here).

Nothing obvious for arming it.