Project Launch MFD development thread

[Zachstar]

Havnt you blown enough minds?

Even tho I do not understand most of the epic math going on I still enjoy reading your updates.

 

[Enjo]

OK, guys! It calculates a solution!

http://orbiter.rox.pl/pliki/LaunchMFD-da-solver.zip

Before you do touch any of the loop buttons, press Restart button to calculate great circles of the ship and of the satellite and get input values. You'll have to press that button each time you change any of the parameters. One exception is the Solve Time-efficient button which does the Reset automatically

All of the input boxes accept parameters in degrees, except scale. The bigger the scale, the more you'll see.

Note that apart from invoking the loops via buttons, you have some handy accelerators defined in Menu -> Loops. What looks good is satellite's movement triggered by Inner Loop accelerator (F2) seen from a bigger scale

There are also some problems with the app, one of which is inability to find solution sometimes. There's a maximal limit of 5000 iterations. If the algorithm can't find a solution after the 5k iterations passed, it quits, because it usually means that it's in an endless loop.

Go ahead and play with the app, but whether it will work in Orbiter or not, is another thing

---------- Post added at 05:56 PM ---------- Previous post was at 01:57 PM ----------

Some more info for those who may want to implement their own Map MFDs:

I've found this, very informative page:
http://williams.best.vwh.net/gccalc.htm
It contains equations needed to perform certain calculations on a subpage:
http://williams.best.vwh.net/avform.htm

Remember that I told that I find a point on a GC numerically? Well, that's not the best solution because it's slow. What will surely speed up the calculations is an example that can be found here:
http://williams.best.vwh.net/avform.htm#Example
( look for "The point 40% of the way from LAX to JFK is found by:" )

---------- Post added 02-19-10 at 11:12 AM ---------- Previous post was 02-18-10 at 05:56 PM ----------

Some significant fixes:

In the previous version you could have seen that after setting a latitude bigger than about 1/2 of the inclination you'd get erratic results. This is fixed now.

After fixing this I've also noticed another problem. In an extreme situation where you start from latitude almost equal to inclination and cross the target orbit in the middle, where the relative angle is the greatest, you'd see situations like this:

Resulting in big relative velocities upon insertion which is not the point of these calculations. By using a closed loop after beginning the turn, I could get smaller relative angles like below:

You can see that the relative angle is also significant on the way, but starts decreasing - the ship first turns left, and in the last seconds it begins to turn right to match up with the orbit. This takes some more CPU time, but at least it's more correct.
As I said, this is an extreme situation. Normally, you'll see situations like this:

like for the case of Cape and ISS.

Another, not much visible update was concerning finding a point on a GC. I borrowed the equations from the web page I mentioned previously, so it's not numerical anymore. A profiler could tell if it's faster, but for sure it's more accurate.

As usual, you can get it here:
http://orbiter.rox.pl/pliki/LaunchMFD-da-solver.zip

 

[Enjo]

And finally, here's the algorithm ported to Launch MFD:

http://orbiter.rox.pl/pliki/LaunchMFD-v.1.3.2-2009-BETA.zip

Of course there are still errors, although it should work for all latitudes and inclinations. I usually end up with +/- 300 km from the ISS, which is unacceptable, but at least reproducible for a given pair of latitude/inclination. My bet is that the problem lies in the turning part of the algorithm, which assumes that the ship moves on a flat surface which is just wrong. However this is just a subroutine and its internals can be replaced some day without having to redesign everything from scratch.

You'll have to press the DEF button twice to get a working solution. That's probably a problem of some uninitialised variable. To do later.

Also, you'll get one solution of several possible ones, which ultimately differ only by constant velocity flight time. I think that it's best to aim for the lowest const vel flight time (about 500s). If you got a greater time, then you have to wait until the waiting time passes and then perform a recalculation.

Remember about the limitations:
- space station should be very low (15 km - already set in DirectAscentTest.scn)
- no atmosphere, or cutoff alt lower than the space station
(15 km - set the following in Earth.cfg:
;AtmAltLimit = 200e3 ; cutoff altitude [m]
AtmAltLimit = 10 ; cutoff altiude [m] )
- only northern launches and latitudes for now ("let's get it working first" principle )

 

[Enjo]

In the last episode, I asked tblaxland if it was possible to use KOST to simulate changes made to orbit by accelerating in some direction. This is to counter the problem of 300 km error from the previous post. He replied that it isn't possible in KOST. I tried it by updating an orbit's parameters in each iteration and indeed - it's impossible or at least I can't do it.

So I've implemented my own, simplified version of KOST-like solver, although a numerical one, and here is what I'd like to share / brag about in today's update of my Launch MFD blog - a huge, numerical plane change maneuver in 3D space, just waiting to be used in the DA-solver if the author had more free time.

BTW. I found a great resource for algebraic computations (and not only!)
http://www.euclideanspace.com/maths/geometry/rotations/theory/inaPlane/index.htm
http://www.euclideanspace.com

Nicely commented Scilab scripts attached.

 

[Enjo]

An update regarding artificial intelligence in Launch MFD:
It seems that fuzzy logic is a great way of dealing with those naive iterative numerical algorithms which have more or less constant increments that lead to the exact solution. The fuzzy logic approach adjusts its increments to the current situation, ie. the closer it is to the solution, the smaller the increments will be (hence "intelligence" - it KNOWS!).

Here you will find an example Java application which uses a self-contained Java Fuzzy Logic Engine from:
http://people.clarkson.edu/~esazonov/neural_fuzzy/loadsway/LoadSway.htm
by prof. Edward Sazonov.

My example is a proof of concept of what will be (un)seen in Launch MFD - for example calculating some problems in max 15 iterations instead of 50. It doesn't sound very impressive indeed, but my stuff is just an example of what can be done with that Fuzzy Engine. I see other uses for the fuzzy logic in Orbiter, like autopilots (see the original example). I remember that Face was doing such experiments with his PID MFD.

The problem with controllers in general is that before you use them, they must be adjusted first. For example, see how my controller fails to calculate solution when velocity is ~ 0.5. This means that it's still incorrectly adjusted.

To make the Fuzzy Engine usable in Orbiter, I must first port it to C++. I think that summer holidays will be just enough for that

 

[Enjo]

What I thought would take me summer holidays, actually took me one Sunday + half of a week of setting up everything.

Here it is, folks: libFuzzyEngine++ - a GNU GPL licensed library, a C++ port of the previously mentioned Fuzzy Engine for Java. The archive contains project files for Code::Blocks and MSVS 2005. The first doesn't allow for creating .lib import library, used by MSVS. In the examples directory you'll find an example program, which can be used to implement a fuzzy controller already. In the bin directory, you have the exemplary program's executable, import and dynamic libraries. inside the src, you have the include directory which should be added to your project.

When I find some time, I'll provide an exemplary fuzzy controller for autopilot. I'll probably already incorporate it into Launch MFD.

Before I start a Sourceforge project, I must first provide this library with doxygen documentation and autobuild tools, so it can be called a serious library... Also, some code restructuring should be done, and some missing features implemented, like blocks of rules. Then, the lib will deserve a special, separate announcement... if anybody cares


All set. I have all the mini blocks prepared for a (hopefully) straightforward further Launch MFD and Direct Ascent development for my graduation.

 

[Zachstar]

Tis as if a thousand nerd heads were stunned then was silenced by thy awesomeness!

Nice work Enjo!

 

[tblaxland]

Tis as if a thousand nerd heads were stunned then was silenced by thy awesomeness!

That's about the sum of it . I couldn't think of what to say so I stuffed libFuzzyEngine++ into my back pocket for future use and settled for clicking the "Thanks" button! Here is the effusive version: awesome work Enjo :tiphat:. I did some fuzzy logic programming when I was at uni 15 years ago and never had a sufficient excuse to return to it. I'm glad to see you taking up the challenge :thumbup:

 

[Enjo]

Ehehehe, thanks for the kind words, guys

tblaxland:
As you can see, there's not much actual programming that you have to do, just tell it to the fuzzy engine as you would to your wife / gf :lol:
Have fun with that lib.

 

[Enjo]

Artificial Inteligence

You asked for it - Presenting the first successful attempt to utilize the FuzzyEngine++ library in an end-user computational application, the Direct Ascent Solver.

You can disable / enable the AI using the "Optimisations (AI)" checkbox to see the influence. Right now, from quite sloppily adjusted fuzzy controllers, I get about 30 - 70% speed up depending on the situation! (see Iterations: )
Let's remind that you can use F2 to simulate the inner loop, to see how the AI adjusts to the situation.
Of course all that you see here will be included in Launch MFD DA Solver by design.

BTW, the libFuzzyEngine++ has a new home -
http://sf.net/projects/libfuzzyengine

OK, I suspect that in a few days a Terminator ( ) will try to pay me a visit to me, as if he weren't happy with the life that he got.

 

[Zachstar]

Ah Skynet... Very nice indeed. And fuzzy!

 

[Enjo]

Because of my commitments to the Community, here is the LaunchMFD with a Fuzzy Autopilot, as a side project of my thesis

http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD-v.1.3.3-2009-BETA.zip ( For Orbiter 2009 )

It can be enabled / disabled with the AP button. Enable it only after you see that the PEG mark is in a reasonable position.
It was quite hard to adjust it so that it worked for both atmosphere and space (EDIT: You'll notice it working above 40 km). Perhaps I will use two separate controllers for those situations later. Also, it will have to be ran not from MFD's context, but each step, so that your ship can be put into orbit while you watch it externally, when the MFD is disabled. I'll do it soon.

Tested with DG. Let me know of any problems.

[EDIT2] I will be using airfoils for atmospheric flight

[EDIT3] Yup, airfoils and 2 separate APs did the trick. Another BETA release soon

 

[Enjo]

OK, Homies. I finally got with the times and linked this version against Orbiter 2010 RC 2.3

http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD-v.1.3.3-BETA-2010-RC-2.3.zip

This version uses two separate autopilots: one for atmospheric flight (density > 0.001) and one for space flight. The conditions are totally different so this is a reasonable solution I think.
The atmospheric autopilot now uses control surfaces, so it's better suited for this purpose.
You'll have to help the AP a bit by steering the roll at first, so that you use lift to get into the right position.

Note that you need to uncomment the following entry in Earth.cfg
;AtmAltLimit = 200e3 ; cutoff altitude [m]
I don't know if it was commented intentionally, but without the AtmAltLimit, the PEG doesn't work.

Next stop: calculating the fuzzy controller's outputs in each frame, not only at each MFD refresh. This is a bit lame for an autopilot.

 

[orb]

Note that you need to uncomment the following entry in Earth.cfg
;AtmAltLimit = 200e3 ; cutoff altitude [m]
I don't know if it was commented intentionally, but without the AtmAltLimit, the PEG doesn't work.

This is because of new atmospheric models added to Orbiter. If you uncomment this line, you also need to change the model to the legacy one from Orbiter 2006.

If you do want to retain the 200km cutoff, it is better to revert to the old (Orbiter 2006) legacy model, since that seriously underestimates high-altitude density, so it is safe to cut off at 200 km.

To use the legacy model:
- go to the Extra tab on the orbiter launchpad
- Select Celestial body configuration, Atmosphere configuration
- Select Earth, then Orbiter 2006 legacy model
- Click Apply

 

[Zachstar]

Going to wait until that alt cutoff situation is revolved before I test it again but I await such like a kid in a candy store while they put candy in the bag... Drooling, and dancing about!

 

[Enjo]

Orb:
Thanks for that info. I'm having a hard time to keep up with anything lately.

Zachstar:

Well silly me, but it appears to be working after I set the altitude manually, that is, I use Shift+A and input 220. However if you're time-limited like me, you'll probably want to wait until I move the calculations outside the MFD context, so that you can switch to external view, accelerate time and sit back.

[EDIT]
OK, it's working outside the MFD's context, but it's still a bit too unstable for a 10x time acceleration, but it does work then. I'll probably make an another beta release on Sunday

 

[Enjo]

Candy

Here comes Candymaaaan! :tiphat:

http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD-v.1.3.3-BETA-2010-RC-2.3.zip

New features:
- the AP is stable enough to pitch down smoothly
- and stable enough to let you use 10x time acceleration
- you can watch the ship from external view with the same effect as from cockpit view (independence from MFD refresh rate)
- AP works for multiple vessels simultaneously (actually thanks to Computerex initially)

Missing:
No bank stabilisation yet. Should be fairly easy to do it now, but my free time for this and next week is over, so have fun with what you got now and please test it Thanks.

ps. There's a scenario file in the LaunchMFD folder which contains some instructions.

 

[Zachstar]

I have finally tried it!

I like how it runs in external view and 10x stable however sadly its not able to lift the craft into orbit correctly.

Looking forward to the next version!

 

[Enjo]

Thanks for testing

I think I know what you're talking about. I think that it's about engines being cut prematurely, ie. not when the advanced measurement which is PEG's "time to Meco" is <= 0, but when the first primitive measurement indicates "Cut your engines". This will be easy.

So if there were no other problems, the current TO DO list is the following:
- bank stabilisation
- cutting the engines dependent on PEG's readout

 

[Zachstar]

Well the issue started when it dedicated to toss me into an apopsis of over 500km trying to burn straight down to compensate than cutting engines at wrong time after wasting lots of fuel.

BTW I don't know if this request is possible but you routinely pull off miracles do you think there is any way to get the MFD to compensate for upper stages that are far less powerful than the stage before? I speak of rockets like the Airane 5 which have upper stages that are lower thrust and meant more to finish than to do any serious amounts of energy change. I notice that most autopilots assume 1 stage or all stages of similar thrust which causes fuel loss at times. Any chance of some kind of profile loading or something to compensate for this?