Expected costs: 1 student, 1-2 weeks

Profile: image processing, C++, Subversion

I have meteorite detection code for RTS2, however it is not integrated in RTS2. The task of the student would be to take the code, merge it with current RTS2-related pipelines, fix bugs and run it on our widefiled CCDs.

The work may be extended so that it would take advantage of the WCS (pixel→world) calibration to provide direct 3D resolved result if observed from more than a single camera.

Expected costs: 1-3 students, 2-6 months

Profile: GTK, PyGTK ideal, XML-RPC, Subversion, GUI design, user documentation

There is prototype implementation of GUI, however I do not have time to finish it. It is in PyGTK, uses XML-RPC to communicate with RTS2. I am able to give away code and provide guidance what shall be implemented.

Expected costs: 1-3 students, 2-6 months

Profile: Google Web Toolkit, Web interface design user documentation, Subversion

There is a prototype implementation of RTS2 web, which have some limited functionalities. I would like to see extension of this piece of software which should result in usable and useful WWW interface for RTS2.

Expected costs: 1 student, 3 months

Profile: computer science theory, C++, Subversion

We went through an interesting history none → SOAP → XML-RPC regarding external access to RTS2. I just recently read through Atom specification, which is widely used by Google (so that was not XML-RPC - my mistake) and do not know if that is what we wanted. I like few characteristics of Atom, but dislike few others (apparent lack of C++ library to handle Atom requests is most probably the most serious one). The tasks of this mainly theoretics work is in comparing those various possibilities, try/use simple implementation with RTS2 and compare them.

Expected costs: 1 student for 6 months

Profile: process scheduling (mathematics or computer science), some programming

I am currently working on making ultimate scheduling, which would fulfill all the expectations we have. Having somebody else working on some topics, but using different algorithms (I am using genetic algorithms as this is required) could be useful and surely beneficial for both parties.

Under scheduling we understand a process of allocating observing time to various tasks (targets) based on their coordinates (i.e. accessibility and airmass), current observing conditions (sky brightness, seeing), priority (group-fair-time-allocation, priority within group) and absolute time (fixed time specified, periodic observation needed). The solution may be obtained by evaluating a certain merit function on the fly during the observation, or by passing through all the available choices using brute force and choosing the best. There are points of essential importance needed to be able to fulfill the task:

1. A good definition of how to observe (i.e. signal-to-noise/exposure time request from the user), and
2. Resultant script execution time (estimate) at the telescope must be known, and
3. How to decide whether and how much succesful was the observation (it's minimum quality and bonuses if it's better i.e. the merit).

RTS2 scripts already do contain a good definition of the first point, however, some information needed is missing (selection criteria, the owner) and some is present only in the database (coordinates, priority). I (mates) believe, that a good definition of the target could be achieved by extending the script into a more complex target description which would, in a human-and-machine readable form, contain all the information needed to plan, execute, and evaluate the observing request.

I believe that having this target description well defined is one of the essential prerequisities of a good scheduler.