OHM OSIRIS-REx

[cristiapi]

Wonderful! :thumbup:

 

[cristiapi]

No idea on how much work is needed, so I can only ask.
It would be useful to also have the best fit ellipsoid for the Bennu model; no texture, only a triaxial ellipsoid (I attached the .bmp). I'd be very grateful if you'd also create this model, but if you don't have time, just ignore this post.

 

[BrianJ]

Hi,
unfortunately I can't access OrbitHangar to either update or upload add-ons, so temporarily you can download an updated version of OSIRIS-REx (v.190901) from my GoogleDrive here:
https://drive.google.com/open?id=1z4Ew5P7lWo_vykTImTd6-qeXjq9bkurx

It includes the new Bennu elevation and surface tiles, and .cfg file.
If you install over an older version - you must DELETE your old /Textures/Bennu folder first.

I'll make a start on your triaxial ellipsoid next

Cheers,
Brian

 

[cristiapi]

Visually stunning! But if you enable the "Visual helpers", the Planetarium mode -> Target Equator line doesn't pass over the equator. Also, if you use Obliquity = 177.6 (a reasonably accurate value), the spin axis seems to be about 100 deg (the ecliptic blue line is almost vertical instead of horizontal).

I don't want to disturb you further; is there a procedure you can recommend to create the elevation data for Orbiter?

 

[BrianJ]

But if you enable the "Visual helpers", the Planetarium mode -> Target Equator line doesn't pass over the equator.

Hi,
looks ok to me. Checked by tracking equatorial feature.

if you use Obliquity = 177.6 (a reasonably accurate value), the spin axis seems to be about 100 deg (the ecliptic blue line is almost vertical instead of horizontal).

For the .cfg files, units are radians not degrees.

is there a procedure you can recommend to create the elevation data for Orbiter?

Here's my rather clunky manually work-intensive procedure:
https://orbithangar.com/showthread.php?p=567567&postcount=24
or try googling for "orbiter forum elevation". Also, have a look in Orbiter Doc/PlanetTextures.pdf.



Cheers,
Brian

 

[cristiapi]

looks ok to me. Checked by tracking equatorial feature.

I'm probably misinterpreting the meaning of the lines, but I think there's something strange. I'll do some testing...

For the .cfg files, units are radians not degrees.

Ooops! You're right.

Here's my rather clunky manually work-intensive procedure:
https://orbithangar.com/showthread.php?p=567567&postcount=24
or try googling for "orbiter forum elevation". Also, have a look in Orbiter Doc/PlanetTextures.pdf.

Thank you. I already read PlanetTextures.pdf, it's the reason I asked here.
I'll try the procedure for the triaxial model. Don't waste your time.

Ciao e grazie
Cristiano

 

[BrianJ]

Hi,
no worries Thanks for uploading the altimetry data image.

The visual helper "Target Equator" green line is a projection of the target planet's equator onto the Celestial sphere, as far as I know.

For a more accurate orientation of Bennu, you may want to figure out the axis LAN parameter in the .cfg file (currently set to LAN = 0 ).
The Wikipedia entry for Bennu gives RightAscension and Declination of the N.Pole, so it can be calculated from that. (I might have a go at some point).

Also, the rotation offset needs to be set (currently set to SidRotOffset = 0).
You might be able to do that if you have an image of Bennu with a time stamp from the spacecraft.

Do let me know if you figure out those parameters!
Cheers,
Brian

 

[cristiapi]

The visual helper "Target Equator" green line is a projection of the target planet's equator onto the Celestial sphere, as far as I know.

The first strange thing is that that line is purple in my installation (Orbiter 2016).
Beside that, I attached one image of Bennu and one of the Earth (for comparison).

I used the global frame (F2) and I oriented the camera to see the retrograde Bennu rotation. To see the line passing over the center of Bennu, I needed to look from about 45 deg nord.

Now I changed to a well known celestial body without changing the camera orientation. We see the south pole up (which is correct) and we see the line passing exactly over the equator when we look the Earth from over the equator, which is also correct, but that doesn't happen with Bennu (I hope that my "English" is clear enough).

I'm not totally sure that it's a problem, but it seems strange to me.

For a more accurate orientation of Bennu, you may want to figure out the axis LAN parameter in the .cfg file (currently set to LAN = 0 ).
The Wikipedia entry for Bennu gives RightAscension and Declination of the N.Pole, so it can be calculated from that. (I might have a go at some point).

Also, the rotation offset needs to be set (currently set to SidRotOffset = 0).
You might be able to do that if you have an image of Bennu with a time stamp from the spacecraft.

Since I use SPICE to do all the calculation, I can calculate and verify anything, but the problem is to understand the exact meaning of those parameters in Orbiter.

What I'm trying to do is to use Orbiter as a 3D visualization tool. All the bodies are moved with the SPICE library (I'm currently using Orbiter 2010) and I orient ORX using the NAIF's data file (which include also the instrument FOV). I'm currently intersted in the preliminary survey phase. In other words, I need a perfect setup!

Do let me know if you figure out those parameters!

You can bet!

 

[BrianJ]

Hi,
I have a hunch you're using the D3D9 graphics client for Orbiter, yes?
For some reason the "Target Equator" display in D3D9 is a purple line and always shows along the Celestial sphere equator (whatever the target is). Try using the default Orbiter2016 graphics - the line is green and looks like it is in the correct place relative to Bennu (to me anyway!).

If you're using SPICE to set the orbit and orientation, I guess you won't need to bother with those parameters in the .cfg file?


FYI, from those red/blue height maps, I estimated the maximum elevation to be 287m, and minimum 215m, and processed the image accordingly. This may not be accurate enough for you. Do you have more accurate max./min. elevation values?

Otherwise I have to rely on moving the cursor around on the height map image and hoping I can find the max/min points. I can already see I'm out by at least 2m on the overall elevation range.

Not much work to re-do those values and run the ele2png.exe
I'll have another go with more accurate max/min values.

Cheers,
Brian

 

[cristiapi]

Hi,
I have a hunch you're using the D3D9 graphics client for Orbiter, yes?
For some reason the "Target Equator" display in D3D9 is a purple line and always shows along the Celestial sphere equator (whatever the target is). Try using the default Orbiter2016 graphics - the line is green and looks like it is in the correct place relative to Bennu (to me anyway!).

You're right! With the default graphics it looks good.

If you're using SPICE to set the orbit and orientation, I guess you won't need to bother with those parameters in the .cfg file?

With SPICE I obtain the "exact" location of the bodies, but if I also want a correct Bennu prime meridian location, I also need to bother with those parameters (I remember the same for Pluto/Charon synchronism).

FYI, from those red/blue height maps, I estimated the maximum elevation to be 287m, and minimum 215m, and processed the image accordingly. This may not be accurate enough for you. Do you have more accurate max./min. elevation values?

The values are 214.55 m and 289.351 m, but if we consider the .bmp image, those 8-bit converted altitudes become 214.404 and 289.205.

Not much work to re-do those values and run the ele2png.exe
I'll have another go with more accurate max/min values.

Thanks a lot

---------- Post added at 16:31 ---------- Previous post was at 09:46 ----------

Here's my rather clunky manually work-intensive procedure:
https://orbithangar.com/showthread.php?p=567567&postcount=24

At step 2 I read that you scale an image to several resolution; isn't it better to have all the necessary .bmp without having to scale them?

 

[BrianJ]

At step 2 I read that you scale an image to several resolution; isn't it better to have all the necessary .bmp without having to scale them?

Hi,
yes, but I rely on height map images from the web - they are not always available in the desired resolutions.


Just working on a more accurate elevation model for Bennu - I think we are up against the maximum resolution that ele2png.exe can process(I believe it uses integers for max./min. values). I have got the accuracy down to ~0.1m at max/min points.



Elevation model max. 289.3m, min. 214.3m (checked visually using sphere overlay).


I think that's the best I can do! Will upload soon.


I'm just looking at the rotation axis parameters.
The Wikipedia RA/Dec for N.Pole implies an obliquity of ~173.32deg. relative to ecliptic. Do we believe that?


Cheers,
Brian

 

[cristiapi]

Just working on a more accurate elevation model for Bennu - I think we are up against the maximum resolution that ele2png.exe can process(I believe it uses integers for max./min. values). I have got the accuracy down to ~0.1m at max/min points.

If I correctly understand the doc "PlanetTextures.pdf" page 9, the elevation resolution is 1 m.

I think that's the best I can do! Will upload soon.

Very good!

I'm just looking at the rotation axis parameters.
The Wikipedia RA/Dec for N.Pole implies an obliquity of ~173.32deg. relative to ecliptic. Do we believe that?

The most updated values used by NAIF are: RA= 85.4567, DE= -60.3574: https://naif.jpl.nasa.gov/pub/naif/ORX/kernels/pck/bennu_v14.tpc
which is 173.477 deg over the ecliptic, but AFAIK almost all the literature gives about 176 - 178 deg.

EDIT: 176 - 178 deg is the axial tilt (the angle between the rotational axis and the orbital axis). Since the orbital inclination is about 6 deg, 173.5 deg over the ecliptic seems coherent with 176 - 178 deg.

 

[BrianJ]

Hi,
a new, I think more accurate, version osiris_rex_190903.zip here:
https://drive.google.com/open?id=1W6f8_PWAIy71SjL34YUSrEZs4n9vF5aN
Only changes are to Bennu elevation tiles and .cfg.
As per previous post, elevation max. 289.3m, min. 214.3m

I used your NAIF data for N.Pole RA/Dec, converted to Ecliptic RA/Dec by online tool here:
https://lambda.gsfc.nasa.gov/toolbox/tb_coordconv.cfm

Epoch = 2019
Ecliptic RA = 69.83347
Ecliptic Dec = -83.47478

.cfg parameters:
Obliquity = 90 - Ecliptic Dec = 173.47478 = 3.02771 radians
LAN = Ecliptic RA - 90 = -20.16653 = -0.35197 radians
Checked visually, matches the Celestial and Ecliptic coords ok.

You can probably figure the SidRotPeriod and SidRotOffset values better than I, definitions are in OrbiterConfig.pdf.
(Changing the .cfg Epoch will invalidate the orbital parameters, but won't matter if you're using SPICE.)

Cheers,
Brian

 

[Tarantul]

Hi Brian, thanks for your outstanding mods, top quality at all!

But I only have a problem with Bennu, I describes it here: https://www.orbiter-forum.com/showthread.php?t=41205

Shortly - when I add Bennu (as Planet13) in sol.cfg, landing pads and vehicles on Earth "sticks" to sea level. Any suggestions?

v.190903

 

[BrianJ]

Hi,
I can't reproduce this bug on my set-up. If you can post your orbiter.log, it might give a clue.

Is this effect only seen on the Earth? (does it happen to the Brighton Beach moon-base, for example?)

Does the effect happen on all scenarios that you try?

Thanks,
Brian

 

[Tarantul]

Yes it definitely doesn't affect Moon, and I noticed that this "underground" effect exist only if I load scenario where vehicle is landed. For example "DG-S ready for takeoff.scn" or "Cape Canaveral.scn".
If I load scenarios with DG orbiting or landed on Moon's base and move it to the Earth' ground with scenario editor - both vehicle and pads are perfectly on the ground. And if I commented Bennu string with ";" in sol.cfg - no problem appears at all in any scenario.

Here is the log after couple of loaded default scenarios with Bennu in sol.cfg

 

[BrianJ]

Hi,
I can't see anything obvious in your orbiter.log that would cause this bug.

If you want to investigate further, I would suggest:

a) Make a new, clean installation of Orbiter2016 and only the Osiris-Rex add-on.
Does the bug still happen?
If "No" then it could be a conflict of add-ons/modules in your original installation.

If "Yes" then:

b) Look in the /Textures/Bennu/Elev folder and remove all .png and .meta files (leave only the .elv files).
I don't see why .png and .meta would cause any problem, but we can eliminate them anyway.

Does the bug still happen? If "Yes" then:

c) Remove the /Textures/Bennu/Elev folder completely, then test.
If the bug is corrected, then we know it's something in the Bennu .elv tiles causing the problem.

If the bug persists, then we can start to look outside the Bennu "Elev" folder for causes.

*****

Since I can't reproduce this problem, it is hard to diagnose the possible cause.

Good luck!
Brian

 

[Tarantul]

Hmm, now that's interesting.

I tried clean install with only D3D9, Multistage2015 and Osiris-REX installed and yes, Bennu presence has no such an effect.

Also when I tried to remove "Bennu/elev" folder from "full-mod" installation, it worked - no underground pads on Earth was anymore! But strange that this "elev" folder has no influence on Earth on clean install...

Also I tried to move "elev" and "elev_mod" folders between "Earth" folders in full-mod and clean installs - no effect - still undergroung in full-mod and still on fresh air on a clean one. (this folders appeared after SpaceX LC39 launchpad' installs).

 

[BrianJ]

I wonder if the bug is related to memory usage.

If you have extra planets or hi-res elevation tiles installed in your "full mod" Orbiter, you could try adding them, one at a time, to your new "clean" Orbiter installation. Then test after each one.

Also, you could check if the Orbiter Video settings and Visualization Parameters tabs are the same on both your Orbiter installations.

Well, I'm just guessing here ;-)

Cheers,
Brian

 

[Tarantul]

Well, all Orbiter parameters is the same, also I've tried to move whole hi-res Earth texture folder to a clean install - no changes, all is ok.

This is the point where I simply give up. I decided to not test by moving planet by planet to a clean install and changing sol.cfg one by one, because of pure lazyness.

Instead I just made a copy of sol.cfg with Bennu, naming it sol_Bennu.cfg and use it only with Osiris-REX post-launch scenarios. I think now in my situation it's the simpliest way to make evething works.

Thanks a lot for trying to help! This a really detective story)