Perhaps you could get some ideas based on the listed features of these commercial products - http://astronomy-software-review.toptenreviews.com/. Also try http://www.techsupportalert.com/best-free-astronomy-software.htm and http://tdc-www.harvard.edu/astro.software.html... http://en.wikipedia.org/wiki/Robotic_telescope perhaps?

Hi essential feature are:

1- your software has to be open source so that others can help and inspire themseves

2- it has to follow established protocols.

3- don't reinvent the wheel

Make it an INDI compliant device and then all the rest will come for free.

http://www.indilib.org/about/discover-indi.html

Thanks, yes, good ideas. I might make it open source at some stage, it is a bit experimental at this stage. Some of the commercial software are quite fancy. My leaning is a bit more towards actual tracking and pointing accuracy, e.g. the ability to make plots of actual local hour angle rate vs. calculated etc. So a bit more instrumental and special functions.

Telescope/mount control is fairly simple - namely "point at this!". Users will generally specify "this" in J2000 coordinates, not current epoch, so you should do the conversion for them. I've never had a need for lunar or other exotic tracking variants. You may want to support "tracking off" for TDI or imaging geostationary satellites (which is fun). Because my mount is so poor, I've automated taking a pointing image, computing a plate solution and sending a correction to the scope, so it's genuinely pointing at the target before taking the "science" image. You can probably use a TPoint model instead. If you have an automated focuser, you could implement your own temperature and filter compensation. Camera control is the real challenge. Useful parameters to expose to users include binning, filter, subframe, exposure, raw/dark/reduced (ie. do you want image calibrated or not). I've gone a bit further to automate stacking and tiling of images. I also compute a plate solution and embed it in the final FITS image.

Hi Andrew, the system can track at any rate currently, lunar, solar, sidereal, satellites etc. I am still optimizing the tracking algorithm, get about 0.5 arc-second SE and 3 arc-sec peak deviations, currently these are linked to a 5 sec periodic error. I am slowly getting to grips with these. I will implement a pointing map, probably not TPoint but something sort-of-similar, based on a matrix, some curve fits etc. Input is J2000, or selectable objects from a menu. I am adding bits of the USNO CCD Astrograph Catalog, UCAC4 in at the moment. Camera software I am hoping to buy off-the-shelf. The pointing map will be done manually initially, I have added a function where RA and Dec offsets can be fed in via the GUI, the idea is to use position cal stars, tweak the pointing, store and go to next to build a pointing map. Part of this is easily automated (I think), but not yet done.

Thanks for the answer!

One thing that is proving very useful is the capability to generate plots of various parameters, e.g. in setting up the servo control units, the drive must be matched to the motor electrical characteristics (torque, min and max voltage, min and max current etc.) so proportional, integral and derivative values can be fine tuned. As example I currently have a bit of noise in the set-up, exhibited as noise in the encoder counts, this has now clearly been identified as the source of a 3 arc-second peak to peak cyclical noise in the HA drive, now I can target it and devise ways to get rid of it. Most software do not have an engineering component, this I would say, is essential to allow improvements in tracking and pointing algorithms, from a nuts and bolts level and upwards.

Hi,

If you have the tracking and pointing algorithms and hardware in place now, my Initial Orbit Determination (IOD) algorithm can verify your observations (angles data in right ascension and declination) are as good as you need.

Gim Der

Hi Gim, the system is nearly complete. Have you got source code available..then I can stick it in and test it.

Regards

Ludwig

I now have 2 refractors on the same mount, a 108mm f14.8 and 125 mm f12.5.

I support the ideas of Nicolas Produit in order to design and develop using standards and do not inventing the wheel, instead of that, cooperation using the free software model in order to improve TCS. For many large grounded based telescopes it is used Linux/CentOS, and VxWorks for such critical RT functions. Interoperability, maintenance, upgrade-ability and long lifespan should be attended in such developments.

salaam

I am interested in the design of harvester satellites for the purpose of prevention of

Kessler syndrome events while providing refined metal for in situ manufacturing.

can on-board optical equipment be designed to track and identify small debris for acquisition? could your software be adapted to this use? I agree with Nicolas Produit that the code should be open source. thank you.

Hi Omar

No, the software depends on human interaction so would not be suitable. 

Thanks for your interest!