[1.3] Pilot Assistant: Atmospheric piloting aids - 1.13.2 (May 28)

[zolotiyeruki]

On 10/12/2017 at 6:55 PM, stuChris said:

never said anything about the runway, im talking about just landing anywhere (well, anywhere flat anyway) ive almost achieved it, but the landing gear on the plane im using is too low, so its definitely possible

Yeah, I guess you could set it up to just fly level with a (for example) 3m/s descent, and hope you end up on a flat-enough spot.

[Goddess Bhavani]

Hoping to use this in 1.3.1

[Lupi]

On 10/18/2017 at 6:04 AM, carmenara said:

Hoping to use this in 1.3.1

Works fine for me!

[Apaseall]

Settings for Acceleration are not being saved to file. To test, load KSP etc, change value of any item listed below, press update, look at file.

Spoiler

    AccelController
    {
        PGain = 0.20000000000000001
        IGain = 0.080000000000000002
        DGain = 0
        MinOut = 0
        MaxOut = 1
        ClampLower = -1
        ClampUpper = 1
        Scalar = 1
        Ease = 1
    }

I tried looking at the source code but it has been a long time since I coded and I did not spot why this part of the data is not being saved whilst the rest is (not that I checked for the speed controller, but the rest seem to load if changed). Hopefully someone can check the source code, make the correction and recompile.

Edited February 9, 2018 by Apaseall
New post, just using this space

[Apaseall]

Couple of more oddities.

1. Target Heading not set to entered value.

On the ground, on the runway, I entered in Target Heading 90.00 as a direction. The entered value was immediately replaced with something else, about 90.44. This is not expected.

I do know that the runway is not at 90.00, if this is the reason for the replacement, well as I said that is not what I expected to happen. Surely it is up to me to either enter the correct heading for the runway or exit the runway slightly off to one side?

2. Trying to use Yaw to help change heading is a bit odd.

Say I initially have all the PID values in the top Yaw controller set to zero. I believe that results in no Yaw being set to assist heading change, that heading change uses Bank only. Accepting that premise I enter PID values in the Bank Controller and the bottom Yaw Controller. After observing craft performance I eventually arrive at values such that the craft performs heading changes with both the Bank Controller and Yaw Controller closely following the target set for them by the Heading Controller. This is expected.

Now I enter values in the top Yaw Controller in the belief that what I am asking is for Yaw to be used in addition to Bank in order to change direction.

If I enter a small value for Kp only in the top Yaw Controller, I see a slowly increasing target for the bottom Yaw controller. Since the bottom Yaw controller already has values that previously faithfully tracked the target set for it to meet it continues to do so. The target for the Bank controller to meet is reduced from when not being used in conjunction with Yaw to control direction. This is expected.

If I increase the Kp in the top Yaw controller something unexpected happens. The target for the Bank Controller to meet changes to the other direction. It is as if Pilot Assist is saying to itself, "hey too much Yaw for the desired change in direction being set by the Heading controller, I will compensate by setting an opposing target for the Bank controller to bring the rate back down". Hmm. Probably correct but for the following.

The reason I increased the Kp in the top Yaw Controller is because after the desired heading had been achieved, the bottom Yaw Controller had a target set for it to meet that was not zero. My belief is that Kp was for proportional and would be therefore zero when the error was zero. That would be when I was going in the direction I had set for the Heading controller to meet. What appeared to happen was this. The error was initially not zero as we were not at the desired heading. Top Yaw controller set a target for the bottom Yaw controller to meet. That target was initially small but slowly increased over time. This increase occurred despite the error in heading decreasing as I was indeed turning towards the desired heading. The target was not zero when the error in heading became zero as I flew in the desired direction. I passed the desired direction. The target for the bottom Yaw Controller to meet was then slowly decreased.

I believe I have observed that even if the error is constant, the set point for the second controller is increased. This would be experienced as watching the target for the bottom Yaw controller increasing whilst the direction remained unchanged.

I also believe I have seen that the initial set point for the second controller is not the maximum Kp. This would be experienced as watching the target for the bottom Yaw controller start out small and slowly increase.

I thought the following took place. I set a direction for the Heading controller to meet. In order to change heading the Heading controller sets a target for the Bank controller to meet. The Heading controller does this in two steps. First it calculates a response to the error in direction vs heading, based on it own PID values. Second it alters the response to something it can send to the Bank controller as a target for it to meet. The top Yaw controller sets a target for the bottom Yaw controller to meet. Again, first it calculates a response to the error in direction vs heading, based on it own PID values. and second it alters the response to something it can send to the bottom Yaw controller as a target for it to meet.

It is clear to me that what I thought was happening is not what is really happening.

Can someone tell me exactly how the four heading controllers behave please?

You might need to be aware that during the process of arriving at 'good' PID values I take a lot of time. After entering new values I observe performance. I then relaunch. I observe performance again. I make small changes. I relaunch. Lots and lots of launches. I mean a lot, I have spent roughly a week of say six hours a day per craft. Sometimes the performance sends me back to the SPH. I make slight changes, which include changes to centers of wet/dry mass, lift and thrust. Rotating wings, viewing static stability analysis. More launches. In other words this is not a new craft, nor is it something I have fiddled with for a couple of hours. Obviously I could be holding strange notions of what I should be aiming for and what to adjust to achieve those aims. I rather enjoy this mod

Edited February 11, 2018 by Apaseall

[Apaseall]

Well now, this is rather interesting.

I was in this situation:

Using Bank and Yaw for heading change. Tiny value for Kp in top Yaw controller. I then set Kp=0. Flight was stable, heading unchanged, slight increase in Bank controller target to meet. This was expected.

I thought to myself, I wonder if I have entered the clamp limits in the top Yaw controller wrongly. I did have max Yaw= 2, min Yaw= -2, I min= -2, I max= 2. So I inverted them. -2 became +2, +2 became -2. Erm WOW that was a bad idea. Despite having all PID values for the top Yaw controller = 0, well the craft certainly went wild. Now why would setting the clamps and integral limits change anything if the PID was being asked to do nothing, which is I assumed what Kp=0 plus Ki=0 and Kd=0 meant?

[Crzyrndm]

Funny story, clamps are applied after all calculations. i.e. if you invert them, the output is clamped to be less than -2 and greater than +2 (I have no idea which one it'll end up at but, either way, not 0)

(no I'm not back, just passing through >.>)

[maculator]

I got a question that I've been asking myself alot. Each time I get this mod for example.

There are 3 atmospheric autopilots out there, they all share the same icon and the same ui layout. Why is that?

This one is the most "basic" so it's my favorite because all I need is something to hold the course of my plane.

But I'd really love to know if they all got some sort of ancient root

[Starwaster]

22 hours ago, maculator said:

I got a question that I've been asking myself alot. Each time I get this mod for example.

There are 3 atmospheric autopilots out there, they all share the same icon and the same ui layout. Why is that?

This one is the most "basic" so it's my favorite because all I need is something to hold the course of my plane.

But I'd really love to know if they all got some sort of ancient root

There is at least one other mod that is derived from this one which adds autopiloting and autolanding capabilities (Kramax Autopilot). That's probably one of the others you're thinking of. I'm unaware of any others but there might be others.

[maculator]

This is the third one:

I was just curious since they all developped in different directions but seem to have the same UI and symbol, wondered what's "their story".

 

Edit:

PA is the basic "hold" option, Kramax has integrated waypoints and profiles and AA has fly by wire and mouse control. I used them all (by accident because I thought they were the same) and each gets the job done.

Edited February 21, 2018 by maculator

[Apaseall]

1 hour ago, maculator said:

This is the third one:

I was just curious since they all developped in different directions but seem to have the same UI and symbol, wondered what's "their story".

 

Edit:

PA is the basic "hold" option, Kramax has integrated waypoints and profiles and AA has fly by wire and mouse control. I used them all (by accident because I thought they were the same) and each gets the job done.

Only just discovered AtmosphereAutopilot. I think it is just what I was hoping PilotAssistant was, without having to learn how to change PID values for each slight change (or major) to a craft. I have enjoyed the challenge of PA but for me AA does what I want with ease. I may take a look at Kramax but only if I fancy using waypoints (I think that is the only difference?).

[zolotiyeruki]

For anyone who still misses this mod, Crzyrndm has given me permission to recompile and repost it.  I've created a new thread for it here: