A small question, for Gauss method they are three coordinates for the observer (i.e. one per measurement). Can the observer be the same (at three different epochs) or Gauss method needs three different observers at three different locations?
Best regards
Bryan
Hello @bcazabonne,
Okay I will open an issue whenever I can, thanks.
On the other hand,
The code I have shared implements 3 observations from one observing location. But it is also possible and easy to apply different observation locations as well. From the below figure given in the Orbital Mechanics for Engineering Students book of Curtis it can also be seen:
Here, having three observations from same or different locations would not create a problem, since capital R vectors will change either way with the rotation of earth.
Kind regards,
Baris
Hi there,
I haven’t looked at the code yet but I don’t understand what you mean by comparing it to Lambert and Gibbs. Unlike those Gauss is an angle only method. If you want to compare like for like, you need to use Laplace and Gooding.
Cheers,
Romain.
Yes you are right, and thank you for the feedback @Serrof . Let me elaborate and fix what I meant there. By using 3 observations and utilizing angles-only Gauss method, we can find the respective position vectors of the satellite.
These three position vectors can later be used in Lambert and Gibbs method to estimate an initial orbit. This was what I meant, and I am sorry if I caused any misunderstanding.
Warning about code: In the code, I tried to test my findings with the results of an example which Vallado shared (Example 7-2). There has been some time since this book was first published so Vallado uses earth parameters slightly different than what we use here in Orekit. Therefore, the capital R vectors we find via this code does not match with Vallado’s results. Although I’ve tested and verified that this is the case, any other user is welcome to test it again. Its a good practice (though time consuming 
).
After being certain about the source of this discrepancy I just overwritten these R vectors manually to get aligning results in the end.
Hello @Echulion,
I am translating what you wrote to resolve issue 982 on the gitlab, i have some questions about your code.
I understand that you followed the Vallado algorithm until the search of v2, where you switched on the algorithm 5.5 of Curtis book. Why did you chose to do that and not follow Vallado suggestion to try to use Gibbs or Lambert methods to find v2 ? Inversely, what not use Curtis algorithm the all time ?
Second i see that you truncated the Taylor serie function of f and g at the first order. Is it approximated like this in Vallado and Curtis but because it seems easier by hand. We could expand the all Taylor serie, or as Vallado suggests “that f and g functions should be used instead of the series coefficients”. What do you think of this ?
Finally, I am translating your code with 3 different positions and not one for now 
Cheers,
Julien A.
Hey @jasquier,
I saw earlier that you’ve started translating the code, its wonderful news! I will try to do my best and address your questions now.
Actually, I implemented both Lambert’s and Gibbs methods at the end of the code as Vallado suggests. The v2 result we get after applying Gibbs method perfectly matches with what Vallado provided in his example.
I cannot rightly remember now but I think that the data Vallado provided in his example was really on point to follow (in terms of verification at every step). So I started with his work. At some point in his example, he mentioned that the Gauss method formally ends once we found slant ranges. And since I’ve also found his v2 result applying Gibbs method, I wanted to see the v2 results of Algorithm 5.5 provided by Curtis. Long story short, I did not have any particular reason to switch between books, but you have every right to question this odd behavior. I would do the same tbh 
It would also be interesting to see the results following Algorithm 5.5. from start to end.
Yes, well Curtis ended up with the first order truncation of the series expressions, as he pointed out that if consecutive time intervals of observations are small enough, just first two terms could be retained. He also states that “we want to exclude all terms in f and g beyond the first two so that only the unknown r2 appears in equations”. So this first order truncation greatly reduces the computational work, and you can check it in the section “5.10 Gauss method of preliminary orbit determination” of Curtis.
Lastly, I couldn’t understand what you mean by this though, I am sorry.
Maybe you could also end the code translation once you found the slant ranges, as Vallado pointed out in his example. I think it makes sense that users ending up with slant ranges (or taking one more step, position vectors) using IodGauss class, since continuing further with velocity requires other IOD methods in play such as Gibbs or Lamberts methods.
Finally, it is wonderful to see that you are also improving the code by including 3 different observation positions! I thank you sincerely for your contribution 
Regards,
Baris
Hey guys,
I posted a comment on the gitlab issue but I’m rewriting it here for everyone. It’d be nice to be able to choose between the original, historical method of the Prince of Mathematics a.k.a. Gauss and iterative versions such as the one described in Vallado’s book.
Looking again at the IOD package, I made a scary discovery. I don’t see any Field version (my apologies if I missed it). Is there any particular reason for that appart from lack of time? In that case I will open an issue (if not already there, sorry I didn’t check) as I think it is very important to keep the gap between code for doubles and code for Field to a minimum. Maybe @jasquier since you’ve started working on IOD classes you’d be keen on tackling that? I’m tempted to say that one has not made a proper contribution to Orekit if one has not implemented some Field stuff 
Romain.
That’s true, there is no Field implementation of the IOD methods. The reason: nobody asked for it before
I agree with this comment.
Hey everyone,
I am sorry but I have never used Field implementations (or I don’t know if I used without knowing). Is there any source where I can check it out? If it is related with my field I could give it some thought.
Though my initial guess is, it is something that developers often deal with?
Field is the dark side of Orekit: powerful and dangerous.
Joking aside, fields are an extension of primitive double computations. In 99% of use cases, they are used to compute automatically derivatives alongside values of algorithms.
Many classes in Orekit have their Field counterpart. You can for instance compare CartesianOrbit to FieldCartesianOrbit. Other coordinates have their Field implementation, as well as propagators, measurement models, etc. You’ll see that it’s quite unreadable as unfortunately the Java language does not authorize operator overloading so “+” becomes “add”…
As Luc said, they are meant to represent classes which have their own algebra, the usual case being partial derivatives up to a given order. Check out Gradient and DerivativeStructure in Hipparchus for respectively the first and arbitrary order respectively.
Note that for partial derivatives, the so called Taylor map inversion can provide a workaround to a complete implementation of a given solver. See here for more details.
Romain.
Thank you for your explanation, I now have a rough image in my mind regarding Field stuff. I will still do my research further whenever I find time.
However, I feel like it is not something for me to worry about 
Hello,
Sorry I did not have a lot of time recently to answer to this topic, I will resume the work on the IOD gauss. @Echulion thanks for the explanation of your work
What I was suggesting, if I remember, was not to limit the f and g definition of the first order of the Taylor Serie and use the definition of f and g found in Vallado equation 2-69 page 87. It should be more precise but maybe the tradeoff between the greater time computation and the gain of precision is not worth it. Anyway for the issue I will just do it at the first order.
For the development of Field, I guess I will have to do it Moreover, there is some duplication in the IOD Laplace and IOD Gooding with the lineOfSight method (and also now in the IOD Gauss) so I was thinking maybe reworking and cleaning the IOD package creating an abstract class and daughter classes. I will also try to take into consideration the proposition of @Serrof of giving the possibility of choosing between different versions.
What was a small issue is kind of becoming a bigger work
Hi @jasquier,
revamping the IOD package sounds like a good idea.
I also noticed methods in Gooding that are redundant w.r.t. what is already in Hipparchus’ Vector3D.
About the Lambert solver, there is already an open issue (#748) on it and it could benefit from a re-implementation I think.
Cheers,
Romain.
Hello all,
So I completed the first part using the @Echulion values as a reference (congrats !) for the validation of my code, because I had the same issue with validating with the Vallado, and Curtis.
I will now work on refactoring the IOD classes and adding fields, so not for now for the merge request but sooner the better !
Hey @jasquier ,
Well done, congrats and thank you for your dedication and hard work! I am glad you’ve also reached same results as I have.
I wish you good luck with implementing field stuff!
Hello again,
I was wondering, why do all the IOD methods return a KeplerianOrbit? Is that because only the elliptical case (and not the hyperbolic one) is treated in general? Even so, I think it should return non singular elements so certainly not Keplerian ones… Thoughts?
Cheers,
Romain.
Hello @Serrof,
I’m not sure, I think it’s an oversight. In my opinion they should all return the generic type Orbit and not be limited to a specific type.
Now during the construction of the output orbit, instead of using KeplerianOrbit we could use for example CartesianOrbit. From what I’ve seen IodGibbs/Gooding/Lambert use PVs to construct a Keplerian orbit while a Cartesian would look more natural (Laplace already returns a Cartesian orbit).
You can open a bug but I think @jasquier is already taking care of this on his issue. Or maybe we should split since this would be an API-breaking modification ?
Cheers,
Maxime
Hello,
I am working on the iod package architecture so I will take care of the issue, as it was already identified with @MaximeJ. However, I tried to create a pertinent abstract class of the iod but all the iods have specific estimate method, even if looking alike. So it is hard without going deep into all the iods algorithms to do a good refactoring, and I have no time to do it right now.
About Fielding IOD Gauss, same I am stuck with the LaguerreSolver, which is not fielded, and so if I want to continue to field I will have to field a lot of things of Hipparchus about Solver, and same i don’t have the time right now, so i will put it aside for now.
So to summarise, working right now on the refactoring of the IOD architecture but not an ambitious one, putting aside fielding of IOD.
So maybe 2 issues to open about fielding the iod package + big refactoring of iod package.
Hello guys,
So to put an end to this topic, I ended the implementation of the IOD Gauss and refactored the IOD package with an Abstract Method “AbstractAnglesOnlyIod” because some features where shared between Gauss, Gooding and Laplace.
The AbstractAnglesOnlyIod method allows the factorisation of the same methods for Gooding, Gauss or Laplace : An IOD can be launched from 3 AngularRaDec measurements, from 3 PVCoordinates or 3 Vector3D at 3 different dates, from only one Vector3D or PVCoordinates corresponding the the station position (at a given date and given frame) giving the 3 targeted measurements dates and the 3 LineOfSights associated.
I added 2 methods to the AngularRaDec class to compute the LineOfsight : “getLineOfSight” if the LineOfSight vector required is at the date of the AngularRaDec measurement, and a “gestEstimatedLOS” if a LOS is requested at another Date.
I tried to refactor all the IOD package but Lambert and Gibbs were not suitable for a refactoring, as the methods are really specific each.
Finally, I tried to field everything but it was depending of the fielding of LaguerreSolver, and so was beyond my scope for this issue.
It is merged in develop right now and will be part of the v12.0, hopefully released soon. Should be bugless as the mighty @Vincent did the review !
Cheers,
Julien
