OHM HoverMFD 1.1.1 for Orbiter 2010

[Mythos]

I am still confused whether it's XR2 or orbiter reducing thruster efficiency within atmosphere.

And I also want my questions about GetMaxThrust and GetThrusterIsp (http://www.orbiter-forum.com/showthread.php?t=27785) cleared for better prediction and future orbiter versions compatibility.

But for now I've solved that atmospheric error by reading the vessels thrust in next timestep and comparing it to the thrust the AP wanted to set. In XR2 on earth I get only 80% of it giving me another factor of 1.25 multiplied to my counter-gravity-thrust-level and my do-something-additional-thrust-level

For this to work, adaption had also to be slowed down by building an weighted average of now calculated and former value.

The efficiency can be read out on engines page below the "Hover Max Thrust" (this name will [for me it was weeks ago] change also in next version to be physically correct, once it was "Hover Power").

For now I spent much time with this topic although I first tended to say "not supported" :lol:

Not only time but also fuel consumptive, since test launches to 20m only, monitoring a while and soft landing (very soft on earth it is) for two or three times empty my standard XR2 tanks... Thanks martins I don't have to pay for that fuel

Side effect of this adaption to athmospheric thrust reduction is of course a general increase of stability. It now also clears out manually applying LIN RCS up or down.

You may thank Keatah for his interest into this topic and keeping my feedback-adrenalin up :thumbup:

 

[Mythos]

For Keatah: http://youtu.be/wM5lHUaAXJk

I'm testing all new features and updating documentaton. Next version will come soon.

 

[Keatah]

Ohh that looks nice. I can't wait to get the avionics updated.
This will be useful in my hoverforce demo team. Looks like we'll all have to have our ships refitted soon enough.

 

[Interceptor]

Very impressive,looking foward to the next release.

 

[Mythos]

Update is done now.

For further improvements you all may help fine-tuning and collecting some common vessel-specific config files.

 

[C3PO]

I've been flying a few approaches at Brighton Beach in a Deltaglider using this MFD, and I noticed that most of the time I was flying with a steady vertical speed. That gave me an idea.
:hide:

When vertical acceleration is zero, the horizontal acceleration depends only on the pitch angle and gravity.
a: horizontal acc. [m/s^2]
g: surface gravity of current body [m/s^2]
[MATH]\alpha[/MATH]: pitch angle
[MATH]a=g*tan \alpha[/MATH]
The linear acceleration makes the stopping distance easy to calculate too.
s: traveled distance [m]
[MATH]\Delta V[/MATH]: initial horizontal speed [m/s]
[MATH]a = \frac{\Delta V^{2}}{2*s}[/MATH]
So if you know the distance to your target and your horizontal speed, you can calculate the required pitch angle to nail the approach.
[MATH]\alpha = atan (\frac{\Delta V^{2}}{2*s*g})[/MATH]

As luck will have it your MFD provides all of the required data. The horizontal Z speed provides the horizontal speed, and the Nav1/Nav2 display provides the distance. You could use the one that's selected in the Hdg Mode.

My idea was to add this "Required pitch" as a number displayed on the MFD. Then the user could set the pitch manually to manage the approach speed. He can choose to carefully approach at a low angle or a last minute hair-on-fire last minute breaking maneuver.
The method isn't super accurate,and you would need to tweak the angle as you get close, but it should be good enough to make the MFD "capture" the pad.

 

[Mythos]

That's a good notice, C3PO.

What I actually calculate is first the maximun angle to still counter gravity by
max_angle = acos ( weight / hover_max_thrust ) = acos ( gravity / hover_accel )

Then the max_angle is reduced to have some reserve for pitch AND bank same time and also to be able to reach upward VS. That factor can be defined in config file (HeliMaxAngle). Default 0.9 would not allow max pitch AND max bank AND positive VS, but 0.8 would do that (Would someone help my to calculate what part of an max_angle towards horizon remains for pitch if some part of it is spent for bank already?)

Thruster level to have 0 VS would then not be 100% but
heli_counter_lvl = hover_counter_lvl / cos ( reduced_angle ) = weight / ( hover_max_thrust * cos ( reduced_angle ))

The de/acceleration done at that angle and at that thruster level should be if I didn't miss anything
heli_accel = hover_accel * heli_counter_lvl * sin ( reduced_angle ) = hover_accel * hover_counter_lvl * tan ( reduced_angle )

Then I calculate the max_speed you can have at current distance to reach target by max deceleration (it's the same with linear thruster acceleration in "Hover" and "Lin Nav" mode)
v_max = sqrt ( 2 * distance * heli_accel )

Again this has to be reduced, because there is always some delay esepcially by pitch-control. Here also equal to linear thruster mode and to vertical speed I have the max speed aimed and compared to current speed. When I'm below I can accelerate or just wait (or apply only a little amount of "thrust" - that is what you suggested). If I start overshooting aimed speed (this will be one delay argument to not aim real max_speed) there comes some need for "thrust". In heli mode I just set angle between + and - reduced_angle like thruster levels are set.

My Idea to wait for reaching max speed or even acceleration (in "Taxi" mode) was to have the approach done in shortest (with reserve) time. Time is fuel since this is a hover with counter-gravity-fuel-waste all the time. I think decelerating just a little all the time will take longer and so use more fuel.

So if you know the distance to your target and your horizontal speed, you can calculate the required pitch angle to nail the approach.

Then the user could set the pitch manually to manage the approach speed. He can choose to carefully approach at a low angle or a last minute hair-on-fire last minute breaking maneuver.

These are two sides. If the all-time-pitch is calulated just from here to target then there is no option to have it smoother or last-minute-hard. Maybe I can build a control to manage the config file option HeliMaxAngle in real time. This would do smooth or hard decision since it goes into calculation of all the others.

My idea was to add this "Required pitch" as a number displayed on the MFD.

That doesn't sound difficult also, I will look for a fine place to write it

If you can read it will be 20° from here to target you may set 10° and AP will take control and do it harder later (this is what "Approach" mode is for).

Some other thing to mention: There is some other break-even-point you will notice. At some distance the function for speed it turned from sqrt to linear (see manual). This causes vessel to break harder / pitch more for short but then coming to a smoother linear approach with less speed and pitch.

 

[C3PO]

I really should learn to do a better job of explaining myself. :lol:

The way I've been using this MFD for powered descent is to disable hover engine and linear RCS. I establish a ~150 x 15 km orbit with Pe close to target. When I get close to the target (~400 km in a DG) I set Yaw to 0° (vv), Pitch to 86° and roll to 0° in hover mode. I set hover to 100% manually, and when the speed gets below 1000 m/s I should have the target VOR on Nav1. I switch Yaw from vv to Nav1 and I use bank to get rid of any cross range error.

When the speed gets to ~500 m/s I set VS to -40 m/s, engage the auto hover and pitch down to 15°. I adjust vs by eyeball (usually to around 20 m/s) and set altitude to 500 m (just as precaution). When the vs is established I set the required angle to stop at the target. This is where the readout would be very helpful. I need time to check the angle on a spreadsheet, so I have to switch task. If the MFD had a readout I could just wait until the readout was down to around 40°, and the breaking could be done later.

Because the speed makes the actual gravity different from surface gravity, the real angle will be higher then in my formula. This isn't a problem because you should use a pitch that is slightly higher so the last part is flown at a lower angle. If the readout had 2 decimals you could pitch up until the readout was slowly decreasing. I like to get the angle down to 15° for the final approach.

I switch to Heli for the capture of Nav2 at the pad, and the MFD takes over without any problems.

---------- Post added at 11:34 PM ---------- Previous post was at 10:27 PM ----------

What I actually calculate is first the maximun angle to still counter gravity by
max_angle = acos ( weight / hover_max_thrust ) = acos ( gravity / hover_accel )

Then the max_angle is reduced to have some reserve for pitch AND bank same time and also to be able to reach upward VS. That factor can be defined in config file (HeliMaxAngle). Default 0.9 would not allow max pitch AND max bank AND positive VS, but 0.8 would do that.

You should never wait until the last moment to break even if that's the most efficient use of fuel. The last part should be at a low enough pitch angle to make it possible for a pilot to fly. The first part is just about slowing down, and vs and direction isn't really that important. It's probably more efficient to have a AoA at exactly 90°. You should be have a ground track that passes close to the target anyway. It takes far less energy to change direction once you've slowed down. Calculating max angle doesn't make any sense for high speeds. The force of gravity is reduced by the ratio between (actual tangential speed)/(circular orbit speed for current radius). At periapsis you're actually at your max upwards acceleration.

Here's a nice paper on powered descent of the LSAM: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=1650&context=etd
Most of the math is beyond me, but the profile on page 93 describes a descent very well.

Would someone help my to calculate what part of an max_angle towards horizon remains for pitch if some part of it is spent for bank already?

Reduce hover force by multiplying with cos(bank angle), and recalculate max pitch.

My Idea to wait for reaching max speed or even acceleration (in "Taxi" mode) was to have the approach done in shortest (with reserve) time. Time is fuel since this is a hover with counter-gravity-fuel-waste all the time. I think decelerating just a little all the time will take longer and so use more fuel.

That's nice in theory but very hard to do in practice. Even the Apollo LM used a 15° flight path towards the "landing gate", and it was notoriously short on fuel.

 

[Mythos]

You are pointing to some problems I noticed too.

It's still just a "Hover MFD" so it's designed for being in a hover already (or put you there from landed state). After deorbit burn being on approach with orbital speed is no hover situation, there is nearly no need for thrust because low VS is done by your speed.

The heli mode just uses a side effect by applying pitch and bank to that thrust needed for VS normally. Here again, no need, no thrust, no heli.

Approaching a base is of course some task I want my AP to be able. The actual version is doing first steps only.

For now the heli mode was done to know how to do such. I "misused" the "Lin Nav" mode to put heli calculations instead. I always thought of more control for horizontal speed. First main and retro engine come to mind that are never touched in current version. There has to come another page with all the related info and parameters. Maybe I move any heli function to such page and have "Lin Nav" for linear RCS only again.

When the vs is established I set the required angle to stop at the target. This is where the readout would be very helpful. I need time to check the angle on a spreadsheet, so I have to switch task. If the MFD had a readout I could just wait until the readout was down to around 40°, and the breaking could be done later.

I see the usage and I will take into my considerations.

Here's a nice paper on powered descent of the LSAM: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=1650&context=etd
Most of the math is beyond me, but the profile on page 93 describes a descent very well.

Also beyond mine. Besides the first part of the path the rest looks like Hover MFD will do it. At least if you use it the way I do, since it's not fully automated (watch eyeball and such).

Reduce hover force by multiplying with cos(bank angle), and recalculate max pitch.

I thought more of a formula containing just 3 angles pitch = f(max_angle, bank) or maybe bank = f(max_angle, pitch)... I don't know what's best to steal from when both pitch and bank are needed.. Reducing both to sum up in max proportional to their need would be best.

That's nice in theory but very hard to do in practice. Even the Apollo LM used a 15° flight path towards the "landing gate", and it was notoriously short on fuel.

Of course Hover MFD should be realistic. On the other hand it's for vessels like DG having main and hover engines, these are somewhat futuristic.

 

[C3PO]

Of course Hover MFD should be realistic. On the other hand it's for vessels like DG having main and hover engines, these are somewhat futuristic.

Making an MFD that works for every craft on every body is a very tall order. But I have to say this is one of the best attempts I've seen so far. :thumbup:

Just for fun i made an Apollo LM Sim. Just a cfg vessel with the LMs data and the ShuttlePB mesh. I tried 3 descents from a 10 x 150 km orbit that was 9 km out of plane. I made it on the pad with more then 1,000 kg of fuel left every time. That's way better than Neil. :lol: Of course he didn't have a pause button.

I had to pause to make the pitch-calculations, but I used the MFD for control all the way down.

 

[Mythos]

So if you know the distance to your target and your horizontal speed, you can calculate the required pitch angle to nail the approach.
[MATH]\alpha = atan (\frac{\Delta V^{2}}{2*s*g})[/MATH]

I just tried this (currently printing to oapiDebugString) and I precisely hit the target :thumbup:

 

[C3PO]

I just tried this (currently printing to oapiDebugString) and I precisely hit the target :thumbup:

Sweet! Engineering is like math, only louder. :lol:

You just have to remember the conditions. A stable VS and low speed (low'ish, not close to orbital). As you get close to your target, the error of using linear acceleration becomes insignificant.

I have been thinking about this for quite some time now. The oldest note I could fid was last saved in 2004. :hmm: What will be the most useful data to present to the pilot? The VTOL-MFD does show the angle and relative speed but isn't really all that useful. You'll have to be very good at mental calculations or an android.

Using autopilots for yaw, bank and hover (VS) makes the job of the pilot so much easier, that it's almost essential. The optimal pitch seemed to be the most useful information. I was thinking of presenting the delta azimuth (DelAz) like the shuttle, but the horizontal X-axis speed works even better. :thumbup:
That leaves the descent rate. This gets more complicated because if you use linear acceleration, the result is only accurate if you fly at the optimal pitch angle. You need to know how much time it will take to arrive at your target, and that depends very much on how "aggressive" you fly the final part.

My idea was to display the final altitude if you used optimal pitch and current VS. The time is easy to calculate for linear acceleration.
[MATH]t = \frac{2*Dist}{\Delta V}[/MATH]
Final altitude would be:
current alt + t * VS (vertical speed should be negative at this point)

This way you can "fly" your approach with only two displayed values. You just have to adjust the VS so the the "final alt" is where you want to end up. The problem with non-linear acceleration can be solved by aiming for a higher Alt initially. Using my pause/spreadsheet method I've found that you can set the VS depending on the distance from target.

150km: 0-1000m final alt
50km: 400m (+-150m. Accuracy not that important yet)
2km: 30-50m (Low if the approach is "aggressive")
Final part: Just make sure it doesn't go negative.

If you use constant VS the final part of the approach is going to be very steep, making it hard to pick a good spot for off-pad landings.

 

[Mythos]

You just have to adjust the VS so the the "final alt" is where you want to end up. The problem with non-linear acceleration can be solved by aiming for a higher Alt initially.

I always did it this way, aiming a point far over the target pad, zeroing all horizontal speed and then go down vertical. This is a must for all vessels without wheels that could handle some speed (z only).
Recently I captured my target pad at 10km altitude and then started the last approach falling like a brick. Hover MFD can handle setting -1000 VS and then watching your fall (what a feeling) relying on "Soft Landing" to have a smooth touchdown

If you use constant VS the final part of the approach is going to be very steep, making it hard to pick a good spot for off-pad landings.

No problem to have it steep. The only problem is to keep target over pad and not falling down so you would come down too soon.
I already had some thoughts about this and I think I will make some control to calculate VS depending on speed or distance, maybe to hold constant angle towards the ground (what name was that? AoA was relative to pitch, I think).

For now I have a version displaying the target angle to have it constant when in heli mode and "Course" or "Capture", here you will need it. In "Approach" mode it displays the Vmax that could be zeroed by automatic pitching in that mode, so you will know if there is some V left for accelerating by main engine or pitch down.

This minor release is attached.

When I have some time again (I used my girlfriends exam for the last update) I will overthrow some things again, remove that HeliNav and move it to another page with some more info and controls for main, retro and such heli movement. Also in my mind is to set up a target by base name or lat/lon and be independent to signal ranges by this. After starting this all is in a mess until that page is finished. So this one here is the last version before that

 

[C3PO]

Wow! That was quick.

I'm grabbing one for tests. Thanks 1E6

---------- Post added 07-04-12 at 03:21 AM ---------- Previous post was 07-03-12 at 05:20 PM ----------

The angle read-out works a treat! :thumbup:

The problem with a steep approach is that leaves you with very little time to pick a landing spot. When you're aiming for a landing pad, it doesn't really matter that much. (except it's not very fuel efficient)

The realistic profile is a slow 15° slope for the last minute, and ends at 30-50 m altitude with a VS of ~-1 m/s. They do a "Powered Pitch Up" to get a better view of the landing area. It's mainly a safety requirement so you can see the landing spot early enough to make changes if there's something wrong.

The LSAM profile:

 

[CaptBlanc]

Given how well this MFD works already, why don't you go ahead and put in a switch allowing the main engines to be used instead of the hover engines, for tail-sitters (Like the Apollo LM and other tailsit rockets.) and variable-vector engines. (Like the Quad-J Firefly.)

This MFD got my attention as a sort of improvement over the older "Auto-Hover" MFD, so I have been playing around with it for a few days now. Pretty sweet tool!

 

[Mythos]

Given how well this MFD works already, why don't you go ahead and put in a switch allowing the main engines to be used instead of the hover engines, for tail-sitters (Like the Apollo LM and other tailsit rockets.) and variable-vector engines. (Like the Quad-J Firefly.)

My work is not done for now. The current version was my second release giving you some new features. Some more features are in my mind since I started my work a year ago, some others come in necessary more just-in-time Without my limitation to standard vessels all would have taken much much longer or maybe I'd gotten lost in code-nirvana. That maybe a thing to consider if other features are done first.
Naming two good examples is a good thing, because my orbiter experience is limited to such standard vessels like DG and Arrow, so I've never tested a tail-sitter or others. First question in my mind would be: Has a tail-sitter it's main engine still at z-axis or does it use standard setup execpt for the gear?

 

[CaptBlanc]

That depends on the vehicle. PROPER tailsitters are just craft that land/takeoff with the nose in the air. Thrust is along the z-axis, always. Have a look at Jason's old Rocketship Heinlein for a good example. [ame="http://www.orbithangar.com/searchid.php?ID=2995"]RocketshipHeinlein V1.2[/ame]

Some, like the Lunar Descent Module in AMSO, use the hover engine as main thrust and have NO main engine at all. This is an easy way to keep the pilot-view horizontal, and not looking up at the sky when manuvering.

If you have a look at Computerex's Hover MFD : [ame="http://www.orbithangar.com/searchid.php?ID=3057"]AutoHover[/ame]

You can see how he cleverly set a Toggle that allows you to swap control between the ships hover engine and main, depending on what you need. No need to code for each-and-every ship addon available!

For variable engines, like the Quad-J Firefly, the mains rotate. So what I do is toggle to Main, then set the engines manually to 90 degrees down. Bam! Instant hover control!

 

[C3PO]

There's a good reason why the Orbiter API uses a standard engine configuration.

An author has almost unlimited options using C++, so making an MFD for every possible engine/view angle combination will be a huge task.

This MFD is trying to control any standard configured craft during a hover approach/landing (and a few other tricks). Making it work smoothly for almost any mass/thrust combination and on any planetary body requires a lot of work.

If a specific addon uses some special engine configuration, it will most likely require a dedicated MFD for tasks like this.

 

[Mythos]

That depends on the vehicle. PROPER tailsitters are just craft that land/takeoff with the nose in the air. Thrust is along the z-axis, always. Have a look at Jason's old Rocketship Heinlein for a good example. RocketshipHeinlein V1.2

So far I always ignored addons with spacecraft3.dll so I won't have to install and learn that also. Is there a PROPER tail-sitter with a dll module? Or a 5 minute checklist where, how, what correct version etc. to install spacecraft3.dll?

Some, like the Lunar Descent Module in AMSO, use the hover engine as main thrust and have NO main engine at all. This is an easy way to keep the pilot-view horizontal, and not looking up at the sky when manuvering.

If there is only hover engine and it's y-aligned and landed is pitch and bank zero, this should already work with my MFD. My "Heli" mode will also allow gaining/reducing horizontal speed by pitch and bank control.

If you have a look at Computerex's Hover MFD : AutoHover

You can see how he cleverly set a Toggle that allows you to swap control between the ships hover engine and main, depending on what you need. No need to code for each-and-every ship addon available!

I've tested that (why does it react such slow?) and turned my DGIV into a tail-sitter. It did a good approach before it ended in the expected unusual way :lol:

I already planned hovering by main engine (my manual calls it "Rocket" mode) but more for the purpose of going to normal hover, then doing some pitch but still keep horizontal speed at zero. Maybe another mode for tail-sitters would be useful.
I've tested keeping pitch 90° months ago and found it hard to maintain bank and heading or even define what will be meant by bank and heading set.

For variable engines, like the Quad-J Firefly, the mains rotate. So what I do is toggle to Main, then set the engines manually to 90 degrees down. Bam! Instant hover control!

Sounds like something I know so far: ShuttleA's pod thrusters. The problem with that I will never solve: It's an independed thruster group and none of the standard handles gives it a usable name.
If I leave the pilot responsible for setting main engine into a proper angle to work as hover engine, it's sounds somewhat easier: Calculate anything as it would be for hover engine, but set the thrust level to main instead :hmm:

So here we have the special case of the special cases sounding easy but the more commonly used special case rather difficult. So it's hard to decide what's worth how much development time.

For the moment it's quite to warm in here to develop at all

 

[C3PO]

I've tested keeping pitch 90° months ago and found it hard to maintain bank and heading or even define what will be meant by bank and heading set.

When you're talking about propulsive landing, bank and yaw doesn't really make sense. From a coding point it would probably make more sense to define the angles of the engine thrust against the local vertical, and use some other plane for the "bank". You could choose to use the current horizontal speed direction, or the direction to your intended target.

When you get one of the angles close to 90°, the system will become more unstable. The only way I can think of around this is to rotate the whole reference 90° so the affected angle becomes close to zero. This will throw the initial definitions off, and be very confusing to use. I have no idea how to start coding such a beast.