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

[RickKermen]

Great Mod! I was looking for such light autopilot to work with FAR. Ty!

[Van Disaster]

That would be the case, yes. I'll have a think about how to manage that a bit better

Could PA not just treat the situation as if it's flying, but just have no output? I realise that might have integral windup issues, but I'm wondering if that really would be an issue - if the craft is not doing what PA thinks it should be doing then integral windup might be a *good* thing; if it turns out to be a problem, maybe turning a PA component on can just reset all the relevant integral values, it'd still transfer with some control deflection and be at least a little primed.

[Crzyrndm]

It really won't work that way. You'll get a way more jarring bump if I just leave it running in the background because if the vessel isn't responding like it wants it to be, it will push everything to it's limits.

There are two options I want to pursue

1) Run it through several frames worth of calculations on startup / preset the integral

2) Fade out any SAS input over a second or so

It's just a matter of finding a bit of free time to experiment with it

EDIT

Actually, if I have the set points track the current flight conditions it could work out. Make that option 3 (E: No that definitely won't work. That would be the same as not running anything)

Edited March 31, 2015 by Crzyrndm

[Crzyrndm]

v1.4.2 Release

• Better integration of non-keyboard input sources (github user bssthu). NOTE: I can't test these changes as I have no analog input source
  
• Smoothed transfer between SSAS pitch control and Pilot Assistant Vertical Control
  

Hopefully that will solve your issue Van Disaster (NOTE: Pitch only at the moment because I'm in a bit of a hurry.)

EDIT

Just randomly:

So this was both more difficult and much easier to resolve than I initially anticipated. Presetting the integrals involved was a piece of cake because the outputs of the various controllers are real values that I can just grab and use. The difficulty was that doing so created even more issues than were originally present (rapid unplanned disintegration level issues). The cause was the derivative action being calculated on the first frame of activation when it has no trend to work off, creating a disturbance of fairly random magnitude in each of the controllers.

Nasty little thing to debug...

Edited March 31, 2015 by Crzyrndm

[Crzyrndm]

Heading Control Test Download

What is it?

This version changes the Assistant heading control system to use a constant direction not a constant heading (especially noticeable around planetary poles because a constant heading is a spiral centered around these locations)

I'm looking for feedback on:

A) How it functions (particularly any wierdness, but all comments are useful)

UI improvements related to this (it's a little counter intuitive to set a heading and then have it constantly changing)

Edited April 1, 2015 by Crzyrndm

[Van Disaster]

Haven't tested yet ( haven't tested yesterday's either! ) but will soon. Inertial mode, perhaps? it's frame of reference is the craft having been initialised to the local planetary frame, if I understand right.

[Crzyrndm]

Not really. The orientation of the craft wrt the planet is constantly varying (on all axes). My understanding of "inertial mode" is also not a particularly good description of what's going on either, although it's probably close.

The basic requirement of the heading control system is a measurement of the deviation from a given direction. Getting a constant direction only requires a consistent reference, the difficulty lies in establishing that reference.

The simplest/most obvious reference would be the current velocity vector, which works until you travel about 1/5th of the way around the planet and that reference points almost straight up. Essentially, it just shifts the location of the poles and doesn't really solve the problem. The solution is to create that direction vector on a regular basis wrt to other constants. The candidates for this are fairly obvious, the two vectors perpendicular to the one we actually want and parallel/perpendicular with the surface. The horizontal reference becomes the fixed direction used to align the target at 90 degrees to itself, while the vertical reference is used to maintain the proper forward facing that is required.

tl;dr

Everything is calculated as if you are always in a trajectory aligned with the equator (see great circle). The planetary north/east directions are irrelevant so location on the planet has no impact on output (although manual input around the poles can still be a chore).

There are a couple of other ways I could have handled it, but this one uses values I've already got and those values are pulled from a relatable quantity (eg. vessel direction) which makes debugging a whole lot easier.

On another note, I think I just fixed a very minor error with the way Squad calculates vertical speed which was preventing high speed vessels (1+km/s) from attaining the altitude target to a noticeable degree (about 5 meters of offset in the worst case I saw). Irritating little bug squashed...

Edited April 1, 2015 by Crzyrndm

[Crzyrndm]

v1.5.0 release

• Heading control locks to a direction. NOTE: Because heading is not constant for a given direction, the target heading will change over time (this is particularly noticeable in polar regions)
  
• Smoothed engagement of heading control based on current angle of bank
  
• Fixed: Vertical speed not being measured as zero at a constant altitude
  
• Fixed: Heading control uses prograde heading instead of craft heading in order to manage sideslip
  

Edited April 2, 2015 by Crzyrndm

[Van Disaster]

Inertial guidance systems just notes deviations from the current vector as far as I'm aware ( using accelerometers etc and I think gyros? I do remember they took time to initialise/align ), hence my comment about the starting frame of reference - so yeah that sounds exactly right . Anyone who's ever made orbit will understand that mode anyway. Navigating by it is another matter...

[Crzyrndm]

Sounds like the analog version of this system (or much closer to it. The update frequency of a modern digital system would be measured in kHz, compared to the sedate 30-60Hz here)

Navigating by it is another matter...

I don't know about that. Everything is a straight line so it's a whole lot more intuitive than the oddities that would crop up with the original system. It also works better with anything that provides a heading to a target (eg. waypoints) because if that value is used as the starting value in the heading control it will continue to point in the correct direction.

Edited April 2, 2015 by Crzyrndm

[Van Disaster]

Erm... the PA vertical modes appear to be completely non-functional if SSAS is on - even if SSAS pitch hold isn't on - whether the PA control is turned on or not. Manually entering altitude & setting it via the target button also seems to have stopped working...

Edit: the latter issue seems a bit intermittent, I'll have to poke at that a bit more.

Edited April 2, 2015 by Van Disaster

[Crzyrndm]

Well thats a bug and a half and I'll be dammed if I have the faintest clue whats causing it.

E:

Found it, fix shortly

Edited April 2, 2015 by Crzyrndm

[Crzyrndm]

Version 1.5.1

• Fixed bad calculation of vertical speed for Pilot Assistant if SSAS was armed
  

[Van Disaster]

Ok, that fixed it.

Tell you what is a little awkward though, using A-D to set a direction when the target heading is changing and you're trying to fly on the navball; not quite sure of the best way to ease that.

Edited April 2, 2015 by Van Disaster

[Crzyrndm]

Is one set of updates overriding the other? I thought I set it up so they would both take effect at the same time.

[Van Disaster]

Hm, let's explain another way: I'm up near the pole flying a diagonal so the target heading is changing reasonably fast and my target is about 15 deg to port; if I start changing direction using the A key I'm not quite sure when I've actually changed the target direction by 15 degrees because everything is moving. I don't think it's anything you've forgotten, it's just the relative vs absolute heading thing. There is probably a clean way of being clear here, I'd settle for another box showing me how many degrees left or right I've set myself up to steer though.

[Crzyrndm]

Version 1.5.2

• New: Added configurable delay to heading alterations made via. Yaw Left/Right controls.
  
• Improvement: Pilot Assistant transition logic improved. Engaging controls and toggling modes is significantly smoother
  
• Improvement: Vertical speed measurement improved (again) as detailed here
  
• Improvement: Split heading target input/readout into two fields. The left field displays the current setpoint, while the right field is for displaying the final target (NOTE: There is a slight error here. I meant to make the right hand field the target entry field as well).
  
• Improvement: Control and data lockouts for vessels moving at a surface speed < 1m/s
  
• Fixed: Direction lock now engages instantly for all methods of target entry. Entering manually previously did not lock for a noteable period of time.
  

With the vertical speed changed from Squads measurement to my own I can now guarantee that the altitude hold is capable of attaining and matching a given target to insane levels of accuracy and precision at any height or velocity. Previously errors in Squad's calculation were causing small (but noticeable) offsets to occur with no apparent explanation.

The VS calculation method has changed a bit since this data was recorded, but it clearly shows a non-zero VS being reported from Squads number for a constant altitude

PS

Altitude variation of less than +/- 15mm over a period of 5 minutes. Me likey

Hm, let's explain another way: I'm up near the pole flying a diagonal so the target heading is changing reasonably fast and my target is about 15 deg to port; if I start changing direction using the A key I'm not quite sure when I've actually changed the target direction by 15 degrees because everything is moving. I don't think it's anything you've forgotten, it's just the relative vs absolute heading thing. There is probably a clean way of being clear here, I'd settle for another box showing me how many degrees left or right I've set myself up to steer though.

The split heading readout and delay was a last minute attempt to address this, hopefully it helps a bit. I'll sort something better out tonight

EDIT

After fiddling around with the dual heading displays a bit more, I think I've got a more intuitive version worked out.

The left side will show the current target or the turn amount if yaw input is waiting on the delay

The right side will always show the final target and will be used for manual entry (as that is a final target). When yaw intput is waiting on the delay it will show the what the final heading will be after the input is commited.

Edited April 3, 2015 by Crzyrndm

[Van Disaster]

Yeah that definitely helps a bit. The current delay using A-D ( IE the new setpoint only gets set when you let go ) will take a little getting used to - given the target heading is an absolute I wonder if that's necessary? the direction of travel needs to match the absolute heading before it starts adjusting itself again anyway, so probably no point in waiting to start changing it.

[Crzyrndm]

Without the delay it defeats the purpose of knowing exactly how far you want to turn (delay is configurable btw. You can zero it if you want to try that). Tomorrows version of the UI will be a lot more helpful in that regard (probably, still not quite sure I like how it's presented, but it's getting better).

I should manage to get the same system working on the SSAS heading by tomorrow as well, since there doesn't appear to be any issues with the control method itself. Yay for no more issues with polar navigation.

[Van Disaster]

Well, no, you're taking a snapshot of the current situation; right at this moment I am currently heading 320, target is 305, set heading 305 right now - given the navball is what we have to use no matter what navigation system the aircraft is using - so you can start actually turning straight away without it upsetting the situation. The original problem was I had no way of knowing when I'd set 305 as a target because the setpoint was changing still. It might be a problem if all we had was a vector nav system.

BTW now you fixed the altitude issue do you think you can use it for sideslip detection somehow to stop planes overbanking? I haven't quite worked out how to link everything together yet but I'm sure there must be some simple way of connecting bank & vertical speed.

Edited April 3, 2015 by Van Disaster

[baldamundo]

Hey. Really enjoy and appreciate the pilot assistant - makes flying planes so much less tedious.

I wondered though if you could explain how to use the SSAS exactly and what benefits/drawbacks it offers compared to the stock SAS? I'm guessing the interface is obvious to like flight-sim vets and such, but it's a little opaque to my ignorant eyes.

Other thing I was wondering - should SAS be enabled while the pilot assistant functions are operating? Does it even make a difference?

Apologies if any of these are stupid questions!

[Crzyrndm]

SSAS vs. Stock SAS

Stock SAS does something very simple, it locks to the direction you are currently facing, irrespective of how far you travel or where you travel to (eg. a vessel engaging SAS facing prograde at periapsis will be facing retrograde at apoapsis).

SSAS (aka Surface SAS) also locks to a direction, but that direction is relative to the planet surface (eg. a vessel locking to prograde at periapsis will still be pointing prograde at apoapsis).

Because of this simple difference in behaviour, Stock SAS will appear to continuously pitch up as you travel around a planet while SSAS will always hold the same pitch.

The only other major functional difference is that the roll axis unlocks seperately to pitch and yaw when you give control input (ie. you can pitch without affecting the locked bank angle), plus a few minor things like being able to only control pitch and roll and leaving heading floating (useful for banked turns with SAS).

PS: I doubt the interface is obvious to anyone that hasn't used it much. Flight sims (and real aircraft for that matter) hide all the configuration options because no/minimal tweaks are needed when the vessel is always the same. In addition, the Stability system (what KSP refers to as SAS) is a very low level part of the overall system (similar to how it is in Pilot Assistant. There's a whole lot of logic before it reaches the raw pitch/bank/yaw control). KSP is the first time I've ever seen it used as a complete system outside of some microController programs for very small operations.

Enabling SAS or SSAS while Pilot Assistant is functioning

Pilot Assistant will always have the final say on how an axis responds and completely overrides both flavours of SAS when it does so. However you can combine systems that don't overlap, such as having Stock SAS controlling pitch and use Pilot Assistant's Bank/Yaw control for steering.

Basically they peacefully coexist, but any conflicts always resolve in favour of Pilot Assistant.

EDIT

Forgot to mention, SSAS only really works when you aren't trying to go vertical. Not exactly an issue as it has no advantage at all when travelling along a vertical direction.

Edited April 5, 2015 by Crzyrndm

[frencrs]

Currently using this to make the flight to the pyramid anomaly with a large plane and not only does it work great, it's practically a necessity for RSS users; flight time to pyramid anomaly in RSS: 4 Hours, 29 Minutes at transonic speeds (Mach 1.074).

Edited April 4, 2015 by frencrs

[futrtrubl]

When you give it a heading does it stick to that numerical heading or to the same great circle of that heading? IE if I tell it to head 45 degrees towards a very distant target will I still be aiming at 45 degrees an hour later and end up spiraling to the pole or will I now be on a different bearing but still heading towards my contract target?

If it doesn't look at great circles can we get that?

[Crzyrndm]

Since 1.5.0 Pilot Assistant is using great circles for it's heading control, the next update (which I'm just ironing out the final kinks in) will give SSAS the same functionality.

Edited April 4, 2015 by Crzyrndm