
Math & Physics Mathematical and physical problems of space flight and astronomy. 

Thread Tools 
09192011, 03:29 PM  #1 
Orbinaut

Calculate (not derive) Orbital Velocity Vector
Hi,
So, I was wondering here, is there a way to calculate an orbital velocity vector without taking the orbital position's derivative? I searched wikipedia a lot, but haven't found anything other than the usual derivative approach. I know the orbital velocity magnitude can be calculated using the visviva equation, but I haven't been able to find anything as elegant for the velocity direction. The reason I'd rather not use a derivative is noise and floating point inaccuracies... If there were a way to get the velocity vector like that, my orbital code would be a lot more reliable. All other orbital parameters are already calculated here. I'm propagating the orbits simply by stepping through time, so the velocity here is pretty much just a result, not an input. I need it to be as precise as possible, though, because later this calculated velocity will be used to throw the propagated satellite back into a simulated orbit. I'd greatly appreciate any help Thanks in advance! Cheers Last edited by HarvesteR; 09192011 at 03:34 PM. 
09192011, 06:07 PM  #2 
Crazy dude with a rocket

well, if you can get the parameters to propagate your position over the orbit, then it should be simple enough to calculate two points close enough to each other so you can use the normalized delta between them as the velocity direction, no?
yeah, it's dirty... but should work and it's not really the same as a derivative, i suppose... well, we're not really propagating over time, but you're still using a timelapse in order to get something akin to a derivative, yes... but instead of propagating it, you simply normalize and use it as a direction better yet, rereading your post.... calculate the precise delta between the "launch back to real orbit" position and the position at current + 1 times the current simulation deltatime... THAT's your velocity  no need to do anything else Last edited by Moach; 09192011 at 06:12 PM. 
09192011, 09:33 PM  #3 
Orbinaut

Yeah, that's what I'm doing now, in fact. My question was whether there wasn't a way to calculate the orbital velocity direction without having to take a delta.
This was mostly because of problems with numerical precision and things like that. I was able to kind of get around the problem, by replacing unity's floatbased vectors and quaternions with my own, doubleprecision versions. They're not as good performancewise (since Unity's data types are embedded in the engine code), but they're much, much more accurate. All the orbital math now is being done in double precision, so these problems are not likely to reappear soon. Cheers 
09202011, 05:16 PM  #4 
Orbinaut

If you know the orbital elements, then you know the shape of your orbit and where you are upon it.
The direction of your velocity is unit vector which is tangent to your orbit in your position. Such a tangent vector can be calculated analitically for Keplerian orbits. Edit: look at the last paragraph here: http://mathworld.wolfram.com/Ellipse.html . Last edited by Calsir; 09202011 at 07:17 PM. Reason: added mathworld link 
09222011, 03:51 PM  #5 
Orbinaut


10182011, 03:54 AM  #6 
Orbinaut

Quote:
Quote:
Cheers 
10182011, 05:08 AM  #7 
Donator

Read this: http://spiff.rit.edu/richmond/nbody/...ungeKutta4.pdf
It's the way orbiter does it and shouldn't take you long to program. If you're worried about numerical accuracy, use a shorter time step and a higher order numerical approximation. One way to test for accuracy is to run multiple cases of a twobody pointpass system. Record data for the semimajor axis of the orbit and take the standard deviation of it for the whole case. In cases with longer time steps you will eventually see the standarddeviation spike rapidly, if you stay under this limit you're all set. 
10252011, 07:24 PM  #8 
Orbinaut

Quote:
Thanks, but this setup needs to work as a precalculated 2body system. It's used to move planets and moons around, and a stable, and most importantly, deterministic system is more important than physical accuracy. I'm aware that I could run the physical integration at startup to put the solar system in the required time frame, but it would be much more computationally expensive (and possibly unstable) than just setting a universal time variable and letting the orbit propagator calculate a position. Cheers 
10262011, 04:50 PM  #9 
Hop David

Quote:
Position vector is r * ( cos(f), sin(f) ) Now draw a line segment to 2nd focus. Call angle F2 P F1 alpha The velocity vector lies on the tangent line at point P. Using a well known reflective property of the ellipse and the fact a straight line subtends pi radians, it can be deduced angle between r and v is (pi  alpha) / 2. The angle of v is f + ((pi  alpha) / 2) But what is alpha? A well known property of the ellipse is F_{2}P + PF_{1} = 2a since PF_{1} = r F_{2}P = 2a  r And of course, the distance between foci is 2ea Knowing the 3 sides of the above triangle allows us find alpha using the law of cosines. However plugging the above into the law of cosines gives an unruly mess that gives me a headache just looking at it. Setting k = r/a, we can get a similar triangle that's much nicer. (2  k)^{2} + k^{2}  2k(2k)cos(alpha) = (2e)^{2} alpha = acos(((22e^{2})/(k(2k)))1) Hopefully that gives you enough to find direction of velocity vector. You mentioned you know the VisViva equation which gives you magnitude. I seem to remember seeing a rotation matrix using the elements OM w and i where you could put this back in the standard coordinate system. I could have sworn it was in Fundamentals of Astrodynamics by Bate Mueller and White. Will look for it when I have time. 
10302011, 03:50 PM  #10 
Orbinaut

Thanks man! This look like it will work perfectly.
The angle is really all I need. With that I can use a quaternion to rotate the position vector, and the magnitude I can get from the VisViva equation: Code:
Vector3d vel = Quaternion.AngleAxis(alpha + ((PI  alpha) / 2.0), h) * pos.normalized * velMag; // h is my orbit plane normal vector Cheers Last edited by HarvesteR; 10302011 at 03:57 PM. 
10312011, 03:29 PM  #11 
Hop David

My pleasure! I've always enjoyed playing with conic sections.
It's a good idea to check my work. There were 4 or 5 steps between the law of cosines and the last equation and I'm prone to making stupid copying errors. 
11012011, 06:22 PM  #12 
Orbinaut

Just to follow up:
I used your cosine law scheme here, and got a much, much more precise velocity vector here. I had to make a few adjustments (if trueAnomaly > PI I had to invert the angle, because Acos returns a value from PI to PI), but it works really well now. To finally solve the inaccuracy when launching the propagated object into a physically integrated trajectory, I also had to get the position at the next frame. I found that there was a significant shift in velocity because the orbit propagation was giving a oneframelate velocity vector. well, I don't think it can get any more precise than this now, short of improving the orbit tracking precision, which is kinda hard since the physics simulation works at a lower precision level, and there's really not much I can do there. Again, many thanks for all that! Cheers 
11032011, 07:23 PM  #13 
Orbinaut

Or you could do this. Start with the equation for a conic section, i.e.
then take the derivative with respect to time to get the radial component of velocity as Now multiply and divide by and use the first equation above to get Recall that the magnitude of an orbit's specific angular momentum is and you can simplify the radial velocity component to For the along track component, it is simply These are the equations from my first post. Now to rotate these components into the frame suggested by HopDavid, the following relations are readily found To find the angle note from the previously posted diagrams that Therefore where is the flight path angle and it is related to the radial and along track velocity components by Using the above expressions for and one can readily show The benefit to using these expressions is that they involve several constants, utilize multiplication with a single division, and the only angle you need to take the sine and cosine of is . This means that the velocity can be calculated quite efficiently in computer code. 

Thread Tools  


Quick Links  Need Help? 