General Question How to get planet position at certian time

[wisaac407]

Hi everyone,

I'm working on updating the [ame="http://orbithangar.com/searchid.php?ID=3165"]Attitude MFD[/ame] addon and would like to add the feature to target a planet (or moon) at a certain point in time. My question is, how do I calculate the position of a celestial body at a given point in time (e.g. the position of mars in 170,000 seconds from the current time)? Is there an API call for that? Or do I need to calculate the orbits manually?

Thanks in advance for any help you can provide.

 

[ADSWNJ]

Dr Keith Gelling described a 4th Order Symplectic Integrator to do just such a calaculation, and I am currently working on an app (Lagrange MFD) that implements this code. You are welcome (with attribution to both Keith and me) to look at the current alpha source in www.github.com/ADSWNJ and clone what you need. (Or ... wait a few weeks for the v1.0 version and then you'll have a stable platform to work from.)

 

[Enjo]

Hi wisaac,

Dr Keith Gelling described a 4th Order Symplectic Integrator to do just such a calaculation, and I am currently working on an app (Lagrange MFD) that implements this code.

But you do a 3-body calculation, which is an overkill for his situation.

Try the KOST library, which performs a 2-body calculation:
[ame="http://www.orbithangar.com/searchid.php?ID=3825"]KOST 0.75[/ame]
You might have to comment its implementation of cosh and sinh, to avoid compilation warnings, since these functions are already present in modern VC++.

 

[jedidia]

Try the KOST library, which performs a 2-body calculation:

Hey, I wasn't aware we had something like this!

 

[Enjo]

Hey, I wasn't aware we had something like this!

Yeah. Some great things in this community have never got the deserved attention.

Here's my wrapper around KOST, which most notably uses right-hand coordinate system, while Orbiter uses left-hand, so make the proper conversion, like my wrapper does.
https://sourceforge.net/p/enjomitchsorbit/codeHG/ci/default/tree/lib/Orbiter/SpaceMathKOST.cpp

As for predicting the future position itself, I remember that there's an example in the package that does just that. You'll need Linux with a GNUplot to visualize it though.

 

[fred18]

Hi everyone,

I'm working on updating the Attitude MFD addon and would like to add the feature to target a planet (or moon) at a certain point in time. My question is, how do I calculate the position of a celestial body at a given point in time (e.g. the position of mars in 170,000 seconds from the current time)? Is there an API call for that? Or do I need to calculate the orbits manually?

Thanks in advance for any help you can provide.

May I ask why do you need the point of the planet or the moon in the future and not at the present time of the simulation? maybe there's an easier solution to suggest if we get more inside the problem

 

[Enjo]

May I ask why do you need the point of the planet or the moon in the future and not at the present time of the simulation? maybe there's an easier solution to suggest if we get more inside the problem

OFF TOPIC!!!

nah, just kidding.

 

[Face]

May I ask why do you need the point of the planet or the moon in the future and not at the present time of the simulation? maybe there's an easier solution to suggest if we get more inside the problem

I think this is background information enough:

I'm working on updating the Attitude MFD addon and would like to add the feature to target a planet (or moon) at a certain point in time.

I'd understand it as a feature that answers the question "where do I point a torchship at if travel time to Mars is 2 weeks?" or something along that line.

 

[fred18]

I have to say that a torchship with that feature would be very useful with my space network, so maybe mine was a silly question

 

[Urwumpe]

I have to say that a torchship with that feature would be very useful with my space network, so maybe mine was a silly question

Also, this position is important for any interplanetary navigation. If you plan a burn, you don't ask for current position, but for the target position after your currently estimated travel time. And then you fiddle with ejection time and travel time for a optimal solution.

 

[fred18]

Also, this position is important for any interplanetary navigation. If you plan a burn, you don't ask for current position, but for the target position after your currently estimated travel time. And then you fiddle with ejection time and travel time for a optimal solution.

My question was mostly because I don't entirely agree with that: even if I know where mars will be in 3 months time, I'm not shooting from earth in that direction, I'm shooting in a direction with a speed that put me in an orbit which intersect the one of mars when mars passes in that point, for example a lambert problem. So I still don't see (except for broadcasting something that goes fast and doesn't get bended by gravity such as radio transmissions) what would be the use of it.

 

[Urwumpe]

My question was mostly because I don't entirely agree with that: even if I know where mars will be in 3 months time, I'm not shooting from earth in that direction, I'm shooting in a direction with a speed that put me in an orbit which intersect the one of mars when mars passes in that point, for example a lambert problem. So I still don't see (except for broadcasting something that goes fast and doesn't get bended by gravity such as radio transmissions) what would be the use of it.

And what else does Lamberts problem use, if not the future position of the planet?

 

[fred18]

And what else does Lamberts problem use, if not the future position of the planet?

Yeah, but this is attitude MFD, I understand it as a mean to point my vessel to something and my thinking is that it's not intended to be a new transx or IMFD. So my question basically was: do you want to use it to point the vessel at the planet's future position for some reason (and if so why, since I can't see it), or are you planning to make a sort of a new transx or a new IMFD? Is that so bad?

 

[Urwumpe]

Is that so bad?

Usually, I keep it the following with add-ons: You can NEVER have too much of them.

 

[jarmonik]

Is there an API call for that?

Yes,

oapiGetCelbodyInterface(hPlanet)->clbkEphemeris(...)

But, that doesn't work with planets using orbital elements in which case 2-body keplerian solution is needed. There are many examples about how to do that.

 

[martins]

Although when it comes to implementing instrumentation, I would encourage to use an independent method, rather than querying Orbiter's ephemeris engine directly, lest you commit an inverse crime.

 

[jedidia]

I would encourage to use an independent method, rather than querying Orbiter's ephemeris engine directly, lest you commit an inverse crime.

So... that's kind of like using your codes output for your unit tests, right? :shifty:

 

[jarmonik]

Although when it comes to implementing instrumentation, I would encourage to use an independent method, rather than querying Orbiter's ephemeris engine directly, lest you commit an inverse crime.

Yes, of course, it's a little a bit of that. But in general a planet positions are pretty well known to us, so, wouldn't it be much bigger crime to use Vessel->GetGlobalPos() since that's much less trivial information. Need to rely on accelerometers, integrators, radars in real world.

Also, all my efforts to predict a future position of the Moon in the Orbiter has failed. It could be implementation error on my side or the velocity/position information is too inaccurate to be used for any predictions.

 

[martins]

So... that's kind of like using your codes output for your unit tests, right? :shifty:

Yes, an inverse crime is essentially the reconstruction of the parameters of a model from data that were generated by that same model. It means that

1. you assume perfect data. This is generally unrealistic, and can completely invalidate any results if the model is very sensitive to noise (ill-posedness)
2. the reconstruction is inherently self-consistent. You can get good results even if the model is completely bogus, since you apply the same systematic error to both the data and the reconstruction. So the results don't tell anything about its applicability to real-life cases.

Yes, of course, it's a little a bit of that. But in general a planet positions are pretty well known to us, so, wouldn't it be much bigger crime to use Vessel->GetGlobalPos() since that's much less trivial information. Need to rely on accelerometers, integrators, radars in real world.

You are right. GetGlobalPos and related API functions fall into the same category. I've been vaguely thinking about an "advanced" API that would restrict access to such "cheat" functions, so that certain spacecraft status parameters would need to be obtained more indirectly. It might be quite interesting if you had to implement inertial guidance systems, a working GPS network, etc. to get your state vectors.

Also, all my efforts to predict a future position of the Moon in the Orbiter has failed. It could be implementation error on my side or the velocity/position information is too inaccurate to be used for any predictions.

This is kind of of my point. If you get a discrepancy with an independent method, that would indicate that either my ephemeris code, or yours, or both, are inaccurate. Maybe we should try to find out which?

 

[jarmonik]

Maybe we should try to find out which?

This is going a little off-topic, but anyway, I made DE405 ephemeris implementation about 8 years ago and I checked it against JPL-Horizon web service and they are exact match. So, maybe we could place an other moon up there and see how much they deviate. One problem is that DE405 uses ICRF-J2000 reference frame which is a little off from the EME-J2000. Unfortunately the conversion between ICRF and EME goes over my head. I guess it wouldn't hurt to have oapi call for the conversion. Also, I need to find out if the DE405 data files can be redistributed.

Would this be a valid approach ?

---------- Post added at 03:32 ---------- Previous post was at 03:25 ----------

I've been vaguely thinking about an "advanced" API that would restrict access to such "cheat" functions, so that certain spacecraft status parameters would need to be obtained more indirectly. It might be quite interesting if you had to implement inertial guidance systems, a working GPS network, etc. to get your state vectors.

It would make things little more interesting not knowing for sure if the vessel really is where a nav-computer thinks it is and getting too close to a planet by surprise as result. :lol: I just don't know how to implement one without braking a lot of things in a process.