API Question clbkEphemeris vs TransX elements method

[Benom8]

Some background:
I'm thinking of writing a general-purpose state-propagation MFD as a more hands-on backup to IMFD or TransX. These are great MFDs but I feel the former can be a bit temperamental and the latter could be more flexible. It might be nice to be able to input a few burn parameters for an arbitrary number of burns and see where you are likely to end up.

The problem:
I need to estimate future state vectors for gravitational bodies. After looking at the SDK and a few old threads here I can see three options:

1) Using clbkEphemeris:
Pros: -A single function to call and accurate.
Cons: -It's probably slow.
-It's a callback (I think it would be bad practice).
-Not all bodies support it.
-Return type can vary.

2) The TransX method (see the source here).
Pros: -It works for TransX!
Cons: -Less accurate (the idea is to calculate a conic orbit based on an initial state vector)
-It could be a lot of work (I don't like pinching source from others for some reason).

3) Propagate the planets too
I can only think of cons :S

My question:
I was wondering if since those old posts anyone has found a nicer alternative to using clbkEphemeris than creating my own model based on conics or crazy option 3.

On a related note, how are the state vectors of bodies which don't support ephemerides propagated? Are they using a conic orbit with elements which are inaccessible through the API?

Many thanks.

 

[martins]

My personal opinion is that it would be best to go with method 2 or 3. Method 1 would be what is known as an "inverse crime", that is, using the same model for your MFD calculations that Orbiter is using to simulate "reality". This would be self-consistent even if Orbiter's propagation model was utterly rubbish.

In my opinion, it's much better if Orbiter and the MFD code try to simulate reality independently. Then instead of magic error-free ephemeris data you'd have approximations from your own model, and you would have to consider if they are acceptable, or if you need to improve the model. A much better challenge. And if you get a discrepancy because your model is better than Orbiter's, it's a challenge for me to improve Orbiter.

I know that there are many other instances where the API offers magic access to parameters that wouldn't be accessible to a "real" instrumentation or spacecraft developer (true spacecraft positions and velocities, etc.) I've been toying with the idea of an alternative API that would block access to such functions, so that addon developers have to come up with their own solutions to get these data.

Edit: And yes, you are right. Calling a callback function from within an addon is not good practice. They are designed to be called by Orbiter.

Edit2: It just occurred to me that here is actually a good argument against opening up the sources of Orbiter's physics engine. After all, Orbiter is meant to be a model of physical reality, and nature doesn't publish its source codes either :lol:

 

[csanders]

I know that there are many other instances where the API offers magic access to parameters that wouldn't be accessible to a "real" instrumentation or spacecraft developer (true spacecraft positions and velocities, etc.) I've been toying with the idea of an alternative API that would block access to such functions, so that addon developers have to come up with their own solutions to get these data.

Interesting.

Perhaps add a perimeter for inherent measurement error.

Oh, and people can't get up-to-the-second positional data unless they launch a set of GPS satellites!

 

[Benom8]

Thanks Martin

Thinking more carefully about option 2, it doesn't seem so bad; I think I'll have a stab at that.

The alternative API does sound interesting, however developers could already write simulations of instruments etc. if they wanted users to be concerned with that stuff (which sounds quite fun actually).

I'm trying to think if there's something that could be added to the API to help developers design sensor systems. It wouldn't affect existing MFDs etc but you could add some kind of "perceived reality" class which is attached to a vessel and updated by sensors. The problem is that you still would want addon sensors which could get the "real" data.

Maybe where the API comes in is to feed sensor-data to existing addons. Rather you than me on that score!

I'm sure you have a few better ideas.

 

[sorindafabico]

Interesting.

Perhaps add a perimeter for inherent measurement error.

Oh, and people can't get up-to-the-second positional data unless they launch a set of GPS satellites!

For end-users, could there be an option to disable the "magic", like the option of (un)limited fuel.

 

[jarmonik]

The problem:
I need to estimate future state vectors for gravitational bodies. After looking at the SDK and a few old threads here I can see three options:

That depends about how are you planing to get future state vectors for the vessel. If you use conic approximation then the method 2 would be best since the errors between vessel and planets tends to compensate each-other. If you prefer numeric state propagation for the vessel then option 1 would be the best choice (in my opinion). Numerical propagation of the planets (Option 3) is a bad one because the initial velocity information is not accurate enough for reliable/usable state propagation. The IMFD relies in options 2 and 3 depending about the program where as the LTMFD relies in option 1 alone.

1) Using clbkEphemeris:
Cons: -It's probably slow.

It could be a little slower then a conic approximation but not slow enough to cause any performance problems.

-Not all bodies support it.

Then a conic approximation is accurate

-Return type can vary.

You can always convert it.

 

[Benom8]

Thanks Jarmonik. I was planning on numerical propagation for the vessel state but I tend to agree with Martin (an easy position to take ) -the callback doesn't seem appropriate/robust.

I think for now I might just write an interface then I can plug in different algorithms and compare them.