While remote and robotic telescopes have been in use for quite some time, current tech allows taking up such projects even on a tight budget. Wherever you are considering costs though, there is a need to prioritize certain aspects of the project, which might mean having to choose certain functionality. Hence the question: having a go at building such a telescope (theoretically) and leaving specific project goals aside for the moment, what features you consider the most important and/or desirable?
Well, it really depends what you want to do with the telescope. A robotic amateur telescope might need only the ability to go to approximately the right patch of sky and take an exposure of appropriate length. A robotic professional telescope is going to need much more: ability to take dome flats, control of the field derotator, ability to switch instruments, et cetera - not to mention control of any adaptive optics hardware. On the other hand, a professional telescope might well offer a lower-level scripting interface, so that observers can write scripts to control it, while an amateur telescope needs to make the control as simple as possible. One key non-obvious feature is a detailed log that records all telescope actions, so that it's possible to reconstruct what actually happened afterwards (as opposed to what was supposed to happen).
Yes, logging is definitely one of the overlooked features that seem obvious when they're pointed out to you. Good point.
Another feature that can matter is pointing accuracy: I once used a (robotic) telescope whose pointing accuracy was poor enough that you had to take a preliminary exposure or two and compare to a finder chart. This obviously limits the possibilities for unattended operation (though if I recall correctly there are automated tools that will take a sky picture with a decent number of stars and tell you where it was pointed).
Another good point, as even a good pier setup and mount/scope alignment will only work to a certain degree, which in unattended mode will definitely require some astrometric guiding, unless it has a really wide field (which obviously is not always the best case).
There are several working robotic telescopes at the moment which are used by the community. These telescopes have been producing very good quality results and their respected pages include some of the technical hardships that the supporting staff have gone throughout the years.
The Liverpool Telescope: http://telescope.livjm.ac.uk/
Osservatorio Astronomico di CampoCatino: http://www.campocatinobservatory.org/
There is also a global network of Robotic Telescopes. You can learn about more telescopes and additional details by visiting this link: http://lcogt.net/network
Although this isn't what I had in mind asking, it's nonetheless helpful. Will check those sites out, thanks.
I suppose it's worth asking: just what did you have in mind when you asked about robotic telescopes?
By one standard, practically every major telescope is robotic, in the sense that the control interface is a scriptable computer program. But these interfaces are usually set up so that planning an observation requires carefully scripting out every action, perhaps up to and including taking a mosaic of offset images to alleviate the effect of chip gaps and noisy pixels. A few telescopes, like those linked by Tigran Khanzadyan, have more substantial automation; one example is PROMPT, a set of telescopes designed to respond very rapidly and without human intervention to supernova detections in order to obtain multicolor magnitudes as soon as possible. Designing such a highly-automated system is far from easy and probably involves certain hardware decisions to simplify calibration and other tasks.
I asked the question mostly to check which features or characteristics you consider essential and which come to your mind first. It's clearly a different kind of information from design specs and operation manuals, yet equally (if not more) important during the process of designing a new instrument. Hence the very general nature of the question. Cheers.
It doesn't mean the discussion is over, though. I appreciate any input. :)
I gues one of the most important aspects in set-up of the robotic telescope would be your budget. I don't mean your immediate budget. You could plan many things and act accordingly on what and when to dedicate. This is similar dilemma with any kind of telescope. Usually you choose a telescope design as flexible as possible in order to build-up in the future. Those big telescopes in Chile had very basic instruments for their "first-light" runs but the telescope design and the positioning was well thought in advance to enable current additions and modifications.
What usually is done the set-up scientific goal in collaboration with many partners and see where this endeavour might lead. If different scientific topics can be addressed using the same basic set-up of the telescope then you might eventually get more budget from your different partners. This could enable you to plan for more instruments for the future.
I would say these are important features of a robotic telescope:
1. As someone said already - pointing accuracy, without it you will be looking at wrong part of the sky
2. Some kind of weather detector - you would not like the telescope to get wet/covered in snow. You probably would not like to take hours of images of clouds - will add up to electricity bill.
3. Filters - for scientific observations we really need filters
There are a few more, but they will depend what is your priority - For example, if you would like to catch sources in outbursts or transients, then how fast can you open your dome and point the telescope (so slewing time will be important). If you are going to observe very faint sources then tracking accuracy, how long you can point at the same source will be important (although you can overcome it taking multiple images and summing them up).
Having worked on a robotic telescope with concurrent cameras for space (lasco on soho) - I found that scheduling the individual components for operations that could be done in parallel was computationally complex - that for certain operations the computation time to create an "efficient" schedule could not be estimated. This is, I believe in general still an unsolved problem.
The next difficulty was managing the personalities (and abilities) of my team, and across teams.
The next was triaging the desired functionality to the actual budget and schedule
(what you promised versus what you have money and schedule to do).
People problems will be, for the most part, greater than technical problems.
Good luck.
I am currently working on a 12.5 cm refractor as a testbed for a 1 m Lunar Laser Ranger, this has certain 'robotic' features. What I would consider quite important is an internal micro-controller based safety system, i.e. software running on the micro-controller that automatically checks voltages, currents, temperatures, limit switches etc. This should be totally independent of the steering hardware and software. Apart from pointing accuracy, a major factor to consider is tracking smoothness. Going to the target is one thing, but staying on it smoothly is very important.
Independent software should run on independent processors.
Questions:
Where are status values bounds checked - on board or on the ground?
What are your plans for status that is out of bounds - keep going, reset, shutdown?
Can you accept a reset command if your processor has "run away"?
This is a ground-based telescope (my example anyway) and status values are checked continuously. If values are out of bounds, the action depends on the severity of the problem. For instance the telescope is completely disabled by removing power to the drive motors when a 'telescope disable' flag is triggered. Under or over voltage power supplies will disable the system, it will also be flagged by the servo controller, i.e. two independent systems will complain and react. The processor can be reset via an external command, it can be done either via software or via a hardware reset (driven by software not running on the microcontroller). So in general, the microcontroller monitors telescope activity in a 'housekeeping' mode, independently, but it can be talked to via other software running on an independent processor (PC). Status commands are sent to the PC for further interpretation.
Well then you won't have to travel a million miles with a screw-driver to fix it when it's broken!
More questions:
How much data per unit time? What buses to transfer data - to what storage device(s)?
What formats for science data/ science metadata?
How will you make your end-product (data+metadata) available to customers?
What type of onboard processing before storage, filtering, etc. if any?
What numbers of gigaflops will be needed for onboard processing, if any?
How will you load in dynamic programs to generate/capture data?
What OS, what language to generate data generation programs?
How will you know your program is doing what it is supposed to be doing - not telemetry but data as it is being generated and stored (assuming it is stored)?
No onboard processing will take place, the sensor will basically be a high density cmos camera. Data are to be stored on solid state memory as frame capture rate can be as high as 21 fps, field of view of the chip is about 17 x 15 minutes of arc. Everything is being developed on Windows, using C++. All processing takes place after the data has been transferred, the transfer rate is limited by internet bandwidth, unless I park a PC with the processing software next to the telescope, this can then be accessed by remote login. I can upload code into the microprocessor or the steering program via ethernet. The microprocessor use s a subset of C, so all updates, recompilations etc. can be done remotely.
Just curious -
Why the choice of Windows versus a Unix/Linux variant?
Why the choice of C++ versus C/Java/Python?
What (open source/commercial) image processing libraries are you using?
Windows is nice, stable, friendly and has many open source applications freely available on the internet. C++ is very powerful, and allows development of code at nearly machine level to nice, friendly graphical user interfaces. I am not using any image processing libraries yet.....the project is not at at that stage, but will be by next year.
The next question's are of interoperability:
Are you planning to share your data with other science institutions?
What format will your output data and metadata be in?
(FITS, JPEG, HDF5, etc.)
Is there a (local or institutional) database for your data?
Well, mostly JPEG for the images. The first use of the telescope will be to re-do the Eddington type measurement of gravitational deflection of light around the Sun, during the 2015 total solar eclipse. This will be done from Ny Alesund, Svalbard. Final images, data reduction etc. will be made available, i.e. if the experiment was'nt clouded out. This was last done in 1973 by the Univ. of Texas. Being 'robotic', this telescope will be able to scan pre-progammed sections of the star field around the eclipse. We normally host data on our server (192.96.5.4) where GNSS etc. data are stored. So I will probably park it there for access by anyone who is interested.
Another important issue when developing a robotic telescope is reliability. There are several automated 'robotic' telescopes located on the observing site of the South African Astronomical Observatory (SAAO) in close to Sutherland, South Africa. During my last visit there one of the technicians told me that although the robotic telescopes are automated and totally remote controlled etc., they suffer from reliability problems which necessitates human intervention on a fairly regular basis, which obviously adversely affects the robotic and autonomous status of these telescopes. Reliability should be part of the original design specifications, apart from hardware this should definitely extend to software, including the ability for easy updates to software components (uploading to micro-controllers, PLCs etc.).
- Badges
- Science topic