[1.3] kOS Scriptable Autopilot System v1.1.3.0

[togfox]

Check my blog Steven. My last blog post just a few days ago touches on exactly what you're talking about. That web link ER posted above is the easiest though as it doesn't require an install.

The link is under my name <-- over there.

[Agathorn]

You math people. Makes my head hurt.

[Dappa]

But a bit of proper maths can make a beautiful script! So it's well worth the head-hurting.

[Camacha]

Have you guys seen the new RISC kOS variant? Any chance those performance gains will be seen in this version of kOS?

You math people. Makes my head hurt.

Head hurting prevents other hurting And seeing a solver working like clockwork is a thing of beauty, of course.

Edited February 23, 2014 by Camacha

[Camacha]

Doppelpost.

[erendrake]

Another pre-release! I think this is the last pre for the direct control and docking milestone

https://github.com/erendrake/KOS/releases/tag/v0.11.1RC

NEW STUFF

• Added to BODY:ATM:SEALEVELPRESSURE
  
• Added Ctrl+Shift+X hotkey to close the terminal window (jwvanderbeck)
  
• Added a DockingPort Part Type, You can access it by "LIST DOCKINGPORTS IN ..."
  
• Improved RemoteTech integration (jwvanderbeck)
  
• SHIP:CONTROL:NEUTRALIZE releases the ship from KOS direct control.
  
• Added PART:CONTROLFROM which centers the transform on that part.
  
• Power requirements are now directly tied to the active volume's size, the ARCHIVE's size is unlimited so it is capped at the equivalent of 50KB.
  

[Zander]

There is still no command reference with all the commands. Can we please get a full command reference with all commands.

[erendrake]

There is still no command reference with all the commands. Can we please get a full command reference with all commands.

Its the very next thing for me to do after i get v0.11.1 released, I have http://erendrake.github.io/KOS/ but i would not consider it complete

[Luis]

Added Ctrl+Shift+X hotkey to close the terminal window (jwvanderbeck)

Thank you erendrake and jwvanderbeck! This makes it possible to execute whole scripts from macro keyboards.

[Zander]

Hi erendrake I first wanted to thank you for your quick replies. You are very responsible.

I have a question. How can I find the pitch which can be set with lock steering to heading 90 by x.

So... how can I "print x" so to speak?

[erendrake]

Hi erendrake I first wanted to thank you for your quick replies. You are very responsible.

I have a question. How can I find the pitch which can be set with lock steering to heading 90 by x.

So... how can I "print x" so to speak?

Sorry i missed your message.

That is a bit of a strange one, and something you should be able to do but cannot easily.

The problem is that when you create a HEADING the values you supply get a bit mangled. I think you should be able to

SET FOO TO HEADING(90,0,0).
PRINT FOO:PITCH. //SHOULD give the pitch back to you

Looks like i have work to do

[frencrs]

Just started using prerelease from github, new getters and setters add an amazing amount of potential. Thank you for this excellent work erendrake.

[erendrake]

Just started using prerelease from github, new getters and setters add an amazing amount of potential. Thank you for this excellent work erendrake.

You are very welcome. Im not the only one who works on this and i know everyone appreciates the support

[Camacha]

There are some really nice things in the new release. A couple excite me, because they allow for some neat stuff that I have been wanting to do for a while now:

- THRUSTLIMIT (get/set)

- Improved RemoteTech integration

- GETTERS YAW/PITCH/ROLL

- Direct control (previous release)

I think the vector math will be pretty useful too, although I desperately need to brush up on that.

I am also slowly coming to terms with what direct control means as a replacement for the magic lock command. It generally complicates stuff dramatically and in most cases mathmatical modelling is not an option anymore, but from an engineering point of view things are a lot more interesting. For me this pretty much transforms KSP from a fun toy into an educational tool.

Edited February 28, 2014 by Camacha

[Joe32320]

I have a question, is it possible to lock steering to the retrograde marker that appears on the navball when in surface mode, the normal "lock steering to retrograde" locks the ship to the retro marker in orbital mode, is there an equivalent for the surface navball mode?

[Dunbaratu]

I am also slowly coming to terms with what direct control means as a replacement for the magic lock command.

I'm considering making my own subprogram to do what lock steering does, not for the same reasons you have, where you basically see it as a sort of cheating, but because it's going to be easier to control things the way I want them controlled that way.

I do most of my steering by vector math and one disadvantage that has is that when you transform a vector into a Euler rotation (which happens behind the scenes in the steering algorithm for 'lock steering'), you lack roll information. From an information theory point of view, both a Euler rotation and a Vector contain the same *amount* of information. The tradeoff is that Vectors have length information but lack roll information, while Euler rotations have roll information but lack length information. So when you 'lock steering' to a vector, you can't control which way the ship is rolled. This is usually okay for rockets which have axial symmetry so you don't care which way it's rolled, but its a big problem for airplanes.

[Osyr]

Hi, I'm trying to execute

WHEN ALTITUDE > BODY:ATM:HEIGHT THEN { AG1 ON. }.

and getting "Flagrant error on line 0." The same for the line

PRINT ship:mass * body:mu / (ship:maxthrust * (body:radius + altitude) * (body:radius + altitude)).

but when I write

SET m TO ship:mass.

PRINT m * body:mu / (ship:maxthrust * (body:radius + altitude) * (body:radius + altitude)).

it works. Can anyone tell me what's wrong?

[Camacha]

I'm considering making my own subprogram to do what lock steering does, not for the same reasons you have, where you basically see it as a sort of cheating

Well, I feel cheating is mostly defined by a dishonest advantage when it comes to competition, and that cheating is therefore unlikely when it comes to a game you play by yourself. There are, of course, some exceptions when participating in challenges and competition where you compare performance, but you get the idea. However, I play KSP partly because I feel it gives me new insights into the difficulties of space flight and engineering in general. Getting solutions handed to me goes against that and that is why I do try to eliminate that as much as possible. This is why I use the term magic numbers a lot - it is not fair to call it cheating as everyone should play the game the way they want to, it is just a recognition of the fact that the numbers are provided by external parties.

I do most of my steering by vector math and one disadvantage that has is that when you transform a vector into a Euler rotation (which happens behind the scenes in the steering algorithm for 'lock steering'), you lack roll information. From an information theory point of view, both a Euler rotation and a Vector contain the same *amount* of information. The tradeoff is that Vectors have length information but lack roll information, while Euler rotations have roll information but lack length information. So when you 'lock steering' to a vector, you can't control which way the ship is rolled. This is usually okay for rockets which have axial symmetry so you don't care which way it's rolled, but its a big problem for airplanes.

Yes, that is a difference of which I am starting to recognize the practical implications. Up until now I have spent most of my time developing throttle capabilities - I had some fun creating mathmatical models that are intended to be as universal and vehicle non-specific as possible. With the advent of direct control I can finally turn my attention to control logic. Although the time I can spend on this is much more limited now and will be for a while, I can already see that the nice and neat type of models that would work so well for throttle control are probably not going to work for attitude control.

Right now I am trying to figure out whether duplicating the lock system is the best way to go, or that a new approach will yield better results. I somehow feel that effectively copying what already exists is not very useful - a new system should add capabilites. Pretty much what you said

Edit: posting this got me thinking about my throttle control script again and it gave me an idea on how to apply the results of the model in a more practical way - hopefully eliminating the guestimating needed to compensate for fuel consumption and aerodynamic drag at the same time. Back to the drawing board!

Edited February 28, 2014 by Camacha

[Lenar]

Hi, all,

I'm using RemoteTech2 together with kOS, and trying to aerobrake my probes. Of course I need to fold the antennas during the aerobreaking, but kOS stops steering the probe as soon as the antennas are deactivated, and the probe tumbles through the atmosphere and partly explodes (DRE+FAR). But the antennas reactivate as planned. So kOS must be working, even if there is no RemoteTech connection. The program I run before entering the atmosphere looks like this (AG10 are antennas and solar panels).

lock steering to retrograde.
wait until altitude < 60000.
toggle ag10.
wait until altitude > 61000.
toggle ag10.

So, locking seems to be not working while the remote connection is broken. Is this actually the intended behaviour?

[Camacha]

Are you absolutely sure the locking does not work, instead of being overpowered by aerodynamic forces or something like that?

[Dunbaratu]

This is why I use the term magic numbers a lot - it is not fair to call it cheating as everyone should play the game the way they want to, it is just a recognition of the fact that the numbers are provided by external parties.

But where I disagree is the very notion that the numbers are magic, and just how "external" those parties really are. The reason NASA can succeed at putting a probe in orbit around Mars is because NASA already knows what BODY("Mars"):Mass and BODY("Mars"):Radius are. It seems silly to have to re-measure it every time once it's been calculated by scientists back home. Either it's calculated already before even the first probe is sent, or if it does require a probe it's only unknown once, the first time, then after that they'd add it as a constant to look up in all future software.

Secondly, it's an utter pain to show off your software to other people if you have to put "spoiler alert" and mask off parts of it.

That's why the only sort of keeping data out of the BODY structure that I'd accept as being okay is if it *IS* there in the structure, but masked off until your career mode campaign has measured it (as described in the post I made earlier). (And in the case of sandbox mode it's not masked off). That way I can still say "here's the code" without it containing spoilers because all people will see is a call to BODY():something and they won't know the actual number unless they're playing sandbox or have gotten that far in their career mode game. It allows me to show 100% of my code rather than only 99% of it and having to hide the private database of stuff I learned in my career.

[Lenar]

Did another test while outside atmosphere.

lock steering to retrograde.
wait 1.
toggle ag10.
wait 10.
toggle ag10.

The ship starts to spin towards retrograde, but when the antennas deactivate, it just spins past retrograde. When the antennas come back, the lock works again, and the ship steers to retrograde.

Btw, I tried this with kOS 0.10 and 1.11.1RC and both have the same behaviour. Oh, and it's RemoteTech2 1.3.3.

[Camacha]

But where I disagree is the very notion that the numbers are magic, and just how "external" those parties really are.

I guess you are referring to the discussion in the development thread I was talking about how commands in degrees are translated into direct input commands. I would consider that magic, as it takes a part of the workload that is usually reserved for the player and transfers that to the computer without user input. In this case, the external party is kOS, which provides the input numbers needed for the desired result.

I think the database discussion is best reserved for the development thread

[kaesekuchen]

I guess you are referring to the discussion in the development thread I was talking about how commands in degrees are translated into direct input commands. I would consider that magic, as it takes a part of the workload that is usually reserved for the player and transfers that to the computer without user input. In this case, the external party is kOS, which provides the input numbers needed for the desired result.

I think the database discussion is best reserved for the development thread

Sorry to barge in on the conversation you two are having, but i felt the urge to comment myself on the "magic numbers" argument.

In my oppinion, wheter or not it's considered cheating, would depend on the way you look at it (well, duh.)

I think what this conversation is really about is, what is acceptable from a "roleplaying" point of view.

For example, automated steering:

You "tell" the ship, with a single command, to change the heading to a specific rotation and internally the "optimal path" to this rotation gets calculated and applied.

Is this cheating in a broader sense? I think it's not, since you don't simply change the rotation in one step by telling the underlying engine to do so, but instead you use a multiude of commands on a higher level to achieve this rotation.

Is this cheating in a "roleplaying" PoV ? Probably yes, unless you have a module on board, that adds a certain mass to your vessel, to account for the additional "hardware" your vessel requires to be able to achieve it. This basically comes down to balancing the tradeoffs one has to consider, when designing a vessel. Let's say you have a small probe, that just barely scratches the 1t mass.

If you want the comfort of "automated steering", you have to add a module that masses 0.3t(arbitrary number) to it, which could make the vessel desing unfeasible. So instead of taking this module, you might consider using a "manual steering algorithm" to keep the mass low.

So to sum it up, my oppinion is, that during the development process, "ethical" questions shouldn't be granted much merit. If there is a shortcut available, it should be made available. Later on, the gameplay tradeoffs can and should be considered.

Be it via high cost, certain resource consumption, aerodynamical / design drawbacks or anything else that comes to mind.

[marianoapp]

I'm considering making my own subprogram to do what lock steering does, not for the same reasons you have, where you basically see it as a sort of cheating, but because it's going to be easier to control things the way I want them controlled that way.

I do most of my steering by vector math and one disadvantage that has is that when you transform a vector into a Euler rotation (which happens behind the scenes in the steering algorithm for 'lock steering'), you lack roll information. From an information theory point of view, both a Euler rotation and a Vector contain the same *amount* of information. The tradeoff is that Vectors have length information but lack roll information, while Euler rotations have roll information but lack length information. So when you 'lock steering' to a vector, you can't control which way the ship is rolled. This is usually okay for rockets which have axial symmetry so you don't care which way it's rolled, but its a big problem for airplanes.

You could use a Rotation for the steering that is the result of adding your vector to a rotation that only has a roll component (similar to the "up + R(0,0,180)" that is in most scripts). If you don't know the roll before hand you will be able to get it from ship:facing:roll (this feature is in my fork of kOS but it will be merged soon).