User Tools

Site Tools


ideas:development_topics

This is an old revision of the document!


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.

GUI

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. Code is at SVN http://rts-2.svn.sf.net/viewsvn/rts-2/trunk/pyrts2, to get it and run it execute:

user@host:~$ svn co https://rts-2.svn.sf.net/svnroot/rts-2/trunk/pyrts2
user@host:~$ cd pyrts2
user@host:~/pyrts2$ ./pyrts2.py

You will need python-gtk2 installed:

user@host:~$ sudo apt-get install python-gtk2

And you need to have rts2-xmlrpcd running.

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

Advanced scripting

The current scripting model proved too difficult to maintain. Hence we are looking for new scripting part of RTS2. It shall be fully integrated. It should provide language specification, so we can easily extend language with new features.

The language must provides constructs for:

  • loops (for, while,..)
  • blocks which execution is based on some external factors (if acqusition is sucessfull, telescope error drop bellow some amount,..)
  • manipulation devices variables
  • executing and possibly queuing commands to devices
  • waiting for system to reach some state (exposure possible,..) with possible timeout
  • procedures and functions with parameters
  • functions to perform various system tasks (copy files, call external programs in background,..)
  • including of “libraries”
  • calls to generate exceptions, which will be catched by RTS2 and resulted in script premature end
  • logging calls to log script progress
  • comments inside scripting language

The idea is that the language will provide variables manipulation routines (including creating customs variables). The variables can be some “strange” astronomical quantities, e.g. error introduced either in degrees, arcminutes or arcseconds - distinguished by d, ', and “ suffix.

Input of the processor is string stream containing script. Its output is a binary sequence of commands, which will be executed by RTS2. There is an example of definition command to execute exposure:

int exposure (camera, length)
{
       waitforSystemState(EXPOSURE_POSSIBLE);  // will wait for system to reach state when exposure is possible
       camera.EXPOSURE = length;               // set camera variable EXPOSURE
       camera.executer("exposure");            // execute command on camera
       system.log ("exposure started on camera " + camera + " with length " + length);  // log command execution
}

and there is a call which include library, and call 10 seconds exposure:

include exposureLibrary;
exposure (C0, 10)
ideas/development_topics.1226064617.txt.gz · Last modified: 2008/11/07 00:00 (external edit)