Automation

Design, construction, tuning of spectroscopes
Information and discussion about softwares (telescope remote, autoguiding, acquisition, spectral processing ...)
Post Reply
Peter Velez
Posts: 146
Joined: Tue May 12, 2020 7:36 am

Automation

Post by Peter Velez »

As I've mentioned to a few other forum members, I've spent the last 12 months working on automating my spectroscopy. I'm pleased to report that I now have a reliable set up that can take spectra while I sleep.

My system is not as elegant as that used by the 2SPOT team. However as it works and (mainly) uses readily available off-the-shelf software, I thought I'd post about my experiences.

You can read the paper available here: https://www.dropbox.com/s/78lheef36p5ta ... s.pdf?dl=0

If I can work out how to do it, I'll take a video of my system in action.

Feel free to send me any questions or comments - either here or to my email address which is noted in the file.

Pete
Olivier GARDE
Posts: 1243
Joined: Thu Sep 29, 2011 6:35 am
Location: Rhône Alpes FRANCE
Contact:

Re: Automation

Post by Olivier GARDE »

Hello Pete,

Wonderfull !!! But I have not access to your dropbox link....
LHIRES III #5, LISA, e-Shel, C14, RC400 Astrosib, AP1600
http://o.garde.free.fr/astro/Spectro1/Bienvenue.html
Peter Velez
Posts: 146
Joined: Tue May 12, 2020 7:36 am

Re: Automation

Post by Peter Velez »

Oops! My apologies.

While I work out how to share the file (which has a few photos), here is the text of the note. Its a bit long...

Automating spectroscope observations

This paper sets out how I have been able to automate spectroscope observations using off-the-shelf software products. The approach I have taken won’t suit all users – hopefully it provides some ideas that can be tweaked as necessary for other set-ups. At the least, its another proof of concept.

The observatory

My gear is housed in the iTelescope facility at Siding Spring Observatory, NSW Australia. It is the pre-eminent optical observing site in Australia with institutions from around the world having observatories all sharing space on the edge of an extinct volcano. It is a very scenic 6 hour drive from my home in Sydney.

iTelescope is a commercial operation with facilities around the world. I rent space in a shed with about 25 telescopes. The shed has a roll off roof controlled by the iTelescope weather station. I don’t need to concern myself with opening and closing the roof as this is externally managed.

My set-up

I have a dedicated pier with a PC and web-controlled power switch in a cabinet at the foot of the pier. The mount is a Paramount MX and is controlled with The SkyX. The principal scope is a Planewave CDK 12.5 with an inbuilt focuser.

I take spectra with a UVEX produced by Shelyak Instruments with the recently released motor unit. I use the Alpy guiding unit and Alpy calibration unit. The science camera is an Atik 460EX and the guide camera is an ASI174MM. To be able to access the NIR and IR, I have a ZWO EFW with a filter blocking wavelengths shorter than 5300 A.

I also have a photometry rig mounted on the main scope. I use a Takahashi Sky 90 with a ZWO EFW with BVRI filters and a ZWO ASI183M imaging camera. Focus is provided by Robofocus.
One of the benefits of operating from a site managed by the Australian National University for astronomy is that the broadband connection is super fast (by Australian standards). I control my observatory computer with Teamviewer.

Rationale for automation

While I enjoy observing in real time, I no longer have the stamina to stay up late into the night to take spectra. Also, as I pay rent for my space in the shed, I want to maximise observation time. So I was looking to establish a set and forget system.

My skill base

I installed my rig at SSO in 2015 and up until 2020 I limited myself to astrophotography. I had used ACP – both for automation and scheduling - quite successfully so I am familiar with the principles of automation.

That said, I am not an engineer, programmer or scientist – by day I practice corporate law. The last course I took in programming was learning Basic for operating the Radio Shack TRS-80 personal computer in 1980. Apart from watching the videos of the excellent sessions on using Python for spectroscope provided by Shelyak in 2021, I am entirely self-taught.

As a result, I needed to use off-the-shelf software for my system.

Other alternatives

I know of some observers using Prism. This is a single program to control all elements of the system. The 2SPOT team use it very successfully in Chile. I experimented with it and concluded it wasn’t right for me. The scripting system seems straightforward but for what I wanted to do it particularly involved. I never quite worked out how to get reliable plate solves of my small FOV. Prism and Paramount mounts don’t play well together. It is also not as well supported in English as other programs though I am sure the Prism forum users would have been extremely helpful if I had reached out to them.

ACP also turned out to be a dead end. The principal issue is that it is prescriptive about the software it works with and those programs don’t have the flexibility to do what we spectroscopists require.

The challenge

To me, the biggest challenge for automation is to get the target on the slit of my spectroscope. This requires much greater precision than is called for in AP. In my case, with x2 binning in my guidescope, the slit is only 4 pixels wide – my plate scale is 0.84 arcseconds per pixel.

However, the greatest impediment is software design – imaging programs are designed for AP. They assume that the imaging/science camera not only takes images, it is used to focus the telescope and to platesolve images; the guider simply guides. For us, the science camera takes spectra only. We use the guide scope for focusing, plate solving and guiding.

(I understand that Prism doesn’t share this problem as it allows cameras to be allocated specific tasks which makes it very attractive to spectroscopists.)

The solution I found was to use Voyager Array.

Voyager

Voyager is a relative newcomer to the automation market. It is similar to other programs in that it manages other astro software rather than replacing them. Where it differs is that it can work with a wiser set of software packages. For example, for imaging, it will work with Maxim DL, The SkyX, any ASCOM camera and the drivers specific to particular camera such as ZWO. Guiding can be done with Maxim DL, TSX, PHD2 or the native guider in Voyager.

Out of the (metaphorical) box, it can manage the mount, imaging, guiding, plate solving, autofocusing, take weather data, sky quality data and safety data and control certain web switches which are used for managing observatories. It is also able to run external programs and scripts.

Observation sessions are managed by DragScripts. A sequence of actions is built up by a user by dragging the requisite task from a list of actions. The sequence is then saved as a new file and run when necessary. There is considerable flexibility in these actions so that the tasks can be run in the right sequence at the right time. Most helpfully for novices like me, this doesn’t require any knowledge of coding – it’s a simple click and drag exercise.

Voyager Advanced has recently been released. This enables the user to select a series of targets with certain constraints and leave it to Voyager to determine what to image and when. For now, this can’t be applied to spectroscopy – though I hope its added soon.

Voyager Array

Voyager Array was designed to provide users to operate several imaging rigs at once. It assumes that the equipment sits on a single mount and that there are multiple scopes or other imaging devices. There is a dedicated instance of Voyager for each imager which can be run on a single or multiple PCs. The master instances manages slewing, plate solving, guiding and responding to weather and other safety events. The other instances (slaves or nodes) can autofocus, manage their filter wheels and rotators and take images but nothing more.

This is the critical feature of my set up.

Maxim DL allows the same camera to be installed as both the imaging camera and guiding camera if the camera is connected as an ASCOM camera. Provided Maxim doesn’t send instructions to take images in both instances at the same time, there is no conflict.

In my set up, I have my ASI174M set as both imaging and guide camera in Maxim. This is the imaging set up for the master instance of Voyager. I then have a second instance set with my spectroscope camera as the imaging camera.

Stripped back to the essentials, here is the sequence of key tasks:

Slew to designated RA and Dec – master.
Autofocus – master - using guide camera as imaging camera.
Calibrate guider – master – using guide camera as guider.
Precision slew – master – using guide camera as imaging camera.
Commence guiding – master – using guide camera as guider.
Take spectra – slave

The precision slew is important. This is similar to the Closed Loop Slew feature in TSX. Voyager will slew to a target, take an image and plate solve it. If allowed by the mount control software, it will sync the mount to that location. It will then slew again and repeat the process.

As Paramounts do not allow external syncing, Voyager simply determines the pointing error, makes a corrective slew and repeats the process. Voyager will do this up to 5 times. Importantly, the user sets the acceptable tolerance for this precision slew. I have it set presently to 0.4 arcseconds.

Offset calculation

Of course, a spectroscope slit is rarely in the centre of an image. To use the above approach, we need to determine the RA and Dec for an image to get the target on the slit.

Manually, a user can slew and ‘jog’ the mount till the target is on the slit. Then take an image of the field and plate solve it – the centre RA and Dec becomes the target for Voyager.

After much tinkering, I have written a couple of simple Python programs that does the work for me. I input the target name or co-ordinates, provide a link to a plate solved image and provide the x and y pixels for the centre of the image and my preferred slit position. The program then tells me where I need to point.

My mount is a GEM so the determined offset is only valid for one side of the meridian. I break up my imaging into east and west sequences.

A sample sequence

To give you an idea of how this all works in practice, I’ve set out below in rough terms how a night’s observations looks.

Voyager provides an imaging sequence framework. The user inputs target name, RA and Dec, filter (if required), exposure length, binning, download speed (if supported) and number of images. You can also specify whether to guide and the guide exposure, whether to autofocus, constraints (such as minimum elevation, hour angle etc).

Voyager also supplies a template flat sequence. By setting the minimum and maximum exposure to the same length, I can force Voyager to take flat images with a fixed exposure length. The template allows an external script to run before and after each sequence. I have written simple Python scripts to turn the flat and ArNe lamp in the Alpy calibration unit on and off.

So a standard imaging run for a target and reference star will be as follows:

1. Wait till 7pm

2. Link Array instances

3. Connect Array software ie connect to all equipment, turn on camera coolers.

4. Wait till nautical night

5. Home the mount - master

6. Slew to preselected field – usually 0 Dec and 1 hour in RA before or after meridian

7. Autofocus – using master only ie the telescope using the guider.

8. Calibrate guider

9. Take flat frames – slave – turn on flat lamp, take flats and turn off flat lamp.

10. Wait for astronomical night

11. Precision slew to reference star – master

12. Take ArNe frames – slave – turn on lamp, take frames and turn off lamp

13. Start guider and take reference star spectra – master and slave

14. Precision slew to target star – master

15. Take ArNe frames – as above

16. Start guider and take target star spectra – as above

17. Park telescope and disconnect equipment.

I take a single line text file from the iTelescope weather station which reports the roof status. It is updated every 15 seconds. If the roof closes, Voyager stops the sequence, turns tracking off and waits for the roof to reopen. It then restarts the system, returns to the sequence that was interrupted and starts again.

Once this is all set, its relatively easy to add a third instance to run the photometry set up. I can autofocus the telescope and photometry set up independently and can take spectra and photometry data at the same time.

I’ve also recently started to adjust the grating angle to access different wavelengths. Voyager manages the EFW to set the blocking filter if I am imaging in the NIR or IR.

Constraints

Here are a few things that are required to use this approach:

1. Permanent set up – while I am sure there are users who are able to set up in the field quickly and efficiently, it will be hard to achieve the necessary precision in slewing without a permanent set up.

2. Weather – as with any automated system, users need to have some system to manage inclement weather – or have great confidence in the accuracy of your local weather reporter.

3. Precision slewing – its critical that your set up can achieve the necessary precision to get the target on the slit reliably. With my rig, Voyager can bring an initial pointing error of 1.5 arcminutes down to less than an arcsecond with 4 – 5 slews. You need to take advantage of any mount tweaks available to you – I use a 200 point TPoint model, PEC and Protrack.

4. FOV – your guider field of view needs to be wide enough to reliably plate solve. The ASI174 provides a nice and wide field. I have a field of 15 x 9 arcminutes to work with though off axis aberrations makes it smaller in practice. I use the ATLAS catalog down to mag 18 for Pinpoint or the Gaia catalog in TSX for plate solving. It can be a challenge when imaging away from the Milky Way sometimes but my plate solves rarely fail.

5. Patience – as with anything in this game, you need plenty of this. I never seem to have enough.

Resources

I plan to update this paper soon with some screenshots of the system in action to illustrate the above. If I can work out how to record and upload it, I also hope to take a video of the system running.

You can find out more about Voyager here: https://software.starkeeper.it

The wiki for Voyager is quite helpful. You can access it here: https://wiki.starkeeper.it

I posted about using Array on the Voyager forum here: https://forum.starkeeper.it/t/spectrosc ... ray/3745/7

My coding is pretty ugly – but if you would like a copy of my offset calculation Python scripts, just drop me an email – peter@oblaw.net.au

Pete
Olivier GARDE
Posts: 1243
Joined: Thu Sep 29, 2011 6:35 am
Location: Rhône Alpes FRANCE
Contact:

Re: Automation

Post by Olivier GARDE »

Your remote installation is very good and the Voyager software seems to be a good solution to control everything remotely and automatically.
LHIRES III #5, LISA, e-Shel, C14, RC400 Astrosib, AP1600
http://o.garde.free.fr/astro/Spectro1/Bienvenue.html
Hamish Barker
Posts: 226
Joined: Thu Jun 20, 2019 12:11 am

Re: Automation

Post by Hamish Barker »

That's a great write up of a lot of work Peter! well done in getting there and sharing the experience so that others might benefit.
Ernst Pollmann
Posts: 461
Joined: Mon Sep 26, 2011 7:16 pm

Re: Automation

Post by Ernst Pollmann »

Hi Peter,
I sent you a private message, did you get it?
Ernst Pollmann
Peter Velez
Posts: 146
Joined: Tue May 12, 2020 7:36 am

Re: Automation

Post by Peter Velez »

Thanks Olivier and Hamish

Ernst, I responded to your PM yesterday. Let me know if you didn’t receive it

Pete
Ernst Pollmann
Posts: 461
Joined: Mon Sep 26, 2011 7:16 pm

Re: Automation

Post by Ernst Pollmann »

Pete,
yes, I received it.
Please let´s communicate via eMail, that´s more comfortable from my side.
Ernst
Post Reply