Radial/transverse orbital velocity

This radial and transverse velocity calculator accepts eccentricity e, true anomaly ν, specific angular momentum h, and an optional gravitational parameter μ, then returns v_r, v_⊥, the speed magnitude, and the flight-path angle in degrees. Non-positive specific angular momentum is rejected with invalid_input because angular momentum sets the scale of both components.

What radial and transverse velocity mean in a Keplerian orbit

In two-body orbital mechanics the position of a satellite relative to the focus is often written in polar form: the radius vector of length r points from the central body to the satellite, and the true anomaly ν measures how far the satellite has travelled past periapsis along the orbit. The inertial velocity vector at that instant always lies in the orbit plane and can be decomposed into a radial part parallel to the position vector and a transverse part perpendicular to it. Their Euclidean norm is the inertial speed. The radial component v_r is positive when the satellite is climbing away from the focus and negative when it is falling back toward periapsis. The transverse component v_⊥ is the local horizontal speed that carries angular momentum; for a circular orbit it is the entire speed and v_r is exactly zero. The classical closed-form identities used by this endpoint are v_r equals (μ divided by h) times e times sin of ν, and v_⊥ equals (μ divided by h) times one plus e times cos of ν, where e is eccentricity, h is specific angular momentum, and μ is the standard gravitational parameter of the central body. The flight-path angle measured from the local horizon is the two-argument arctangent of v_r over v_⊥. Those four numbers let you reconstruct the polar velocity state without a full Cartesian ephemeris, which is why radial-and-transverse calculators show up in preliminary design notebooks, exam solvers, and lightweight edge workers that must stay deterministic.

Input contract, units, defaults, and error behaviour

Optional mu defaults to one so textbook problems written in canonical units work without an extra field; when you work in SI or kilometre-second units, pass μ consistent with h (for example Earth μ about 3.986 times ten to the five km cubed per second squared with h in km squared per second). Values are rounded to twelve significant digits for stable goldens across runtimes. POST a JSON body with three required finite numbers: eccentricity e (non-negative), true_anomaly ν, and specific_angular_momentum h (strictly positive). Optional angle_unit is an enum of deg or rad and defaults to deg; true anomaly is converted to radians only for the sine and cosine calls. Each numeric field may arrive as a JSON number or as a numeric string; missing fields, empty strings, and non-finite values fail with invalid_input naming the field. On success the body echoes the cleaned inputs, returns true_anomaly_rad normalized to the interval from zero to two pi, radial_velocity, transverse_velocity, speed, flight_path_angle_deg, a formula string restating the polar identities, and method equal to orbital_velocity_vector. Pair the response with your own orbit plotter if you need a sketch; this endpoint only evaluates the velocity split at one true anomaly.

Where a polar orbital velocity API earns its keep

University orbital mechanics courses ask students to compute v_r and v_⊥ at selected true anomalies for elliptical, parabolic, and hyperbolic transfer legs; a free browser tool that matches the paid API byte-for-byte removes calculator drift between homework and LMS auto-graders.