Orbiter as a visualization tool of external data

[LauncherLover]

Hello everyone,

I'm currently working on a project that utilizes Orbiter as a data visualization tool for output from a launch simulator I have in Simulink. I have managed to replicate the file structure with the .att, .pos, and .atc files, along with other necessary files to achieve this goal. I have successfully visualized the data I have after applying all the necessary rotation matrices to switch from ECI to the ECPLIPTIC reference frame. However, I am encountering an issue.

It seems that there might be a discrepancy in the definitions of time or the way the Earth rotates between my simulator and Orbiter, as my launcher appears to be displaced by several meters from where I would expect it to be (I have already taken into account that in Orbiter, the Earth is spherical with a radius of 6371.01 km).

Do you have any ideas on how I can solve this? Some thoughts I've had include:

• Upon initializing the scenario (with the launcher at the exact launch point), somehow reading its state vector and rescaling the data to start from that point. However, I would prefer to do this automatically from my MATLAB code, without having to open Orbiter, read the state vector in the ScnEditor, and apply the correction (although I could consider it as a last resort if necessary).
• Having a function that, given a date, applies a correction in the form of a time delay to the date I am inputting into Orbiter so that it starts from where it should.

Any insights or suggestions would be greatly appreciated. Thank you.

 

[Urwumpe]

What is several meters to you? I could imagine Orbiter lagging behind the data stream by a timestep, because you had a different loop in Matlab than Orbiter uses.

It could of course also be a rounding error if it is really small, especially if you have multiple projections in the data flow, which could easily get up to about 3-4 meters.

 

[n72.75]

This might be a helpful thread https://www.orbiter-forum.com/threads/orbiter-and-earth-rotation.40260/

Also, this.

Post in thread 'SPICE module' https://www.orbiter-forum.com/threads/spice-module.1108/post-609388

 

[LauncherLover]

What is several meters to you? I could imagine Orbiter lagging behind the data stream by a timestep, because you had a different loop in Matlab than Orbiter uses.

It could of course also be a rounding error if it is really small, especially if you have multiple projections in the data flow, which could easily get up to about 3-4 meters.

Thank you for your response!

The range can vary, but it can reach up to half a kilometer. Regarding the issue of lag, I don't believe that's the problem because I'm doing everything offline. That is to say: I have my .mat file with the outputs from my Simulink simulation. I process these data with a MATLAB code in which I write all the .pos, .att, and .atc files used by the "playback/record" function. Additionally, I generate the scenario and configuration files for my vessel.

It must be something related to the rotations, that much is clear, but I'm unsure how to solve it.

 

[LauncherLover]

This might be a helpful thread https://www.orbiter-forum.com/threads/orbiter-and-earth-rotation.40260/

Also, this.

Post in thread 'SPICE module' https://www.orbiter-forum.com/threads/spice-module.1108/post-609388

Thank you for your answer @n72.75 ! I ran across this thread but couldnt get to install the SPICE module, will try to do it again, but any help regarding this would be absolutely apreciated

Again, thanks for your response

 

[Thunder Chicken]

The range can vary, but it can reach up to half a kilometer.

Is your position consistently east or west of the target location? If so, that would suggest a time step discrepancy. At Earth's rotation speed a deviation of a time step could displace you such a distance depending on your latitude.

If the distance and orientation varies, that would suggest a round-off discrepancy.

 

[Urwumpe]

Is your position consistently east or west of the target location? If so, that would suggest a time step discrepancy. At Earth's rotation speed a deviation of a time step could displace you such a distance depending on your latitude.

If the distance and orientation varies, that would suggest a round-off discrepancy.

If its in North-South direction, it could also be a different Earth model, geographic coordinates vs geocentric coordinates. This can cause up to 20 km difference.

 

[LauncherLover]

Is your position consistently east or west of the target location? If so, that would suggest a time step discrepancy. At Earth's rotation speed a deviation of a time step could displace you such a distance depending on your latitude.

If the distance and orientation varies, that would suggest a round-off discrepancy.

Yep, always east-west. If I add a time delay to the date (from which one of my rotation matrixes is build) I can get it closer, but its not a constant time delay (if I change to another date in the simulation that time delay wont work for the correction).

I've tried to research about how the Earth rotates in Orbiter, all I found was the information about the sidereal day here https://www.orbiterwiki.org/wiki/Earth (and constant obliquity). I'll try to install the SPICE module tomorrow, will keep you posted.
Thank you all for your help! Any further assistance is appreciated

 

[n72.75]

Yep, always east-west. If I add a time delay to the date (from which one of my rotation matrixes is build) I can get it closer, but its not a constant time delay (if I change to another date in the simulation that time delay wont work for the correction).

I've tried to research about how the Earth rotates in Orbiter, all I found was the information about the sidereal day here https://www.orbiterwiki.org/wiki/Earth (and constant obliquity). I'll try to install the SPICE module tomorrow, will keep you posted.
Thank you all for your help! Any further assistance is appreciated

What's your time epoch. Orbiter uses TDB Modified Julian Date + 29999.5

Thank you for your answer @n72.75 ! I ran across this thread but couldnt get to install the SPICE module, will try to do it again, but any help regarding this would be absolutely apreciated

Again, thanks for your response

Where did you run into trouble with this?

(and constant obliquity)

Extremely long-term effects (Milankovitch cycles, etc) are (as far as I can recall) definitely not simulated by the default Earth module, but not in-practice, impossible.

 

[LauncherLover]

Where did you run into trouble with this?

Well, I download the repository, then copy all the files in my Orbiter directory, then when I open Orbiter it crashes

 

[LauncherLover]

What's your time epoch. Orbiter uses TDB Modified Julian Date + 29999.5

Good question, no idea. I changed the fate formar from gregorian to MJD, but maybe the TDB is causing some discrepancies? Will look into that

 

[n72.75]

Well, I download the repository, then copy all the files in my Orbiter directory, then when I open Orbiter it crashes

oh no...I may have steered you a bit wrong on this. The github repo is for OpenOrbiter (not released yet)

@Ajaja is there a version of your spice module for O2016? if not I can build it.

 

[Ajaja]

@Ajaja is there a version of your spice module for O2016? if not I can build it.

It would be nice. I use OpenOrbiter x64 and haven't built the spice module for O2016.

 

[LauncherLover]

@Ajaja is there a version of your spice module for O2016? if not I can build it.

It would be fantastic if someone could develop this, as I believe it could resolve the issue at hand.

Alternatively, if this doesn't address the problem, I'm considering proposing a straightforward addon. This addon would take a date, longitude, and latitude as inputs, then calculate the position state vector in both Cartesian coordinates and the ecliptic reference frame relative to Earth. The calculated data would then be saved into a .txt file or similar format. I'm uncertain if this is feasible without starting Orbiter. While the concept seems straightforward, my proficiency with C++ is quite limited.

The purpose of this addon would be to compare my initial data in the ecliptic reference frame with the data provided by Orbiter. This would enable me to align all my data with Orbiter's initial position accurately. Currently, I've experimented with a rather rudimentary method involving manually copying the state vector from the ScnEditor window in Orbiter, pasting it into a MATLAB code, correcting the data, generating all the necessary .pos, .att, and .atc files, then saving them again in the Orbiter directory for playback visualization. However, I believe there's a more streamlined and efficient way to achieve this alignment.

 

[Thunder Chicken]

It would be fantastic if someone could develop this, as I believe it could resolve the issue at hand.

Alternatively, if this doesn't address the problem, I'm considering proposing a straightforward addon. This addon would take a date, longitude, and latitude as inputs, then calculate the position state vector in both Cartesian coordinates and the ecliptic reference frame relative to Earth. The calculated data would then be saved into a .txt file or similar format. I'm uncertain if this is feasible without starting Orbiter. While the concept seems straightforward, my proficiency with C++ is quite limited.

The purpose of this addon would be to compare my initial data in the ecliptic reference frame with the data provided by Orbiter. This would enable me to align all my data with Orbiter's initial position accurately. Currently, I've experimented with a rather rudimentary method involving manually copying the state vector from the ScnEditor window in Orbiter, pasting it into a MATLAB code, correcting the data, generating all the necessary .pos, .att, and .atc files, then saving them again in the Orbiter directory for playback visualization. However, I believe there's a more streamlined and efficient way to achieve this alignment.

You could do something like this in Orbiter with a Lua MFD script. There are coordinate converters available such as
oapi.global_to_equ.

 

[Boxx]

Hi, I think there is a confusion here:

Good question, no idea. I changed the fate formar from gregorian to MJD, but maybe the TDB is causing some discrepancies? Will look into that

MJD is just a format, TDB is a time system. SPICE uses a reliable conversion between common time systems (TDB, UTC, TT...) whereas UTC is the time system apparently used by Orbiter. I know it sounds weird but Earth time system (UTC = Orbiter) is quiet irregular "if used from outside of Earth" (!) ... hence the leap second to reduce by "less than 1s." the need of conversion, to tell it in very few words.

If your launch simulation is an integrator, you'd likely use a TT ~ TDB time system. Then, maybe instead of installing SPICE for Orbiter you just use it in MATLAB (the MICE package of SPICE) and converts in your MATLAB the time to output directly Orbiter time. On naif.jpl.nasa.org you've got some tuto to install and use SPICE.

Also, FYI: sideral day is ca.86164s, solar day is 86400s.... so many traps whit that! Good luck

 

[Boxx]

It would be of course nice to use Orbiter for your work. Nevertheless, you can also use another free visualization tool, that makes use of Celestia as a graphic engine: VTS by the French space agency CNES, that also has a stream feature (to display on the fly...). All data need to be formatted in "simple" tabulated text files (CIC-CCSDS). But this will not solve per se your time problem (if any).