Project Launch MFD development thread

[Enjo]

After Agentgonzo joined the party, there were lots of crispy changes in Launch MFD:

- Agentgonzo integrated his Launch Compass into Launch MFD:

- Launch MFD gets married with TransX
Agentgonzo also updated TransX so that it outputs inclination and LAN of a parking orbit. Having this info, I've changed LaunchMFD's target selection to this:

You can enter the target string as usual, but also a predefined inclination, and the inclination and LAN pair that TransX gives you, so that you can enter the parking orbit with minimal relative inclination. See below:

If you enter only the inclination, then nothing happens in particular, but if you enter inclination and LAN pair, then a reference vessel (Carina satellite) is created in orbit with the inc. and LAN that you supplied and is being targeted by the MFD. The reason behind it is that the MFD needs state vectors from that vessel to calculate Launch Window Time, and there's no other way that I know of for acquiring them. When you change your reference body and retarget inc. and LAN, then the Carina is transfered to that body. I chose Carina instead of eg. DeltaGlider because DG could mess up your docking HUD with his XPDR transmitter, which the Carina hasn't got.

Here's my SourceForge.net project page, including Orbitrader MFD code:

https://sourceforge.net/projects/enjomitchsorbit/

 

[Andy44]

This is looking good, Enjo.

Nice to see a set of essential Orbiter flight tools coming together in an integrated system.

 

[TSPenguin]

This is a great project!

A project that does exactly what I missed in my recent flights. Thank you all!

Hail Probe!

 

[C3PO]

How cool is that?:dance2:
Are we close to a release date?

If you enter only the inclination, then nothing happens in particular, but if you enter inclination and LAN pair, then a reference vessel (Carina satellite) is created in orbit with the inc. and LAN that you supplied and is being targeted by the MFD. The reason behind it is that the MFD needs state vectors from that vessel to calculate Launch Window Time, and there's no other way that I know of for acquiring them. When you change your reference body and retarget inc. and LAN, then the Carina is transfered to that body. I chose Carina instead of eg. DeltaGlider because DG could mess up your docking HUD with his XPDR transmitter, which the Carina hasn't got.

btw I made a dummy mesh a few years ago. It's just an invisible triangle, and it's probably the shortest msh file you're ever going to see.

DummyMSH.msh

MSHX1
GROUPS 1
LABEL Plane01
MATERIAL 1
TEXTURE 0
GEOM 3 1 ; Plane01
0.0176966 0.0 0.00884689 0.0 1.0 0.0
-0.00770341 0.0 0.00884689 0.0 1.0 0.0
-0.00770341 0.0 -0.0165531 0.0 1.0 0.0
1 0 2
MATERIALS 1
Mtl #1
MATERIAL Mtl #1
0.588 0.588 0.588 0.0
0.0 0.0 0.0 0.0
0.9 0.9 0.9 0.0 0.0
0.0 0.0 0.0 0.0
TEXTURES 0

 

[Enjo]

The release date is hard to define currently, because there's another thing that Agentgonzo is working on - integrating [ame="http://www.orbithangar.com/searchid.php?ID=2783"]PEG[/ame] into Launch MFD. It will not necessarily be an autopilot though. Anyway, if it takes him much more time then I'll release the MFD as it is. All that's left to do beside the PEG is: to finish code restructuring, writing docs, and maybe getting incl. and LAN directly from TransX instead of from user input.

Thanks for the mesh. So should I create a new vessel using this mesh and follow 3DModel.pdf from Orbiter SDK?

 

[C3PO]

:speakcool: I love the PEG. I hope there will be some readouts so that you can fly a manual ascent.

Thanks for the mesh. So should I create a new vessel using this mesh and follow 3DModel.pdf from Orbiter SDK?

I just copied Carina.cfg.

NavTarget.cfg:

; === Configuration file for vessel class NavTarget ===
ClassName = NavTarget
MeshName = NavTarget
Size = 5.0
Mass = 5000; empty mass [kg]
MaxFuel = 0  ; max fuel mass [kg]
Isp = 0        ; fuel specific impulse [m/s]
MaxMainThrust = 0
MaxRetroThrust = 0
MaxHoverThrust = 0
MaxAttitudeThrust = 5e2
COG_OverGround = 2.0
CameraOffset = -.715 .865 -2.5
CW = 10 10 5
LiftFactor = 0.0
CrossSections = 2.45 6.25 2.45

 

[Urwumpe]

:speakcool: I love the PEG. I hope there will be some readouts so that you can fly a manual ascent.

A flight director display would be cool.

 

[Enjo]

Thanks, C3PO. It works

As for display, I was thinking about something like in the attached image. Similar to Reentry MFD, but more visible and autoscaled in both pitch and yaw directions separately.

 

[C3PO]

Great! I love flight directors too

 

[agentgonzo]

Just some updates from me.

First off, credit must go to the boffins at NASA for developing the PEG algorithm and to kwan for coding it.

I managed to get PEG into LaunchMFD last night in the most minimalist way. I flew a few test flights and it worked to get me into a stable orbit, so that's good. There is still, however, a lot of work to do on it.

PEG is ridiculously complicated and I honestly have no idea how it works and don't intend to put the time in to understanding it (this is only the second time in my life I've accepted something I work with as working without understanding it myself!).


Once I've got those done, integration shouldn't be too hard. I'd wanted to get a flight director marker on the HUD (and also a compass for LaunchCompass functionality), but haven't been able to do this. I've got one more avenue to try (DirectX function hooking) which is not simple and may not work. If that doesn't work, then I'll have to leave it in the MFD.

Integration with TransX is on my todo list, but won't have the time to get it done in the immediate future as I have too many other commitments.

An autopilot feature probably won't be around in the near future (if at all). Looking at PEGAutopilot, kwan had a lot of trouble as crafts are configured so vastly differently so I'm hesitant to work on this.

 

[Enjo]

Who needs autopilots anyway. :beach:

 

[tblaxland]

I'd wanted to get a flight director marker on the HUD (and also a compass for LaunchCompass functionality), but haven't been able to do this. I've got one more avenue to try (DirectX function hooking) which is not simple and may not work. If that doesn't work, then I'll have to leave it in the MFD.

Perhaps this OrbiterWiki article helps?

 

[agentgonzo]

Perhaps this OrbiterWiki article helps?

Unfortunately not. The clbkDrawHUD callback is a virtual function in the VESSEL class that I can't get access to.

 

[computerex]

Hello. There are two ways for non-vessel modules to paint on the "HUD". They both cause what is being printed to flicker a little bit, but they work OK for things like flight directors.


#1 - opcOpenRenderViewport contains the handle of the orbiter window as a parameter. So you can simply cache the handle, and use the win32 GetDC call to get the handle to the device context.

#2 - Use the FindWindow win32 API call to get the handle to orbiter's window, and use GetDC to get the handle to the device context.

 

[agentgonzo]

Hello. There are two ways for non-vessel modules to paint on the "HUD".

I used the opcOpenRenderViewport function whilst trying this out, and as you said, I can draw to the HUD, but it flickers because it's not part of the render cycle and so sometimes will not get called in between the end of the render cycle (flip, or however orbiter does it) and when the screen next gets refreshed at the vertical sync. I felt that this was not good enough to implement as a HUD because the flicker was very annoying.

 

[computerex]

I used the opcOpenRenderViewport function whilst trying this out, and as you said, I can draw to the HUD, but it flickers because it's not part of the render cycle and so sometimes will not get called in between the end of the render cycle (flip, or however orbiter does it) and when the screen next gets refreshed at the vertical sync. I felt that this was not good enough to implement as a HUD because the flicker was very annoying.

The flickering is annoying if you are painting text, but if you are painting graphics with the appropriate pens, it works OK. AutoFCS uses this method, no one seems to have noticed the flickering in it's HUD.

 

[agentgonzo]

The flickering is annoying if you are painting text, but if you are painting graphics with the appropriate pens, it works OK. AutoFCS uses this method, no one seems to have noticed the flickering in it's HUD.

Ah, in which case, I may give it a go. Cheers computerex. I did a quick test a few weeks ago and noticed flickering. If I find that it's still flickering, I can always try the API hook method I've been thinking of. The drawing functions will be the same anyway, so no effort lost.

When you say appropriate pens, which ones do you mean? I'm just drawing with standard pens returned from the CreatePen call (or whatever it is).

 

[computerex]

When you say appropriate pens, which ones do you mean? I'm just drawing with standard pens returned from the CreatePen call (or whatever it is).

Well by "appropriate" pens I meant any pen that is not default. :sorry:

 

[C3PO]

Who needs autopilots anyway. :beach:

I actually like scripted APs. (not the ones where you just press "play") I like to (try to) optimize the ascent profile manually. A scripted AP allows you to make small adjustments without loosing it all in a sloppy liftoff. The script can make two liftoff identical.

The real Shuttles don't use closed loop AP for the first part of the ascent. I think the PEG doesn't take control until after SRB Sep.

 

[Enjo]

Seriously speaking, I was thinking about using Face's PID MFD, and Computerex' PID Adjustment MFD (sorry, but I don't remember the full name). If I could only link you to the m6 thread...

The idea is that since all vessels have different parameters, and as Agentgonzo pointed, are configured differently, the PID loop adjustment could be performed before the launch and the parameters of the loop would be saved in a file, similarly like the Aerobrake MFD stores the vessels' Lift/Drag data. The files could be generated by me, or anybody who's willing, after countless launches with different craft, and saved in one big pack, then distributed, so that you don't need to adjust the loops parameters every time.

The PID algorithm could work independently of PEG. The PEG would only pass its data to PID.

At least this is how I understand it. Feel free to correct me if I'm wrong.


[EDIT]
C3PO: Is it that the fundamental difference between scripted and and closed loop AP is that the scripted one sets some pitch at some altitude, and that closed loop is actually the "Play" AP ?


Agentgonzo: I will reply to your e-mail soon, or tomorrow morning. I need to do some stuff here first