Orbiter's orbital coordinates?

[AphelionHellion]

Does anyone know the formula for translating the .scn file orbit attributes into measurements we might be familiar
with (ie feet or meters)?
For instance, lets say I have a spacecraft .scn here:
...
 STATUS Orbiting Earth
  RPOS -101012.21 6488636.99 -1810060.01
  RVEL 7562.150 -273.687 -1387.773
  AROT 111.76 30.30 -13.17
...
I'm assuming RVEL is relative velocity and AROT is angular rotation - so really all I'm concerned with is this line:
  RPOS -101012.21 6488636.99 -1810060.01
I presume this is our set of XYZ coordinates.  My question then is this: What sort of coordinates would I use to
position a spacecraft, say, 80 meters away from this spacecraft? What direction doesn't really matter to me right now,
although I would like to figure this out at some point - so if anyone knows which number represents which dimension
relative to the reference body, I'd be very grateful for your assistance
In fact I need to know this stuff for a few interesting little scenarios I'm toying with, which hopefully y'all will find quite
amusing as well.

[McBrain]

When I want to do such things, I set the other ship with the same coordinates and start the scenario.
Then I fly the ship with translational thrust away from the ship. (here 80m)

That's the way I do it. I have no idea how to edit the coordinates.

[Simonpro]

Erm, they are in metres. Add 80 to one of the rpos numbers and you shall find yourself 80 m away, but not along the
orbital track, so a perfectly circular initial orbit will be, when the 80m is added, a slightly elliptical orbit due to your
position but old velocity. This can be nulled out with the translational controls as you are not that far from the other
craft.

[AphelionHellion]

McBrain: I normally do that too, but I've run into some problems recently with docking modules and dockable ships.
For instance, if I put two DGIIIs in exactly the same location, sometimes they'll end up docked together.
Not really a problem though, my main problem is that I'm trying to build these little structures out of docking modules
(from the Dragonfly scenarios)
So for instance
.............
....| |......
[ ] + [ ]..
....| |......
.............
Ignore the periods - the forum seems to delete excess spaces
Ok that's a 6-way "Module2" with 4 cylindrical modules docked to it in sort of a giant "plus" shape (use your
imagination, my drawing is even worse than my ASCII "art".) Lets call the modules "up," "down," "left," and "right"
Now, if I use the position of module "left" and put it down for module "right" - even if the docking info is correct -
sometimes I'll get both modules docked to the same port! One "inside" the other.
I get other odd effects - modules that don't look physically connected moving in unison, for instance as if they were.
And I haven't run into this problem yet, but if you dock a DGIII with the nosecone closed, it malfunctions the nosecone
(makes sense).  And when I tried docking some modules to the Vepucci, something (I think some sort of bug with its
rotating sections?)  "threw" those modules way the heck out into space at a slow but constant acceleration :\
Anyway I just wanted to put the modules a little ways apart from each other, yet close enough together that I can use
the Dragonfly to dock them manually.
It's fun to practice doing that, anyway

[AphelionHellion]

Simon: Oh...

Well that splains a lot

So for instance 0000600.50 would be 600 and one half meters from, say, 00001201.00?
Spiffy! Sounds easy enough...
Now I just need to figure out which way is up and I be in biznez!

[DocHoliday]

Like Simonpro said, all numbers relating to distance are in meter and all numbers relating to velocitity in m/s. Now if
you just change the position of a craft, you would also have to adjust the velocity vectors components otherwise it
will drift away. You can try adding really small numbers to the original values of the position, less than 10m in every
direction. That's how I got the MMU for the Ascent Scenario to drift near the ISS. With small numbers like that, the
velocity vector will not have much influence, you may see the object drift away from it's relative position in half an
orbit or more.

What you could do is to position all the modules in a straight line and then haul them together with a dragonfly. Now,
there are formulae to calculate all this but they may be too unpractical. What you can do is this. Take one section of
the station. Put it in orbit and run Orbiter.. Let is run for say 5 seconds and then SAVE the position (CTRL-S). After five
more seconds save it again. Repeat this as many times as you need. Then, open up all the scenarios that have been
created for this in the Quicksave directory and copy the positions of his module into a single scenario, renaming of
course the modules. You should get them in a straight line, 5 seconds appart (which at 7,6km/s should be a lot), and
see if they are too far appart. If they are just try doing it again, saving every second or so..

Otherwise the formula to calculate a distance in 3d space is: distance=SquareRoot(x^2+y^2+z^2).. "^" meaning
raised to the power of. Similar thing for velocity. But their corelation in orbit is something that would require a little
more mental power than I can muster in the morning You're right, it's angular velocity so all three components
change all the time, as does the position.

Cheers,

[Simonpro]

orbiter doesnt use angular velocity, it deals in cartesian space only.

[AphelionHellion]

Ahhhh..... I see!
Damn Doc, you is smart!!

Yeah I figure if the objects are in the same orbital "line" they won't really drift away from each other, just up and down
in relation to each other... As opposed to if I had one above the other, in which case they'd drift apart from orbital
speed differences?
Anyway I'm moderately fast with the dragonfly (and getting better) so I've found that the biggest drift problem I have
is with objects I move myself (for instance something I dock with and then undock with - it gets two small velocity kicks
that way). So I nudge it and then come back to it later and it's 20 klicks away


Also with the new .6 tether MFD it's easier than ever to make sure stuff doesn't drift away. You can lash a whole
station's worth of stuff together  

[Simonpro]

If you arrange a line of objects all in the same orbit (i.e: dimensions and velocities are the same) then the objects will
not drift away from each other.
As you say, though - stacking one above the other in terms of altitude will allow the objects to slowly drift away,
perhaps at the rate of a couple of metres per hour/day.

However, in the next orbiter version Martin is programming a limited version of non spherical gravity (only one of
three sets of harmonics is supported) but this will cause a small amount of orbital drift between objects even in
the same orbital track
That should provide some entertainment for you

[AphelionHellion]

Simon: Wow!! So we'll get some very unusual results orbiting those asteroids and other bodies of weirdly distributed
density eh? Great, one more thing to deal with Hehe

Simon: Yes in the same orbital track I figured there'd be no relative motion, however even if I were to perfectly
arrange each object in the same orbital track using .scn coordinates, their velocity vector would still be the same,
right? So their orbits would be the same size, but their Apoapsis/periapses wouldn't be in the same places.

Wait you said orbiter doesn't use angular velocity? At all??
Wow... So orbits are orbits are orbits. No other way to go, eh?


//flunked math, but is under the impression that Cartesian refers to elipses and foci and stuff

[Simonpro]

AphelionHellion wrote:
Simon: Wow!! So we'll get some very unusual results orbiting those asteroids and other bodies of weirdly distributed
density eh? Great, one more thing to deal with Hehe

Not sure, i doubt martin has coded in the harmonics or anything other than the planets and large moons - and even
these are not going to be terribly accurate. Also, we only have one out of three sets of data being implemented in
orbiter - so GEO drifting will not be a feature of the new version. However, i am sure the upgrade will keep all but a
few of us on our toes for a couple of months - rendevous and docking will be increased in complexity.

Simon: Yes in the same orbital track I figured there'd be no relative motion, however even if I were to perfectly
arrange each object in the same orbital track using .scn coordinates, their velocity vector would still be the same,
right? So their orbits would be the same size, but their Apoapsis/periapses wouldn't be in the same places.

No, as say you wish to place four bodies around one orbit - each at 90 degrees from each other. You'll have to
change the rvel's as well as rpos's, and that can take some effort, 90 degrees apart being the simplest case.
You can use the orbital elements scheme, though and simply change the longitude at reference time to be slightly
different for each body. This has the advantage that the orbits will be exactly the same for each body in orbit,
but there is a small distance separation along the orbit track. Simple trig can then be used to determine the distance
between objects based upon their orbital altitude and longitudinal spacing.

Wait you said orbiter doesn't use angular velocity? At all??
Wow... So orbits are orbits are orbits. No other way to go, eh?

I have not seen any references to angular velocity in orbiter - all velocities are based puon the 3 cartesian axes, x y
and z. I will be happy to be proved wrong on this point but i fail to see the logic in programming orbiter using angular
velocity, as it is simpler (from a coding and methematics perspective) to use cartesian coordinates rather than
angular coordinates.

//flunked math, but is under the impression that Cartesian refers to elipses and foci and stuff

Yes, it can do - but i am meaning cartesian as in velocity being based around the three axes x y and z, rather than
along orbit, out from orbit and up from orbit.
[/quote]

[DocHoliday]

I have not seen any references to angular velocity in orbiter - all velocities are based puon the 3 cartesian
axes, x y
and z. I will be happy to be proved wrong on this point but i fail to see the logic in programming orbiter using angular
velocity, as it is simpler (from a coding and methematics perspective) to use cartesian coordinates rather than
angular coordinates.

Hm, I'm not familiar with the Orbiter code, but the various Excel tables I've studied use angular velocities and all that,
but as you said, they are then always converted back to cartesian... Then again, my math is too basic to argue
anything

[Simonpro]

Excel tables are not orbiter, however - they are generally tools made up by people with a less than satisfactory level
of orbital mechanics experience, hence why they seldom work

[DocHoliday]

Granted. Although, they are still better than what I so far was able to come up with How are you getting on here?
You mentioned once, you'd be working on some calculus yourself.

[David Fox]

If you'd like to try an Excel program that does seem to work (although, admittedly, by someone with little orbital
mechanics experience), then I'd be willing to send it (it's about 2MB, however).

Basically, it allows one to describe an orbit by its orbital elements, or initial state vectors, and see what the orbit will
look like. The initial state vectors will also be generated, for orbits having been input by orbital elements, so that the
orbit can be reproduced in Orbiter, by copying and pasting the state vectors into a scenario, in the form:

RPOS x z y
RVEL vx vz vy


I would certainly be willing to consider any criticism, or suggestions for improvement.



David

[DocHoliday]

Yes, I'd like to see that. Did you make it yourself?

[David Fox]

Yes, I made it myself, although I had to learn a bunch of things, from other people, to do it.

I can send it to you, by email, if you post your address (I can't read your profile, without being registered), or you can
send me an email, yourself, and I'll send it as a response (make sure that you give your email a recognizable subject,
since I get a lot of junk, which I delete without reading; so, I'll need to know that it's you, lest I delete your email,
inadvertently).


David

[Simonpro]

DocHoliday wrote:
Granted. Although, they are still better than what I so far was able to come up with How are you getting on here?
You mentioned once, you'd be working on some calculus yourself.

Im a physics and space science student, so working with calculus is part of my job. David appears to have spotted a
bug in my version of the program although it works absolutely fine on my pc and i am not sure what is different about
the one he downloaded. Ill post a link once i figure out why his isnt working.

[DocHoliday]

David: my address is janez.orbiter@vidmar.org

[quote
Im a physics and space science student, so working with calculus is part of my job. David appears to have spotted a
bug in my version of the program although it works absolutely fine on my pc and i am not sure what is different about
the one he downloaded. Ill post a link once i figure out why his isnt working.
[/quote]
Oh, I see! I'm just a humble economist What does (should) the program do?

Cheers,

[Simonpro]

All will become clear in a couple of hours when i get a chance to examine the thing and find out what is so different
about the version on the net.

[DocHoliday]

Where can I get it on the net?

[Simonpro]

As i said, it appears to not work for some people, so i need tro get that sorted before i give you all the link