Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > MFD Questions & Help
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

MFD Questions & Help Post your questions here for help with the Multi-Function Displays.

Reply
 
Thread Tools
Old 05-19-2009, 11:22 PM   #1
Thierry Lys
Orbinaut
 
Thierry Lys's Avatar
Default Accuracy of closest approach distance

I want to know how accurate is the distance of the closest approach shown by this MFD while you are setting a stage or planning a manoeuvre while you are in a stage centred on major body. Futhermore I have seen that after all have been set, and before the burn, this distance is oscillating with regularity when you are accelerating the time and increasing in general. As I stop to accelerate time, the distance has changed, so it isnít just due to the time acceleration. Perhaps as we are moving, gravity attractions are responsible of that changes but it could also has no physical signification. Therefore how is it precise and what are the reasons of those oscillations ?
Thierry Lys is offline   Reply With Quote
Old 05-20-2009, 12:27 AM   #2
Linguofreak
Orbinaut
Default

Which MFD is "this MFD"?
Linguofreak is offline   Reply With Quote
Old 05-20-2009, 12:49 AM   #3
Hielor
Defender of Truth

Default

Quote:
Originally Posted by Linguofreak View Post
 Which MFD is "this MFD"?
TransX. The thread is tagged with it.
Hielor is offline   Reply With Quote
Old 05-20-2009, 01:29 AM   #4
tblaxland
Webmaster
 
tblaxland's Avatar


Default

I can't give you an absolute answer but I can give you some background...

The author may correct me if I am wrong, but I believe that TransX works on a patched conic model which is an approximation to the numerical integration of the flight path that Orbiter does, so inaccuracies will inevitably result. The reason for the approximation is to keep the calculation times reasonable - you can imagine how long you would have to wait for a result if the MFD had to do a full numerical integration all the way to your destination with the same accuracy as Orbiter does, and then consider that it would need to do so every time you change a variable. IMFD's Map program does a numerical integration but it still suffers from similar (although smaller) inaccuracies for the same reason - sacrificing accuracy for calculation time.
tblaxland is offline   Reply With Quote
Old 05-20-2009, 01:31 AM   #5
flytandem
Tutorial Publisher
 
flytandem's Avatar
Default

Make sure you have the
latest version of TransX
, the wobble wrt Earth is far less than previous versions.

Even so there is a fair amount of both wobble and drift. As you get better you can start to actually get a feel for the changes in cl.app. Some of the worst offenders are going from moon to moon in the Jupiter system. Saturn is a close second. Earth has a bit of binary wobble still but not very much. Venus behaves fairly well. As do Uranus and Neptune and their moons.

Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App. Then again, if there was perfect accuracy in the maneuver, it would take a lot of the fun and challenge out of it.

The good thing is that if you are at the point where the inaccuracies in Cl App are becoming a game of chase then it means you are getting pretty good at TransX. And that in itself deserves a nice high five.
flytandem is offline   Reply With Quote
Old 05-20-2009, 03:47 AM   #6
Zatnikitelman
Addon Developer
 
Zatnikitelman's Avatar
Default

Hmm, sounds like some sort of application for the new format of Orbiter!
Zatnikitelman is offline   Reply With Quote
Old 05-20-2009, 04:23 AM   #7
tblaxland
Webmaster
 
tblaxland's Avatar


Default

Quote:
Originally Posted by flytandem View Post
 Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.
I thought I had seen that suggestion somewhere before... over one year ago actually
http://www.orbiter-forum.com/showthr...3569#post13569
tblaxland is offline   Reply With Quote
Old 05-20-2009, 06:37 AM   #8
martins
Orbiter Founder
Default

Quote:
Originally Posted by flytandem View Post
 Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.
I had been thinking about this possibility as well, but there are disadvantages to this approach. In the inverse problems community, this would qualify as an "inverse crime": you use the same model to generate data and analyse them. It enforces self-consistency, even if orbiter's model was completely wrong. In other words, if TransX or IMFD used orbiter's model, then the fact that they work correctly would not tell anything about how good orbiter's physics actually is. Whereas an independently developed model provides more feedback about the relative validity of the two models. If they work together, then there is a good chance that the adhere to a common standard (ideally, reality).
martins is offline   Reply With Quote
Old 05-20-2009, 07:54 AM   #9
agentgonzo
Grounded since '09
 
agentgonzo's Avatar
Default

Quote:
Originally Posted by tblaxland View Post
 The author may correct me if I am wrong, but I believe that TransX works on a patched conic model...
Correct.

Quote:
Originally Posted by martins
 Stuff about self consistency
You're right about independent verification of the Orbiter physics model. However, from a user's POV when using TransX/IMFD, and entirely self-consistent model would be idea as the planned trajectory would match the future trajectory exactly. Though this would take some of the challenge out of it and remove the need for MCCs that make the flight more enjoyable.

Quote:
Originally Posted by flytandem
 Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.
It would be cool, though it would make a change to the way that the MFD worked (especially on long trips to the outer solar system). I'm not sure how fast this could work and whether it would be limited by the time accel of the orbiter-core thread doing the numerical propagation. It would take some time for the Cl App to update following a change of burn parameters.

I also don't have the time to re-write the core engine of TransX away from the patched-conics method either, so if you want this to be done, someone else will have to take the plunge . I'm away from a computer for the whole of 2010 and don't have time to do it this year.
agentgonzo is offline   Reply With Quote
Old 05-20-2009, 09:43 AM   #10
Thierry Lys
Orbinaut
 
Thierry Lys's Avatar
Default

Thank you very much for the pertinence and the level of your answers. I know that this precision of the closest approache distance is one of the challenge of TransX because we always want to make flights as perfect as possible and with a minimum of course corrections. It takes part in the fun of Orbiter. However, because the numbers evolve with our position in space, variations could have been the consequence of the evolution of forces operating on the vessel as these variations didn’t seem totally unpredictable. Futhermore as with set a correction for a precise time that TransX has memorized and because we don’t change anything until the burn staying on the same orbit, the cloasest approach distance as no reason to change unless there are external factors. If the vessel is evolving in space, its speed and position at the time set for the burn stay the same and are memorized by the MFD. Therefore why the number is changing ?
Thierry Lys is offline   Reply With Quote
Old 05-20-2009, 11:04 AM   #11
agentgonzo
Grounded since '09
 
agentgonzo's Avatar
Default

Quote:
Originally Posted by Thierry Lys View Post
 Thank you very much for the pertinence and the level of your answers. I know that this precision of the closest approache distance is one of the challenge of TransX because we always want to make flights as perfect as possible and with a minimum of course corrections. It takes part in the fun of Orbiter. However, because the numbers evolve with our position in space, variations could have been the consequence of the evolution of forces operating on the vessel as these variations didnít seem totally unpredictable. Futhermore as with set a correction for a precise time that TransX has memorized and because we donít change anything until the burn staying on the same orbit, the cloasest approach distance as no reason to change unless there are external factors. If the vessel is evolving in space, its speed and position at the time set for the burn stay the same and are memorized by the MFD. Therefore why the number is changing ?
TransX will remember the burn time (in MJD) and the burn direction and Delta-V. The position that the vessel is in at this burn time is not remembered and is calculated each time the MFD is updated from the current position and velocity. The same applies to all minor bodies in the current system. Therefore as the simulation progresses, the expected position of minor bodies in the system and the vessel change from the inital prediction.
agentgonzo is offline   Reply With Quote
Old 05-20-2009, 12:25 PM   #12
tblaxland
Webmaster
 
tblaxland's Avatar


Default

This is how I visualise what agentgonzo put in words (see attachment).
Attached Thumbnails
TransXManoeuvre.png  
tblaxland is offline   Reply With Quote
Old 05-20-2009, 12:27 PM   #13
Thierry Lys
Orbinaut
 
Thierry Lys's Avatar
Default

Okay now it is clear for me. Thank you very much.

Last edited by Thierry Lys; 05-20-2009 at 07:47 PM.
Thierry Lys is offline   Reply With Quote
Old 05-21-2009, 02:44 AM   #14
Andy44
owner: Oil Creek Astronautix
 
Andy44's Avatar
Default

Quote:
Originally Posted by martins View Post
 I had been thinking about this possibility as well, but there are disadvantages to this approach. In the inverse problems community, this would qualify as an "inverse crime": you use the same model to generate data and analyse them. It enforces self-consistency, even if orbiter's model was completely wrong. In other words, if TransX or IMFD used orbiter's model, then the fact that they work correctly would not tell anything about how good orbiter's physics actually is. Whereas an independently developed model provides more feedback about the relative validity of the two models. If they work together, then there is a good chance that the adhere to a common standard (ideally, reality).
I agree. But I also think that TransX (or whatever new tool is used) could use a nicer model. Some sort of numerical model, just not the same one used by Orbiter itself, which is supposed to represent "real life".

In real life mission planners use models which are very high speed, and of course the actual mission is flown using the actual physics of creation. Since the models are pretty good, the missions are amazingly precise. TransX is good, but it doesn't allow us to recreate the precision real life mission planners can demonstrate.
Andy44 is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > MFD Questions & Help


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 02:13 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright ©2007 - 2017, Orbiter-Forum.com. All rights reserved.