OHM HoverMFD 1.1.3 for Orbiter 2016

Mythos

Addon Developer
Addon Developer
Donator
Joined
Apr 28, 2012
Messages
103
Reaction score
7
Points
33
Location
Kiel
In test I now have that alt mode switch and the delta of the two altitudes is displayed also. And you convinced me to convert the target alt when switching (could be disabled in config file).
I now need to have a look at "VS to target" which should be set on approach. At the moment it sometimes does weird things. It should work like in 2010 version, just considering that target base is not always at alt 0 (ground mode, at least doing all these unnecessary corrections, sounds not to be the right choice for this). It will be up to the pilot to have a look for that huge mountain on the way.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
...It will be up to the pilot to have a look for that huge mountain on the way.

I agree, HoverMFD was allways some kind of semi-automatic-pilot, and this is what makes this MFD something special and nice.
You have to plan a bit in advance (rather than just pressing a button), provide the MFD the correct parameters and enjoy the show(...or disaster...if planning-error).

Regarding the "vs to target", I haven't used it much. It causes some issues for me (in Orbiter2010), when using long-range-travel(went down too soon).
I guess this "vs to target" is more helpful for a classic de-orbit situation(from a high altitude and a steep descent path). If its sending the vessel gradually downwards to base and you are far-fast-traveling, its very likely to hit the ground/a mountain far before the target.
 
Last edited:

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
I had this bug while landing at Brighton Beach.
I admit, I just tried using it without knowing the MFD and reading the docs, so maybe I just clicked on something I shouldn't have clicked.

Z1Vz7Um.jpg


I don't have that scenario anymore, sorry.
 

C3PO

Addon Developer
Addon Developer
Donator
Joined
Feb 11, 2008
Messages
2,605
Reaction score
17
Points
53
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

You use MSL when you want to know where the craft is, and AGL when you want to know where the ground is.
 

Iacomus Maximus

New member
Joined
Sep 10, 2010
Messages
29
Reaction score
0
Points
0
Location
Chelsea
You use MSL when you want to know where the craft is, and AGL when you want to know where the ground is.

Yes, you are much more concise with your statement than I was.

I was trying, poorly, to explain that many aircraft autopilots (military in my experience) have both a calibrated MSL (air pressure) and a radar altimeter AGL input.
However, no autopilot is as sophisticated as 'HoverMFD' but since we have it... why not make it as functional as possible. As a pilot, depending on the situation, I would love to have the option to set altitude as either AGL or MSL.
 

Mythos

Addon Developer
Addon Developer
Donator
Joined
Apr 28, 2012
Messages
103
Reaction score
7
Points
33
Location
Kiel
Version 1.1.3 is on OH now, having that ground or mean radius switch and more improvements about surface elevation.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Many thanks for the new feature. :thumbup:
I have just run some tests on the moon, and it works perfect.
-fast flying to a POI using mean-rad-alt
-as soon as reached destination, switching back to surface-alt and explore the area in slow-flight/hover.

A perfect new way to explore Orbiters new 3D world(s).
 
Joined
Oct 1, 2013
Messages
112
Reaction score
5
Points
18
I exported things to my orbiter program directory as per usual, checked every affected file and everything seems to be working correctly, yet the MFD doesn't show up. Did I do something wrong?
Edit: Oops, forgot to toggle it on in the modules tab
 
Last edited:

potjoe

Member
Joined
Jun 1, 2018
Messages
38
Reaction score
11
Points
8
Hi! After many sessions with this MFD, I realize I just used it wrong, because it is not clear to me how Horizontal speed is handled. The way I used it was : standard deorbit, enable Travel Distance and VS to target, wait until Brake rate = 90%, enable Hor. Speed at current speed, brake. But now, as I deep dive into it again, I have noticed that the documentation states for horizontal speed in travel page : "If only this control is activated, your current speed is increased or reduced to the exact given value. If also “Target Distance” is activated, this speed would be used at maximum speed on the approach to your target."

Currently, I thing this is not the way the MFD behave. Enabled, Horizontal speed setting is always trying to keep the vessel at this exact value, whether or not Target Distance is activated. In any case, small burst from main or retro are keeping the speed to the set value. Thus, it does not seem to be used as a "maximum speed on the approach", suggering that the AP would not keep trying to reach it, or maybe I'm missing something. Am I understanding the way Target Distance works correctly ?
 

Mythos

Addon Developer
Addon Developer
Donator
Joined
Apr 28, 2012
Messages
103
Reaction score
7
Points
33
Location
Kiel
Thus, it does not seem to be used as a "maximum speed on the approach", suggering that the AP would not keep trying to reach it, or maybe I'm missing something. Am I understanding the way Target Distance works correctly ?
Well, if you have set a target, then you pretty much always want to finally reach a "target distance" of 0, because you want to get there (If I remember correctly, the only reason to set a value > 0, would be to chase a moving target). By enabling that control element, you tell the autopilot, to brake early enough to stop exactly there, according to which engine is available for braking. This translates into a speed limit as a funtion of distance to target, to not overshoot.
If you are far far away, the AP would be happy to accelerate to any speed until it immediately starts to brake, because of that speed limit. This would be the fastest, but also burns a lot of fuel. As a trade-off you have to decide on a speed at which to coast, and that is the "horizontal speed" setting in that case. As the AP will accelerate to that speed (if possible), and will reduce from that speed in brake phase, I have chosen the phrase "maximum speed", I think.
It is totally possible that the set speed will never be reached, because you already are within a range where that would be too fast and overshoot.
I thing this is not the way the MFD behave. Enabled, Horizontal speed setting is always trying to keep the vessel at this exact value, whether or not Target Distance is activated. In any case, small burst from main or retro are keeping the speed to the set value.
If it is not reducing from the set "horizontal speed", then it seems to be not set up correctly. Because braking to stop at the target should overrule that. Check that you have a target set, that your vessel is able to brake (retro doors) and so on... Sorry for asking "is the power cable plugged in" :D
Ah, and there is a thing about pointing to the target first. If the AP still tries do achieve that, it is too busy to do any corrections about speed.
The way I used it was : standard deorbit, enable Travel Distance and VS to target, wait until Brake rate = 90%, enable Hor. Speed at current speed, brake.
If you do it like this, none of the settings will have any effect on the AP, until you do the "enable Hor. Speed". This should be indicated by a purple readout, when you enabled them, instead of blue (not quite sure about the VS at the moment). Especially the "wait until Brake rate = 90%" is what the AP should do on its own.

Right after deorbit, I would do (actually started Orbiter after quite a long pause): enable travel distance 0, set horizontal speed to current and enable, enable VS to target. Then just let go.
The only problem with that, is that is messes your speed up a little bit (but will reach target). As you go faster while falling towards Pe, the AP will prevent that from happening and by that reduce your Pe even more. Maybe that is why you waited alle the time without horizontal speed control.

Orbit is actually outside the scope of HoverMFD, so deorbit is quite on the border. It's probably not the best AP for that and taking control and disable AP while watching parameters is probably a good thing.

Maybe David Courtney covers HoverMFD in his recent video series, people seem to ask for. This would be very interesting to me. Not from the point of being most efficient (it probably isn't), but rather to see how people's usage differs from what I had in mind :)
 

potjoe

Member
Joined
Jun 1, 2018
Messages
38
Reaction score
11
Points
8
Thank you very much for your answer! It's nice to see this forum living :).

if you have set a target, then you pretty much always want to finally reach a "target distance" of 0, because you want to get there
So, I understood it correctly : active, it tells the AP to brake in order to stop at the target set. We're good on that.

If it is not reducing from the set "horizontal speed", then it seems to be not set up correctly. Because braking to stop at the target should overrule that. Check that you have a target set, that your vessel is able to brake (retro doors) and so on... Sorry for asking "is the power cable plugged in"
Actually, this is quite the contrary I'm observing, but the rest of your answer explains it. I think HoverMFD currently works as intended : with an horizontal speed set and active, it brakes when brake rate is equal to 90% (or whatever rate set). I do have a Target set (no worries for Pebcak check ;)) but as you described, the velocity is not the same accross the descending trajectory after deorbit : Pe. vel > Ap. Vel. Then, the issue I'm having is not that "it is not reducing speed", rather that the AP keeps the ship at Ap. Vel. if you set and activate Horizontal speed right after your deorbit.

Maybe that is why you waited alle the time without horizontal speed control.

Absolutely, but I understand now that it is not an issue, but it is by design way this MFD works. You can set a Cruise speed, that the AP will try to maintain, whether Target Distance/Vs To Target are active or not (this is what confused me in the documentation). As you mentionned, we are there at the limit of a Cruise MFD/orbit MFD, since doing so would result, in a deorbit, to a waste of fuel. In the situation desribed above :
the AP will prevent that from happening and by that reduce your Pe even more
because keeping the vessel at Ap. Vel. during the descending phase mecanically reduces PeA.


Then, to sum it up, we seems to have at least two ways to achieve a successful landing :
Right after deorbit, I would do (actually started Orbiter after quite a long pause): enable travel distance 0, set horizontal speed to current and enable, enable VS to target. Then just let go.
if you're not concerned about Fuel consumption, or
standard deorbit, enable Travel Distance and VS to target, wait until Brake rate = 90%, enable Hor. Speed at current speed, brake.
if you want to be as fuel efficient as possible. Am I right ?
Actually, I also reopened Orbiter after a long pause to compare HoverMFD's efficiency with what David tested ! Thank you again for your detailed explanations.
 
Last edited:

Mythos

Addon Developer
Addon Developer
Donator
Joined
Apr 28, 2012
Messages
103
Reaction score
7
Points
33
Location
Kiel
if you want to be as fuel efficient as possible. Am I right ?
Thinking about it, you only want it to brake and not accelerate after deorbit, but the little bit of acceleration from gravity is ok. So what you can do to have a more fully automated approach is:
  • Disable forward engine control on page 4
  • set a way too high horizontal speed and enable, without forward control AP will not accelerate
  • enable VS to target
  • the AP will ignore the urge to speed up, but will be fine watching the speed rise from gravity
  • on time it will start braking, because that control is still enabled
Usually for the good looking approach you would use main as forward and retro to brake. But the more fuel efficient way would be to fly in reverse all the way, so have retro as forward thrust and brake with main.
 

potjoe

Member
Joined
Jun 1, 2018
Messages
38
Reaction score
11
Points
8
  • Disable forward engine control on page 4
  • set a way too high horizontal speed and enable, without forward control AP will not accelerate
  • enable VS to target
  • the AP will ignore the urge to speed up, but will be fine watching the speed rise from gravity
  • on time it will start braking, because that control is still enabled
Yes I definetely agree with it ! Tinkering with the MFD this is something I had the occasion to try and you're right, it seems to be the most efficient in hover mode. Indeed, as you mentionned, you do not encounter this kind of issue with Tailsit or Heli mode since the AP is too busy correcting lateral speed. In Hover mode, it works really well to set the heading to 180, disable retro engine to avoid acceleration, and to enable it again once braking has started (to correct overshoots if needed). I ended up with a reasonable fuel cost with this method!
On the subject of comparing the different modes, I do have some issues with tailsit and heli mode though, not sure what it is related to. Breaking burn does not always start. Here are the parameters : every engine enabled page 4, Hor. Speed / Travel distance to 0 / VS to target set and active page 3, base / pad and heading 0° set and active pg. 2, Vertical speed set to -100 page 1. AP active, it will correct the lateral speed by rotating the ship, and slowly pitch up the nose to prepare the braking burn. But when braking is suppose starts (Brake phase) , the hover engine does not fire at all. I saw this behaviour both in tailsit and heli modes, in case of a descent to brighton beach from a 15km apa, and PEA set to 11km right after the base. I initially thought it was due to some issues with the Xr2, so I started the "Landed at brighton beach" scenario, and going from one pad to another in both modes worked without issue and hover started as intended. PEBCAK check : Yes, hover and retro doors were opened :D
 

Mythos

Addon Developer
Addon Developer
Donator
Joined
Apr 28, 2012
Messages
103
Reaction score
7
Points
33
Location
Kiel
But when braking is suppose starts (Brake phase) , the hover engine does not fire at all. I saw this behaviour both in tailsit and heli modes
Yes, I was originally supposing heli mode in the first reply, but then removed that in the edit, after I tried myself in Orbiter. What you describe is totally by design, because the heli (and tailsit) never ever control the downward facing engines. That is exclusively controlled by the VS and altitude part of the AP. But after deorbit, the vertical descent is actually very slow and the AP is totally fine with that, so the engine never fires. The heli mode is just designed assuming that there will be some necessary hovering, and then just tries to accel/decel by pitch only, no thruster control.
My idea about heli mode would be to do your deorbit burn in such a way, that the trajectory actually hits the surface way earlier than the target. The AP will avoid the surface hit by starting a proper hover and then the heli may have enough thrust to work with for braking horizontally. In heli mode you have the advantage, that it might pitch down right after deorbit, when you set a way to high horizontal speed. But for the same reasons, it justs pitches and since there is no thrust from vertical AP, it doesn't accelerate.
 

potjoe

Member
Joined
Jun 1, 2018
Messages
38
Reaction score
11
Points
8
What you describe is totally by design, because the heli (and tailsit) never ever control the downward facing engines. That is exclusively controlled by the VS and altitude part of the AP. But after deorbit, the vertical descent is actually very slow and the AP is totally fine with that, so the engine never fires.
This makes totally sense, VS is indeed really close to 0, or even positive if you have not perform a prior deorbit burn. I intuitively thought that the downward facing was actually controlled during descent phase but as you said, Hover MFD is not meant to be used for orbital operations. I will try different scenarios, with different hit points to see what I can come up with! Anyway, if I read you correctly, in order to have a braking in these modes, I should aim a trajectory where VS to target is too low, and where the energy cost to raise this VS is higher or equal to the cost for braking (lower horizontal speed to 0). Thank you very much for your detailed answer on your MFD! Happy to see that you opened Orbiter to answer, I hope you had a good flight :hailprobe:
 
Top