OHM Glideslope 2.7 for Orbiter 2010

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
I tried it again.
This time, I started orbiter when I was about one-half orbit before the (GS2-calculated) de-orbit burn.
So, not too much Orbiter/GS2-uptime/session time.
However, the GS-file has skipped data again.
This time, plenty of the XTS-data is missing.
I am also wondering about the wrong displayed range-to-base value...somewhere at the beginning of the log.
The cross-range was about 25 km's...so should be fine.

Below, you will fine the pasted scenario, which starts at about 3.5 orbits before DEO-burn.
I have done this, to play evtl. around with differet orbiter-session-time/uptime.
The latest "skip-log" is attached.

Code:
BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51996.0501874639
END_ENVIRONMENT

BEGIN_FOCUS
  Ship XR2-01
END_FOCUS

BEGIN_CAMERA
  TARGET XR2-01
  MODE Cockpit
  FOV 49.59
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_MFD Left
  TYPE Orbit
  PROJ Ship
  FRAME Ecliptic
  ALT
  REF Earth
END_MFD

BEGIN_MFD Right
  TYPE Orbit
  PROJ Ship
  FRAME Ecliptic
  ALT
  REF Earth
END_MFD

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
XR2-01:XR2Ravenstar
  STATUS Orbiting Earth
  RPOS 5911664.58 1424053.47 -2504597.02
  RVEL 2327.118 -7308.075 1335.853
  AROT 95.15 31.59 154.03
  PRPLEVEL 0:0.367057 1:0.607091
  IDS 0:199 100
  NAVFREQ 589 466 84 114
  XPDR 193
  SECONDARY_HUD 5
  LAST_ACTIVE_SECONDARY_HUD 0
  ADCTRL_MODE 0
  TAKEOFF_LANDING_CALLOUTS 7511.956119 55156.228483 55156.232659 0.000000 0.650568
  APU_FUEL_QTY 0.900284
  LOX_QTY 0.478869
  CABIN_O2_LEVEL 0.209000
  CREW_STATE 0
  INTERNAL_SYSTEMS_FAILURE 0
  COGSHIFT_MODES 0 0 0
  MWS_ACTIVE 0
  COOLANT_TEMP 31.200000
  DMG_0 1.000000 Left Wing
  DMG_1 1.000000 Right Wing
  DMG_2 1.000000 Left Aileron
  DMG_3 1.000000 Right Aileron
  DMG_4 1.000000 Landing Gear
  DMG_5 1.000000 Nosecone
  DMG_6 1.000000 Retro Doors
  DMG_7 1.000000 Top Hatch
  DMG_8 1.000000 Radiator
  DMG_9 1.000000 Airbrake
  DMG_10 1.000000 Left Main Engine
  DMG_11 1.000000 Right Main Engine
  DMG_12 1.000000 Left SCRAM Engine
  DMG_13 1.000000 Right SCRAM Engine
  DMG_14 1.000000 Fore Hover Engine
  DMG_15 1.000000 Aft Hover Engine
  DMG_16 1.000000 Left Retro Engine
  DMG_17 1.000000 Right Retro Engine
  DMG_18 1.000000 Forward Lower RCS
  DMG_19 1.000000 Aft Upper RCS
  DMG_20 1.000000 Forward Upper RCS
  DMG_21 1.000000 Aft Lower RCS
  DMG_22 1.000000 Forward Star. RCS
  DMG_23 1.000000 Aft Port RCS
  DMG_24 1.000000 Forward Port RCS
  DMG_25 1.000000 Aft Star. RCS
  DMG_26 1.000000 Outboard Upper Port RCS
  DMG_27 1.000000 Outboard Lower Star. RCS
  DMG_28 1.000000 Outboard Upper Star. RCS
  DMG_29 1.000000 Outboard Lower Port RCS
  DMG_30 1.000000 Aft RCS
  DMG_31 1.000000 Forward RCS
  DMG_32 1.000000 Bay Doors
  IS_CRASHED 0
  MET_STARTING_MJD 51994.222037
  INTERVAL1_ELAPSED_TIME -1.000000
  INTERVAL2_ELAPSED_TIME -1.000000
  MET_RUNNING 1
  INTERVAL1_RUNNING 0
  INTERVAL2_RUNNING 0
  ACTIVE_MDM 3
  TEMP_SCALE 2
  CUSTOM_AUTOPILOT_MODE 0
  AIRSPEED_HOLD_ENGAGED 0
  SCRAM0DIR 0.000000 0.000000 1.000000
  SCRAM1DIR 0.000000 0.000000 1.000000
  HOVER_BALANCE 0.000000
  MAIN0DIR 0.000000 0.000000 1.000000
  MAIN1DIR 0.000000 0.000000 1.000000
  GIMBAL_BUTTON_STATES 0 0 0 0 0 0
  ATTITUDE_HOLD_DATA 0.000000 0.000000 0 0 0.000000
  DESCENT_HOLD_DATA 0.000000 -3.000000 0
  AIRSPEED_HOLD_DATA 225.000000
  OVERRIDE_INTERLOCKS 0 0
  TERTIARY_HUD_ON 1
  CREW_DISPLAY_INDEX 0
  GEAR 0 0.0000
  RCOVER 1 1.0000
  NOSECONE 0 0.0000
  AIRLOCK 0 0.0000
  IAIRLOCK 0 0.0000
  CHAMBER 0 0.0000
  AIRBRAKE 0 0.0000
  RADIATOR 1 1.0000
  HATCH 0 0.0000
  SCRAM_DOORS 0 0.0000
  HOVER_DOORS 0 0.0000
  BAY_DOORS 0 0.0000
  APU_STATUS 0
  EXTCOOLING_STATUS 0
  TRIM 0.000000
  LIGHTS 1 1 1
  XRUMMU_CREW_DATA_VALID 1
  UMMUCREW XI0-Lee_Nash-39-63-78
  PAYLOAD_SCREENS_DATA 0.2 0 1 0
END
XR2-01_Bay:XRPayloadBay
  STATUS Orbiting Earth
  RPOS 5911666.54 1424051.27 -2504595.85
  RVEL 2327.118 -7308.075 1335.853
  AROT 95.15 31.59 154.03
  ATTACHED 0:3,XR2-01
  AFCMODE 7
END
XR2PayloadCHM-01-1:XR2PayloadCHM
  STATUS Orbiting Earth
  RPOS 5911663.78 1424055.46 -2504596.51
  RVEL 2327.118 -7308.075 1335.853
  AROT 95.15 31.59 154.03
  ATTACHED 0:0,XR2-01
  AFCMODE 7
  NAVFREQ 0 0
END
END_SHIPS
 

Attachments

  • GS2-started-at-half-orbit-before-deo-burn.zip
    1.4 KB · Views: 7

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
I have recreated your problem scenario, Turtle, and I can now tell you in detail what is going on. The SAV button writes the user glide slope, as you know. It looks through the track logs for the closest entries to 50 pre-determined distance waypoints (km): 8150, 8000, 7500, 7000, ..., 1500, 1000, 900, 800, 700, 600, 500, 450, 400, 350, 300, 275, 250, 225, 200, 190, 180, ..., 100, 90, 80, ..., 20, 10, 2, 0.

When I use GS2, post deorbit burn, I always hit CLR to clear the track (and de-clutter the VSIT display). When this is done, it resets the track data, so from this point on, the distances are always descending. **However** if you don't do this, then you have distance artifacts from prior orbits (where the distance to base oscillates from say 35000km to 0km, depending on each orbit's closest tangential distance to base).

In your case, Turtle, I can see that you were saving a track with multiple orbits in it. So when the SAV function tried to save the data, it found waypoints below 8150km, and thought you were on the glide slope on a prior orbit. It then skipped forward one or more orbits to get to the next waypoint, leaving a very weird glide slope!

Simple fix: always hit CLR post-burn, and when you are under a half-orbit to base.

Better fix: I've built a modified version of GS2.dll (put it in your modules\plugin folder), which correctly saves the Glideslope with the following logic: it searches backwards in time through the track save, to the point where you are over 1000km to run. From there, it searches until it gets to the start of the track log, or when it sees the distance start to invert. From that point, it then saves the track properly. One other feature: if you have XTS on, then it will now save every 10 seconds as well (Ext Track Save tags in the save file). So you can now see the default save entries and the extended track save entries in the file.

One thing: if you are planning to reuse a custom glide slope, there is a user-entry limit of 1024 points. Usually this will not be a problem, but in case you are re-flying an extended track save with **loads** of entries, then you may see this.

Hope this works well for you.

I won't push this to OrbitHangar, as it's probably just you and me looking at this, but it's in my base code now, so it'll get incorporated on my next full release.
 

Attachments

  • GS2.zip
    62 KB · Views: 9

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Many thanks Andrew.
I will give the new GS2.dll a try.
But there seems to be a confusion:

>In your case, Turtle, I can see that you were saving a track with multiple orbits in it.

No, I used the pasted scenario, which is about 3.5 orbits away from the base (so...yes, IF GS2 will be started at the beginning of the scenario, we would have multiple orbit-tracks).
BUT: I waited until 0.5 orbit from base (about 190 degrees), quit orbiter, and reloaded orbiter...just to have a clean base.

THEN I started GS2 the first time and waited for the de-orbit-burn.
After this 0.5 orbit-flight, I got the strange GS-file-output.

However, I will test the same again, using the new GS2.dll and let you know.

Many thanks again.
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
If you look at the glideslope you attached on post #101, it had a 31k KM, then a 40k km, then a couple of divide by zero's (must have been directly overhead), then a 0.5km, then the countdown from 7000 km. That's the pattern I am trying to suppress!
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Sorry for the delay.
However, I have tried the new GS-build and it works now perfect. :thumbup:
I tested another scenario where I have to undock from ISS first, so much more session/orbiter-uptime this time.

I started the GS2-mfd about 4 orbits before the de-orbit burn (so...stress-test...).
Right after the deo-burn, I pressed the CLR-button (just in case...I have not done this in my previous tests, which might explain the trouble).
The user-saved-GS-file looks great, also including plenty pf XTS-data.

So, in short words....problem solved.

Many thanks for the quick fix. :cheers:
 

Attachments

  • GS2-with-fix-ok.zip
    6.2 KB · Views: 4

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
That's awesome! Thanks Ingo ...

You owe me some new reference glideslopes now :). Fly some descents with vehicles of your choice, rename then something useful, and I'll add them to the next release.

What would be interesting would be max and min entry glideslopes - e.g. an emergency 4 degree descent in XR2 or XR5, and a minimum say 0.25 degree descent ... just to see the differences.

I've always threatened to take the docking corridor code out of RV Orientation and mate it with Glideslope to make a massive version of a Wet n'Wild tube ride. It would probably be a major undertaking, rewriting the core of Glideslope to make it more supportable, plus giving it and awesome S-turn guidance control. But that would take me as long as Dr Schweiger, doing an hour or two each Sunday morning for several years!
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Hello again ;)

I have one more question regarding the de-orbit-parameters set by GS2 into BaseSync-MFD.

I am asking, because my previous attached GS-reference-file caused a really strange de-orbit burn.
The burn started at the correct distance, but put my PEA down to about -800 meters(instead of the expected 40 kms).
I used the same altitude of 205 kms, for both reentries.
As a result, according to AerobrakeMFD, this would result in a high-G reentry and a landing point about 1500 km's too early.

So the question is, how does GS2-MFD determine its de-orbit-burn-parameters ?

I guess...but I need to test this during my next run, that the vey first entry within the GS-refernce-file is used as a base to calculated the required/correct burn-parameters ?

This would make sense in my case, as my (previous attached) GS-ref-file started much much earlier(about 17000 kms before base).
The GS2 default XR-ref-file starts at 8500 km before the base.
Is this "8500 km mark" the base-value of deorbit-calculation ?

If yes...the solution could be, that I cut all non-needed-data wihin my GS2-ref-file until it starts at about 8500 kms,m too.

Correct ?:hmm:
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
Pretty much, yeah. You want the first line to be at around 120KM alt.

I'll check the actual logic next time I am at my PC (weekend, most likely).
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
After I cut the un-needed entries, the de-orbit burn was fine.
So the "first hit/mark" was too far away, which caused the calculated confusion.

Next one:)

I am currently trying to make GS2 a bit more Orbiter2016 compatible, esp the vacuum-land-mode.
While I have still issues with hover-cut-off, as explained before, I tried to "miss-use" the vaccum-ap for something different:

-started at brighton beach in latest XR2, used XR2-built-in-hover-ap.
-moved a couple of kms away from the base (just flying a bit around to enjoy the scenery)
-navigated manually roughly back to base, used GS2 as a GPS-device
-when about 5 kms away from the base, I started GS2's AP :)
-while the XR2-hover-ap was still enabled, GS2 has done a great job to navigate the vessel right over the seleced pad(used retros and RCS).

So it seem to be, that XR2's hover-ap is overriding GS2's hover-logic...which is fine for me.

-I activated the XR2's autoland and the vessel descended while GS2 was still correcting the lateral offset...all fine...so far.
-as soon as the vessel went below zero-alt (bb is in a crater), GS2's AP switched off (as expected...).

But I want the GS2-lateral corection until touchdown, so I am thinking on two solutions:

1. The clean solution, but would work in Orbiter2016 only:
-using the the new "GetAltitude(altmode_gound)" or "oapiSurfaceElevation".

I tied this, without success...I have really trouble to understand the code, esp to find the correct references to modify.

2. dirty cheat solution
keep GS2's AP "on", and let the user disable the AP as soon as touched down, to disable the RCS-lateral-correction.

I tried this too, but the RCS-corection cannot be switched off via AP-button, once engaged in PLND-mode.
If I i.e. dirty-FORCE the AP to stay online:


Code:
if (Altitude == 888888.10) {  // never-laned-test
      
      VacLandRMode = VACLANDR_INAC; 
      VacLandHMode = VACLANDH_INAC;
      steerActive = false;
      break;

As expeted, after touchdown the RCS keps active.
But VACLANDHR_INAC and VACLANDH_INAC cannot be controlled via AP button.
Would be nice to have this feature.

And....I found a bug, while trying dirty things like above:
-If on a planet without any base configured..i.e. Venus
-you go into CFG
-base shows SURFACE
-hit "next"
=Orbiter-hangs

It seems to be, it tries to cycle to available bases, but if no bases are defined...the MFD is lost as soon as it runs into this cycle.

Ok, it might be very rare, that a user will run in such a problem, because it does not make sense to load GS2 on planet without a base, but I think GS2 should not hang/crash orbiter.

I found this, while searching the code for a "Body-reference" only object, but found only "base.ref, BasePlanet[RunwayBase[runway]]".
So a base and runway/pad is a "must have", to avoid possible Orbiter crashes/hangs. (?)

Why I was searching for a Body-only-Reference ?
Answer: I wanted to use "oapiSurfaceElevation(planet,lon,lat)", for the "clean Orbite2016 only solution".
I didn't find one, so I created my own.
But I was not able to find a place, where I can put the "surfacElevation-value", to make the alt-calculations Orbiter2016-compatible.
The are too many altitude-refs in the code, which confused me.
(i.e. base-alt, target-alt etc....).

Btw...and as mentioned before....the main reason why I have trouble to understand the code, might be related with the fact, that my "programming-skills" are far below zero. :facepalm:
Sorry for such an ASCII-blast. :blush:



Found another bug:
-once landed(via vacuum-ap), you cannot fast-forward the time anymore(it jumps back to realtime)
This happens in Orbiter-2010, too.
It seems to be, that even that thrusters are disabled after touchdown, the part of the AP logic is still running.
 
Last edited:

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
I will release a GS2 for Orbiter 2016 in due course. Actually, I wanted to have a single DLL that could call the O2016 altitude API if present, else default to the O2010 code, and I could not get that to work ... so yeah, don't land anywhere but ~sea level on O2016 yet, till I get you a new version.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Thanks, I remember the discussion about a single dll for both APIs.
In the meantime, I found a temp. solution to take the "surface_alt" during the very last step into the calculations. (was easier then I thought...).
But the main problem for both Orbiter versions is, that the AP is allway active.

I.e.:

-load a scenario with i.e. the XR2 landed at Brighton Beach
-start GS2, while still landed
-select the same base but different pad for later on approach
-cycle through all available modes
-don't start the AP
-launch the XR2, i.e. just hover a couple of meters up
=
GS2 kicks in and tries to navigate to the new new pad via RCS-steering
So the RCS'es are allways active, even after landing.
I.e. try to translate while landed...GS2 tries to compensate back to zero distance.
And as a side-effect, you cannot use time-accel. anymore...for any ship in the running scenario.
The only solution I found was, to quick-save,exit and re-load Orbiter.
Is there no other way to re-init the entire GS2-mfd (not just the stored GS-data and the plotted HAC-view) ?
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
That sounds wrong. You should always be able to deselect the AP and get full manual control back, plus the AP should only activate on positive command.

I have a few things building up here, for a new version. My buddy Ripley is always detailed on my documentation, so I have to take care of that, plus some more work on this AP. I could easily do a cycle-control on the AP, to do full AP, LNAV only, VNAV only, to allow other AP's to do the descent control and alt hold as needed.

I also want to see if there's a way to stream data direct to Excel in real-time, to allow faster diagnosis and tuning of the AP.

And then the RV Orientation descent corridor stuff ... my dream still.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
could easily do a cycle-control on the AP, to do full AP, LNAV only, VNAV only, to allow other AP's to do the descent control and alt hold as needed.

This would be great, so we are more flexible to use the AP in different ways...like i.e. pad-to-pad taxi..or small fly-arounds.
Maybe in LNAV-mode only, it might work on planets with light atmosphere, so the "HAS-ATMO" should be manually toggle-able, i.e. within the CFG-section of GS2-MFD.
Otherwise the AP will not work i.e. on Io.

And btw...the AP is doing a great job, the only issue is the very last step, when it comes to descent to touchdown-point.
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
This would be great, so we are more flexible to use the AP in different ways...like i.e. pad-to-pad taxi..or small fly-arounds.
Maybe in LNAV-mode only, it might work on planets with light atmosphere, so the "HAS-ATMO" should be manually toggle-able, i.e. within the CFG-section of GS2-MFD.
Otherwise the AP will not work i.e. on Io.

And btw...the AP is doing a great job, the only issue is the very last step, when it comes to descent to touchdown-point.

Yup - love that idea of the AP working in light atmo. It would be really cool to calibrate vessels lift, drag and turning authority by pressure and velocity, by AoA and by bank, for each vessel and planet, to determine the amount of assistance from the aerodynamics. In this regard, Aerobrake MFD does an outstanding job, but sadly GP has not posted on the forum for over 5 years. Maybe that's the MFD for renovation next, where Glideslope and AeroBrake could interact so Glideslope gives the AoA and the flight objectives, and AeroBrake returns the drag, heating, and turning authority calculations, to make a symbiotic pair. Damn wow!!
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
I realy like the idea of cross-MFD-communication.
There are a lot of benefits, from what I can see:
-reduce the amount of loaded/needed MFDs...so more runtime-stability
-no need to develop the wheel again and again, just use existent logics and couple them together
-for the beginner...easier to jump into Orbiter's magic, without the need to learn the different usage of many different MFDs.
...

And yes...I agree...AerobrakeMFD coupled to GS2-MFD would be a dream-team.:yes:
Maybe...finaly the XR-vessel API could connect to Module-Messaging-API, then we can sit back and relax and the API's are doing the entire job from take-off to touch-down...:lol:
 

mati140

New member
Joined
Sep 25, 2011
Messages
25
Reaction score
0
Points
0
Unfortunately GS 2.4 doesn't seem to work in Orbiter 2016, it causes a crash on loading.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Unfortunately GS 2.4 doesn't seem to work in Orbiter 2016, it causes a crash on loading.
It works, but needs to be re-compiled against the new Orbiter-SDK.
I have just re-compiled it and it works out of the box...without any changes needed.
However, as far as I know a "pure" 2016 version is in progress, which also checks for the new elevation/altitude-modell.(important for the new vacumm-landing-AP).
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
My beta version 2.5 for Orbiter 2016 is working fine, with full altitude support, and with better terrain avoidance for Brighton Beach. (BB approaching from the west is interesting, as you need to scale a 2km mountain and then drop into a 2km dip, so it's a real test for automated approaches).

Holding off on release, as the non-atmo AP is causing me some major frustration with tuning out the overcorrections on the attitude control, and landing smoothly. Plus I need to sort out Ripley's errata list. I'll get a version out when I have some time (Real Life being the major impediment, of course!).
 

crisbeta

Member
Joined
May 27, 2013
Messages
140
Reaction score
4
Points
18
Glideslope 2 for Orbiter 2010 v2.4

*** Do not use for Orbiter 2016 ***

For this add-on the version selected is Orbiter Version: 160828 :)

Wrong Orbiter version also selected for:
BaseSyncMFD for Orbiter 2010 v3.0
BurnTimeCalcMFD (BTC) 2.9.2 for Orbiter 2010
 
Top