[WIP] Open Avionics

[MeateaW]

Open Avionics

2014-09-02

Just an update, I haven't stopped work.

But in case people are impatient I thought I should mention similar mods (that really should have popped up earlier in my searching!)

http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6)

I haven't downloaded it and tried it out, but it sounds like it is still working in 24.x

This sounds like it does at least two major components of what mine does (rotation torque control with variable engines).

And it sounds like it does what I am currently calling "thrust mode".

Slightly disappointing that I didn't find this before starting work, but I am going to continue my work (since I find it actually fun, not work!).

I am slowly cleaning up my code, with the intention of releasing a first version soon. My initial code was all over the place, and hosted on my works source repository, I have since separated it to my own personal repo, and am considering a github release repository.

I can tell you it now takes into account engine ISP when deciding which engines to use, so when it is in hover mode you can be assured it is using the most efficient combination of engines to achieve it.

Not to mention millions of bugs have met their end.

Once I have finished getting the code so that it implements all the features it used to.

IE

I killed position lock recently in my code-cleanup, it is now back, but I am going to do it better than ever.

I plan to make it choose a velocity that best matches the available thrust, to minimise overshooting your target position.

It did a basic version of this in the past, but large displacement still ended up with big overshoot, which I hope to basically eliminate.

2014-08-22

Fought a lot with trying to implement altitude lock, before I realised that the world-space transform is at all kinds of wiggy angles, some dot products and unit vectors later it all works flawlessly.

I now have Altitude lock, East-West lock and North-South lock. (obviously EW and NS locks aren't quite as useful, individually, but they aren't too bad).

Combined they form 3D-space-surface-position-lock.

I also have movement dampening mode, which holds you still*!

* where still is defined as some velocity** at or below 0.1m/s.

** Rotating isn't considered velocity. (but your SAS can help here)

I would like to apologize right now; for the horrible piloting, and pretty poor example of what everything is doing.

I cut the building since it is less important.

What you are seeing

Most of the video is showing the various position lock methods.

Note the "Movement Dampening" option, that doesn't lock you in a specific location, but does attempt to reduce your surface velocity (in all axes) to zero.

When you hit a translation key, the dampening limits the maximum velocity you can get, and after letting go of the translation key the movement dampening halts your movement.

2014-08-11

First post.

I am working on remaking from scratch the KerbComAvionics module that appears no longer maintained.

see: http://forum.kerbalspaceprogram.com/threads/29387-0-21-x-KerbCom-Avionics-0-3-0-6-Alpha-(29-August)-now-with-video! for the original.

Due to the license around that module (CC no Derivatives); (and the complexity of the code) I have had to re-implement everything. (I had intended to refurbish, and contact ZRM to get permission to release, but I honestly couldn't figure out how to get the mod to work, and had literally no idea where it was actually doing anything)

ZRM had identified an open source solver, so I had a library to begin work with. And luckily about 7 years ago I took a single subject at uni that covered Linear Programming (the type of mathematics to solve this species of problem), so the whole concept wasn't foreign - and the library was doing the maths-heavy part. But; about 3 weeks of fairly solid development time (that have severely impacted my output at work! ssh don't tell!) the above is where I am at.

Some history

ZRM began his mod; as a way of simplifying RCS thruster placement. By automating the output intensity at each nozzle; he would ensure no errant torque from poorly or imbalanced RCS thruster placement. Eventually after ZRM completed these tasks, he moved on to balancing everything; from Gimballed engines, Reaction Wheels and RCS simultaneously. All whilst (apparently) taking the most fuel efficient route.

what I have right now

I am no where near the complexity of ZRMs implementation.

I solve exclusively for Torque and Translation using Engines right now.

I do take into account Solid Rocket Boosters (I don't believe ZRM ever bothered).

I do take into account Gravity (this is useful for arresting translations)

I do not take into account Gimbals.

I do not take into account Reaction Wheels.

I haven't even considered what I am going to do about RCS yet.

Gimbals and Reaction Wheels are important when we start thinking about Fuel Efficiency. To be honest; I am not sure I can figure out how to plug efficiency numbers into the solver. And from the moment I decided to re-implement I have specifically avoided looking into ZRMs code.

My code is ugly right now, and I have only just today gotten it to do what I actually intend. (The above video was made about 1 hour after the maiden flight of the solver model that first actually worked as intended).

Does it really work yet?

Mostly!

See (skip to 3:30 for the actually interesting part!)

What you are seeing here:

The solver is currently configured to cancel gravity.

When at full throttle there is a slight vertical acceleration (I think this is rounding error)

I use the rotation and translation controls to modify the constraints of the model.

So; if I hit the RCS 'Translate Up' key; the model no longer solves for zero upward translation, and instead adds some amount of upward translation into the "solution".

A quirk you'll notice, is when I "Translate Down" it turns out that gravity is still greater than the amount of translation I pass in. So there is no "downward" thrust; just a massive reduction in the force counteracting gravity.

It is of course using infinite fuel - the only practical way to perform on-pad testing.

I left the reaction wheels in place; but 99% of all rotations and translations are performed by the Rocket Engines.

You will notice that SAS performs amazingly well with the solver in place. SAS was a perfect fit for precisely calculated torques. It isn't great for the reaction model (you get lots of bouncing back and forth), but when your engines produce the exact torque required to right the ship; SAS has a firm grip and rarely gets it wrong.

Why am I making this? And what will I do with it

Well; think about all those times in vanilla KSP where you had an imbalanced rocket. There weren't many.

Now think back to the first time you ever tried to perform an Asteroid Redirect, and how easy it was to just claw up and push in the direction you actually wanted to go.

It is the ARM that really got me to think about this.

I intend to release this code under a very permissive, to near completely permissive license.

I am thinking of something like a; Creative Commons - Attribution, (but maybe even less restrictive than that?)

Edited September 2, 2014 by MeateaW
Progress update

[blackheart612]

That testing looked totally awesome I must say. Haha.

[MeateaW]

That testing looked totally awesome I must say. Haha.

When it finally did what I was hoping for it turned out quite fun!

I did have one build that would always be moving sideways; but always at a stable altitude, I made a hover car and had some fun with that.

Which leads me to think that perhaps a few mode could be implemented - "Stable Altitude" mode; where it tries to keep a craft x meters off the ground.

I am also considering a "landing mode" which uses your engines and evenly slows you down based on altitude, so you always get perfectly soft landings. The precision the solver lets you get is pretty good. In some tests I was controlling my speed down to 0.1 m/second, and that was without any guidance systems trying to keep me horizontally stationary.

[blackheart612]

When it finally did what I was hoping for it turned out quite fun!

I did have one build that would always be moving sideways; but always at a stable altitude, I made a hover car and had some fun with that.

Which leads me to think that perhaps a few mode could be implemented - "Stable Altitude" mode; where it tries to keep a craft x meters off the ground.

I am also considering a "landing mode" which uses your engines and evenly slows you down based on altitude, so you always get perfectly soft landings. The precision the solver lets you get is pretty good. In some tests I was controlling my speed down to 0.1 m/second, and that was without any guidance systems trying to keep me horizontally stationary.

Sounds neat, I like the hovering idea, dibs on it!

[MeateaW]

2014-08-22

Updated!

Includes new video, and various position locking.

[NathanKell]

This sounds awesome!

[MeateaW]

Thanks Nathan, working on making it actually useful, right now it runs using MaxThrust and assumes maximum throttle, I need to get it to do its work based off real-time available thrust, maybe with some smoothing or other special treatment for jet engines.

[NathanKell]

It'll be engine.requestedThrust, multiplied by engine.velocityCurve.Evaluate(currentSurfaceVelocity.magnitude) if there's a velocityCurve.

[MK3424]

Can it also be used for RCS and/or with the new engine nacelles?

[MeateaW]

RCS is still on the to do list, and I haven't yet tackled it.

In a way however using real engines is better, since the ISP of RCS is pretty poor. (The biggest advantage it has is no worries about hooking up fuel)

The new engines should be working the same way as the older engines, the only proviso is I haven't confirmed what it does with the RAPIER yet, but since atmosphere mode of the RAPIER is similar to a jet engine it sort of isn't worth getting confused over till I have a better solution in place with them.

Also, with engines like the new cluster engines from the NASA pack it would be great if they were actually 4 separate engine modules, as then with those alone I could do some torque control with them, but sadly as far as I can tell they are ultimately throttleable only as a single unit.

Maybe one day I'll override the engine module and split up each engine by its own nozzle, and vary the output independently , but that is a whole lot of work for a grand total of 2 parts. (Maybe 3 if the RAPIER is considered 4 thruster transforms... Sounds a little silly though)

Edited August 23, 2014 by MeateaW
auto correct failure

[NathanKell]

I too have been wishing I could specify the amount each thrust transform will add; right now it's a flat thrust = 1 / (num_transforms).

With that we could have the gas generator exhaust act as a vernier

[MeateaW]

Just an update, I haven't stopped work.

But in case people are interested I thought I should mention mods (that really should have popped up earlier in my searching!)

I have found this:

http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6)

I haven't downloaded it and tried it out, but it sounds like it is still working in 24.x

This sounds like it does at least one major component of what mine does (rotation torque control with variable engines).

And it sounds like it does what I am currently calling "thrust mode".

I am slowly cleaning up my code, with the intention of releasing a first version soon. My initial code was all over the place, and hosted on my works source repository, I have since separated it to my own personal repo, and am considering a github release repository.

I can tell you it now takes into account engine ISP when deciding which engines to use, so when it is in hover mode you can be assured it is using the most efficient combination of engines to achieve it.

Not to mention millions of bugs have met their end.

Once I have finished getting the code so that it implements all the features it used to (I killed position lock recently in my refactor, it is now back, but I am going to do it better than ever).