Re: [Orekit Users] transformation

[Martin Spel <martin.spel@rtech.fr>]

OK, I think we can live with the limitation for the time being.
Thanks for the info!

Martin


Le 9 oct. 2011 à 21:38, MAISONOBE Luc a écrit :

> Martin <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
>> 
>> 
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
>