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

Re: [Orekit Developers] [SOCIS 2011 | Android] Status of the test application

Alexis ROBERT <alexis.robert@gmail.com> a écrit :


Hi,


Hello Alexis,



As I said in my previous message, I'm working on a text-mode test
application just to see if I ask the correct parameters and to see if
I correctly understood how Orekit works. The idea is to make it manage
everything asked for the final Android application with all the
settings which will be asked in Android application.

Thanks to all the people in the Orekit team, there is a forge for the
SOCIS 2011 project, available here :
https://www.orekit.org/forge/projects/socis-2011 so you can get the
source code using git.


You're welcome.



You can build the test application as a typical Eclipse project (you
may need to change the absolute paths to orekit and common-math jars).
I see you use the Autoconfiguration feature from the tutorials. This is fine for a first quick setup but should be removed soon. There are two reasons for that: 

 1) this feature was only intended for the tutorials and to allow first time
    users to have an almost immediate setup so they can play with the library.
    As such, it does not scale to real-life applications or special data
    settings.

 2) one of the things we would like to test with this Socis project concerns
    data handling. How should it be done to integrate smoothly as any other
    android application ? I have seen somewhere many android applications use
    a small database (sqlite-based if I remember correctly). Should we use
    this ? If not, how should we set up our data, I guess there could be a
    two-fold approach, some of the data being in a dedicated folder on the
    sdcard where user could put his own data sets, and some of the data being
    downloaded directly from the web (for example in a dedicated download
    area on Orekit site) as these devices are often connected.

What approach would you choose and why ?


If you want a runnable JAR snapshot, I can give you one, just ask me
:) The test application should do the tasks asked in the original
SOCIS idea on the Orekit's wiki, such as orbit conversion, visibility
test from a ground station and impulse maneuver computation (revision
d8816904).


I have tested it, and found no obvious problems. Good work.
Some of the parameters that user should be able to set are the gravitation coefficient (mu) and the inertial frame in which orbit is defined. For these parameters, a few default values should be available. For example typical mu values are given by a few important gravity fields models like EGM96, Grim5 or Eigen, but users may find useful to set up their own mu for a specific run, and may want to configure a default mu they often use in some user preferences settings. Concerning the frame, we should provide a selectable list with the predefined frames that are inertial (see the enum org.orekit.frames.Predefined, the method org.orekit.frames.FramesFactory.getFrame(Predefined) factory method and the org.orekit.frames.Frame.isPseudoInertial() predicate method). 



* Orbit conversion : I don't currently convert from other kind of
orbits to TLE as I didn't found any way to do this in the Orekit API
(maybe I haven't searched enough), but conversion to TLE should work.
TLE conversion is very specific as TLE are specifically linked to one propagation model: SGP4/SDP4, so some filtering must be done. We will set this conversion aside at first, and go back to it if we have enough time. 


I have a little problem here, when I convert to an other orbit type
and back, I always get different values. For instance (using the
values in the VisibilityCheck tutorial) :

cartesian parameters: {P(-6142438.668, 3492467.56, -25767.2568),
V(505.8479685, 942.7809215, 7435.922231)}
=> keplerian parameters: {a: 7069220.386682823; e:
4.7773560605573003E-4; i: 98.18525099174988; pa: 13.741061002484;
raan: 150.34825333049; v: -13.952151446377911;}
=> cartesian parameters: {P(6678075.265811305, -2061220.4235367593,
1058183.5469654775), V(-811.5757877856272, -5310.96037055833,
-5246.935091790779)}
Small differences are expected (last few digits), but not large differences like these ones! Are you sure there are no units problems (typically like degrees/radians conversions) ? Orekit uses only SI units, i.e. m, m/s, rad, rad/s, kg, s ...
You can look at the unit tests from the Orekit library itself to debug, as these tests have already been validated. 



--

cartesian parameters: {P(-6142438.668, 3492467.56, -25767.2568),
V(505.8479685, 942.7809215, 7435.922231)}
=> circular parameters: {a: 7069220.386682823, ex:
4.640624024164525E-4, ey: 1.1347861453554246E-4, i: 98.18525099174988,
raan: 150.34825333049, alphaV: -0.2110904438939327;}
=> cartesian parameters: {P(6675791.679616528, -2060515.583546613,
1057821.6981928425), V(-809.9979252320031, -5313.349791618699,
-5248.435897099367)}

--

cartesian parameters: {P(-6142438.668, 3492467.56, -25767.2568),
V(505.8479685, 942.7809215, 7435.922231)}
=> equinoctial parameters: {a: 7069220.386682823; ex:
-4.5943365025280937E-4; ey: 1.3096576006275438E-4; hx:
-1.00299611012708; hy: 0.5709798956859086; lv: 150.1371628865961;}
=> cartesian parameters: {P(6154945.399984764, -3340147.482146172,
989070.1001473623), V(399.397286380678, -1444.6395330257305,
-7354.513659130439)}

I hope it's correct, but that seems strange. Maybe all the conversion
thing I did is wrong, but I reviewed the code multiple times and I
don't know what could cause that (except when I'm saying that the
toString() attribute outputs TRUE position angle type, but that's what
I understood in the Orekit API documentation).
The toString method is mainly useful for debugging, as debuggers do use it when you look at a variable. This method *does* convert angles to degrees, whereas the API itself does not. 



* Visibility test from a ground station : It's basically a copy/paste
of the code present in tutorial/, with prompting the values from the
command-line instead of using only predefined constants.
I tried to play a little with it but did not found good initial data, so I'll have to check it more thoroughsly later on.
What could be done is to create some table with all spacecraft passes. Each row would correspond to an interval during which the satellite can be seen from one station. Each row would have 3 columns : the station name or id (stations are often abbreviated with 3 or 4 letters mnemonic like KRU for Kourou, AUS for Aussaguel, HBK for Harteebesthoek ...), the AOS (Acquisition Of Signal, or visibility start) time and the LOS (Loss Of Signal, or visibility end) time. It should be possible to have several stations in one run. Some additional optional features could be to have also a visibility duration (i.e. duration between AOS and LOS), to have the max elevation during the pass, to have Doppler at AOS and LOS ... 



* Impulse maneuver : I don't know if it's what is requested, but I've
handled this by asking a start date & maneuver length (in sec),
stopping the simulation at initial_date + start_date + maneuver_time
and showing the current orbit parameters just after the simulation
stopped.


Yes, this is what we wanted.
We would prefer the maneuver date to be absolute rather than relative to initial date, though. Also the maneuver is not always defined in the same inertial frame as the orbit, but sometimes is in a Local Orbital Frame (see org.orekit.frames.LOFType and org.orekit.frames.LocalOrbitalFrame). 



As I don't know how to find data to test it, I may did some mistakes I
didn't noticed but I hope this app works :) I may also be wrong in
understanding how this works, just tell me so I can fix this :)

Ask me if you have any idea, if you think that I ask one parameter
which is useless (or if you want one more), or anything :)
Pascal and myself did some brainstorming about what we wanted yesterday. We will set up a more detail specification. We will ask you to review this specification and help us decide on what can be achieved and what cannot be done in the time frame you have. So we will have first a few iterations on these specifications before you can really start real coding). Unfortunately, I am not at my office today, so we will not be able to post this to the list before at least tomorrow.
In the mean time, could you set up a few guidelines on the wiki on how to go from an eclipse project running on a dsktop to an application running on a device. This could be simple pointers to the appropriate online documentation, with a step by step example using Apache Commons Math, Orekit and your first sample application as an example. 



Have a nice day


best regards,
Luc



Alexis






----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.