Custom Orbit Paths

How would I go about inserting my own orbit paths into Uniview? What files would I need to create and what information do I need about the orbit?
Advanced

Is this article helpful for you?

+1
Answer
Answered
Hi Kerri,

This is a pretty complex or simple thing to do depending on what type of orbit you are trying to add. 

This will be a quick (relatively) and dirty way of going about this.

We can see some examples of this by checking out a few modules in the application/modules folder.

Let's take a look at Ceres for example. You should see 6 files in there.

 ceres.dds is the mercator projection texture of the object so we can just ignore that for now.

ceres.mod has a bunch of elements that are important and tell Uniview where to place this particular object (or objects)
There are 2 coord sections. The first one tells you where the barycenter for the object should live and what the parent of the object is. For example in Ceres we name the first coord CeresBarycenter to define where the barycenter is. Then we say the parent is the SolarSystem. If this were an object like a moon orbiting jupiter, we would have the parent be Jupiter.

you can also set the scale and units for it as well as the entry distance

then you should see the positionfile, orbitfile and position hook.

The first two will reference modules that have orbital elements in them and the third is what we want to to name the object for the purposes of adding an actual textured object to the orbital path. You should be able to see (by looking through the mod file) how each is related to one another. 

Then at the end of the mod file you will see the object references. The first one basically places it in the dwarf planet catagory on the object tree and allows for each of those objects to be controlled by the parent object in the object tree. in this case "Dwarf Planets" is the parent of Pluto, Ceres, and Eris.

The rest of the information can be looked up under sgOrbitalObjexts in your Run-Time Syntax command help in Uniview.

ceresbarycenterpos.conf  is an important file that basically tells Uniview where to find the orbital elements either in kepler Orbital elements (the simple way) or as a BSP or binary spice file(the more complex way). The BSP file for objects is usally found online for specific spacecraft or objects and takes you down a pretty complicated path which we will avoid right now.

ceres.SGO is where you enter in the orbital elements for the object. It should looks something like this

Inclination 10.587
SemiMajorAxis 2.7678
Eccentricity 0.0774
LongOfAscNode 80.7
DailyMotion 0.214274
LongOfPerihelion 153.681
MeanLongitude 262.19

which I am sure you are relatively familiar with.

ceresorbit.conf this is where we define what the orbit looks like in Uniview along with the period of the orbit. The segments basically defines how many orbital segments (straight lines) the orbit is made of. The higher this number the better looking your orbit will be, but it will also effect performance. 200 generally looks pretty good.

So basically all you need to do is copy Ceres, change the names of the files and then update the SGO and Mod file for your new object (not forgetting what the parents should be) 

I hope this made a bit of sense to you. if you want to go ahead and give it a try and then you can send in the file to us if you are having problems getting it up and running and perhaps we can help you with it.

Also if I have missed something in this description (totally possible) please ask and I will be happy to answer.




If I can add a couple of things I've noticed:

For accuracy, I also always add a DateofElements to the .sgo file with the julian ephemeris date for the elements. I'm not sure what Uniview does otherwise (assumes 1/1/2000 12:00?).

Also of note, the "position.conf" file will often contain a number after the location for the SGO or BSP file, like "1495.9"--which is to scale the orbit from AU to 100,000km (the usual default unit for solar system coordinate spaces). For satellites orbiting planets, this value is usually 1.0 and the semimajor axis should be given in 10s of KMs (ie, if the semimajor axis is 2000km, it should be put in the SGO as "200"). For .bsp files using AUs in the Solar System scale of 0.00001 is assigned, and for those orbiting planets, 0.0014959

BSP files for some active missions can often be found at NAIF: http://naif.jpl.nasa.gov/naif/data_archived.html

However, SPICE kernels are restricted by ITAR, so the most current versions aren't always released (the available New Horizons one, for example, only runs from launch to 2010 or so). It's possible (but extremely complicated) to construct them from Vector data obtained from JPL horizons (which itself pulls from SPICE kernels, including those not available publicly--just the vector data and reconstructing kernels from it is not considered an ITAR issue). This is a REALLY complicated process though, but if there's interest I'd be happy to make a write-up eventually.

For Earth-orbiting satellites it's also possible to use a TLE file, which contains all the keplerian parameters: http://www.celestrak.com/NORAD/elements/
I followed the instructions and was able to generate an orbit into Uniview but it looks really abnormal. For the orbit I am trying to represent I looked up the information I needed for the .sgo file. The only parameter I don't know how to obtain is the DailyMotion. I tried a random value and I am assuming that's why I got an abnormal shape to the orbit. Is there any way to calculate the value for this parameter? I tried to figure it out myself using the example orbits as a guideline but can't seem to match the number they have for that parameter.

Thanks again!
I always use JPL HORIZONS for orbit data http://ssd.jpl.nasa.gov/horizons.cgi which lists "DailyMotion" as "N" in degrees. It's also important to make sure you have the right period in the orbit.conf file. If it's too long, it will loop back on itself, if it's too short, it will cut across itself (PR on HORIZONS in days, although I'll convert to hours when appropriate). Also important to make sure that the orbit is tied to the right object in the .mod file (this is declared in the coordinate system, but needs the name of the object). This is another place DateofElements is important, because of kepler's 2nd law.

Also as a general tip for those less familiar with orbital elements who might be reading this: Uniview (and every other planetarium program I've worked with) needs the longitude of the ascending node, longitude of the periapsis (or perihelion or perigee, periapsis is the generic term) and mean longitude. HORIZONS and most other services provide the longitude of the ascending node (OM), argument of the periapsis (W) and mean anomaly. Longitude of the periapsis is the longitude of the ascending node + argument of the periapsis (OM+W) and then mean longitude is the longitude of the periapsis + mean anomaly (OM+W+MA). When numbers exceed 360, you can subtract 360 (or not, Uniview doesn't care).
This is why we here at SCISS love Dan Tell. He always picks up where I leave out information

He is correct that a lot of the orbital elements can vary from where you obtain the information from. The HORIZONS database is a great resource and should be able to get you the information that you need.

We have a write up on how to work with BSP files and a link to the NAIF Toolkit that you need to use in order to extract the pertinent data, but this is a very complicated process that is in no way intuitive or easy to use. This is why we have been working on getting more and more modules added to Uniview when we can, but rely on important contributors like Dan and Tim and a few others to contribute to the Ucare Site. The nice thing about BSP is that they contain all the information and date/time information in one (sometimes gigantic) file. 

If you want Kerri, you can send us the module you are trying to work on and we can fix it for you and tell you what we did to help you along. You can send it to support@sciss.se.


spicekernelorbitconstruction.docx

Since this reminded me to finally write a guide for our reference here at CAS on working with kernel based orbits, I thought I'd provide it here too... although sorry it's not totally proofread yet. This lengthy document will hopefully walk one through the creation of most SPICE kernel based trajectories. It's still not an easy process, but hopefully I break it down step-by-step for anyone who wants to try. Otherwise, I guess you can keep just waiting on me to build the modules for you :).

Greg, if this seems useful, is there another good place to put it on UCare?