Hello,
I am currently in need of evaluating the position of one spacecraft with respect to another one based on the local orbital frame of one of the two. I have tried using the approach mentioned in Relative position vector in orbital reference frame - #2 by luc
While it is doing what I expect, the local orbital frame adopted is defined using the position vector and orbital momentum vector. What I need, instead, is a local orbital frame defined using the vectors of position and velocity (in ECEF). While the two frames should be equal in theory, I have seen in the past that the two definitions bring two different results, that grow larger with time.
Is it feasible to define a Frame instance built with these directions, such that it is possible to use the method linked before to evaluate the position of a second spacecraft in this new local orbital frame?
It’s not possible because in the general case position and velocity are not perpendicular. They are perpendicular if and only if the orbit is perfectly circular and stays that way throughout the propagation. That’s why the orbital momentum is always used as a second reference in the LOFs, along with either position (e.g. QSW) or velocity (e.g. TNW).
Now if you really need to use position/velocity you can project (using a scalar product) the relative position on those vectors.
Dear @MaximeJ
thank you for the heads up! You are right, and I have wrongly worded my request. What I would like to create is a frame, centered in the position of my main spacecraft, that has as unit vectors the three following vectors:
position
crossProduct(position,velocity)
crossProduct of the previous two
It should be equal to the ones defined in the Orekit library, but I would still like to try to define this frame manually per each propagation step, in the Python wrapper. How could I do it?
Anyhow, I think I have also found something strange within my code. I am currently also implementing some Elevation detectors to monitor the elevation with respect to some targets. What I am observing is that if I keep these in, the relative position experiences errors, as seen in the figure below for the along-track difference. If I remove every detector, the relative position that I obtain is smooth. See figures (top, with detectors. Bottom, without detectors) What could be causing it?
Ok, sorry I misunderstood your need. Unfortunately, there’s not built-in LOFType that suits your need.
Two solutions:
At each propagation step, project the relative position on each of the three axes manually
Define your own LOF from the interface, in the same fashion as in LOFType, and use a transform from there.
Hard to say without the code. Do the dates where the relative position gets buggy matches starts/stops of the elevation detectors?
Using detectors and multi-satellite propagation can be tricky if you have intertwined calls between propagators (which shouldn’t be the case from what you say but I have no other idea). I suggest you first produce ephemeris of the two propagators, and then compute the elevation detection using these ephemeris.
I have gone deeper into the code and yes, what is actually happening is that I am creating a list of SpacecraftState(s) per each propagation step (say 10 seconds). Whenever the elevation detector registers an event, which in this case is an ElevationExtremumDetector event, the current time-step is changed with the date of the event. Since the spacecrafts are flying close to each other, what I am witnessing is:
states of both spacecrafts at 10-20-30s…
event happens (with slightly different dates). Spacecraft state stored at 38.674s and 39.413s
state of both spacecrafts at 50-60-70s…
When computing the relative position I am taking each spacecraft state from the list, but whenever the detector is triggered, I am comparing positions that are relative to a different date!
So, the best way to maintain the uniformity of propagation is to generate ephemeris and then from these compute the elevationExtremum events? I was thinking about propagating twice for the relative position and twice for the detector, but probably your way is more consistent. How can I generate ephemeris for my needs?
You can look at this tutorial for ephemeris generation.
The idea is to do the following, given a propagator object:
// Set the propagator to ephemeris mode
final EphemerisGenerator generator = propagator.getEphemerisGenerator();
// Propagate
propagator.propagate(t0, tf);
// Getting the integrated ephemeris
final BoundedPropagator ephemeris = generator.getGeneratedEphemeris();
Then you can use the ephemeris as any propagator. The main point here is to convert an integrated propagation to an analytical propagation. Thus avoid integrating the trajectory twice. But if you were already using an analytical propagator from the start there’s no gain.
To go further, I suggest you use:
An OrekitFixedStepHandler to get the states at each time step and compute the relative position on the fly (see this tutorial),
A custom EventHandler to print/store the event dates (see here for an example).
Or an EventsLogger if you want to store the events automatically and get them at the end of the propagation (example in the test suite here)
