SOCIS » History » Version 17

« Previous - Version 17/41 (diff) - Next » - Current version
Michael Turner, 2012-08-04 12:48
light touchups on the text, mainly to provide proper paragraph sectioning


h1. SOCIS

In July 2012, ESA launched its Summer Of Code In Space (SOCIS) initiative. The main SOCIS site is located here: http://sophia.estec.esa.int/socis2012/.

The Orekit project proposes the following subjects to the students. Note that until the mentor application date has passed (2012-07-15) this list will be completed and updated, so if you are interested you can always come back to see new proposals. Also, if anyone has new subject ideas, do not hesitate to discuss them on the development mailing lists.

  • verify the OREKIT Java implementation of the Draper Semi-analytical Satellite Theory (DSST),
  • create a demonstration application with user interaction for Orekit features,
  • create a web application for orbit propagation with operational forecasts,
  • create a 3D visualization application for attitude,
  • extend the "space flight dynamics pocket calculator" application for Android mobile devices which was started as of SOCIS 2011

h2. Verify the OREKIT Java implementation of the Draper Semi-analytical Satellite Theory (DSST)

The purpose of this subject is to evaluate the DSST orbit propagator software currently included in the OREKIT open-source library with respect to the standard implementation of the DSST. The DSST standard is implemented in the Linux R&D Goddard Trajectory Determination System (GTDS) program. The OREKIT DSST is implemented in java and employs a decomposition strategy consistent with the object-oriented paradigm. The Linux R&D GTDS program employs the Fortran 77 programming language and the procedural paradigm.

The DSST replaces the conventional equations of motion with two formulas:

equations of motion for the mean equinoctial elements,

expressions for the short periodic motion in the equinoctial elements.

The DSST is based on the Generalizing Method of Averaging perturbation theory. Very complete force models have been developed for the mean element equations of motion and for the short periodic motion.

The DSST models have been tested in the GTDS program for geopotential fields as large as 50 x 50. The DSST includes the lunar-solar point masses and the solid Earth tides. Surface forces such as atmospheric drag and solar radiation pressure are included in the DSST via a numerical averaging approach. There is also a semi-analytical theory for the partial derivatives of the perturbed motion.

An interpolation strategy greatly assists in producing the mean elements, the short-periodic Fourier coefficients, the osculating elements, the perturbed position and velocity, and the partial derivatives at the output request times.

The Linux R&D GTDS DSST capability has been tested extensively against external sources of data including:

precision trajectories such as GPS,

precise observation data such as satellite laser ranging (SLR).

Because the OREKIT DSST software represents a very comprehensive evolution of the Fortran 77 DSST, the OREKIT DSST needs to be verified starting with the lowest level of functionality. However, the Fortran 77 DSST has been ported to a variety of platforms and the required verification process is well known:

The physical models (geopotential fields, time and coordinate systems, etc) need to be aligned between the computer platforms

and software environments whose DSST results are being compared.

We need a set of test cases that spans the present DSST functionality of the OREKIT.

The OREKIT DSST set of test cases will be of great value to the OREKIT project. These cases can serve as regression test cases when future refactoring of the OREKIT source is undertaken. Additionally, these test cases can serve as a starting point for the development of the expanded test cases necessary when additional functionality is added to the OREKIT DSST (for example, the short-periodic models) or when higher level functions are built that link to the Orekit library. Scripts should be developed to facilitate the execution of multiple test cases. All development should be done in the Java programming language and should require only free software libraries compatible with the Apache Software License.

The DSST test cases will be organized as follows:
* Zonal Harmonic Test Cases
* Tesseral Resonance Test Cases
* Geopotential plus Lunar-Solar Point Masses Test Cases
* Geopotential plus Atmosphere Drag Test Cases
* Geopotential plus Lunar-Solar Point Masses plus Solar Radiation Pressure

The resolution of the anomalies discovered during the verification process and the resulting improvement in the OREKIT DSST software will be an important aspect of this SOCIS project.

This project requires a good understanding of the java programming language and Eclipse Integrated Development Environment (IDE) for java. Particularly relevant is experience with the Testing and Debugging processes that are available for Eclipse java, especially the interactive Debugger.

While prior understanding of the semi-analytical satellite theory is not mandatory, some experience with mathematical analysis and a basic understanding of the notions of orbital dynamics and a willingness to dig further will be helpful.

There will be multiple mentors for this project. One of the mentors will be knowledgeable of Fortran 77 software for the DSST standard and the debugging process required for generating intermediate outputs from that standard software. There is a distributed aspect to this project and experience with applications such as WebEx will be helpful.

This project will provide a great opportunity for the student to learn about astrodynamic applications and modern computing platforms. This project is in accord with traditional astrodynamics which emphasizes the interface between physics, astronomy, and computer science. It is anticipated that this project will lead to a technical paper to be presented at a technical conference in the next year.

h2. Create a demonstration application with user interaction for Orekit features

Orekit is a low-level library. As such, it does not provide any visible user interaction and does not display anything fancy. It must be called by a higher-level application that configures it and provides it the initial data to propagate. It is therefore difficult to explain Orekit features and have new users play with it a little to get a sense of what it can do.

The purpose of this subject is to set up a calling application that can be used as a showroom for Orekit features. It is focused more on the input than on the output, i.e. it should be able to select features and run them quickly in front of an audience. The application should have both a set of predefined configurations showing specific features (orbit propagation, events, frames transformations, time scales, attitude ...) and allow users (even new ones) to change the settings and see immediately the effects of the changes. For each feature, links to example code, tutorials and documentation would be an interesting add-on.

The display part should not be the main concern, but it should not be neglected either. It should at least include some simple form-based results (a propagated orbit, an event occurrence report ...), tabular outputs (orbits and attitude ephemerides ...), curves and plots, and animated 2D views (satellite ground tracks, sensors footprints, ground station visibility circles ...). No 3D views are considered here (yet).

The work to be done will be split into nine work packages:
* select the features to be demonstrated,
* for each feature, find the most educational use cases to present it,
* identify the configuration parameters and set up reference scenarios,
* implement a top level application with graphical user interface to run these use cases with simple textual output,
* add tabular output for ephemerides,
* add 1D curves with some specific marks for discrete events,
* add 2D ground tracks,
* add sensor footprints and ground station visibility circles,
* add time animation and events triggering feedback

All development should be done in the Java programming language and should require only free software libraries compatible with the Apache Software License (i.e. strong copyleft licensed library should not be used, and weak copyleft libraries could be used only if not modified). The developed system should run on any operating system, or at least on GNU/Linux and Windows.

This project requires a good grasp of graphical user interfaces, both from a technical standpoint and from a user standpoint (ergonomics, intuitive use for users discovering the program for the first time as they pass in front of a demo booth or during a face-to-face encounter with the Orekit team).

h2. Create a web application for orbit propagation with operational forecasts

The purpose of this subject is to study the suitability of the Orekit library's various propagation modes in web applications.

Orekit provides several modes for orbit propagation (see https://www.orekit.org/static/architecture/propagation.html). The more classical one is slave mode: the propagator is the slave and the calling application is the master. In this mode, time evolution is entirely driven by the application and at each call the library computes one final state and returns it.

Another mode which is less intuitive but more powerful, more efficient and leads to simpler code is master mode: the propagator is the master and the calling application is the slave. In this mode, time evolution is entirely driven by the library and the application calls the library only once and lets the propagator drive time evolution and call it back at each step end, providing it a local interpolation model valid throughout the computed step.

The last available mode is ephemeris generation, where a first propagation is done by the library, then an ephemeris is generated and returned to the caller, and afterwards the caller uses the ephemeris and navigates at will throughout its time range, possibly going back and forth.

All these modes change the interaction schedule between the caller and the library. Handling all these modes is well understood for a standalone application with direct method calls. We would like to know how these modes scale in distributed environments, with a server performing the computations and a remote lightweight client connecting to it. A typical use case would be a tiny device (say a mobile phone) with limited computed capacity and no storage of large data requesting a computation of operational forecasts with full-blown accuracy and complete models to a server from the operational ground system.

The objective of this subject is to implement this use case using the three difference propagation modes and compare them.

The work to be done will be split into six work packages:
* design a Service Oriented Architecture (SOA) for the use case,
* select and set up the framework (middleware, server, client), using a standard desktop computer for the client at first,
* design a communication architecture for each propagation mode (slave, master, ephemeris generation),
* implement all three architectures,
* analyze and document ease of design and implementation for all architectures,
* analyze the performance of each architecture.

All development should be done in the Java programming language and should require only free software libraries compatible with the Apache Software License (i.e. strong copyleft licensed library should not be used, and weak copyleft libraries could be used only if not modified). The client system should run on any operating system, or at least on GNU/Linux and Windows. The server system should run on GNU/Linux.

This project requires a good understanding of distributed architectures and middleware. Complete understanding of what propagation modes mean is not mandatory, this will be explained by the mentor at project start, and only a basic understanding of the space flight dynamics notions will be needed to complete the task. It is more important to master the notions of communication scheduling and which patterns should be used (publish/subscribe, request/answer, streaming and out-of-band control ...).

h2. Create a 3D visualization application for attitude

Attitude simulation is a difficult task. It features non-obvious equations and has a lot of pitfalls.

As an example, many models are based on angles, but the plane inside which the angle is measured can be considered from above or from below, and it is easy to mix orientations and hence angle signs. Even using a vectorial cross product to compute a reference normal for a plane in which two directions are constrained will give one direction in half the plane, and the opposite direction in the other half, with an instantaneous switch when the vectors become aligned.

The results from a simulation are also difficult to analyze: the numerically stable quaternions are not human-friendly, and the human-friendly angles are both numerically unstable and still non-obvious as soon as some of the angles exceed π/2.

A great way to make sure an attitude definition corresponds to what users wanted is to display it in a graphical 3D view with many augmented reality hints. The aim of this subject is to develop such a graphical view.

We don't consider here only realistic views, with fancy satellite shapes moving above a beautiful Earth with photographic textures. This could be done, but the focus should be more on additional features that users should be able to switch on and off, while viewing the same from any side. These additional features should be vectorial directions from the spacecraft to some targets (ground-based, Sun, Moon, normals to reference planes, fixed directions, frame axes for several fixed and moving frames ...), planes (either as infinite translucent sheets or as a circle drawn on a transparent sphere surrounding the spacecraft), angular arcs between vectors, angular arcs between planes ...)

The work to be done will be split into four work packages:
* identify the useful display elements and how they can be defined by users,
* select and set up the 3D rendering technology compatible with the requirements,
* design and develop a prototype displaying at least vectors and angles,
* add more graphical features as time permits.

All development should be done in the Java programming language and should require only free software libraries compatible with the Apache Software License (i.e. strong copyleft licensed library should not be used, and weak copyleft libraries could be used only if not modified). The developed system should run on any operating system, or at least on GNU/Linux and Windows.

This project is difficult. It requires good understanding of 3D geometry, both from a computer science point of view for rendering and more importantly from a mathematical or geometric point of view. The notions of unit sphere, vectors, planes, normals, dihedral angles, planar angles, vectorial angles, orientation should be mastered in order to complete this project.

h2. Extend the "space flight dynamics pocket calculator" application for Android mobile devices which was started as of SOCIS 2011

Some space flight computations are needed all the time, for example to assess some orders of magnitude or check the consistency of an operational result. These computations are usually done by applying Keplerian formulas on standard calculators. This does not scale well for computing next visibility time, or to convert a TLE orbit to traditional Keplerian elements.

The aim of this project is to assess the feasibility of a small space flight dynamics application on mobile devices like Android tablets. We would like to know if it is possible to port the Java libraries (Apache Commons Math) and Orekit and to build a small application on top of them for touch screen devices to answer some simple questions: orbit conversions, impulse maneuver computation, orbit propagation, event detection ...

The work to be done will be split into six work packages:
* improve user interface (both input and output)
* update the application to latest Orekit and Android versions
* add orbit propagation features
* add impulse maneuvers handling
* extend 2D display with more features (meta-data, zoom, touch-screen forward/backward navigation in time...)
* evaluate basic 3D capabilities

All development should be done in the Java programming language and should require only free software libraries compatible with the Apache Software License (i.e. strong copyleft licensed library should not be used, and weak copyleft libraries could be used only if not modified). The development environment should run on GNU/Linux and the developed application should run on Android tablets.