New Release LunarTransferMFD v1.1 released

[jarmonik]

Hello,

I have released the first official release of LunarTransferMFD. It is allready pretty well beta tested but let's hope that everyting is working well. There is a Manual and a LunarTransfer Tutorial distributed with in the LTMFD package.

LunarTransferMFD is mostly designed to be used with Apollo but can be used with most lunar missions. There is still much that need to be done to improve trajectory profiles and optimize the code to run faster. LTMFD is pretty heavy, since, it's using Broyden's method with numerical forward trajectory model to find desired transfer trajectory.

If there are any problems or bugs just report them here.

http://koti.mbnet.fi/jarmonik/Orbiter.html


Jarmo

 

[garyw]

Nice! I'm doing a moon run in Orbiter this weekend and will try it out.

 

[the.punk]

Cool.
Thank you.

 

[flying coffin]

I wonder if this will be useful for LRO? I'll try it out as soon as I get home from work tonight.

Edit:
This is Faaaantastic! I just put the whole LRO stack into a lunar polar orbit insertion over the north pole, ending up with an Ecc. of 0.6

I did the targeting during TLI, then a correction at 20-30M alt. above earth, and no further corrections needed!

You have just made my life sooooo much easier!

ThankyouThankyouThankyouThankyouThankyou!

 

[flying coffin]

OK I have questions.

In the tutorial it says launch the dg at t-100 seconds. I assume that for a vertically launched vehicle, launch would be at T-0, correct?

The next question is about the PeT values.

The scenario is this... will provide scenario file at end of post:

on ksc launch pad at June 17 2009 at 16:40:00 UTC, MJD 54999.694444

This is about 15 minutes before I would expect to launch, as align planes shows
RInc to the moon at 2.92 degrees and slowly decreasing.
IMFD5.3 course, target moon shows a PeT of about 425k, MJD 55004.625

This is about what I would expect, as it is a little less than 5 days, and the published
transit times for LRO were all within 4 or 5 days.

When I fire up LTMFD, TLI Program, Surface Launch mode, it picks a default PeT of
55002.7957 or a little over 3 days. When I set Pet to 55004.625 in LTMFD,

It actually sets it to 55004.1959. In addition, the Hed shows 114.58 which is not the 90 degrees I would expect. If I decrease Pet further to 55003.9105 the heading is back at 90 degrees, but things still seem to proceed downhill from there.

What am I doing wrong here?

Thank you very much!

-Chris

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 54999.6994889814
END_ENVIRONMENT

BEGIN_FOCUS
  Ship DG01
END_FOCUS

BEGIN_CAMERA
  TARGET DG01
  MODE Cockpit
  FOV 40.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
  TYPE User
  MODE Interplanetary
  Scenario Old2
  MapMFD V5
  Reference Auto
  Target none
  Center GravityRef
  Data 0 1 1e-006 1 0 0 0 0 1 0 0 0
  MassLimit 1e+020
  CMode 0
  Config 1 1 1 1 0 0
  ExtMode 0
  Periapis none
  END 
  CorMFD V4
  Reference Earth
  Target Moon
  Source DG01
  ActiveProg 1 1
  DataA 0 3 0 0 0 0
  DataB 1 1 54999.71652461661 0 0 1.543309370760595 0 55004.62933320629 0
  DVProg 0 0 0 1
  AdvConf 0 0 1 0 0
  Guidance 0
  END 
  EjectMFD V5
  Reference Auto
  Data 0 1 3 0 1 54999.6994889814 10
  Guidance 0
  END 
  BaseAprMFD V2
  Reference Auto
  Target none
  Source none
  DataA 0 0 120000 0.10821 0.366519 1 1 54999.6994889814 54999.6994889814 0
  DataB 0 3 0 1 0 1
  END 
  SlingMFD V4
  Reference Auto
  Source none
  Data 0 1 1 3 0 1 54999.6994889814 0
  END 
  LaunchMFD V4
  Target None
  Data 0 1 1 3 0 1 0
  END 
  CF1_DataA 1 0
  CF1_DataB 54999.6994889814 10 120000 2 20 150000
  CF1_SecTgt 
  mfdShare -1
  mfdProgram 2
END_MFD

BEGIN_MFD Right
  TYPE User
  MODE LunarTransferMFD
  DataA1 2 2 1 0 0 0 -1 0
  DataB1 2088000 55003.95972222209 4.712388980384685 0 0 -1.569050997542901
  DataB2 55002.84844347214 54999.76577711722 54999.6979074189 0 120000
END_MFD


BEGIN_SHIPS
DG01:Deltaglider
  STATUS Landed Earth
  POS -80.5858324 28.5767768
  HEADING 99.96
  PRPLEVEL 0:1.000 1:1.000
  NAVFREQ 0 0 0 0
  XPDR 0
END
END_SHIPS

BEGIN_Attachment Manager
END

 

[jarmonik]

What am I doing wrong here?

Nothing actually. There is something wrong in LTMFD.

In the tutorial it says launch the dg at t-100 seconds. I assume that for a vertically launched vehicle, launch would be at T-0, correct?

Yes, I suppose. I haven't computed any numbers because it really isn't critical issue.

 

[NukeET]

CTD on a clean install

I'm getting CTDs on a clean install of Orbiter 060929 (patch applied) on all 3 scenarios supplied with LTMFD.

Since no one else is reporting any issues, my guess is that I'm overlooking something simple.

Contents of Orbiter.log:

**** Orbiter.log
Build Sep 29 2006 [v.060929]
Found 0 joystick(s)
Module AtlantisConfig.dll [API v.060425]
Module DGConfig.dll [API v.060425]
Module ScnEditor.dll [API v.060425]
Module Rcontrol.dll [API v.050206]
Module Meshdebug.dll [API v.060425]
Module Framerate.dll [API v.050206]
Module FlightData.dll [API v.050206]
Module ExtMFD.dll [API v.060425]
Module CustomMFD.dll [API v.060425]
Module LunarTransferMFD.dll [API v.060425]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Zbuffer: 32 bit
Stencil buffer: 8 bit
Render device: Fullscreen 1024 x 768
Device has no hardware T&L capability
Module Sun.dll [API v.050206]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll [API v.050206]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll [API v.050206]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll [API v.050206]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll [API v.041022]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll [API v.060425]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll [API v.060425]
Module Deimos.dll [API v.060425]
Module Galsat.dll [API v.041022]
Module Jupiter.dll [API v.050206]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll [API v.041022]
Module Europa.dll [API v.041022]
Module Ganymede.dll [API v.041022]
Module Callisto.dll [API v.041022]
Module Satsat.dll [API v.050206]
Module Saturn.dll [API v.060425]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll [API v.050206]
SATSAT Mimas: Terms 113
Module Enceladus.dll [API v.050206]
SATSAT Enceladus: Terms 33
Module Tethys.dll [API v.050206]
SATSAT Tethys: Terms 101
Module Dione.dll [API v.050206]
SATSAT Dione: Terms 59
Module Rhea.dll [API v.050206]
SATSAT Rhea: Terms 68
Module Titan.dll [API v.050206]
SATSAT Titan: Terms 100
Module Hyperion.dll [API v.050206]
SATSAT Hyperion: Terms 595
Module Iapetus.dll [API v.050206]
SATSAT Iapetus: Terms 605
Module Uranus.dll [API v.050206]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll [API v.060425]
Module Ariel.dll [API v.060425]
Module Umbriel.dll [API v.060425]
Module Titania.dll [API v.060425]
Module Oberon.dll [API v.060425]
Module Neptune.dll [API v.050206]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Module Triton.dll [API v.060425]
Finished initialising world
Module DeltaGlider.dll [API v.060425]
Finished initialising status
Finished initialising camera

In addition, there is a "IFP-SDK_Err.html" file generated with the same date/time stamp.

IFP-SDK Error Log

Contents of this file is deleted during Orbiter shutdown if orbiter shutdown option
Extra->Debugging options->Orbiter shutdown options: is set to Respawn

Celestial Mechanics Toolkit, Date of Build: May 15 2009

(Mon May 18 09:37:53 2009) *** Module attached in new process (3372) ThreadId=2920 ***
(Mon May 18 09:37:53 2009) Toolkit Date of Build May 15 2009
(Mon May 18 09:37:53 2009) -- InitModule called --
(Mon May 18 09:37:53 2009) LTMFD Date of build May 15 2009
(Mon May 18 09:37:53 2009) LTMFD: IMFD_COM_IPC_100 created, Size = 784
(Mon May 18 09:37:53 2009) LTMFD: IMFD_COM_AREA created, Size = 24
(Mon May 18 09:37:53 2009) InitModule Ready
(Mon May 18 09:38:16 2009) *** Module attached in new thread (3916) ***
(Mon May 18 09:38:18 2009) --FocusChanged called--
(Mon May 18 09:38:18 2009) -- MsgProc called, Thread (2920) --
(Mon May 18 09:38:18 2009) OAPI_MSG_MFD_OPENED
(Mon May 18 09:38:18 2009) Binding new MFD into a ShellMFD. Id = 0
(Mon May 18 09:38:18 2009) Size of LunarTransferMFD class 1576 bytes
(Mon May 18 09:38:21 2009) *** Module attached in new thread (756) ***
(Mon May 18 09:38:21 2009) *** Module detached from thread. (1) Remains in threads ***

 

[jarmonik]

Since no one else is reporting any issues, my guess is that I'm overlooking something simple.

What ever it is, it's not simpple. I have been trying to track down this issue ever since the very first alpha was released. This is second report of CTD in LTMFD. I suppose this issue is somehow related in memory allocation.

Current LTMFD is statically linked and it's possible that the runtime library is not fully compatible with your computer. But that's just a theory.

Here is dynamic version of LTMFD, if you could give it a try.

http://koti.mbnet.fi/jarmonik/DLTest.zip

It will replace two DLLs (LunarTransferMFD.dll and CSystem.dll) with new ones using dynamic linking. Also SSE2 instructions are disabled.

Could you give some system specs like OS, CPU and how much memory is there ?

------------------------------------------------------------------

The CTD will occur after calling 'new' operator in order to allocate new MFD class.

MFD *mfd = new LunarTransferMFD(LOWORD(wparam), HIWORD(wparam), (VESSEL*)lparam)

But the CTD will occur before the LunarTransferMFD constructor is called.

---------- Post added at 01:29 AM ---------- Previous post was Yesterday at 09:04 PM ----------

This is about what I would expect, as it is a little less than 5 days, and the published transit times for LRO were all within 4 or 5 days.

This is somewhat problematic. Due to long transfer time this will lead nearly 180 degrees transfer solution and that will lead in very high inclination transfer. LTMFD can't deal with this kind of cases very easily. This would require a bi-elliptic transfer solution or at least different kind of search algorithm. Both of these are something that won't be implemented anytime soon.

I suppose the best bet would be using Target intercept program form IMFD in "source plane" opmode to compute initial TLI burn. LTMFD can handle the course corrections later on.

However, if you want to execute the TLI burn with LTMFD. While being in earth orbit, PeT must be selected so that EIn is zero. Also you need to increase TIg by 1-3 minutes in manual mode. This will become easier to do if you enable "Auto EXE" from configuration menu.

---------- Post added at 01:36 AM ---------- Previous post was at 01:29 AM ----------

When I fire up LTMFD, TLI Program, Surface Launch mode, it picks a default PeT of
55002.7957 or a little over 3 days. When I set Pet to 55004.625 in LTMFD,

It actually sets it to 55004.1959. In addition, the Hed shows 114.58 which is not the 90 degrees I would expect. If I decrease Pet further to 55003.9105 the heading is back at 90 degrees, but things still seem to proceed downhill from there.

Both of these issues are fixed but I'll try to fix few other things before uploading new version.

 

[tblaxland]

The CTD will occur after calling 'new' operator in order to allocate new MFD class.

MFD *mfd = new LunarTransferMFD(LOWORD(wparam), HIWORD(wparam), (VESSEL*)lparam)

But the CTD will occur before the LunarTransferMFD constructor is called.

I'm surprised you don't at least get a compiler warning on that without an explicit cast. Besides that, does the new operator return a valid value at all (can you tell with the debugger)? If it does, do you have anything else in the LunarTransferMFD initaliser list besides the base class constructor?

 

[Graham2001]

------------------------------------------------------------------

The CTD will occur after calling 'new' operator in order to allocate new MFD class.

MFD *mfd = new LunarTransferMFD(LOWORD(wparam), HIWORD(wparam), (VESSEL*)lparam)

But the CTD will occur before the LunarTransferMFD constructor is called.

---------- Post added at 01:29 AM ---------- Previous post was Yesterday at 09:04 PM ----------

Glad to find out that I'm not alone. Still have not had a chance to try out the dynamic linking version, yet. I'll post my report to this thread when I have done so.

If it is any help I am running Orbiter on a machine of the following configuration.

OS: Windows XP(SP3)
RAM: 2gb
CPU: AMD Athlon XP 2800

 

[NukeET]

What ever it is, it's not simpple. I have been trying to track down this issue ever since the very first alpha was released. This is second report of CTD in LTMFD. I suppose this issue is somehow related in memory allocation.

Current LTMFD is statically linked and it's possible that the runtime library is not fully compatible with your computer. But that's just a theory.

Here is dynamic version of LTMFD, if you could give it a try.

http://koti.mbnet.fi/jarmonik/DLTest.zip

It will replace two DLLs (LunarTransferMFD.dll and CSystem.dll) with new ones using dynamic linking. Also SSE2 instructions are disabled.

Could you give some system specs like OS, CPU and how much memory is there ?

The dynamic version stopped the CTDs, but now I get a message in the MFD window stating, "Earth or Moon is missing from CSol"...and it doesn't matter which of the 3 scenarios I try.

System specs: Windows XP SP2, 2400+ AMD Athlon XP processor, 1GB RAM.

Edit...

I experimented more with the settings on the Extra tab (launchpad). If "Extra\Debugging options\Orbiter shutdown options" is set to "Terminate Orbiter process", all 3 scenarios work well enough to start playing with them.

If I set the same to "De-allocate memory and display launchpad dialog", I get the "Earth or Moon is missing..." message as stated above.

 

[jarmonik]

I'm surprised you don't at least get a compiler warning on that without an explicit cast. Besides that, does the new operator return a valid value at all (can you tell with the debugger)? If it does, do you have anything else in the LunarTransferMFD initaliser list besides the base class constructor?

Sorry, I cleaned up the code a bit to prevent confusion but I just did the opposite.

Since, the Orbiter will always delete a MFD when switching between panels. So, I made a ShellMFD implementation, as you may already guess, it's a shell for a TrueMFD and only the shell gets deleted when switching a panel. It will also provide a vessel specific instance of the TrueMFD. When a TrueMFD is binded into a shell, the shell will just reroute all calls for the TrueMFD. I suppose I could include the code of ShellMFD in distribution, it's pretty small and handy.

Actual code was:

#define TRUE_MFD LunarTransferMFD

LogMsg(ErrorLog,"Size of LunarTransferMFD class %d bytes",(int)sizeof(TRUE_MFD));

TRUE_MFD *TrMFD = new TRUE_MFD(LOWORD(wparam), HIWORD(wparam), (VESSEL*)lparam);

LogMsg(ErrorLog,"Number of bytes allocated %d", (int)_msize((void *)TrMFD));

---------- Post added at 01:17 PM ---------- Previous post was at 01:08 PM ----------

The dynamic version stopped the CTDs...
System specs: Windows XP SP2, 2400+ AMD Athlon XP processor, 1GB RAM.

Thanks for testing it. It looks like a static build of LTMFD is failing with Athlon XP. But why does the IMFD work or does it ? It's builded in same way.

..but now I get a message in the MFD window stating, "Earth or Moon is missing from CSol"...and it doesn't matter which of the 3 scenarios I try.

That's most likely a memory de-allocation problem. I should be able to reproduce the problem and fix it.

---------- Post added at 01:31 PM ---------- Previous post was at 01:17 PM ----------

Besides that, does the new operator return a valid value at all (can you tell with the debugger)?

I can't reproduce this issue in my computer, therefore it always returns a valid value. In some computer the CTD will occur before the 'new' operator returns, therefore I can't write it into a log either.

If it does, do you have anything else in the LunarTransferMFD initaliser list besides the base class constructor?

No, it's just the LunarTranferMFD class, there is no base class either. However, the MFD class is a base class for ShellMFD.

 

[tblaxland]

Since, the Orbiter will always delete a MFD when switching between panels. So, I made a ShellMFD implementation, as you may already guess, it's a shell for a TrueMFD and only the shell gets deleted when switching a panel. It will also provide a vessel specific instance of the TrueMFD. When a TrueMFD is binded into a shell, the shell will just reroute all calls for the TrueMFD. I suppose I could include the code of ShellMFD in distribution, it's pretty small and handy.

I have done something similar for StateVector MFD and now also for the new version of Attitude MFD I am working on. The "TrueMFD" (I use a different naming schema) still gets calls via opcPostStep so that it can continue to maintain attitude.

Thanks for testing it. It looks like a static build of LTMFD is failing with Athlon XP. But why does the IMFD work or does it ? It's builded in same way.

I have an Athlon 64 so I'll give it a go when I get a chance. I also use IMFD successfully (5.1g ATM, but I'll also try 5.3).

I can't reproduce this issue in my computer, therefore it always returns a valid value. In some computer the CTD will occur before the 'new' operator returns, therefore I can't write it into a log either.

No, it's just the LunarTranferMFD class, there is no base class either. However, the MFD class is a base class for ShellMFD.

Makes sense based on your above description.

---------- Post added at 22:05 ---------- Previous post was at 21:11 ----------

I have an Athlon 64 so I'll give it a go when I get a chance. I also use IMFD successfully (5.1g ATM, but I'll also try 5.3).

Tried both LTMFD (statically linked version) and IMFD 5.3. Did a TLI burn no problems.

 

[jarmonik]

It looks like the Athlon XP doesn't have SSE2 instruction set, however Athlon 64 do have. I may need to create two versions of LTMFD since SSE2 will improve execution speed by 40% It would be good idea to use it when it's available.

When I have fixed the issue with memory deallocation I will upload new version for testing. (Static linking, SSE2 disabled)

 

[NukeET]

Thanks for testing it. It looks like a static build of LTMFD is failing with Athlon XP. But why does the IMFD work or does it ? It's builded in same way.

I have used IMFD versions 4.2.1 through 5.3 with the same processor and never had any problems with them (aside from the stiff learning curve). I felt honored you asked me to test...you've always produced excellent add-ons. Bugs are bound to happen...it is code after all. If you need further help with testing, please let me know.

 

[jarmonik]

I have used IMFD versions 4.2.1 through 5.3 with the same processor and never had any problems with them

The problem seems to be in SSE2 instructions. IMFD is not using them so no problem there.

Here's a new module pack http://koti.mbnet.fi/jarmonik/SSE2Test.zip

It will replace the modules with a static build with no SSE2 instructions. If it works then we can be 100% sure that SSE2 was the source of the problem. Also the memory deallocation issue should be fixed.

 

[flying coffin]

I just checked out the latest version. All of the LRO issues seem to be solved.
I just did a TLI for the minmum energy type transfer, and a TLCC at
32M Alt. The burn times were great, I've got plenty of dV budget left,
and IMFD map shows a great trajectory!

I have an Intel CPU, so I can't help check out the strange instruction issues.

From my perspective so far, it works GREAT!

Edit:

I passed over the North pole. For TLI and TLCC I had Lat. set at 89.9 S (entered -89.9) Frm: Moon Equ. I'll try 89.9 N and see if I go over the South pole.

for LOI It said not enough thrust in engines, but I half expected that, since it takes LRO 3 burns to get into a circular orbit. The first burn is just to get
captured in a stable orbit. I can use IMFD for the LOI burns, so that's not an issue for me.

-Chris

 

[NukeET]

The problem seems to be in SSE2 instructions. IMFD is not using them so no problem there.

Here's a new module pack http://koti.mbnet.fi/jarmonik/SSE2Test.zip

It will replace the modules with a static build with no SSE2 instructions. If it works then we can be 100% sure that SSE2 was the source of the problem. Also the memory deallocation issue should be fixed.

SSE2Test.zip works very well. I'm astounded at the accuracy of LTMFD! :speakcool:

I had one CTD, but I'm unable to recreate the conditions after a dozen tries.

 

[jarmonik]

I passed over the North pole. For TLI and TLCC I had Lat. set at 89.9 S (entered -89.9) Frm: Moon Equ. I'll try 89.9 N and see if I go over the South pole.

Why not just use 'Heading' mode with flight heading of 0 degrees if you want to approach from south pole into polar orbit.

for LOI It said not enough thrust in engines, but I half expected that, since it takes LRO 3 burns to get into a circular orbit. The first burn is just to get captured in a stable orbit. I can use IMFD for the LOI burns, so that's not an issue for me.

It should be possible to use LOI program to insert in high eccentricity orbit by defining orbit eccentricity or apoapis altitude.

 

[flying coffin]

Why not just use 'Heading' mode with flight heading of 0 degrees if you want to approach from south pole into polar orbit.

I will try that. I'll have to re-read the docs to see how heading mode works.

It should be possible to use LOI program to insert in high eccentricity orbit by defining orbit eccentricity or apoapis altitude.

I tried 0.6, 0.8, and 0.9 Ecc values, with no luck. Here are the specs for LRO:

• Empty Mass 809kg
• Fuel Mass 897kg, ISP 2100Ns/kg
• Main Engine 352N
• RCS 20N

The first LOI burn, just to get captured takes about 2k seconds.

Edit:

Now I see in the docs that burn time is limited to 1k seconds or less. That's why it doesn't work. We'll keep using IMFD for LOI.

---------- Post added at 08:45 PM ---------- Previous post was at 06:13 PM ----------

Heading mode worked like a champ! Woo Hoo!

Ding Dong the witch is dead, the mean old (IMFD TLI offset) witch is DEAD!

Thank you very much for your guidance and patience!