This section depicts what is missing inside RTS2. In states expected human (and other) investments, profile of people doing that and a brief description of the problem. If somebody will be interested in taking a problem and solve it, we will move it to extra page under ideas: namespace and provide a link there.

Final integration of meteorite detection code to RTS2

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.

Transient pipeline

Will be provided by Pi-of-the Sky, expected to be integrated by end of 2008.

GUI

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

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

For description of XML-RPC interface, please see XML-RPC wiki page. Also see description of current GUI there.

As astronomers are strange beasts, it must be multi-platform (at least Windows + Linux, Mac highly recommended). We do not expect it will be feasible to code all as Web application - standalone application is preferred. The application might integrate various programmes (image display,..) with SAMP. We expect various team members will pick different areas.

What we expect:

RTS2 Web

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.

Comparsion of various XML-based interfaces for remote telescope

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.

Scheduling

Better scheduling

Advanced scripting

Advanced scripting

Database improvements

We need to improve database design. Current summary is given at there. Database was originally developed as a quick hack, and the project grows of the original scope. It is clear that we will need to improve our current design. The work should provide summary of a current state, and should try to draw a new design.