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

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



On Wed, Aug 3, 2011 at 4:11 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
> 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:
>
>  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 ?

Basically, you can store data in the same way you do in plain Java,
you open a file in a folder where the application has the unix rights
to access, etc... The only question is where to store data on an
Android phone and there is three ways for that.

The first way is to bundle a .zip file into the final .apk file (an
apk file is the file you'll install on your phone/tablet). The
advantage is that you don't have to launch a HTTP download on first
launch, and it can be moved on the sdcard when the user wants to move
the application to the sdcard (except on pre-Android 2.2 phones which
don't support moving applications to the sdcard -- I haven't tested
this but it's not difficult to test). You just have a call to make
(it's named AssetManager), with the filename embedded in the .apk and
it returns an InputStream.

The second way is to use internal memory. The application has the
right to write in the folder /data/data/fr.cs.orekit.blah/data/ (and
you have an API call which gives you the exact path so it's future
proof :) ), so you just trigger an HTTP download on first launch for
instance and it's ok.

The last way is to use sdcard. If you say in the application manifest
that you require the permission "Read/write from the SDcard" (which
will be shown to the user when he'll install the app), the application
will have the right to open any file on /sdcard/ (it's better to use
the API to have the path on the SDcard). You can also use an other API
call which gives you a path like /sdcard/data/fr.cs.orekit.blah/ so it
doesn't mess the user's SDcard and this folder is also automatically
removed when the application is uninstalled.

I think the best way would be to use the sdcard, it's far more
flexible, lets the user the choice to put their own data files very
easily, and as a lot of Android phones don't have a lot of internal
storage it makes the user happy :) The first way would be the best if
you want to be stuck with one default file which is often used and
just use custom file on the sdcard from time to time.

You can also open a SQLite database anywhere the application has unix
rights, but that's not mandatory.

> 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).

Ok I'll do that.

>> 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) :
>>
> 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're right, toString() outputs degrees and I was inputting radians.
After converting, it returns the correct result. Thanks! :)

> 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 ...

I'll think about how I can do this in the future Android UI (it's more
how I can add the different stations that outputting the final table).

> We would prefer the maneuver date to be absolute rather than relative to
> initial date, though.

Commited :)

> 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).

If I understood correctly, a local orbital frame is a little bit like
the TopocentricFrame (which was centered on the station in
VisibilityTest and moved with the earth), but centered on a satellite
and translating/rotating with the satellite, am I right ?

> 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.

Ok :)

Alexis