[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Users] 0.1 deg Inclination bias?


"Hammel, Gregory (ASC/CSA)" <gregory.hammel@canada.ca> a écrit :


Hello Luc,
Do you believe that the 0.005 deg inclination error in the fit is a step-size issue? Have you observed this? 

I don't know, I did not encouter this.
One to two months is definitely doable. Launch is (currently) in November so we have time. My plan for now is that when we need to target sma/ecc we will use the fit method (given that it provides a much more stable sma) and when targeting inclination we will use the simple computeMeanState method for the more accurate inc. If a fix is available that can correct this inclination issue, then I will go over to using the fitting process for all targeting. 

Good to see you have found a workaround.
I'm still not convinced that the inclination problem is not mine (unless you tell me its a known issue) so I would be interested in seeing what a DSSTPropagatorBuilder (and associated conversion code) would look like from the current release of Orekit if anyone has already done this. 

I'm not sure a lot of people have exercized  DSSTPropagatorBuilder.
Several people use the Orekit implementation of DSST, but from the
questions we have seen on the lists, it seems mainly for station
keeping and using conversions from/to osculating elements to share
data with other operational applications. So it may well be a problem
in the builder.

Also note that our implementation of the DSST is clearly not optimal
yet, it is really much slower than it should. It is a known problem,
and this problem is specific to the Orekit implementation.
We will address it but this performance problem is not our priority
yet (as long as nobody complains too loud).

best regards,
Luc



Thanks,
Greg
___________________________________________________
Gregory Hammel
Analyste de la dynamique de vol
Contractuel SED a division of Calian Ltd. Utilisation de l’espace
Agence spatiale canadienne / Gouvernement du Canada
gregory.hammel@canada.ca / Tél.: 450-926-5138

Flight Dynamics Analyst
Consultant SED a division of Calian Ltd. Space Utilization
Canadian Space Agency / Government of Canada
gregory.hammel@canada.ca / Tel.: 450-926-5138

________________________________________
From: orekit-users-request@orekit.org <orekit-users-request@orekit.org> on behalf of MAISONOBE Luc <luc.maisonobe@c-s.fr> 
Sent: Friday, July 27, 2018 9:16 AM
To: orekit-users@orekit.org
Subject: Re: [Orekit Users] 0.1 deg Inclination bias?

Hi Greg,

"Hammel, Gregory (ASC/CSA)" <gregory.hammel@canada.ca> a écrit :


I've modified the positionScale on the AbstactPropagatorBuilider to
as low as 1e-7 but found that if I go below 1e-5 the outputs begin
getting very inconsistent (I'm stepping along an ephemeris in 10 min
increments, performing a 24-hour fit starting at each point to see
how stable the outputs are). At 1e-5 the inclination variation is
only +/- 0.0001deg, but at 1e-7 it increases to +/- 0.008 deg -
nearly 2 orders of magnitude . So 1e-5 seems to be the lower limit,
but inc still has the 0.005deg offset.


I have an intern working on a DSST-based orbit determination. His work
implies that DSST propagator and associated builder will be able
to compute partial derivatives and hence to be used with
JacobianPropagatorConverter. This should remove the needs for
finite differences and the problem of step sizes.

The work is going well, and we are already able to compute the
partial derivatives of both the mean elements and also for all
the short periodic terms (which I think is new). However, this work
is not complete yet, and the link with JacobianPropagatorConverter
has not been done. We expect this to be available in the time
frame of one or two months.

Would such a feature helps you and could you wait until it is
available?

If you want to play with the current status, you can see it
in the dsst-od branch in the git repository. Take care it is
still work in progress!

best regards,
Luc




Greg

___________________________________________________
Gregory Hammel
Analyste de la dynamique de vol
Contractuel SED a division of Calian Ltd. Utilisation de l’espace
Agence spatiale canadienne / Gouvernement du Canada
gregory.hammel@canada.ca / Tél.: 450-926-5138

Flight Dynamics Analyst
Consultant SED a division of Calian Ltd. Space Utilization
Canadian Space Agency / Government of Canada
gregory.hammel@canada.ca / Tel.: 450-926-5138
________________________________
From: orekit-users-request@orekit.org
<orekit-users-request@orekit.org> on behalf of Ward, Evan
<Evan.Ward@nrl.navy.mil>
Sent: Thursday, July 26, 2018 12:09 PM
To: orekit-users@orekit.org
Subject: Re: [Orekit Users] 0.1 deg Inclination bias?

Hi Greg,

On Thu, 2018-07-26 at 14:35 +0000, Hammel, Gregory (ASC/CSA) wrote:

So, I have found the source of my 0.1deg error - it was a reference
frame issue that I had missed (was passing a TOD vector but telling
the Draper code it was J2000).

I have taken the step to using the conversion process because the
sma noise on the Draper propagation is larger than I would like.
However, while my results are providing very good sma's,
eccentricities and argument of perigees, I seem to have a "twist" in
my orbit. Both the inclination and RAAN are off by ~0.005 deg. I've
double checked against the osculating values and this is definitely
not correct. The upper end of the osc inclination is 97.765deg which
is what my fitted mean inclination is at.

I've run the Draper propagator alongside the fit in the same code,
so I've eliminated any possible errors in initial state, EOP data,
reference frame, etc. When I do this, I am seeing inc values from
the propagator of 97.760 deg, which is what I would be expecting.
I've poured over my code and can't see where the problem is, but I'm
sure its something I'm doing wrong - I just can't see it. I'm very
new to both Java and Orekit so there is probably some fundamental
mistake I'm making, but its not clear.

Has anyone else build a Draper propagator builder? Any traps I may
have fallen into that I should be wary of?


Have you checked the step size of the finite difference?  It is hard
for the FiniteDifferencePropagatorConverter to achieve better
accuracy than the finite difference step size. The step size is the
scale factor for each parameter that is solved for (selected). 0.005
deg is about 1e-4 rad. So a step size of 1e-4 on an angular
parameter might result in this behavior. Just a thought.

Best Regards,
Evan


One of the things I'm doing is using the FiniteDifferenceConverter
and then casting it as a DSSTPropagator as follows:

PropagatorConverter fitter = new
FiniteDifferencePropagatorConverter(builder, 1.e-6, 5000);
DSSTPropagator meanprop = (DSSTPropagator)fitter.convert(ephemeris,
86400, 251);

Where "builder" is the DSSTPropagatorBuilider that I created and
ephemeris is a BoundedPropagator osculating input. Is this valid?

Any help, insights, pointers would be greatly appreciated. If I can
get this sorted out this will be a very powerful tool for our
upcoming mission. But a 0.005deg offset in inclination and RAAN will
be difficult to work around.

Thanks,
Greg
___________________________________________________
Gregory Hammel
Analyste de la dynamique de vol
Contractuel SED a division of Calian Ltd. Utilisation de l’espace
Agence spatiale canadienne / Gouvernement du Canada
gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca> / Tél.:
450-926-5138

Flight Dynamics Analyst
Consultant SED a division of Calian Ltd. Space Utilization
Canadian Space Agency / Government of Canada
gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca> / Tel.:
450-926-5138



________________________________________
From:
orekit-users-request@orekit.org<mailto:orekit-users-request@orekit.org>
<orekit-users-request@orekit.org<mailto:orekit-users-request@orekit.org>> on
behalf of MAISONOBE Luc
<luc.maisonobe@c-s.fr<mailto:luc.maisonobe@c-s.fr>>
Sent: Thursday, July 19, 2018 2:35 PM
To: orekit-users@orekit.org<mailto:orekit-users@orekit.org>
Subject: Re: [Orekit Users] 0.1 deg Inclination bias?

"Hammel, Gregory (ASC/CSA)"
<gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca>> a écrit :



Hello Luc,

Thanks for this. This was actually going to be my next question -
how to use LS to convert from osculating to DSST - was digging
around the estimation project and was starting to run into a brick
wall at the PropagatorBuilder. I didn't realize that my two problems
may be actually only one.

If this is the source of the problem, then what purpose does the
DSSTPropagator.computeMeanState function serve? Is is intended to be
a quick way to get mean states when precision isn't required?



No, it is really intended to do what you want, but using only
DSST models, not converting models at the same time, i.e.
without a "first propagation" from another model beforehand.

Some other things you could check are the difference between mean
and osculating, i.e. the amplitude of the short periodic
terms and the evolution rate of the mean elements, and compare
this to the 0.1° you see. It may help understand what happens.

best regards,
Luc




Will give this a go. Thanks,

Greg
________________________________________
From: orekit-users-request@orekit.org<mailto:orekit-users-request@orekit.org> 
<orekit-users-request@orekit.org<mailto:orekit-users-request@orekit.org>> on
behalf of MAISONOBE Luc
<luc.maisonobe@c-s.fr<mailto:luc.maisonobe@c-s.fr>>
Sent: Thursday, July 19, 2018 2:08 PM
To: orekit-users@orekit.org<mailto:orekit-users@orekit.org>
Subject: Re: [Orekit Users] 0.1 deg Inclination bias?

"Hammel, Gregory (ASC/CSA)"
<gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca>> a écrit :



Hello,



Hi Greg,




This is my first post to this list, so I would just like to start by
thanking everyone who contributes to this project. Its an incredible
resource.


I am trying to use Orekit for mean state generation for
stationkeeping using DSST. To that end I want to take in a vector
from an external source (in this case, STK) read it in, propagate
it, including manoeuvres, and then use DSST to get pre and
post-maneouvre mean states. If I take a J2000 vector and provide it
to DSST to get a mean state, I get an inclination of 97.75 deg.
However, if I first propagate that same vector and then pass it
through DSST I get an inclination of 97.65 (in this case, without
any manoeuvres).


I'm using the same methods as outlined in the "MasterMode.java"
tutorial for my "pre-mean" propagation, but I've modified it by
including solar and lunar grav and DTM2000 drag.


Can anyone explain why there is a 0.1 deg shift in the inclination?
I can provide the code if it helps.



If you convert starting from a single state vector, and change from
one propagator to another one, you can have this sort of problems.

I'll suggest to look at the propagation.conversion package and
at the associated test cases to do the conversion from a full
time range (say one or two periods) instead of a single state
vector. What this package does is a fitting, trying to ensure
the trajectories stay close to each other, in a least squares
sense.

Hope this helps,
Luc





Thanks,

Greg Hammel

___________________________________________________
Gregory Hammel
Analyste de la dynamique de vol
Contractuel SED a division of Calian Ltd. Utilisation de l'espace
Agence spatiale canadienne / Gouvernement du Canada
gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca> / Tél.:
450-926-5138

Flight Dynamics Analyst
Consultant SED a division of Calian Ltd. Space Utilization
Canadian Space Agency / Government of Canada
gregory.hammel@canada.ca<mailto:gregory.hammel@canada.ca> / Tel.:
450-926-5138