RTS2 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
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 [[code:xmlrpc|XML-RPC wiki page]]. Also see description of current [[doc:gui|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 [[http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampDoc|SAMP]]. We expect various team members will pick different areas.

What we expect:

  * configurable interface to display (using various fancy displays - bars, gauges,..) and change variables, display events, notification and warnings, and display and modify scheduling database.
  * 3D telescope visualisation, with interface to describe various system attached to the telescope and describe its status, failures etc..
  * plotting of history of selected variables (temperature,..), similar to what [[http://finance.google.com|Google]] provides for finance or [[http://meteo.othello.ch|Meteo]] provides for meteo data display
  * display observations, images related to observations,..

====== RTS2 Web ======

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

Profile: [[http://gwt.google.com|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 ======

[[ideas:Better scheduling]]

====== Advanced scripting ======

[[ideas:Advanced scripting]]

====== Database improvements ======

We need to improve database design. Current summary is given at [[devel:database_structure|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.