Project Launch MFD development thread

[Enjo]

But were you testing it with Ariane or DG? Right now it only works for SSTO, just like the PEG, because the autopilot only dumbly points your craft to what PEG indicates. They're all separate modules.

What you are asking me about is actually utilising [ame="http://www.orbithangar.com/searchid.php?ID=3800"]kwan's multistage PEG[/ame] in Launch MFD, which is doable of course, but would take tons of time, which I lack unfortunately I'm waiting for the day when I can do it, but I will. I'm graduating in exactly one year from now. After that I will take no days off for learning, plus I will have free weekends.
First step - my graduation. Meanwhile I can fiddle with the fuzzy AP - fix bugs, improve the fuzzy rules, but that's all about it for now. There's also MDDClone community waiting for me skillz

 

[Zachstar]

I was using the included tutorial scn in your pack.

You ported fuzzy by basically looking at it. Im sure one day you will "happen" to port it heh

 

[Enjo]

Before you judge the port, you should tell if it was PEG directing you to an erratic pitch, or it was Fuzzy AP not following the PEG.
If the first, did you get the readout showing you to pitch to about 40 degrees? Then it was a wrong readout. You need to pitch up more, wait for a proper readout (~70*) and then init the AP. It just follows the PEG.
There's also a problem with the rules - even if you have a perfectly ported fuzzy engine, you can mess up the controllers from "client's site" by simply writing wrong rules.
Do you understand the modularity of this system now?

The port... well, it works just like the original (I've tested it), but it misses some optimisation features, which only lessen CPU usage. If I didn't care much, from a sloppily made Java 2 C++ port, you'd get stuff that eats up your memory very quickly

 

[Zachstar]

My memory was forged from the sweat of Chuck Norris! It can handle it! :lol:

I shall go and test it further. I must have been dazzled by your insane code skillz and failed at my task :hail:

---------- Post added at 11:57 PM ---------- Previous post was at 11:47 PM ----------

Good news in that I got it working... Sorta

I notice you really have to baby it until you get high enough and pitched up enough before starting. Perhaps its not fair to keep mentioning that but it is a tad bit annoying tis all.

what I am REALLY impressed with this time was it wasn't jerking around like last time. Matter of fact it was one of the smoothest pitching autopilots I have seen yet only issue is it decided again not to finish the burn. A quick burn at apogee fixed this tho. I want to try this approach with a velcro rocket upper stage at some point and report its results.


EDIT: Whoops I think I spoke with the wrong words when I said port by looking. I had meant it in a way like "The code decided to port itself in fear of your skillz" Instead of a judgment of the port. Pardon me if it came off that way

 

[Enjo]

Great news!

I notice you really have to baby it until you get high enough and pitched up enough before starting. Perhaps its not fair to keep mentioning that but it is a tad bit annoying tis all.

There are two things to take into account. If you're using the complex flight model, notice that after you pitch up high manually, the PEG suddenly switches to what it was before + 30 degrees (which is the proper readout). This is a source of one problem, because the AP just blindly follows it.
Another one is that, as you know, yawing has very little effect for atmospheric flight, and you indeed have to bank to have the PEG marker above you, to use ship's lift. I was wondering myself if I want to leave it this way so that the user has to do some thinking, but I think I'll automate it. I just didn't have enough time.
If you think how it would work (When should it bank to use lift? When should it bank to wings level?), you'll realise that it will have to be more intelligent than simple X and Y stabilisation. In other words - complicated enough to leave it when I have more free time.

what I am REALLY impressed with this time was it wasn't jerking around like last time. Matter of fact it was one of the smoothest pitching autopilots I have seen yet only issue is it decided again not to finish the burn. A quick burn at apogee fixed this tho. I want to try this approach with a velcro rocket upper stage at some point and report its results.

Thanks for the opinion. Smooth pitching is possible, but the "client" defining the fuzzy rules, has to know what he's doing and perform many tests... I hope that someday I will make the rules ship-neutral, by using fractions, for example - instead of telling that velocity = 1 m/s is medium, I tell use for example ship's RCS_thrust / Fuel_mass_flow and post process the value. We'll see.

About that burn:

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.

EDIT: Whoops I think I spoke with the wrong words when I said port by looking. I had meant it in a way like "The code decided to port itself in fear of your skillz" Instead of a judgment of the port. Pardon me if it came off that way

:rofl:
No problem. Anyway criticism is welcome, as long as it's understandable what is actually going on, and which subsystem is responsible for a given fault. At least I had a chance to explain it.

Awaiting patiently for next reports

---------- Post added 06-04-10 at 07:34 AM ---------- Previous post was 06-03-10 at 07:35 AM ----------

Straight out of boredom:

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

The latest changes are:

1. Proper MECO, ie. when PEG's time to MECO is <= 0
2. Simple bank stabilisation. It's not that intelligent because it simply stabilises bank when the distance to the PEG mark on X axis is small.

That's is it for now. I'll leave the advanced bank topics for later.

 

[Zachstar]

ECC of 0.0003 GREAT SCOT! It works!

I noticed a little of the smoothness is roughed up however I cant claim a clean test environment because #1 I have hulu buffering in the background (Just did this test while it buffered) and #2 My CPU is in cool n quiet mode to reduce CPU use which may or may not respond to fuzzy wrongly. However I cant change this because the heat from my computer is too hard to AC cool in my room if I want a decent power bill (Its normally overclocked to 3.2) You mentioned clientside variables but just wanted to give you a heads up if you are looking to keep the crown of smoothest auto (Sounds like a beer)

The bank system works very well. Wont be the best thing ever for stages but for the DG it seems to just work.

 

[Enjo]

TA, Zachstar.
Yes, the CPU usage may be the problem. One thing is that the variables have to be correctly adjusted, but generally for a controller to work, the periods between subsequent events of getting and returning data (here: position + velocity -> power) have to be the smallest, because the controller needs to have the most recent data available, so it immediately sees the results of its steering, to steer it even better. It's a known control engineering problem.

The fuzzy controller works in each timestep, which are smaller if you give them more CPU time. In short - the more FPS you have, the more stable it will be, just like the Orbiter itself.

I realise that this may be a bit banal, but some folks may want to learn that

 

[Zachstar]

My FPS is in the 200s range (The next version does have great FPS improvements) Also I have now done testing with CPU-Z and now I can say that it is not jumping into the lower P-states when orbiter is running. I can rule out cool n quiet.

May have been a hicup I shall wait for the next version and try again. Sadly I cant get velcro running in the orbiter beta so im stuck testing shuttle and dg for now.

 

[Enjo]

So you're saying that even though you get 200 FPS, the AP is still jumpy?
That's weird because on my box it isn't and I didn't change that part. I only added the bank stabilisation.

[EDIT] Are you also saying that one CPU core is not working at its 100% (50% total) while Orbiter is running? This would be weird.

As for Velcro, I will release the 2006 version later today.

 

[Zachstar]

A bit jumpy but I dont think its anything to worry about right now.

I dont know if you have used AMD CPUs in the past but they have a feature called cool and quiet. It measures CPU use and if enabled reduces voltage and speed greatly during times of little CPU use. In the past this was a bit icky because sometimes it diddnt update right and for a time you would suddenly drop into low state. However the 45nm AMD cores have a more advanced version that has multiple P-states and updates faster. I had worried that it would read things wrong and that was causing the roughness but CPU-Z testing confirmed its in normal and overclocked.

Its not a big deal right now. For all I know I flipped something I ought to not have. Im going to test on a fresh install but if possible please provide beta and 06 modules for now on so I can see if this roughness is something to do with beta on my PC. Somthing tells me tho the bit of roughness is going to drop if I redo the install anyway.

 

[Graham2001]

So you're saying that even though you get 200 FPS, the AP is still jumpy?
That's weird because on my box it isn't and I didn't change that part. I only added the bank stabilisation.

[EDIT] Are you also saying that one CPU core is not working at its 100% (50% total) while Orbiter is running? This would be weird.

As for Velcro, I will release the 2006 version later today.

I'm looking forward to trying this out with the Delta IV Versatile.

 

[Enjo]

There you go:

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

Zachstar:
I have AMD 3000+ Dual Core, but I've never heard of that feature. However I do know about the much bigger power consumption, compared to Intels.

 

[Zachstar]

My power consumption is huge because #1 I am tri core with L3 cache and #2 I am overclocked but with that cool n quiet on it purrs quietly and without much wattage

Intel's are just as bad if not worse. AMD overclocks are known for being light on the volts while Intel FSB overclocks usually require a good bit of extra voltage.

Thanks for the version will test it when I get home from work tonight.

 

[astrosammy]

Cool, launched the DG to a 300x301.1km Orbit. Only 1.1km off target. I also tested it with the Falcon 9, but had to pitch manually in the atmosphere because the AP used a very low pitch angle, causing a high dynamic pressure. Also for the last seconds it just went vertical to reach the target altitude and the vehicle didn't reach orbital velocity. There was nearly no impact on FPS.

 

[Zachstar]

Now that Orbiter 2010 is out I am going to wait for velcro to be ported as well as some other addons before I continue testing.

 

[Enjo]

(...) I also tested it with the Falcon 9, but had to pitch manually in the atmosphere because the AP used a very low pitch angle, causing a high dynamic pressure. Also for the last seconds it just went vertical to reach the target altitude and the vehicle didn't reach orbital velocity. There was nearly no impact on FPS.

Thanks for testing. I assume that you mean this addon:
[ame="http://orbithangar.com/searchid.php?ID=3308"]Falcon 9 - Dragon Beta 3[/ame]

The low pitch angle at the beginning is I think a normal problem of PEG. We'll have to live with this.
I noticed that the last stage oscillates too much to reach target pitch which causes you to loose fuel and disallows you to reach the orbit. This is caused by the fact that the AP has been adjusted for DG's specific rotation capabilities. It just has to be normalised.
There's only one school week left for me, except this one, so you can expect some changes in this field soon

 

[Enjo]

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


Latest changes:

- fuzzy AP works with Falcon 9, and should work with other rockets. Please test
- automatic alt functionality restored

By saying that the AP works for Falcon 9, I mean that it follows the PEG marker better, not that the PEG guides your multistage vessel correctly. Falcon 9 still can't reach orbit because of that.

I also realised that the bank mechanism should work completely differently for tail sitters and winged craft. Will do later.

 

[Enjo]

Thanks to help received here, I was able to improve time of satellite's orbit passing, which was working correctly, thanks to Agentgonzo, but only during flight. In case of nonspherical gravity sources usage, the time is off only by roughly 0.02% which is 12s for 54000s waiting time.

Here's just the dll, and I will prepare releases later this week. I need to update Polish translation and include the documentation that I forgot about.

http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD.dll.zip

You can find the (outdated) documentation here:
http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD-doc.pdf

 

[Zachstar]

Wake up Enjo! My mind is not blown away this time! OH NOES!!!!

Thanks for the update tho!

 

[Enjo]

Hey, I'm workin' on it!
Right now I want to improve the AP, so you don't have to "baby" it any more.