OHM HoverMFD 1.1.3 for Orbiter 2016

[Mythos]

Hover MFD is an add-on for Orbiter introducing a new multifunctional display and a universal (meant for all spacecraft) autopilot for many kinds of maneuvers that use your hover engines.

The autopilot functions are inspired by autopilots built in Arrow Freighter and DGIV. I wanted these functions to be available for other spacecraft and I wanted some fine tuning to be able, like having a “Level Horizon” that doesn’t keep pitch and bank to zero, but only one of both.

With the right parameter setup the autopilot can:

• Launch in hover style (e.g. from pad)
• Landing in hover style (e.g. on pad)
• Apply desired vertical speed (up or down)
• Slow downward vertical speed automatically for soft touchdown
• Maintain specific altitude
• Keep horizon level (standard) or any other pitch and bank
• Turn to desired heading
• Turn nose into horizontal airspeed direction (or relative to)
• Turn (relative) to target (NAV signal, coordinates, named base)
• Travel to target by main- and retro-engine
• Travel to target by hover-engine with pitch/bank control
• Maintain or capture center position over target
• Taxi from pad to pad (or any other target)
• Dynamic engine assignment (pod thruster support)

This is version 1.1.3 for Orbiter 2016, main updates from Version 1.1.2:

• New setting “Alt Mode / Delta” on page 1 lets you switch between altitude above ground or mean radius
• Reworked “VS To Target” for surface elevation of target, changed display to current and target VS value
• Horizontal speed is now using ground speed instead of airspeed
• Workaround for Orbiter [v.160828] issue with SetAttitudeRotLevel

For Orbiter 2010 version use Hover MFD 1.1.1

Here are some video samples using Hover MFD:

DG going into Tailsit mode (1.1.1)
http://youtu.be/AO-y6A9B8 Uc
Using Travel page for base approach (1.1.0)
http://youtu.be/a_L--KlDo 1g
ShuttleA pod thrusters used dynamically (1.1.0)
http://youtu.be/xcaFzxcTf wY
Launch, taxiing and landing (1.0.2)
http://youtu.be/X9zPhNLd7 qw
XR2 heli taxiing on earth (1.0.2)
http://youtu.be/wM5lHUaAX Jk

Installation or update: Unpack HoverMFD-VERSION.zip to your orbiter folder and overwrite all files.

Read the HoverMFD.pdf (unpacked in orbiter's doc folder) for more details.


DOWNLOAD

 

[Mythos]

Feedback wanted

Not that intense testing, just made sure it is usable with Orbiter 2016. Had a quick look on ground level of course. Please report!

 

[turtle91]

Just hovered around at Brighton Beach.
I went carefully into the mountain area (alt 250 agl/about 60 m/s forward velocity).
It was funny to see how HoverMFD has done very precise terrain-follow.
Then I switched to NAV mode, to auto-heli-hover the DG back to the pad.
The landing was fine.
This was exactly for what I was looking for, I will do more sightseeing trips close above the moon-surface now...

Many thanks

 

[Iacomus Maximus]

Have not tested yet, but have been waiting for this update to 2016 more than any other.

All I need now is RV Orientation and I'll be all set for my highly computer assisted futuristic jaunts around the solar system.

 

[Nicholas Kang]

A great add-on. Launched aboard DG to orbit and deorbited using this HoverMFD but I noticed one strange effect of DG after landing from deorbiting when using this add-on. The autopilot system automatically terminated soft-landing but hit F1 on keyboard on you will notice there appears to be a slight glow on the right-hand side of DG's wing, which I suspect was the RCS still functioning. I can confirm this when I saw the numbers on vertical speed, horizontal speed and heading changes even though DG has landed and appears to be stationary. Also, DG appears to be slanting to one side (to the right as I deorbited using main engine, 180 degree hdg, thus when arrived at brighton beach, my cockpit faces 270 degree.) Is this effect due to uneven surface of landing pad?

I follow the "launch to orbit" and "deorbit" tutorial at the end of the HoverMFD tutorial and tested this MFD using the default brighton beach scenario included in the original Orbiter 2016 folder. Using Windows xp, d3d9 client, full screen.

Can anyone reproduce my problem and explain why? Or is it due to a bug in the program?

Nicholas.

 

[Mythos]

autopilot system automatically terminated... RCS still functioning.

I can confirm this and standard level horizon with a manual hover does not have this issue, so blame it on me.. I will have a look

DG appears to be slanting to one side.

Confirmed, this is most likely due to previous problem.

Is this effect due to uneven surface of landing pad?

Brighton Beach look pretty flat to me. But on my test flight on earth yesterday I landed on a slight slope nearby a lake where AP didn't realize the touchdown. I wouldn't call this a bug since AP is made to level horizon and having only one wheel on the ground could not be called landing finished. At the moment I have no solution but may think about it.

180 degree hdg, thus when arrived at brighton beach, my cockpit faces 270 degree.

Did you notice when the rotation happened? There can still be some deviation in your speed slightly missing the pad by some meters. This is when you may notice nose direction and speed indicator slightly dancing around each other and linear RCS may be not capable correcting this or being interrupted by rotational RCS in another dance about having control. This has been in 2010 version, too.

 

[turtle91]

autopilot system automatically terminated... RCS still functioning.

Might be related to this new bug:
http://www.orbiter-forum.com/project.php?issueid=1271

 

[Mythos]

Might be related to this new bug:
http://www.orbiter-forum.com/project.php?issueid=1271

Sure, that's what HoverMFD does. If Orbiter doesn't react to this command, that's a problem. Maybe there is a workaround or we'll have to wait for an Orbiter patch.

 

[turtle91]

The only workaround I found is to "missuse" PursuitMFD.
After landing, when the RCS is still firing, I open PursuitMFD and switch to landing-mode.
Then a (very short) AP press/unpress released the RCS and the vessel comes to "landed/IDLE"-state.

 

[mati140]

It appears that the autopilot reads airspeed instead of ground speed, because when set to maintain 0 horizontal speed it starts moving trying to zero-out TAS. Orbiter 2016 introduced wind, which means it should read ground speed here instead of airspeed.

 

[turtle91]

I have an idea for a new feature...should be not too complicated to implement.
While at slow and low hovering, the terrain-altitude-follow is a nice feature to i.e. explore the area around a landing site.
But for base-to-base flights, it makes the AP a bit unprecise(might be caused by the many "AP freefall" events).

Example:
I hovered in heli-style from Brighton Beach to the "UMMU 2.0 DEMO" base (which comes with Dan's UCGO addon).
-Base distance is about 2000 kms.
-I set HoverMFD to 7500 meters altitude (alt in relation to starting point at Brighton Beach)
-travel-speed was slightly below orbital-speed, I used 1200 m/s
=
As expected, the AP tried to follow the ground-elevation altiude, which causes some wild corrections at such horizontal-speed.

So...my idea for long-smooth-distance-travel....
-A button, wich switches between (now default) ground_alt and "current mean radius altitude"(old style alt).
The "forget-about-ground-level(FABGL?)-button" could be placed on the first page of HoverMFD...there is still one button free.

 

[paddy]

Just been told about this version for 2016 ( don't know why search did not find it??).
I like the idea of being able to switch between "altitudes".
If I was to fly between lunar bases on a "as crow flys" path, surely it would be down me to be to avoid any great mountain peaks in the planning stage!
If I am flying at 10k above all peaks, would it matter if I was 9.5, 10 or 10.5 (en-route), fuel saving would be much more important?


P.S. I had intended not to use "2016" if this add on was not available. Many thanks

 

[Iacomus Maximus]

It's common practice to MSL "Mean Sea-Level" for most high altitude flying and to use AGL "Above Ground Level" at lower altitudes.

 

[Mythos]

In test I now have a workaround for the RCS issue and replaced airspeed by ground speed. And I like the idea of a ground/mean-radius switch.

 

[Interceptor]

Thank you Mythos for this Very essential MFD.

 

[Mythos]

Would you all agree that setting negative values to target altitude should still not be allowed when it's related to mean radius, just as a security feature?

 

[turtle91]

So you want to make the mean radius user-set-able ?
Would it be not easier to translate(via switch) the current ground-elevation-altitude to static mean radius-altitude ?
So one could reach a safe-altitude and just hit the hold-mean-radius-alt-button on the "fly".

However, if you want to set mean-radius user-selectable, I agree with you.
If one wants to fly in craters/below-sea-level, he could(and should) allways switch back to ground-elevation-mode.

 

[Mythos]

Would it be not easier to translate(via switch) the current ground-elevation-altitude to static mean radius-altitude ?
So one could reach a safe-altitude and just hit the hold-mean-radius-alt-button on the "fly".

This is not how Hover MFD handles all other values and I'll make it consistent. So if there is a reading in mean-rad the below target value is also given in mean-rad and AP tries to match. And the target value is fixed and should not change while moving.

Also I don't like to add a magic number to the target value and a moment later subtract another magic number (because you moved) when you switch back because is was the wrong switch to touch.

But that really will mean just switching the mode will NOT keep you in position when the target was already reached. And changing mode and target value simultaneously is only possible when temporarily turning off alt control... And that will need to have VS set to 0 before... Or temporarily turning off AP at all (hover thrust level will stay almost right).

Just to set the value "where you are now" there is this trick with right click on the SET button.

I also don't see any smooth transition from tailsit mode to any other, made quite a trick move in the example video

But this is how it works. If you change a setting AP will react. That's no problem if you plan it beforehand (how would you do that in your suggestion?).

I'm not really satisfied with this. But I would not be with violating consistency also. It's one thing what you would expect to happen and another what someone else does :hmm:

 

[turtle91]

Another aproach of using the "switch-button" might be:

-start from base with 0 horizontal speed...just hover-up to safe-altitude
-at safe-altitude, switch to mean-radius-mode (so a short AP disconnect should be not a problem at this stage, as the hover engines are still running at previous AP set power(alt-hold)
-then activate nav-taxi-mode and fly to the target
-when target reached (still at mean-alt)...AP disco....switch to ground-alt....AP connect
-fast-descent to target setting high negative VS...if you are in a hurry
This might be not the most fuel/time/efficent method, but might be the easiest way.

So...short version:
The "mean-switch" button should only be click-able, while horizontal-speed is very low(i.e. -+5 m/s to give it a bit tolerance).

Why I want to be at mean-alt until target reached ?:
The reason is, when coming in fast (i.e. moon horizontal speed 1200 m/s, brake rate set to 85 percent), and using ground-elevation as the reference, the AP will likely overshoot about 100 kms (tested). Of course this has been caused by underlying bumpy terrain and too much "free fall" events.
The same setting worked fine for me in Orbiter2010.
So "mean-radius until target reached" should be used for high-range-travel.

 

[Iacomus Maximus]

MSL vs. AGL - Let's not over think this

I worked for many years as a software engineer maintaining a few simulators for the Air Force. I do not have a pilot license but I have flown all the simulators I ever worked on and am rather confident in my abilities. Having said that... Let's not over think this.

AGL and MSL are just different representations of the same altitude.

If you are landed at Ascension Island you are 85 meters MSL and 0 AGL
If you are landed in Death Valley you are -86 meters MSL and 0 AGL

As a pilot, hovering above the ground, I believe the format of most important piece of information you would want would be is your altitude in AGL, followed by ascent/descent rate m/s, and then perhaps horizontal speed.

However, for high and fast travel I would prefer MSL for continuity. I don't believe terrain following is what you want to be doing at 10.6 km (35,000 ft). That could be quite the roller-coaster ride!
Below 3 km (10,000 ft) you might want AGL or you may prefer to wait until you begin your final descent I think that should be up to the pilot.

Sitting on the ground at Ascension Island: ELEVATION: 0 AGL / 85 MSL
Set Mode Switch to AGL.
Enter Target 1000 meters. Enable AP. Climb (hover) to 1000 meters AGL.
Set Mode Switch to MSL. Target Altitude now reads 1085 MSL.
(the highest point on the island is 566 meters MSL)
In MSL mode you can taxi all over the island and be flat and level the entire time.
In AGL mode you would be continually ascending and descending to follow the terrain.

I agree with Turtle91:
"Why I want to be at mean-alt until target reached ?:
The reason is, when coming in fast (i.e. moon horizontal speed 1200 m/s, brake rate set to 85 percent), and using ground-elevation as the reference, the AP will likely overshoot about 100 kms (tested). Of course this has been caused by underlying bumpy terrain and too much "free fall" events.
The same setting worked fine for me in Orbiter2010.
So "mean-radius until target reached" should be used for high-range-travel."

I have developed a procedure for a deceleration and hover descent from orbit to land at a landing pad.
With the addition of ground elevation in Orbiter 2016 (and if AGL were included in Hover)
I would amend my procedure for rapid descent to ~3,000 meters MSL, zero-out my horizontal speed, proceed to touch-down in AGL mode.
If I were to forget to change modes and slammed into the ground at 250 meters/second... I see that as "pilot error"