OHM Launch MFD - v. 1.6.6 for Orbiter 2016

[Enjo]

In the direct ascent program (in the latest version), the values of heading for northbound and southbound seem to have been reversed. Here is a screenshot:

Alright, I've checked it, and it's perfectly fine, however it may look. The DA mode's required azimuth just tells you where the program thinks you should be directing your nose in the current situation (relative position & velocity), to meet at the target in future. If you let the AP run, you'll see that it tries to reach these numbers, and that they can change quite drastically, depending on the situation (many details spared...)

 

[Castor]

Alright, I've checked it, and it's perfectly fine, however it may look. The DA mode's required azimuth just tells you where the program thinks you should be directing your nose in the current situation (relative position & velocity), to meet at the target in future. If you let the AP run, you'll see that it tries to reach these numbers, and that they can change quite drastically, depending on the situation (many details spared...)

But what I have noticed is that the autopilot does not correct itself.

In the same situation, the standard ascent screen shows me this:

If I switch over to the direct ascent program, the headings get subtracted from 180°, i.e., their supplementary angles are displayed. This does not change even after I launch :

But if I disable the correction by pressing the <COR> button, the heading corrects itself, but I am no longer in plane with the target later in the ascent:

 

[Enjo]

If I switch over to the direct ascent program, the headings get subtracted from 180°, i.e., their supplementary angles are displayed. This does not change even after I launch

They change once you get closer to the plane. You're too far at the beginning.

But if I disable the correction by pressing the <COR> button, the heading corrects itself, but I am no longer in plane with the target later in the ascent

You shouldn't disable the correction. It's an integral part of the DA mode.

Just launch soon enough and press AP. The AP is your friend. Trust the AP. :thumbup:

---------- Post added at 08:46 PM ---------- Previous post was at 07:22 PM ----------

BTW, before considering a launch, you must have enough DeltaT budget. Give it at least 300 seconds. Having a negative DeltaT means that it's already too late to launch.

 

[Enjo]

A new version for ADSWNJ's RV_Orientation:

v. 1.6.3 04-01-2015

- Integration with RV_Orientation: Exposing "TargetObjectIndex" variable through ModuleMessaging, so that the RV_Orientation may automatically get the target from Launch MFD.

Of course, now you have to wait for an update of RV_Orientation, before being able to use this mini-feature.

 

[Cras]

Oh my, a lovely feature indeed! Look forward to trying this out. Launch MFD and RV Orientation being two rock solid MFDs that should be included on ALL must-have lists.

 

[IronRain]

Launch MFD - v. 1.6.3 for Orbiter 2010

:hesaid:

 

[ADSWNJ]

Enjo is the man with these utilities. We've been discussing a method for general exchange of data between MFD's (so long as the MFD's are coded to handle it). I'm busy on a separate project at present (a mod of RV Orientation that is specific to maneuvering modules for space station building), but I'll add the support for Enjo's vessel-passing on a Tuesday sometime!

 

[Interceptor]

HI has anybody run in to some problems using direct accsent? it seems like in version 162 it worked perfectly,but in 163,it all ways starts climbing the rinc up after guidance converging,BTW this is when using the DG-S,I haven't tried out other ships yet.Thanks

 

[Cras]

I havent tried using the direct ascent program in a long long time, I will have a look when I can and see how it goes. I am not the best with that program so I am never sure that when it goes bad it is the MFD at fault, or pilot error. I always feel it is pilot error when I mess it up lol.

 

[Enjo]

I've just had time to try it out, to verify my statement, although I haven't changed anything in that section of code between the versions, and I can say that the program behaves exactly the same.

What you're describing is a symptom of having simply too small relative inclination just before the orbital insertion. This means that once you start the insertion, you might start flying over the plane, and the system destabilizes itself. You could theoretically try to get under the plane again, but that's not easy. Some Rinc "margin" is needed for the insertion sub program to succeed.

The cure is simple: don't launch too early (with DeltaT say > 3000), or the Rinc corrector will have simply too much time to decrease the Rinc and will lead to the described problem.

Let me know how it goes next time.

 

[Ripley]

Oops, better late than never, I just found out that whenever I launch Orbiter, Launch MFD always starts with the last page displayed (without exiting Launchpad).

 

[Enjo]

I realize this. It's because the MFDButtonPage class is a property of the Plugin class. If this really annoys you, then the remedy would be to always uncheck and re-check the Launch MFD module in the Launchpad, so that the Plugin gets reinitialized

 

[Ripley]

No, it doesn't annoy me at all, no problem.
It's just that I was surprised I didn't realize it before.

 

[Buck Rogers]

I have an issue; lunar surface launch, all presets retained (50km, 90°), Orb2010, inline, 2001 World of, Gagarin(launch from Tchalinko), Aries(Clavius).
Manual ignition followed by AP.
Nominal ascent til about halfway (alt 21km, ApA 31km), then sudden pitch up to 80° vertical! and proceeds to burn a Sol escape trajectory! Aries just seems to lose control! (I don't think it used to before?). Don't know if it's a bug or I'm doing something wrong! (probably the latter!).
Why are there two crosshairs(HUD)?
Appreciate advise

PS. Quote from Red Dwarf "Why he do that it look wrong"

PPS. After a few quick tests it seems to get better with higher target ApA, but even then the AP has large pitch errors? and the ascent profile is rather eccentric(inbetween the ApA was double over target), perfect circ. though(ApA 150km). Aries still loses control completely!
I get the impression the space ascent algorithm has changed and/or is incompatible with these vessels?

PPPS. Throttling back to 50% helps, pitch is still very wobbly, Aries still spins out of control half way up.
Tested an Earth launch with my SSTO(Kankoh), was satisfactory, does seem somehow more wobbly than before? Heinlein Earth launch: nominal ascent. BB launch stock DG, didn't work(50&150km),Rolling Stone lunar launch: no go.
Q. What do you use as a reference vessel?
IIRC this did smooth lunar ascents, or does it not work on the moon? confused!? Roll and initial pitch are still good.
Otherwise great, I use it on nearly every earth launch, at least as a reference, esp. XR2. Still having problems with DA though, I would like to use it as a manual guidance but couldn't get that to work, but that's another issue...
best regards

 

[Enjo]

I ran a quick test, and I conclude that the Aries' (same as DG's) engines are too powerful for a full throttle ascent with the assistance of PEG on the Moon. Whenever you see the crosshair wobbling, it means that PEG lost its convergence, and you need to throttle down smoothly, until the crosshair reappears in a correct position (like 30* higher), and continues its smooth descent. For an orbit of 50x50 km, I had to throttle down to 10%.
This is normal, because PEG assumes keeping engines on all the time until reaching orbit. There's no place for cutting them and circularizing later. This special requirement imposes limitations on the maximal power of engines, or you eject your craft from orbit, like you noticed. Keep in mind that there's a spectrum of engine power that guarantees convergence. You have to experimentally check what is the spectrum's range, by smoothly controlling the thrust.

The DA is quite similar in this regard, where the spectrum regards both PEG and synchronization phase, which in the latter case means a spectrum of allowed relative inclinations before the injection burn. Too small is also bad. We can get to it later.

PS. There are two crosshairs, because you might choose a northern or southern orbit with the same inclination. Once you setup a target, there's no choice anymore.

 

[jgrillo2002]

I ran a quick test, and I conclude that the Aries' (same as DG's) engines are too powerful for a full throttle ascent with the assistance of PEG on the Moon. Whenever you see the crosshair wobbling, it means that PEG lost its convergence, and you need to throttle down smoothly, until the crosshair reappears in a correct position (like 30* higher), and continues its smooth descent. For an orbit of 50x50 km, I had to throttle down to 10%.
This is normal, because PEG assumes keeping engines on all the time until reaching orbit. There's no place for cutting them and circularizing later. This special requirement imposes limitations on the maximal power of engines, or you eject your craft from orbit, like you noticed. Keep in mind that there's a spectrum of engine power that guarantees convergence. You have to experimentally check what is the spectrum's range, by smoothly controlling the thrust.

The DA is quite similar in this regard, where the spectrum regards both PEG and synchronization phase, which in this case means a spectrum or allowed relative inclinations before the injection burn. Too small is also bad. We can get to it later.

PS. There are two crosshairs, because you might choose a northern or southern orbit with the same inclination. Once you setup a target, there's no choice anymore.

That really explains why I always keep overshooting my target orbit altitude.

 

[Enjo]

Oh, that's nice to hear. I think I should start YouTubing my stuff.

 

[Buck Rogers]

Thanks for the (very) quick reply, and taking time to look into it.
The double crosshair with no target makes sense, should've figured.
I was thinking it must have something to do with Acc. but deemed the engines as not being so powerful and am therefore a little surprised. Throttling back does seem a little inefficient though. As said the ascent profile is good up to halfway and it's nice to have a smooth and automated roll man.. Previously I have always disengaged the AP and finished orbital insertion manually. I will experiment further and try to optimize the launch profile; disengage only pitch, or manual coast and reengage...
Thanks again for your help.

 

[Enjo]

Thanks for the (very) quick reply, and taking time to look into it.

No problem. I'm currently (and unusually) enjoying my free time.

I was thinking it must have something to do with Acc. but deemed the engines as not being so powerful and am therefore a little surprised..

The Moon has 9 times weaker gravity than Earth. Throttling down to ~10% seems to be confirming this number.

Throttling back does seem a little inefficient though.

Then try to run a test: Let the AP do its job until the end and note the remaining fuel, and then try to do it by yourself and compare.
[EDIT] But even if you prove your method better, I'll repeat that PEG has the special requirement of not cutting the main (booster) engines on the way to orbit, which AFAIK, is a realistic scenario. Try to meet the requirement manually
[EDIT2] and throttling down is just our idea to make the PEG converge. It should be started with 20% of power in the first place. Having to throttle down means reaching the upper limit of PEG's convergence, and trying to fix things.

 

[Ripley]

Hi Enjo.
What is the VC++ redist required version for LaunchMFD for Orbiter 2016?