# ProjectOpen Universal Autopilots

#### Artlav

##### Aperiodic traveller
Beta Tester
As i mentioned before, odds are i won't be around to finish or improve my add-ons, even the good ones.

But there is one add-on that is both good and open-source friendly, being made in C++ and with extendability in mind.
UAP, the Universal Autopilots.

So...
Here are the sources for it:
http://www.thespaceway.org/files/uap-0.3.1-sources.zip
EDIT 201224: And Github version: https://github.com/artlav/uap

I tweaked them to compile with recent Orbiter, and checked that they still work, but other than that it's as-is.
I don't know what the consensus was on the GPL vs LGPL vs Whatever, so it's released under the "Don't be a dickhead" license (if i missed some development to the effect of "no open source addons are allowed now", please tell me).
I've also included some of the reference materials used.
The most impressive part, transorbit module, is based on OrbiterPEG by Chris Jeppesen, the rest of it is mine as far as i remember.

The system was designed under assumption that other people would write modules for it.
There is an extensive base class that you derive from to make an actual autopilot.
The base class handles the scheduling and housekeeping, as well as abstracting the vessel, providing an intuitive interface at the level of "accelerate this way at this many m/s^2 with this engine set", or "point north".
Since there never was any interest in it, the interface didn't get cleaned up, completed or documented.

The rest of the system are:
-SAL, Simulation Abstraction Layer. This abstracts the simulator (Orbiter, Spaceway) into an API used by the autopilots.
-UAPSYS, the system itself, that handles task scheduling, vessel tracking, state saving and so on.
-UAP MFD, the user interface that shows the UAP info for the vessel you are sitting in.
Basically, the system is designed to run in the background, with the MFD being a terminal into it.

I figured it's better to leave it here with small odds that someone will pick up the work and give it future, rather than not leaving it here with exactly zero odds of it having a future.

If you have any questions, i'm here to answer them.

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
I thought the only legal license was beerware...

Code:
/*
* ----------------------------------------------------------------------------
* "THE BEER-WARE LICENSE" (Revision 42):
* <[email protected]> wrote this file.  As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
* ----------------------------------------------------------------------------
*/

#### jedidia

##### shoemaker without legs
oh, goodie! might be worth looking at integrating these directly into IMS2, now that they're open. Though possibly after actually adding thrusters and RCS :lol:

#### Artlav

##### Aperiodic traveller
Beta Tester
Hm, what is the point of integrating it into an add-on, when you can use a general, independent system?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Hm, what is the point of integrating it into an add-on, when you can use a general, independent system?

One point could be that by integrating it, you can strip off unnecessary code that isn't needed in the current addon.

You can also avoid shipping a component that you have no control of. Think of versioning it - should you include a specific binary, only reference to a download place, hope for all developers doing backwards-compatibility, yaddayadda...

And last but not least, you can keep your code all closed, effectively dodging all the licensing debacle.

Of course all of this or part of it might violate your "don't be a dickhead" license :lol:. I like that license, BTW. :thumbup:

Many thanks for releasing your sources!

#### jedidia

##### shoemaker without legs
Hm, what is the point of integrating it into an add-on, when you can use a general, independent system?

One word: Interface!
The MFD interface sucks for more complex operations (this is a general problem with the MFDs, not UAP specific) and UAP is complicated enough as it is. By integrating it directly I could slap on a more user friendly GUI and some abstraction.

There are additional reasons, like the stock autopilots being mostly useless for IMS, and writing custom autopilots for it being nowhere on my priority list, so this might make for a solid compromise.

And last but not least, you can keep your code all closed

Did not even enter my mind :lol:

#### Artlav

##### Aperiodic traveller
Beta Tester
You can also avoid shipping a component that you have no control of. Think of versioning it - should you include a specific binary, only reference to a download place, hope for all developers doing backwards-compatibility, yaddayadda...
Makes sense, but yet having a libuap of some sort that you take a specific version or fork of makes more sense to me.
You can statically link it, to avoid versioning issues.

One word: Interface!
Ah, i guess i'm too spoiled by Spaceway to remember that Orbiter still does not have mouse input in the MFDs.

Speaking of interface, do you have any ideas on what would fit UAP best?
Even with SW's input capabilities, this is all i came up with:

Which is pretty much just moving the buttons from the sides to the insides.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Makes sense, but yet having a libuap of some sort that you take a specific version or fork of makes more sense to me.
You can statically link it, to avoid versioning issues.

As long as that libuap is not the complete general independent system, that will work. Otherwise you might end up with multiple "general systems" stepping on each others toes if addons link it statically and a user uses both addons simultaneously.

Anyway, I'm looking forward to what people make of it now.

#### jedidia

##### shoemaker without legs
Speaking of interface, do you have any ideas on what would fit UAP best?

I'd have to spend a lot more time with it to come up with something good, but for starters I would do exactly what you did on the image: Put the pages with the steps side by side on the interface. And of course update them in real time as needed when the user makes a change to a previous step.

#### Artlav

##### Aperiodic traveller
Beta Tester
I would do exactly what you did on the image: Put the pages with the steps side by side on the interface.
That was 4 separate images, but i guess i can do the real deal as well.
(pardon the software rendering, am at work)

#### Lisias

##### Space Traveller Wanna-be
I thought the only legal license was beerware...

Double-license it to Baconware, and I'm good!

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
Speaking of interface, do you have any ideas on what would fit UAP best?

Actually, I believe that the classic Soviet interface design concepts are great as inspiration.

http://web.mit.edu/slava/space/essays/essay-tiapchenko3.htm

While a lot of the examples are forced by the technical limitations, the basic ideas about how to present data and interact with the astronauts are good. Similar ideas can be observed in the Cockpit Avionics Update that was planned for the Space Shuttle and which is now getting included in a more advanced form in the Orion spacecraft.

But the modern devices with 3D elements and hardware acceleration essentially mean that the user interface has the same rendering capability and priority as the simulation itself. Not that nice. Makes the old historic examples more attractive.

#### Artlav

##### Aperiodic traveller
Beta Tester
Actually, I believe that the classic Soviet interface design concepts are great as inspiration.
Hm, does not seem to be particularly inspiring.
Just your regular bulky avionics, with an occasional CRT.

I'm thinking more of the "game UI" kind of perspective.

#### Urwumpe

##### Not funny anymore
Donator
Hm, does not seem to be particularly inspiring.
Just your regular bulky avionics, with an occasional CRT.

I'm thinking more of the "game UI" kind of perspective.

I don't mean the technical implementation, but rather the way how data and processes are presented. Many game UIs look cool, but are rather distracting. Also such game UIs rarely present "slow" processes.

#### chalcrow

##### Donator
Donator
I'm interested in developing a readily pluggable UAP for Orbiter. In particular, I want to play with the extra-terrestrial landing phase. If anyone happens to be reading this and you're interested in co-developing this via github, please email me. [email protected]

Beta Tester

Replies
72
Views
5K
Replies
2
Views
275
Replies
34
Views
3K
Replies
6
Views
549
Replies
74
Views
4K