SOCIS » History » Version 20

« Previous - Version 20/41 (diff) - Next » - Current version
Michael Turner, 2013-07-24 13:09
a few minor typo and grammar fixes, should really be checked because I didn't understand everything that I "fixed"


h1. SOCIS

Starting a few years ago, ESA has been holding an annual Summer Of Code In Space (SOCIS). The main SOCIS site for year 2013 is located here: http://sophia.estec.esa.int/socis2013/.

The Orekit project proposes the following projects for students. Note that even after the mentor application date (2013-06-20T23:00:00Z) expires, this list will be updated. So if you are interested you can always come back to see new proposals. Also, if anyone has new project ideas, do not hesitate to discuss them on the development mailing lists.

Here is the current list of ideas:

  • 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
  • Take acceleration into account in frame transforms
  • Add smooth transition laws between attitude laws

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 project is to set up a calling application that can be used as a showcase 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. no strong copyleft licensed library should 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 project 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 project 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. no strong copyleft licensed library should 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 project 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. no strong copyleft licensed library should 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. Take acceleration into account in frame transforms

Space flight dynamics involve numerous frames and lots of transforms between them. There are quasi-inertial frames in which orbits are propagated (geocentric ones, heliocentric ones, some with fixed alignments with respect to reference quasars, some with very slow rotation like precession and nutation effects.) There are body-fixed frames in which all computations relative to Earth observation or ground stations are performed. There are moving frames relative to various spacecraft sensors. Users can also define their own frames ...

In order to transform coordinates between these various frames, Orekit uses a generic approach were each frame is linked to its parent frame with a dedicated TransformProvider that is able to recompute the relative position and orientation and its first time derivative depending on context. Some providers are simple ones, for example constant providers when a frame is defined by a constant rotation with respect to its parent. Some are very complex, for example when precession, nutation and external corrections are to be handled. In all cases, a temporary Transform object is created, which is a simple container for translation, rotation and their first derivatives. A general algorithm converts coordinates between any two frames by walking the frame tree and combining all individual transforms together.

Up to now, neither the Transform object nor the general algorithm takes second derivatives into account. This means we can transform positions, velocities, angles and angular rates, but neither linear nor angular accelerations.

The aim of this project is to add second order derivatives to this framework.

The work to be done will be split into four work packages:

  • Identify the scope of the change within Orekit (obviously the Transform class will be changed, but probably some other interfaces and classes like PVCoordinates may be affected),
  • Add second derivatives attributes to all needed classes,
  • Implement acceleration composition (linear and angular) to the general composition algorithm,
  • Add acceleration initialisation for spacecraft state in the simple case of numerical propagation, as is is already computed and available and simply needs to be stored

h2. Add smooth transition laws between attitude laws

The attitude of a spacecraft represents its orientation around its center of gravity. The attitude changes over time according to prescribed attitude laws in order to ensure
the spacecraft observes some desired targets or to ensure its solar arrays are correctly oriented with respect to the Sun for example. The latest version of Orekit does handle
attitudes sequences, i.e. it is possible to have a spacecraft switch from one attitude law to another attitude law when a triggering condition (some user defined discrete event)
is met. This switch is however an instantaneous switch, which is not realistic.

The aim of this project is to provide a smooth transition feature between two attitude laws. Various boundary conditions should be available: simple linear slew when only orientation
is considered or higher degrees polynomials when rendezvous is also done on angular velocity, acceleration or jerk. It should be possible to specify either a fixed time to go from one
attitude to the other or find the smallest possible slew duration that respects some constraints like maximal angular velocity or maximal acceleration.

The work to be done will be split into five work packages:

  • Analyse the current attitude sequence implementation
  • Perform a trade-off between transitions implemented as an internal feature of the attitude sequence class or as a dedicated mode that the user should insert in the sequence
  • Implement a prototype fixed-time linear slew as a first proof of concept
  • From lessons learned from the prototype, design a transition mechanism supporting degrees 2 and more, still in fixed-time
  • Modify the previous mechanism to support minimal transition time while fulfilling max angular rate/acceleration constraints