OHM Glideslope 2.7 for Orbiter 2010

[ky]

This sounds awesome

 

[Interceptor]

So it is OK to use this patch with the version on OH?

 

[ADSWNJ]

It's doable. It'll come to RVO first, as I'm inside that code and working in port rotations and all the madness of how to lay out docking rectangles in 3D curved onto the final approach. I'm looking at craziness like how a line intersects a sphere, so the transitions on the waypoints are beautiful.

I swear it's a kind of madness, but hey I like it!

For Glideslope ... well, I'd love to do something as cool as FSim's final approach, or the actual shuttle HUD graphics. But it may be at least until a Tuesday before I can do that

 

[Cras]

Fsim does have a neat display, but if you can just have something simple like the shuttle hud, a simple donut in the the hole concept that can help with getting on and maintaining the 20 degree glidepath, as well as maybe pre-flare guidance.....that would be so useful.

Look forward to it. You ever need help with testing, just let me know. Good luck

 

[ADSWNJ]

Here's a little v2.3 update to Glideslope, prompted by some side-conversations with Blixel.

Key things this time are *all* the runways and pads from the Orbiter Stock Bases Upgrade (4th Rock), and a new Visual Base mode to show the geometry of each base and visually select your active landing runway or pad.

Still waiting to get time to add the Shuttle-like HUD to GS, but that's for v3.0.

 

[ADSWNJ]

Can't believe it's been 3 years since Glideslope 2 has been updated. I've been working on a vacuum autoland mode for landing on Mercury, or the Moon, etc. Plus Glideslope now interfaces to BaseSync to pass it a target, and get back a retro-firing solution, to drive an auto-pilot retro-fire.

This is all possible via the new ModuleMessagingExt that Enjo and I co-designed. We will soon have everything from launch control (LaunchMFD), interplanetary guidance (TransX). rendezvous control (RV Orientation), on-station space station building guidance (On Station Ops), base synchronization (BaseSync), autoburn control (BurnTimeCalc), deorbit and glideslope guidance (Glideslope 2) all linked though Module Messaging. For other developers - please drop Enjo or me a PM if you want to plug in your addon, vessel, or MFD, for cross-connect features.

 

[Enjo]

We will soon have everything from launch control (LaunchMFD), interplanetary guidance (TransX). rendezvous control (RV Orientation), on-station space station building guidance (On Station Ops), base synchronization (BaseSync), autoburn control (BurnTimeCalc), deorbit and glideslope guidance (Glideslope 2) all linked though Module Messaging.

In the previous century somebody would write an article about it.
In the previous decade somebody would record a YouTube video about it.
...

 

[ADSWNJ]

Announcing the new Glideslope 2 v2.4 ! !

Glideslope 2 is a reentry guidance utility to assist you to make precision landings from orbit to the runway or landing pad. It is based on the original Glideslope by Chris Jeppesen. For atmospheric landings, Glideslope 2 calculates the reentry profile downt to a Heading Alignment Cylinder (HAC) tun similar to the profile that the Space Shuttle used to fly. The utility has extensive configuration files to allow you to create your own custom reference landing profiles for different vessels or types of reentry (e.g. you could create an emergency descent profile for a DG, or an max weight landing for a Shuttle).

Updates this version: tight interaction with the new BaseSync v3.0 for the new deorbit autopilot. Plus a whole new vacuum landing mode for precision landings onto the Moon, Mercury, etc.

 

[jgrillo2002]

Plus a whole new vacuum landing mode for precision landings onto the Moon, Mercury, etc.

How do you activate that option in the MFD?

 

[ADSWNJ]

How do you activate that option in the MFD?

Get yourself in orbit around a vacuum body (e.g. Moon), select a base (e.g. Brighton Beach), bring up Base Sync to see if your orbit is within say 100km cross-range, and then hit AP. You will see AUT come on in the top right hand corner, and then select the digital data display to see what it does.

I tried it with the Shuttle-A into jplaja's Myron Base on Mercury, to try different vessels and gravity gradients (as well as Atlantis, DG, XR2, XR5 into Brighton Beach).

Give it a go and see what you think. I know the HSIT graphics are a bit messed up (that's for a future fix), and the reentry into Earth does not perfectly hit the top of descent point (I need to debug whether that's a Glideslope or a BaseSync error), but I had to get it released, as I had been sitting on it for over 3 months!

PS y'all: the manual is also worth reading (I spent a couple hours putting it together!)

 

[jgrillo2002]

Get yourself in orbit around a vacuum body (e.g. Moon), select a base (e.g. Brighton Beach), bring up Base Sync to see if your orbit is within say 100km cross-range, and then hit AP. You will see AUT come on in the top right hand corner, and then select the digital data display to see what it does.

I tried it with the Shuttle-A into jplaja's Myron Base on Mercury, to try different vessels and gravity gradients (as well as Atlantis, DG, XR2, XR5 into Brighton Beach).

Give it a go and see what you think. I know the HSIT graphics are a bit messed up (that's for a future fix), and the reentry into Earth does not perfectly hit the top of descent point (I need to debug whether that's a Glideslope or a BaseSync error), but I had to get it released, as I had been sitting on it for over 3 months!

PS y'all: the manual is also worth reading (I spent a couple hours putting it together!)

It works good but sometimes, The Shuttle A wont land on a pad and instead just uses hover engine to stay afloat over the pad.

 

[ADSWNJ]

It works good but sometimes, The Shuttle A wont land on a pad and instead just uses hover engine to stay afloat over the pad.

For the good landings, we celebrate. For the rest, we make a strong cofee, go to the .CSV files in the Diags folder, and then try to work it backwards to the point where the AP couldn't handle it. (Not that I did this any more than a few thousand times ).

If you can reproduce it at will, jgrillo, then send me a .scn file, any commentary on what it does for you, and then the files in the Diag directory. No guarantees of turnaround, but I'll see what I can do.

 

[turtle91]

I got some issues regarding reading/writing to the related configs, within GS 2.4.

My plan was/is:
-To run an automated de-orb burn using BaseSync linked to GS2.4
-using the "hard-coded(?)" from-deorbit-burn-values (120 km, ANG 7.3, ANT 73) to create a new reference GS-file using the XR2.
-I used latest AerobrakeMFD after the automated deorbit has finished burning the reentry-burn.(PEA to 40 km)

All went fine...nice and smooth landing at KSC RW33.
So I pressed the SAV-button in GS2.4MFD to save my nice reentry to a new GS-file.

The save went fine, according to the file-time-stamps, but plenty of reentry-time has been "skipped".

I.e.:

0.50 204.99 7566 -0.1 168.4 ; Time 74732 secs
0.50 204.99 7566 -0.1 168.3 ; Time 74733 secs
302.24 37.84 2785 -99.8 40.2 ; Time 82321 secs
272.59 36.71 2586 -102.8 40.2 ; Time 82332 secs

So this file can only be used after the reentry at about 37 km altitude.
I checked th logs a bit further and found this:

PREFS LOADED: Mode=3/1/4 Units=METRIC Base=Cape Canaveral Runway=PAD01 Glideslope=XR
Successfully parsed GS2.cfg

But the GS2.cfg shows this unique entry at the bottom:
PREFS DATA VSIT HSIT METRIC "Cape Canaveral" "RWY33" XR

KSC RW33 is correctly define in the same cfg:
RUNWAY "Cape Canaveral" "RWY33" -8220.0 -600.0 -12670.0 -3155.0 -2000.0 500.0 0.00 100 5131 331.0

Maybe this might be the problem to cause confusions with the GS-file-write ?
When started GS2.4, there is allways KSC PAD01 defined.
-When switching to "RW33", I got a zero-distance-HAC
-so I must press the "++" button to increase the HAC-size.
-then....and only then....(after increasing HAC-size >0) I got i.e. AOA values other the 1.x (so 40 i.e. )

Maybe a problem with write/read-buffers ?
I.e. I tried to use the DIAG-option in one of he tests before the last one and got a more strange result:
Just two lines within the new created GS-file which were different:
Plenty of 201 km altitude-lines (like in this test) and just one last line with "0" altitude.
So everything between 201 kms and 0 kms altitude has been skipped.

I used previous version of GS and didn't run into such problems, using the same test-machine.
Windows 7, using a non-OS-owned-free-orbiter-dir on drive D:.

I will attach the relevant GS2 logs.



p.s. One more thing...GS2-MFD was open/visible all the time on left MFD-side....so never closed, but still have the time-skips.
And....btw I am talking of Orbiter-2010.

 

[ADSWNJ]

@turtle91 Check out "XTS" in the Config menu. By default GS2 stores a relatively short track for debug purposes. By selecting XTS, you let the MFD know you are interested in the whole glideslope.

With this done, I think you will be fine. By the way - your use-case this was my initial goal for coding the SAV function: i.e. to take the stock glideslopes and improve them either for your vessel or for a vessel with a totally different aerodynamic profile.

Try it out, and if it's not working, then I will be happy to debug with you until it works exactly as you need it to.

 

[turtle91]

Thanks Andrew.
I have allready tested the XTS, and the situation was even worse.

>I.e. I tried to use the DIAG-option in one of he tests before the last one >got a more strange result:
>Just two lines within the new created GS-file which were different:
>Plenty of 201 km altitude-lines (like in this test) and just one last line with >"0" >altitude.
>So everything between 201 kms and 0 kms altitude has been skipped.

Sorry for the confusion, with DIAG I meant XTS.
However, I will test the reentry again using XTS and provide you with the logs.

Btw., different topic....could it be that the vacuum-land-ap does not like Enjo's "absolute-killrot module" ?
All went fine until 2000 meters above the landing-site.
Then the AP descended (with about 1.3 m/s) down to about 1500 meters, and then ascended again to 2000+ meters.
This happened in some kind of a loop. After the third loop I landed then manually.
I used the XR2.
Maybe something we could check later on ? ( I have a 160 MB CSV-file....so much stuff to read ) .

Thanks again,
Ingo

 

[ADSWNJ]

Thanks Andrew.
I have allready tested the XTS, and the situation was even worse.

>I.e. I tried to use the DIAG-option in one of he tests before the last one >got a more strange result:
>Just two lines within the new created GS-file which were different:
>Plenty of 201 km altitude-lines (like in this test) and just one last line with >"0" >altitude.
>So everything between 201 kms and 0 kms altitude has been skipped.

Sorry for the confusion, with DIAG I meant XTS.
However, I will test the reentry again using XTS and provide you with the logs.

Btw., different topic....could it be that the vacuum-land-ap does not like Enjo's "absolute-killrot module" ?
All went fine until 2000 meters above the landing-site.
Then the AP descended (with about 1.3 m/s) down to about 1500 meters, and then ascended again to 2000+ meters.
This happened in some kind of a loop. After the third loop I landed then manually.
I used the XR2.
Maybe something we could check later on ? ( I have a 160 MB CSV-file....so much stuff to read ) .

Thanks again,
Ingo

Hi Ingo,
Vacuum land ... assume you are landing on the Moon? (Other landings are possible - e.g. Mercury). If you have 2 AP's engaged, the results are undefined, as they will very likely fight each other. I have to say, I'm not 100% happy with the stability of the Vac AP algorithms, but they work 99% of the time and then do weird things for the remaining 1%.

Always happy to look at a reproducible scenario (i.e. give me a starting .scn, and the simplest possible reproduction inputs, and I'll take a look on a weekend session).

By the way - insight for anyone interested ... we can run the tools in Debug mode in Visual Studio, stopping the simulator dead in its tracks to look deeply at data structures, etc. Only, with real time activities like auto-pilots, resuming the sim usually freaks everything out as it warps 5 mins in time, etc. So the alternative is brute force debugging, with massively complex debug .csv files that you'll find in the GS2 sub folders. It's a labor of love, and man vs. the machine!

 

[turtle91]

Regarding the vacuum landing-ap, I have done some more testing by using the XR2 on the moon, all tests now without "AbsoluteKillrot" :

1. test, used a modified XR2-config (increased hover-power=168 kn, increased ISP, all RCS are still default):

-took off form Brighton Beach at 90 degrees into a 50 km circularized orbit.
-started GS2.4 and BaseSync 3.0, set target to gs2 = crossrange to BB about 230 meters...so..perfect.
-started GS's AP and all went fine until the last step (2000 meters above landing site
-the AP was "overcorrecting" the lateral offset all the time during descent form 2000 meters.
At about 1500 meters altitude (maybe be less), the AP was still busy with RCS-overcorrection-tasks (0.13 meters to much.....then 1.2 meters too less...etc).
During the very fine last RCS adjustements, the AP used too much hover-power, so the XR2 was ascending again to more then 2000 meters above the surface.
This overcorrecting and ascending/descending/ascending happend three times until I stoppd orbiter for the next test:


test2: using standard XR2 config(so weaker hover...132 kn), started again from BB to 90 degrees and 50 km altitude.

-all went fine until the 2000 meter above the landing-pad-spot.
-RCS was still overcorrecting lateral offset(in the 0.1 - 1.5 meters range),
but the XR2 went down all the time (from 2000 to 0.9 meters), without any ascent. So the AP does not like the "easy 168 kn hover" option.
-However, after reaching altitude of 0.9 meter, the AP never stopped
-so I stopped the AP and decreased the hover just a a bit, to finish my "near perfect" landing )lateral offsert about 0.5 meters.

I cannot attach the CSVs, caused by OH's 5 MB limit.

Maybe a "RCS/Hover-rates recalibation function" like the RCS-recalibration in RV_Orientation might help ?

Later on today I will try the XTS-feature from GS2 again, to hopefully get a valid UserDefined_GS for my planned earth landing.

 

[ADSWNJ]

Thanks Ingo - great details. Will examine when I get a couple of hours. Damn fuzzy logic loops. Each time I get annoyed with a fuzzy solution (i.e. limit offset rate to X when range is Y), I yearn to go back to PID controls, but they are super hard to tune for accurate execution on a general use-case of any vessel and weight.

 

[turtle91]

I have done 2 tests regarding the GS-file-save issue(using XTS-feature).

1.Test I used a SC3 vessel and all went fine(except the landing...my fault....)
The GS-file was saved correctly and I will attach it to this post.
I know....the profile I created is bad, but it was just for testing.
So..please don't try this GS-file at home...:thumbsdown:

2.Test I used the XR2, and here I was able to reproduce the problem again.
I mean the landing was fine, but the GS-file seems to be screwed-up.
There was a skip from 208 kms to 58 kms altitude. All stuff between is lost.
I have attached this file, too.

I both cases I have started a scenario, where I was dockked at ISS, so the Orbiter's uptime/session-time was nearly the same (about 1 hour).
But how should the XR2 vessel create data-loss in GS2-mfd ?
The only big difference I can think of, might the the memory-usage, which seems to be much higher for a vessel like the XR2 compared to a "basic" SC3 vessel.

Btw., as you can see from the logs, the XTS-entries are complete, the later on generated standard-logs are skipped.


p.s. just "trying" to check he code with my 0.1 percent programming skill and a thought:
evtl.: enabling ?:

// Debug full dump
// if (extendedTrackSave) {
// for (i=0;i<TrackPtr;i++) {
// fprintf(ouf,"; RNG %10.2f ALT %10.2f TAS %10.0f VSP %10.1f AOA %10.1f ; Time %i secs, Row %i\n",
// TrackD,TrackA,TrackV,TrackVspd,TrackAlpha*RAD2DEG, (int) TrackT, i);
// }
// }
I mean if I understand this correct. You have created a 50 elements array, which stores "50x trigger save-points-relative-to-destination".
Maybe a 50 elements-array is too large ? So...separating ot to 2x25 ?
...Or maybe using "short" instead of "int" for this array to save some memory ?
....But then we need to convert "short" to "int" again before running the DIST*1000....but if doing this one by one....?

 

[ADSWNJ]

I mean if I understand this correct. You have created a 50 elements array, which stores "50x trigger save-points-relative-to-destination".
Maybe a 50 elements-array is too large ? So...separating ot to 2x25 ?
...Or maybe using "short" instead of "int" for this array to save some memory ?
....But then we need to convert "short" to "int" again before running the DIST*1000....but if doing this one by one....?

Could well be one of these, and I'll look in detail if I can reproduce it. This stuff was written for my private debugging initially, and it's laid dormant waiting for somebody to examine it in detail. Exciting, eh? We'll fix it.

---------- Post added at 02:31 AM ---------- Previous post was at 02:26 AM ----------

I both cases I have started a scenario, where I was dockked at ISS, so the Orbiter's uptime/session-time was nearly the same (about 1 hour).
But how should the XR2 vessel create data-loss in GS2-mfd ?

Can you upload a starting scenario for your docked at ISS scenario (i.e. quick save it, and just copy into your reply between [ code] and [ /code] tags without the space between [ and code.) Just thinking ... do you start GS2, then do multiple orbits? Or do you do a deorbit burn shortly after starting the scenario? Just trying to reproduce most efficiently.