Project Universal autopilots

[Artlav]

Was there already made, and is there an interest for universal autopilots?

What i have in mind is a modular set of universal autopilots for different situations and all kinds of vessels, linked by a centralized system. Thus, you can give it a command to get this vessel there, and it will break up the goal into steps and let the autopilots execute it - take off, launch into orbit, transfer, orbital insertion, landing, each a separate module.
Alternatively, one should be able to define a sequence of actions - take off, hover for a minute, do a barrel roll, land, for example.

I'd imagine quite a use for such system - how often did you wanted the computer to do the now-boring part of the game? Instead of tenuously fly a set of vessels from one jovian moon to the other, to fly one interesting one, and unpack the base while watching the others arrive and land?

Thoughts? Ideas? WTFs?

EDIT: Alpha release discussion there: http://orbiter-forum.com/showthread.php?t=14704

 

[garyw]

Overall I like the idea, I'd love to be able to launch a cargo ship like progress, ATV or Shuttle-C almost on remote and then 2-3 days later see it dock all on it's own.

It would also be useful for ASAT or other interception style addons...

I'm less keen on the idea for human crewed vessels as I quite like doing that stuff myself.

 

[Loru]

Nice idea - I hope it wil be better than redshift

 

[MeDiCS]

Would each vessel need a customized 'autopilot module'? Or you'll get the vessel parameters dynamically?

Also, some modules could be generalized. Instead of having, for example, different take-off/enter orbit/reentry/land autopilots, have one that'll make the vessel go from point A to point B, while taking into account specific limitations (such as fuel and vessel integrity).

I could also help programming it if ya need :thumbup:.

 

[Zatnikitelman]

I like the idea! It sounds good to me!

 

[Artlav]

Would each vessel need a customized 'autopilot module'? Or you'll get the vessel parameters dynamically?

I hope to get them vessel-independent, but there should be an option for the user to define which thrusters to use, for example.


Now, in the scratch, there is the system description:
All autopilots are inherited from a basic class.
In the basic class there are a set of primitives:
-Give that much acceleration that way using these groups.
-Give that much momentum '----' with RCS
-Give that much momentum '----' with surfaces
-Get major gravity acceleration local vector

Based on that, more complex ones:
-Point and keep that engine this way
-Set (and/or keep) that orientation
-Hold this speed relative to that

And, some more. Also, something about trajectory prediction and control primitives.

Inherited from that class are the actual autopilot modules of two types - permanent and sequential, one can be both. Permanent are things like orient to zenith, cancel gravity, hold speed. Sequential - launch into orbit, take off from a runway, land onto a pad, etc.

The set of autopilots can be pipelined, linked into a sequence one after another, allowing full flight plans to be automated.

Also, an MFD to set and control the thing.

A first, the sequences are to be defined by user.
Further on, an automatic optimizer can be made for making them out of "get this to there" requests.

could also help programming

On that topic, yes. It sounds too good for me alone to almost make over indefinite time, so open development is quite an option.
If the above said framework is discussed, set, and perfected, anyone can write autopilots for it. I'd expect it can be an open-source monoblock or semi-opensource linked modules.

There are many developers who already made different autopilot tools - launch MFD, reentry, IMFD, TransX, various base-to-base ones, etc.
If some of them can and agree to implement a good quality autopilot on the framework, the development will go faster and with better end result.

So far, i'm thinking and trying to get framework functions of appropriate quality, with most of Intermod 2-level functionality stuff working nicely.

Any thoughts?

 

[RisingFury]

I'm working on a general autopilot / AI for the OBSP system. The ultimate goal is to have autonomous interplanetary travel, but currently I'm only focussing on winged craft...

I've been promissing a video of formation flying for a while now, but pitch control seems to be a pain in the ass...


The way I'm doing things is by having a function that takes desired pitch, heading and yaw and uses control surfaces to turn the craft. Another function takes a desired location on the planet, latitude, longitude and altitude and current vessel location and calculates the desired pitch and heading and passes it to the other function.

Currently I'm only focussing on navigational flying within the atmosphere, but I've set the function up so that I can expand it to high altitude, high speed flight and space flight.


The problem currently is getting the velocity vector to pitch into the desired pitch, instead of just the nose. I hope I findally found a system that works though. If it does, I'll post a vid soon...

 

[Artlav]

Currently I'm only focussing on navigational flying within the atmosphere, but I've set the function up so that I can expand it to high altitude, high speed flight and space flight.

So, can your system be broken into or be based off some primitives, like the ones i described? Any descriptions of it or suggestions for the project discussed?

 

[Donamy]

Would this include animations, eg. staging, chutes ?

 

[markl316]

I know computerex made something like this, but different. It had like hold attitude, hold altitude, hold AOA, hold airspeed. It was called autohover MFD, and I still have it, if you need it, with computerex's permission, of course.

 

[Artlav]

Would this include animations, eg. staging, chutes ?

Sorry?

I know computerex made something like this, but different. It had like hold attitude, hold altitude, hold AOA, hold airspeed..

So did i, a thing called Intermod. But, such things are not what this project is about. I want to make a system of separate and sequentiable autopilots that you can set up in for a task or use for separate steps.
The closest thing to that is the discontinued RedShift system.

 

[jedidia]

Sounds like the first step to introduce AI into orbiter, which would suit my long term goals (like, my goals for the next 20 years or so...), so this gets my wholehearted support.
However, isn't there an OGL-client you should be finishing first?

 

[Artlav]

However, isn't there an OGL-client you should be finishing first?

That never stopped, and seeing the lack of Orbiter updates, tilted to another engine for a while - http://orbides.1gb.ru/planeter-gal.php?lng=eng . In any case, OGLA is useless here until O2010 is out, while UAP can be useful right now.

 

[jedidia]

since you bring up spaceways, I haven't yet figured out two things:

1. How do you use a stargate (I can dial and activate, but it doesn't seem to take me anywhere), and
2. are there any hover thrusters? I made a landing on some martian planet yesterday with a few hundred kilometers roll-out :lol:

anyways, OT.

I would very much welcome a universal set of autopilots!

 

[MeDiCS]

Would this include animations, eg. staging, chutes ?

Sorry?

I think he's referring to the use of boosters, fuel tanks and parachutes by the autopilot.

I'm specially interested in how it will work with atmospheric flights, taking into account damage simulation (heating, wing stress, max Gs) and winged flight.


As far as the primitives go, everything's nice, but I think that sequential autopilots should be a bit more generic. As I've posted, instead of having a 'from A to B' autopilot built from 'take off', 'hover' and 'land', do the reverse. Have an atmo autopilot, that'll get you from A to B inside the atmosphere, an orbit autopilot, doing the same in orbit, and interplanetary autopilot, which would handle anything between planets. If you're landed at Cape, and want to got to Wideawake, the atmospheric autopilot would plot the trajectory inside the atmosphere and use the primitives to get there. Then, based on those generic autopilots, 'land on runway X from heading Y' or 'land on pad Z' could be easily implemented, even from a simple INI file.

 

[cinder1992]

You might want to add some sort of logic system to it, otherwise the autopilots will only be functional ONCE. I.E.

IF altitude IS < 600 THEN pitch +20.

OR

IF E.inclination IS = 90 AND ecc BETWEEN 0, 0.1 THEN engines = 0

 

[jinglesassy]

You might want to add some sort of logic system to it

Great giving spaceships ai to fly themselves from launch to landing no of course that cant go wrong especially if you make it really intelligent :lol: but sounds good artlav.

 

[cinder1992]

pure logic IS NOT AI.

fuzzy logic ~ AI.

NOTE: The caps are to emphasise the fact that the statements are pure logic, not to yell or be a general annoyance.

 

[Artlav]

As far as the primitives go, everything's nice, but I think that sequential autopilots should be a bit more generic.

You might want to add some sort of logic system to it, otherwise the autopilots will only be functional ONCE.

It's not quite that generic.
There is a base class that all autopilots are derived from:

class iautopilot{
public:
 iautopilot(VESSEL *vessel);
 ~iautopilot();
 
 double give_thgrp_accel(double acc,VECTOR3 dir,int groups);
 void stop_all_engines();
 double get_thruster_isp(THRUSTER_HANDLE th);
 double get_group_isp(int tg,int ismax);
 VECTOR3 get_group_thrust_vector(int tg,int ismax);
 VECTOR3 get_major_gravity_local_acc_vector();
 double get_group_thrust_angle(int tg,int ismax);
 double get_bank(int grp=0);
 double get_pitch(int grp=0);
 double get_pitch_horizon(int grp=0);
 double get_slip_angle(int grp=0);
 double get_heading(int grp=0);
 void set_rotation_rcs_levels(double p,double y,double r,int grp=0);
 VECTOR3 get_angular_vel_grp(int grp=0);
 void make_horvecs(VECTOR3 &wing,VECTOR3 &tail,VECTOR3 &nose,int grp=0);
 virtual void step(double SimT){}
 virtual void start(){}
 virtual void stop(){}
 
 int is_started,is_running,is_finished;
 VESSEL *us;
};

The class supposed to provide all the necessary primitives to write autopilots independent of the engine or vessel used, allowing to concentrate on the actual guidance code.

Over it, the autopilots are quite not that simple.

For example, i've already made hover from pad and turn to heading autopilot and launch into orbit autopilot, both working with whatever engine user specifies - main, hover, rcs, etc. Thus, you can launch DG from the Moon to orbit on retro engines, for example.

The base class provides sequencing methods, so each autopilot can signal when it's done and if it was successful, and the main system kicks the next one into action.
The sequence can be defined or read thru an MFD, and is planned to be defineable from add-on vessels or files.

I think he's referring to the use of boosters, fuel tanks and parachutes by the autopilot.

Could be done, if animations are key-triggered, one might be able to add a key press into the sequence, or something like that.

I'm specially interested in how it will work with atmospheric flights, taking into account damage simulation (heating, wing stress, max Gs) and winged flight.

Hard to say, i only made a rather ballistic launch autopilot so far.

since you bring up spaceways, I haven't yet figured out two things:

To Spaceway forum/comments or PM please.

 

[MeDiCS]

You might want to add some sort of logic system to it, otherwise the autopilots will only be functional ONCE. I.E.

IF altitude IS < 600 THEN pitch +20.

OR

IF E.inclination IS = 90 AND ecc BETWEEN 0, 0.1 THEN engines = 0

I can't quite understand you about adding logic. I mean, it seems you're suggesting some type of COBOL interpreter...