Astronomical Algorithms software
Astronomical Objects Database
Telescope Control Software
Download Hints
I'll be filling this page out with additional details as I get further into the design and construction of the control system. Check back every now and then!
Digital Setting Circles software
Astronomical Algorithms software
Astronomical Objects Database
Telescope Control Software
Download Hints
"Setting circles" are the angular calibrations you find on the axes of a telescope which, when aligned, you can use as a reference when slewing your telescope around the heavens. "Digital setting circles" is a fancy name which describes an electronic implementation with a digital read out.
There are various ways of implementing digital setting circles. Typically, you start with a subset of the following:
The digital setting circles algorithm operates on information from this list and calculates where the telescope is presently pointed. As you move the telescope, the algorithm faithfully recalculates its bearings so that you know what you're looking at, or at least where you're pointing. In order to build a computer controlled telescope, you must implement your own digital setting circles system.
I've talked quite a lot about using shaft encoders for measuring where the telescope is pointing on my design notes page. Shaft encoders provide you with two indices, one for each of the axes around which the telescope can rotate. For a dobsonian telescope, these two indices relate to the Altitude (how high above the horizon) and Azimuth (which compass direction) to which the telescope is pointing.
You can imagine that the Alt and Az for any particular object will be different from any two locations on the earth's surface. Even worse, if you set your telescope to point to an object at one instant in time, it will quickly (within minutes) drift out of view of the telescope as the earth rotates and you will need to adjust the Alt / Az orientation of the telescope to recentre it! Not surprisingly, Alt/Az is a poor coordinate system when looking skywards.
In order that astronomers retain their sanity, celestial objects are catalogued according to Right Ascension and Declination (the heavenly equivalent of latitude and longitude on the Earth). RA and DEC remain the same no matter which location you're observing from on the earth and no matter which instant of the earth's rotation you wish to make your observation. The digital setting circles algorithm thus examines the ALT/AZ registered by the telescope's shaft encoders and calculates RA/DEC. Conversely, the algorithm also allows you to calculate ALT/AZ if you know the RA and DEC.
There are several mathematical approaches which have been proposed for implementing digital setting circles. The approach that I took is based upon an algorithm published in the February 1989 edition of "Sky and Telescope" by T.Taki. It requires a two or three star alignment process but has, in my view, the tremendous advantage that you do not need to align the telescope in any other manner. That is, you don't need to level the optical axis, point it at zenith or point it at the celestial pole. You don't need to orient the telescope's mount in any particular direction and you don't even need to level the mount. Your shaft encoders don't need to be calibrated to read zero at any particular point. You don't need to set the time on the computer's clock and you don't even need to work out what latitude and longitude you're observing from. The same algorithm will work, without change or reconfiguration, for ALT/AZ mounts and Equatorial mounts: it is said that an ALT/AZ mount is just a terribly aligned Equatorial mount, or vice versa!
In order to use this algorithm, you must first "calibrate" the transform matrices at the start of the observing session. Practically, this means that you need to point the telescope at two or three known objects (most likely easy to find bright stars) and snapshot the readings from the two shaft encoders. At the instant that you sample the shaft encoder positions, you must also record the relative time of the reading. By relative time, I mean (for example) the number of fractional seconds since you launched the digital setting circles code: I do not mean the "clock" time in terms of date, hours, minutes and seconds.
When you've obtained at least two readings like this, the digital setting circles code calculates two matrices: one matrix which will be used to convert RA/DEC into ALT/AZ and the other matrix which will be used to convert ALT/AZ into RA/DEC. Reading the software, it is somewhat tricky to follow the mathematics behind this.
Now that the two transform matrices are initialised, you can calculate where to point your telescope to find the Andromeda Galaxy (M31) by specifying RA=42.7 degrees, DEC=41.16 degrees, relative time=NOW and calling the routine to calculate ALT/AZ. The calculated ALT/AZ values will be relative to the current zero point of the shaft encoders. That is, even though your shaft encoders don't have their origins aligned with any particular point, you just need to move the telescope so that the shaft encoders read the same numbers as the calculated ALT/AZ values and you'll be pointing at Andromeda.
On the other hand, you might be scanning the heavens and find a cool binary / nebula / comet etc. In order to determine the RA/DEC, you can snapshot the ALT/AZ readings from the shaft encoders along with the relative time and then use the other transform to calculate the RA/DEC.
It's not hard to see that you can get the telescope to track an object across the sky by (for example) iteratively recalculating the ALT/AZ every (say) second. If we want to track the Andromeda Galaxy then, we'd call the ALT/AZ calculation routine every second and with each successive call, increment the relative time by one second. By computing the difference between the present shaft encoder reading and the calculated ALT/AZ values, we can determine the step rate to use to drive each of the stepper motors.
Download the digital setting circles software
After searching the web, I found very few sources of digital setting circles code. The code I found was not quite what I wanted so in the end, I hacked and changed it and you can find my implementation here. If it doesn't seem to download properly for you, click here for some hints.
The file is a gzipped tarfile. Some PC based decompression programmes will be able to read it and extract the files but I wrote the code to compile on a Unix / Linux based platform. If you want to look at the code and perhaps base your own digital setting circles control on it, download it and then execute "tar -zxf telescope.tgz". You can compile the code by running Unix / Linux "make" within the "telescope/setcirc" directory.
Refer to the file called "test_setcirc.c" to see how to call and use the routines. It should be very straightforward.
I can't think of a reason that would prevent the code from also working on a Windows based system, so try it an see.
There comes a time in any computer controlled Dob project when you need to start getting serious about astronomical calculations. If you're new to these, you want to understand the maths and you're in the process of putting your computer controlled Dob together, I'd recommend getting a hold of this book. It's available through technical bookshops but the publisher sells it directly to the public also.
I've started the process of translating many of the published algorithms into the C programming language. So far, I've coded up the calculations to derive sidereal time, the position of the moon, planets and more generally, the algorithms to account for nutation, aberration, refraction, etc. With these formulae alone, it is possible to take the RA and DEC of a known object and to translate these to local Alt, Az coordinates suitable for pointing a telescope.
Strictly speaking, the book tends to calculate things more accurately than required for a Dob application. Apart from consuming more CPU cycles, there's no real problem with over-accuracy. If you're thinking that you'll implement telescope tracking by iteratively recalculating coordinates many times per second, you might have some trouble if your CPU is only micro-controller class. However, there's no real reason to iterate at this frequency for a Dob application so the algorithms should work just fine as implemented, right?
If you want to take a peek at the code, perhaps to modify and use it yourself, it can be downloaded here. (This is the same tar ball as described above for the setting circles code - all software on this page has been bundled together.) If it doesn't seem to download properly for you, click here for some hints.
This is a tar ball containing several test programmes and the astronomical algorithms are just a part. After you've downloaded the gzipped tar file, you can extract the files by typing "tar -zxf telescope.tgz". This will create a sub directory for you called "telescope/astro" containing all the files. You can compile just the astro code by changing into the telescope/astro directory and running Unix / Linux "make test_astro".
The file "astro.c" contains the astronomical algorithms largely as described in Jean Meeus' book. I won't claim that I've transcribed everything without error so if you find something wrong, let me know so that I can fix it. Another file, "astro_data.c", contains only static data tables which are used by some of the algorithms. "test_astro.c" contains test vector code. Largely, the test vectors are based upon the worked examples in the book and I've debugged astro.c by making sure that the values that it returns match the worked examples.
Jean Meeus seems to have played games with rounding intermediate results to a certain number of places and when these rounding errors are carried through to the end of many of the calculations, the results which astro.c produces (based on 15 digit precision) are sometimes slightly different. I've no great concern about these except in the calculations of planetary positions. Although the planetary results of astro.c appear to be within a thousandth of a degree (or so) of what they should be, I'm not yet confident that I've found all of the typos.
As it stands, you can see how the routines are called by looking at "test_astro.c" but you'll need to integrate them all into your own control software and star database. Hopefully, it's more or less obvious even if it's not so trivial.
I've been wanting to build an object database for some time, just to see how large it would need to be in order to cover the sky in a reasonable amount of detail. Well, here's my first shot at it.
In truth, this database is not really mine. I've written C code to distil the information from a number of public domain catalogues and then write the gathered information out to a file using a relatively efficient structure. The result is a binary database file containing around 20k objects in about 630k bytes. The database is cross referenced across several well known catalogues and the number of items in each catalogue are as follows: Messier (110), UGC (109), NGC (1708), HR (9041), IC (1518), SAO (12508), PGC (2418), HD (12561), PPM (11619), Alignment stars (78).
The telescope control programme sequentially parses the database file to build catalogue specific arrays of object names and file pointers. When a lookup is needed, the programme can search its arrays quickly (for example, search the MESSIER array for an object with a name of "42") and then open the database at the file location stored in the array to read the information about M42.
Here's an example of a familiar object as it appears in the compiled database.
RA: 00h 42m 44.3s, DEC: +41 deg 16' 9" Common name: Andromeda galaxy Catalogued as: M 31, NGC 224, UGC 454, PGC 2557 Magnitude: 4.3 Type: Unclassified galaxy Apparent size: 189 x 62 arc seconds Constellation: Andromeda Subjective rating: Excellent (B) Angle class: 4
Here's the entry for another, probably the most regularly observed, northern object.
RA: 02h 31m 48.7s, DEC: +89° 15' 51" RA Annual proper motion: 0.200 sec Common name: Polaris Formal name: 1 Alp UMi Catalogued as: HR 424, SAO 308, HD 8890, PPM 431 This is an alignment star Magnitude: 2.0 Type: Double star Number of components: 5 Magnitude difference: 6.8 Separation: 184 arc sec Constellation: Ursa Minor Spectrum: F8 Description: Double: A* 2.0 var. F8Ib, 30.46y, a = 0.038. AB physical, B, 8.20V, +0.49(B-V), +0.16(U-B), F3V, 0.0 color excess, vsini =<60k/s, C, 13v at 43, D, 14v at 83 Group: Red star Pleiades Name: Alruccabah, Cynosura, Phoenice, Lodestar, Pole Star, Tramontana, Angel Stern, Navigatoria, Star of Arcady, Yilduz, Mismar
Looking at these, you can get an idea of some of the detail you can pull down off the web and incorporate into a database. If you're prepared to look around and then write some code, you can build yourself a database with an arbitrary amount of detail. Obviously, not all entries in the database contain so much information or the size would exceed the 600 kbyte that it turns out to be. However, there's a surprising amount of information you get for 600 kbyte.
In order to keep the size of the database at about 600k, I've arbitrarily excluded stars dimmer than magnitude 7 by simply not writing them out to the final database file. If I didn't bother to activate this filter, the number of objects, based on just the catalogues I've downloaded from the web, increases to several hundred thousand and the size of the distilled database file trebles.
So enough of the advertisement, how do you download it? Firstly, fetch this file (the same tar ball containing the astronomical algorithms mentioned in the previous section). If it doesn't seem to download properly for you, click here for some hints.
Extract the files using "tar -zxf telescope.tgz". You'll now have a new directory called "astro" containing the source code as well as a shell script call "fetch.sh" to automate the downloading of the raw databases for you.
The size of the uncompressed raw databases amounts to more than 50 Megabytes of files. Two of the files are larger than 20 Megabytes each. The file "fetch.sh" was my way of telling you where these raw databases can be found without having to put the files directly on my own web site. When you run the shell script, it will check to see whether you've already downloaded a copy or a partial copy of each of the files and then fetch the missing (partial) files for you. All up, there's around 30 Megabytes of downloading so it might tie up your network connection for a while - go and visit a friend that has DSL.
When the downloads are complete, the script decompresses those files which need to be decompressed and then compiles the source code. The script then runs the compiled code to build a binary database file (called COMP.dat) and finally runs the database browser to create an ASCII representation of the database (called COMP.txt, from which the above two example entries were cut and pasted). Depending upon how fast your computer is and how much memory it contains, you'll find that it can take a long long time for the database compiler code to run - it has to parse a LOT of text and after I discovered some problems with some short cuts I tried to make, the code now does an excessive amount of sorting and cross correlation of the various star catalogues. If your memory is really small and the programme starts to swap out, you'll find it running unbearably slow. As it is, a PII-400 takes several hours to run to completion and a PI-200 takes about 9 hours.
OK. Now I've told you about how cool this code really is, I'll make my disclaimer. The source code for data.c, the heart of the programme which creates the database, was thrown together in the loosest, most haphazard manner I could possibly muster. It is good example of bad programming. It's a kludgey keyboard bashed monster. Don't emulate my style (sic) if you can possibly avoid it. etc etc etc. But it seems to work fine. If you find errors in the database, check that the errors haven't come from the source files and if not, let me know and I'll try to fix it :-)
Have fun. Let me know if you improve it so I can share your wisdom with others. Stay tuned for some telescope control code.
|
|
|
I've been working on the telescope controller software and have managed to implement joystick control of the telescope and a fancy joystick controlled menu system to configure and control the scope. For me, this seems like considerable progress in the project. For you, perhaps it's not so impressive. Stay tuned however, the controller is getting better.
In the photo, you can see the telescope controller mounted on the side of the rocker box. The controller has an two line, 20 character per line LCD display on it which I will be using to provide the user interface. I have butchered an old but high-quality joystick to use as the input device using a coiled cable from an old keyboard to replaced the straight joystick cable. The other box to the left of the controller box contains the power transistors which drive the stepper motor along with the EDE-1204 stepper motor controller circuit.
Today, I can use the joystick to slew the telescope in altitude and azimuth directions. I can select the slew speed using a button on the joystick shaft. I can also jump between a slewing mode and a menu driven command mode by pressing the button on the base of the joystick. When in the command mode, I use the joystick to traverse the menus. So far, I have implemented time/date and time zone setting, calculation of planet positions and altitudes, selection of an alignment star that's presently up, looking up stars or objects from the following catalogues: Messier, UGC, NGC, HR, IC, SAO, PGC, HD, PPM, and setting the observing location.
All in all, I've surprised myself that the software has bolted together so simply and straightforwardly. Linux really is a wonderful platform. I've no doubt that the end of this project is not too far off now.... except for one thing. My family and I are about to make an international move and I'm going to be without computers and telescope for several months. :-(
I've written the software in a modular sort of way. Firstly, I drew heavily from some of the OS wrapper code I wrote for my train set but it's now rather more tidy than presented there. I've tried to break out the parts of the software specific to my implementation so that they could "easily" be replaced by alternate code. Thus, the joystick interface, the LCD interface and the motor controller code each have their own files and each have a "standardised" software interface. So even though my implementation runs on uClinux and uses a dicky joystick and LCD for I/O, it should be relatively straightforward (for example) to replace a couple of the source files and then control a telescope out of the parallel port of a laptop running full-blown Linux.
I you want to take a look at the telescope control software but have not yet downloaded the tarball of code from one of the other download links on this page, fetch it at this place and extract the files using the Linux command "tar zxf telescope.tgz". If it doesn't seem to download properly for you, click here for some hints.
Using Linux "tar zxf", a directory called "telescope" will be created for you which itself contains several more directories. The telescope controller itself lives in "telescope/control/*" but there are a bunch of other directories containing test code for various parts of the controller. For example, "telescope/astro/*" contains test code for the astronomical algorithms and database, "telescope/menu/*" contains test code for the menu navigation routines, "telescope/process/*" contains test code for the wrapper routines that hide Linux's interprocess communication (etc), "telescope/setcirc/*" contains test code for the digital setting circles algorithm.
In order to reduce the size of the tar ball and to make sure that changes in one directory are automatically reflected in other directories, I've used Linux symbolic links extensively. All the original files exist in "telescope/control/*" and the other directories which require a copy of one of these files link to the original. If you try to open the tar file on a Windows based machine, the chances are that your archive programme will ignore the symbolic links. If so, you'll have to manually recreate the links in order to compile under Windows.
You should be able to compile most of the test code under Windows and it should work first off, certainly if you use a GNU compiler. That is, the "astro", "menu" and "setcirc" code should be fine under Windows - I've written a shell script in "astro" and you should look at this before compiling under Windows. The "process" code will not compile as is under Windows because there's Linux specific calls in it. "Control" additionally contains uClinux and hardware specific code and there's a "readme.txt" describing the function of all of the source files. You can find out more about uClinux by surfing to the uClinux home page. Even if you're only interested in Windows based operation, you can probably modify the code to work by changing the "process.c" file.
I plan to update this software link as I implement more and more code. Check back every now and then if you're interested and I'll make sure I mark this page when I change the "telescope.tgz" file.
The compressed software files in this directory are in gzipped tar format and end in ".tgz". Your unix-challenged browser and operating system may not understand what a ".tgz" file is and you might become frustrated trying to work out how to download and decode it.
To save the file to disk instead of having your browser try to display it, hold down the shift key when you click on the link and the browser will ask you where you want the file saved. Make sure that your browser does NOT try rename the extension: it should end in "tgz". Better still, fire up Linux and at a shell prompt, type wget http://www.geocities.com/kellertuberg/telescope/filename.tgz.
Newer versions of Winzip will be able to decompress tgz files for you so that you can look and play with them under Bill's operating system. However I assembled these archives under Linux which uses gunzip and tar -xzf to decompress the files. The source code files were intended to be compiled using Gnu CC and Gnu make, which also come for free with your favourite Linux distribution.
I've noticed that the newest version of Winzip provides a limited time trial before you need to pay. In the interests of something more openly available and free, check out stuffit instead.
