TransX Accuracy of closest approach distance

Thierry Lys

New member
Joined
Feb 16, 2009
Messages
9
Reaction score
0
Points
0
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 ?
 

tblaxland

O-F Administrator
Administrator
Addon Developer
Webmaster
Joined
Jan 1, 2008
Messages
7,347
Reaction score
11
Points
113
Location
Sydney, Australia
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.
 

flytandem

Tutorial Publisher
Tutorial Publisher
Joined
Oct 19, 2007
Messages
501
Reaction score
4
Points
0
Location
San Bernardino
Website
www.flytandem.com
Make sure you have the [ame="http://www.orbithangar.com/searchid.php?ID=3039"]latest version of TransX[/ame], 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. :cheers:
 

tblaxland

O-F Administrator
Administrator
Addon Developer
Webmaster
Joined
Jan 1, 2008
Messages
7,347
Reaction score
11
Points
113
Location
Sydney, Australia

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
8
Points
0
Website
orbit.medphys.ucl.ac.uk
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).
 

agentgonzo

Grounded since '09
Addon Developer
Joined
Feb 8, 2008
Messages
1,659
Reaction score
4
Points
0
Location
Hampshire, UK
Website
orbiter.quorg.org
The author may correct me if I am wrong, but I believe that TransX works on a patched conic model...
Correct.

martins said:
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.

flytandem said:
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.
 

Thierry Lys

New member
Joined
Feb 16, 2009
Messages
9
Reaction score
0
Points
0
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 ?
 

agentgonzo

Grounded since '09
Addon Developer
Joined
Feb 8, 2008
Messages
1,659
Reaction score
4
Points
0
Location
Hampshire, UK
Website
orbiter.quorg.org
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.
 

Thierry Lys

New member
Joined
Feb 16, 2009
Messages
9
Reaction score
0
Points
0
Okay now it is clear for me. Thank you very much.
 
Last edited:

Andy44

owner: Oil Creek Astronautix
Addon Developer
Joined
Nov 22, 2007
Messages
7,625
Reaction score
4
Points
113
Location
In the Mid-Atlantic states
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.
 
Top