Indeed, I just tried the Veis1950 and I get an inclination angle of
9.9e-5°, so it is better than the EME2000. For the earth frame I use
ITRF_2005.
Unfortunately, it creates another problem. The computation which
previously took about 20s to finish is now taking forever, I did not
let it go till the end, but it is more something like 20s per
iteration now. Is it something know about the conversion between
frames that it takes longer with this frame? Or is it something else?
Vincent
From: pascal parraud [mailto:pascal.parraud@c-s.fr]
Sent: 19 October 2011 18:24
To: orekit-users@orekit.org
Subject: Re: [Orekit Users] transformation
You can try the Veis1950, instead of EME2000, it is the best
(quasi)inertial Z aligned with earth frame (ITRF93 for example).
It is supposed to be perfectly Z aligned but, in practice, it does
not fit exactly (a quick test shows that a 7000.0 m/s velocity in
the ITRF93 equatorial plane gives a 0.01 m/s Z component in the
Veis1950).
Pascal
Le 19/10/2011 16:37, Vincent Rivola a écrit :
Dear Pascal,
Thank you for your reply. It confirms what I was thinking but
unfortunately I do not know why they are not z aligned.
Do you think I could you other frames than earth and EME2000 which
would be z aligned to avoid this problem. If yes, which one?
The important part for me is to be able to have some kind of ENU
(East North Up) frame in which I can easily define the velocity
vector of my body, and another frame which must be inertial so I
can use it to create the orbit element (which only takes inertial
frame as input).
Do you have other frames to suggest me which would help me to do this?
Regards,
Vincent
From: pascal parraud [mailto:pascal.parraud@c-s.fr]
Sent: 19 October 2011 16:28
To: orekit-users@orekit.org
Subject: Re: [Orekit Users] transformation
Hello Vincent,
At first sight, and if I understand well the way you do, the non
zero inclination angle comes from the transform between the earth
reference frame, underlying frame of the TopocentricFrame, and the
inertial EME2000 frame. As these two frames are not perfectly "Z
aligned", defining the velocity in the equatorial plane of the earth
frame doesn't provide a zero inclination orbit in EME2000.
Does it help you ?
Best regards,
Pascal
Le 19/10/2011 10:51, Vincent Rivola a écrit :
Dear Pascal,
Thank you for your reply. I am now facing another problem.
Let me describe my code, I have some information about a body
(longitude, latitude, altitude, inclination angle of the orbit,
speed) as some point and I want to use orekit to propagate the
trajectory.
First step I create a topocentric frame based on the body location:
GeodeticPoint station = new GeodeticPoint(latitudeRad, longitudeRad,
altitude);
AbsoluteDate date = getInitialDate(); //defined by the user
TopocentricFrame frame = new TopocentricFrame(earth, station,
"initial"); //earth is a OneAxisEllipsoid
Then I create a transformation to go from my topocentric frame to an
EME2000 inertial frame:
Transform t=null;
try {
t = frame.getTransformTo(inertialFrame, date); //inertial frame is
my EME2000 frame
} catch (OrekitException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Then I compute the speed of rotation of the earth at body position
which gives me the relativeVelocity vector:
PVCoordinates pv2000 = t.transformPVCoordinates(new
PVCoordinates(Vector3D.ZERO, Vector3D.ZERO));
Vector3D relativeVelocity =
t.getInverse().transformPVCoordinates(new
PVCoordinates(pv2000.getPosition(), Vector3D.ZERO)).getVelocity();
Then I define the coordinates of my body speed in the topocentric
frame, but also including the relative velocity due to earth rotation:
Vector3D velocityVector = MakeVelocityENU(flightPathAngleRad, A,
velocity, relativeVelocity); //MakeVelocity returns a Vector3D with
the coordinates of the body velocity in topocentric frame
And finally I use my transformation created earlier to go from the
PVcoordinates in Topocentric frame to the PVcoordinates in intertial
frame, and I create a new orbit:
pv2000 = t.transformPVCoordinates(new PVCoordinates(Vector3D.ZERO,
velocityVector));
orbit = new CartesianOrbit(pv2000, inertialFrame, date,
PlanetEarth.gravitation_coeff);
The problem I have is that the inclination of the orbit at the end
of this process is equal to the inclination of the orbit the user is
entering. For a very simple case with longitude and latitude (0,0)
and an inclination orbit of 0° (so on the equator) if I print the
result of "orbit.getI()" I get an inclination angle of
0.0023128007807688327° instead of 0°.
I also noticed that if I change the inital date I use for my
computation, the inclination angle is changing.
Do you have any idea how I can solve this problem?
Best regards,
Vincent
On Mon, 2011-10-10 at 11:07 +0200, pascal parraud wrote:
Dear Vincent,
The altitude of a GeodeticPoint is defined with respect to some BodyShape.
If you usually construct the central body, namely the Earth in your
case, as a OneAxisEllipsoid,
the only implementation of a BodyShape in Orekit, then the altitude
is defined with respect to the underlying geoid.
By the way, the latitude is a geodetic one, it is not geocentric.
Best regards,
Pascal
Le 10/10/2011 10:19, Vincent Rivola a écrit :
Dear all,
I have a question about the altitude considered inside Orekit.
When I create a point with "new GeodeticPoint(lon, lat, alt)", what
is the altitude to enter? Is it with respect to the sea, or with
respect to the geoid? Or even something else?
While propagating the trajectory, I also use the function
"getAltitude" and I have the same question about this. What type of
altitude does it return?
Thank you for your help.
Vincent
-----Original Message-----
From: MAISONOBE Luc [mailto:luc.maisonobe@c-s.fr]
Sent: 09 October 2011 21:38
To: Martin
Cc: orekit-users@orekit.org
Subject: Re: Re: [Orekit Users] transformation
Martin <mailto:martin.spel@rtech.fr> <martin.spel@rtech.fr> a écrit :
Dear Luc, thank you very much for the idea.
It is giving the same results as something we were doing before, but this is
more elegant.
For anybody interested, the velocity vector in the ENU frame is build as:
//velocity expressed in ENU referential
double cosI = Math.cos(inclinationAngleRad);
double sinI = Math.sin(inclinationAngleRad);
double cosFPA = Math.cos(pFlightPathAngleRad);
double sinFPA = Math.sin(pFlightPathAngleRad);
double vE = pVelocity * cosI* cosFPA + relativeVelocity.getX();
double vN = pVelocity * sinI* cosFPA;
double vU = pVelocity * sinFPA;
The main issue we had is that this gives an orbit with an inclination in the
earth fixed frame. Plotting orbit->getI() gives a different
inclination due to
the east component being different in the inertial frame. The problem is that
in the input we have velocity and FPA being relative, and inclination in the
inertial. We now solved the problem by only allowing all parameters to be
either in the earth fixed frame or in the inertial frame. No more mixing!
One more question: defining an equatorial orbit going westward seems
to pose a
problem. I'm getting errors that the minimum step size is reached. Is this a
known issue?
Yes, perfectly equatorial orbits that are also retrograde cannot be
represented with the current implementation of EquinoctialOrbit. There
is an extension of EquinoctialOrbits that can handle retrograde
equatorial orbits, but it is not in Orekit yet (it will be in the
future). Meanwhile, if you use the current development version of
Orekit from the Git source repository, you can use the numerical
propagator with any orbit types, including Cartesian. Up to Orekit
5.x, numerical propagation always used EquinoctialOrbit internally, so
you hit the retrograde/equatorial problem.
The development version of Orekit depends on the development version
of Apache Commons Math, and will be released only when Apache Commons
Math 3.0 will be released, and this as not yet been decided.
So if you must have equatorial retrograde orbits, you must use both
development versions. If you can use only released versions, you will
not be able to handle equatorial retrograde orbits. I'm sorry about
this.
best regards
Luc
Kind regards,
Martin