A Fully Automated Imaging Observatory - WIP

[martin_h]

Well done!! its great when it all comes together.

[steppenwolf]

Indeed it is, Martin, very satisfying as this was not an 'out of the box' working solution as you know!

[SnakeyJ]

Well done Steve, a long and difficult path and not for the feint hearted - rather more of a pilgrimage in hair shirt 'n shorts. The end result must be even more satisfying, particularly after a good night's sleep.

Now it just remains to batch and automate the processing :-)

Sent from my D6603 using Tapatalk

[steppenwolf]

Hi Jake,

Thanks for taking the time to comment on my thread at such a difficult time for you and your family.

Now it just remains to batch and automate the processing :-)

A step too far! I love the post processing part as it allows me to get a little bit creative so I'm more than happy to keep this 'hands-on'. Although I can now run the observatory fully automatically, it is my intention to generally run it 'remotely' so that I am still very much involved.

[steppenwolf]

Additional Note 19 - Dome Ancillary Control Components have arrived

My two sons very kindly bought me the two circuit boards - mentioned in post #140 - that I need to complete my ancillary control module, as a Christmas present!

The first circuit board is a digital input/output board controlled via a USB port and it is the same board as the one used to control all movements of the dome in azimuth as well as opening and closing the aperture slit. The digital board has 8 outputs that are pulled to ground when activated under software control. Coupled to this board is a simple relay board with 8 relays capable of handling up to 5 amps at 230VAC but the relays can also be used to switch 12v DC and signal levels. This combined control module will allow me to carry out the following updated actions under software control:-

1. Turn on/off the dehumidifier

2. Turn on/off the ancillary equipment 12v PSU

The above two work together via an external relay unit. The normally closed (NC) contacts supply 230VAC to the dehumidifier when the relay is un-powered. Operating the relay switches the power over to the observatory's ancillary equipment 12v PSU in readiness for switching each component's power line in turn thus avoiding any chance of a 'spike'.

3. Turn on/off the dome control PSU

4. Turn on/off the mount

5. Turn on/off the focuser

6. Turn on/off the AAG CloudWatcher

7. Open and close the telescope's dust cap

8. Turn on/off the observatory light to allow the dome's webcam to see what is going on.

Circuit Diagram

Software Virtual Controller

I have plans for the extra digital inputs and analog outputs that are available on the primary board but haven't fully formulated these yet - watch this space!

[tdnicholls]

Looks good Steve, I do a similar thing but use a Arduino and 8 way relay board, wrote my own control software as well as the ASCOM drivers for the roof control, needed more flexibility than std software offers.

It does basically the same thing, my roof has a lock on it so the software handles the control of lock disengagement and roof opening. I use SGP and read the notification log to allow me to disable the IR on the CCTV cameras when images are being taken.

I also have various environmental monitoring kit that control when the dehumidifier kicks in, currently on at 60% and off at 50%.

[steppenwolf]

That's a nice elegant solution - unfortunately my software writing skills are firmly embedded in the past with FoxPro and DBFast! Luckily, my dome control software (LesveDome) has built in support for 9/10 switches so I can use that.

I can, however, also control each of my 8 switches (and one other on the dome control board not shown here which is for the 'flat-flap') using a set of VBScripts that I can run from either a batch file or call from CCD Commander. Here's a couple of examples - unfortunately, VBScript has a limited range of 'buttons' so I can't write my own 'button dialogue box' to call them!

Turn on the first switch

driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 4, True

Turn off the first switch

driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 4, False

[steppenwolf]

Additional Note 20 - Dome Ancillary Control Box construction and installation completed

The appalling weather this week has given me an opportunity to construct the ancillary control box from the components I got for Christmas. Obtaining a suitable project box wasn't as straightforward as I had expected but I found one at Maplin that would just accept the larger of the two boards (the relay board) by grinding off the bottom section of the two centre pillars. The smaller board (the controller itself) attaches to the lid for easy servicing. The divided section on the left hand side houses the relay for the dehumidifier/12v PSU changeover thus keeping the 230VAC section as far away from the digital boards as possible. Not shown in this image is the micro USB cable which has a détente cable clamp attached to the lid to ensure that no tension can be put on the controller board if the USB cable is pulled.

Roll on the next clear night!

[steppenwolf]

Additional Note 21 - Last night was the first imaging session that proved the advantages of this project for me!

Last night had plenty of promise for a clear night but we had friends round for the evening from 19:00 onwards (before my chosen object even came into view above my local eastern horizon) so under 'normal' circumstances, I would have had no chance of taking advantage of the clear spell. However, before our guests arrived, I programmed up a fully automated session that started at 19:30 by checking the sky and then opening up the observatory, cooling the camera, locating the Rosette Nebula, acquiring a guide star and then starting to capture a series of 600 second subframes - nothing special so far, this is all standard fodder!

What makes the whole project so worthwhile is that at 21:26 the sky clouded over - normally cause for calling it quits, closing down and going to bed! However, the system simply paused the session, carried out a meridian flip at 22:58 and then, when the cloud dispersed at 23:07, the session re-started automatically, capturing a total of 21 x 600 subframes before carrying out an automated close-down when the nebula reached my local western horizon.

We had a great evening and meal with our friends and I didn't have to look in on the observatory at any time - it was only this morning that I realised that the sky had clouded over at all.

Happy boy? Oh, yes!

The Rosette Nebula in Hydrogen Alpha

[AndyUK]

A superb result, Steve...

(And the next project will be...?!)

[martin_h]

Sorted then!

[steppenwolf]

Additional Note 22 - I have discovered that my Flat calibration files are over-correcting

I noticed recently that although I was fairly happy with the images that I was capturing with the automated system, something was 'missing'. I tracked this down to my Flats over-correcting resulting in bright corners and a dark patch in the centre of the frame. This was something new as previously I had been really pleased with the Flats that I was getting when I collected them manually. Having tried increasing the flush intensity to no avail (the camera disengages if a flush higher than 'Normal' is used), I re-evaluated some images that I took some time ago and confirmed that the Flats worked perfectly in the past so I started looking for anything that had changed.

Full automation is the biggest change which means that MaxIm DL is now controlled by CCD Commander and therein lay the issue. Not a problem with CCD Commander as such but a simple case of CCD Commander taking its lead from a preset within MaxIm DL.

I have set the exposure presets in MaxIm DL's Readout Mode to download images in 'fast mode' when manually locating stars, manually focusing or when checking the framing of deep sky objects. Unbeknown to me, CCD Commander was taking the readout mode from the first preset in the list and applying it to Light, Bias, Dark and Flat frames so all the frames were suboptimal. The solution was simple - make a new preset called 'Imaging Session' with the readout mode set to 'Image Quality' and place it at the top of the list.

Problem solved.

[Scott]

7 minutes ago, steppenwolf said:

Additional Note 22 - I have discovered that my Flat calibration files are over-correcting

I noticed recently that although I was fairly happy with the images that I was capturing with the automated system, something was 'missing'. I tracked this down to my Flats over-correcting resulting in bright corners and a dark patch in the centre of the frame. This was something new as previously I had been really pleased with the Flats that I was getting when I collected them manually. Having tried increasing the flush intensity to no avail (the camera disengages if a flush higher than 'Normal' is used), I re-evaluated some images that I took some time ago and confirmed that the Flats worked perfectly in the past so I started looking for anything that had changed.

Full automation is the biggest change which means that MaxIm DL is now controlled by CCD Commander and therein lay the issue. Not a problem with CCD Commander as such but a simple case of CCD Commander taking its lead from a preset within MaxIm DL.

I have set the exposure presets in MaxIm DL's Readout Mode to download images in 'fast mode' when manually locating stars, manually focusing or when checking the framing of deep sky objects. Unbeknown to me, CCD Commander was taking the readout mode from the first preset in the list and applying it to Light, Bias, Dark and Flat frames so all the frames were suboptimal. The solution was simple - make a new preset called 'Imaging Session' with the readout mode set to 'Image Quality' and place it at the top of the list.

Problem solved.

When I win the lottery and build my fully automated obs, you are gonna be one busy man

 

[steppenwolf]

Quote

When I win the lottery and build my fully automated obs, you are gonna be one busy man

Buy that ticket, mate, you know I'll be first in line to help you get it all set up and working!

[steppenwolf]

Additional Note 23 - Observatory Drive Units Updated and Focus Issues

1. Updated Drive

Pulsar have recently updated their azimuth and shutter drive motors and controllers. This has taken them away from the well-proven LesveDome software and on to custom software that they have had developed specifically for them. I have the latest system installed in my observatory and I am pleased to say that Pulsar have done a great job and the updated system works very well indeed.

The new system can be operated in both stand-alone and PC controlled mode although I am using the PC mode as this is an integral part of my automation project.

New Controller with built-in Control Panel

Bluetooth actuated Shutter Controller

2. Focus Issues

One aspect of this automation project has proved to be unreliable and that has been the auto-focus system! There is nothing wrong with the SharpSky hardware or its ASCOM driver - the issues are centred on FocusMax. FocusMax is a very capable piece of software that interfaces between CCD Commander, MaxIM DL and the focuser's ASCOM driver - and it is very clever. The main reason for using it for this project is that for many people, it works well and has one feature, AcquireStar that makes it very appealing for an automation project like mine.

AcquireStar uses the PinPoint astrometry engine to plate solve the current location and then finds a nearby star of suitable magnitude for FocusMax to focus on and once it has chosen one, it slews the telescope to the star, plate solves, syncs and re-points to centre the star then it sets the focus routine in motion. After focus is achieved, the telescope slews back to the imaging object, plate solves and syncs again to ensure that the original location is matched and the imaging session resumes. Sounds cool? ....... and it is cool - when it works but there's the rub, for me it doesn't always work!

I have decided to try a different auto-focus system and, to my surprise, one of the options supported by CCD Commander is the SharpStar focus routine built in to MaxIM DL itself. Although the focus routine is fully automatic, it works by centring a suitable focus star manually and then focusing on the star. To resolve this issue, I have been experimenting with a simple solution - pairing. I choose my imaging object and then look around for a nearby isolated mag. + 5 star to focus on then simply plug the coordinates of both into CCD Commander - simple. First results are very encouraging.

 

[steppenwolf]

Additional Note 24 - Addition of a New Imaging Telescope Requires Additional Automation

A fairly significant birthday and an amazing gift from my wife to celebrate it, has necessitated an additional piece of automation. A second telescope (Esprit 150 ED Pro) with autofocuser and flat flap (not to mention the re-installation of my old SXVF-M25C CCD camera!) means that to switch from one imaging system to the other, will require yet another automated control box to switch the correct components into play. The number of connections that need to be switched soon adds up:-

1. Autofocuser motor - 2 x 12V DC power lines + 7 x data lines

2. Flat Flap - 1 x 12v power line + 1 x data line

3. Camera swap-over - 1 x AC power line

This adds up to 12 individual single pole double throw (SPDT) connections to automate. Luckily, I found some suitable 12v x 8 port SPDT relay boards on Ebay and these simply required lacing up with control wires for each switched output and a series of wire loops on the inputs so that a single input line shorted to ground will trip all 12 relays at the same time.

With this new control box I can now switch all the required services between one telescope or the other either manually using the toggle switch on the control panel or under software control using one of the spare outputs from my previously built USB Equipment Controller.

Multiple Pole Switch Controller with Flat-Flap Cables and CCD Camera Power Connections

Esprit 150 ED Pro and William Optics FLT98 Telescopes mounted together

Software Switch Panel (Telescope 2)

As you can imagine, it is important to ensure that all the components are enabled and disabled in the correct order especially when switching from 'Telescope 1' to Telescope 2'. To automate this, I use two batch files with external VBScript scripts and here I show the one that selects Telescope 2:-

Telescope 2 Batch file

: Telescope 2
:Pause to display warning message about dome locks
echo off
CLS
:*** WARNING - UNDO DOME LOCKS ***
undo_locks.vbs
: Ancillaries Startup Sequence
turn_on_ancillaries_telescope_2.vbs
: Run FocusMax - disabled 070616
: start "" "C:\Program Files\FocusMax\FocusMax.exe
: Start AAG_CloudWatcher executable
cd\AAG Cloudwatcher
autostart_CloudWatcher.vbs
: Run Cartes Du Ciel
start "" "C:\Program Files\Ciel\skychart.exe
: Re-Park Mount in C du C
re-park_mount.vbs
: connect_focuser.vbs - disabled 270816
: Start MaxIM DL
start "" "C:\program files\MaxIm_DL_V5\MaxIm_DL.exe
: Start CCD Commander and wait for it to close
start /wait "" "C:\ccd commander\CCDCommander.exe
: Run AAG_CloudWatcher executable closedown after CCD Commander closes
call close_AAG_CloudWatcher.bat
: Disconnect Camera, Mount and Focuser from MaxIm DL
disconnect_camera_and_mount_and_focuser.vbs
: Disconnect MaxIm DL
: taskkill /IM MaxIm_DL.exe
: Disconnect Mount from C du C
disconnect_mount_close_C_du_C.vbs
: Ancillaries Closedown Sequence
turn_off_ancillaries_telescope_2.vbs
:Exit this batch file
exit

turn_on_ancillaries_telescope_2.vbs

' Turn OFF De-humidifier Turn ON Dome PSU
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 7, True

' Turn ON Telescope Switch
'driverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 9, True
WScript.Sleep 60 * 60

' Turn ON 12v PSU
'driverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 6, True
WScript.Sleep 60 * 60

' Turn ON Camera
'driverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 5, True

' Turn OFF Flat Panel
'driverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 10, True

' Turn ON Mount
'DriverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 8, True

At the end of an imaging session, a controlled close-down is also required and this is the task of the final VBScript

turn_off_ancillaries_telescope_2.vbs

' Turn ON De-humidifier Turn OFF Dome PSU
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 7, False

' Turn ON Flat Flap
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 10, False
WScript.Sleep 5000

' Turn OFF Mount
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 8, False
WScript.Sleep 5000

' Turn OFF Camera
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 5, False

' Turn OFF 12v PSU
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 6, False
WScript.Sleep 60 * 60

' Turn OFF Telescope Switch
'driverID = "ASCOM.LesveDomeNet.Switch"
'set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 9, False

This new addition has proved to work very well indeed but sadly, there is little point in switching between instruments if there are only clouds to be observed which is the situation as I write on 12th March, 2017!!!

 

 

 

[steppenwolf]

Additional Note 25 - Improving Start Up and Closing Down Procedures

1. Plate Solving at start of session

I have noted that from time to time, usually after an automated shut-down following a cloud warning - but not always - the next session sometimes fails to plate solve the first slew as the telescope is pointing just outside the plate solve search region. When this happens, I simply run a manual 'blind solve' from MaxIm DL via PinPoint, however, I wanted to automate this smoothly and came to the conclusion that as I cannot specify a blind solve as an action in CCD Commander, I should find another way of doing it.

The solution came in the form of the free software 'All Sky Plate Solver'  as this allows 3rd party software (MaxIm DL) to access its search engine which is based on a local version of Astrometry.net. This feature connects to the CCD camera and telescope, captures an image, plate solves it from local data and then syncs the telescope to the solved position so that carrying out a subsequent normal plate solve now works flawlessly as the co-ordinates supplied by the mount are already very accurate. I now run this as an 'external program' in the form of a batch file using an action in CCD Commander to call the batch file:-

Batch File for Calling All Sky Plate Solver

: Run All Sky Plate Solver
start "" "C:\Program Files\PlateSolver\PlateSolver.exe" /solve
taskkill /f PlateSolver.exe

2. Disconnecting the CCD Camera at the end of a session

The short nights of summer highlighted a small issue with my close down procedure in that it got light at 03:00! Part of the close down included warming up the camera and then I would manually turn it off when I awoke later in the morning. However, this left the camera running off-cooler but with the fan operating and the sensor 'live' for up to five hours unnecessarily. The solution was to write a VBScript to disconnect the camera from MaxIm DL, wait a few seconds and then physically turn it off under software control of the eight port switch unit that I built to control the observatory equipment.

VBScript File for Disconnecting and Turning Off My CCD Camera

' Disconnect Camera from MaxIm DL
Dim cam ' "The" Camera object
Set cam = CreateObject("MaxIm.CCDCamera")
cam.LinkEnabled = True
cam.LinkEnabled = False
WScript.Sleep 5000
' Turn OFF Camera
driverID = "ASCOM.LesveDomeNet.Switch"
set o = CreateObject(driverID)
o.Connected = True
o.SetSwitch 5, False

I am currently working on a new VBScript to control cloud cover .............

 

[steppenwolf]

Well, I give up after several days of testing and head-scratching! Unfortunately ASPS is too flaky to be relied on in a remote operating environment which is a great shame as it showed great promise as a blind solver when operated manually.

Unfortunately, under CCD Commander control, it fails to respond correctly. This could be a setting that I have got wrong but either with or without the 'Taskkill' command in place, the program returns to CCD Commander too early so the next action is started prematurely. Not only that but it doesn't always solve despite good data and even when it does, it never syncs the mount to the solved position, making it useless for my purposes.

Thankfully, it is only rarely that I need to carry out a blind solve so I will just revert to my old method when required.

If anyone can recommend another local blind solver that can be reliably called from CCD Commander, please let me know!

[jimjam11]

About to embark on a similar project with a pulsar dome which leads me onto a very simple question:

How did you route  power and weather monitor cabling into the dome?

 

As an aside have you looked into any of the smart home products as a way of automating certain aspects (power, light etc)?

 

 

[steppenwolf]

5 hours ago, jimjam11 said:

How did you route  power and weather monitor cabling into the dome?

Power is routed through conduit buried in the concrete base of the observatory. When I originally built the original non-automated Pulsar observatory, I laid in conduit for power, network and security system. However, I have since added a permanent drain dehumidifier, the AAG weather system and an all sky camera and these exit the the observatory low down through the glass fibre walls using 21.5mm waste overflow pipe connectors.

5 hours ago, jimjam11 said:

As an aside have you looked into any of the smart home products as a way of automating certain aspects (power, light etc)?

No, I hadn't considered that although for a very short period of time, I did play with an Energenie USB controlled switch but after the second unit failed in a different manner to the first one, I decided to design my own which works faultlessly. However, I am sure that there are other solutions!

Good luck with your project, I hope it is a great success for you.

[steppenwolf]

Additional Note 26 - Updated Computer System

It's been a while since I updated this article but my Windows XP system started to give unreliable results in recent months so I have finally bitten the bullet and upgraded my observatory PC and moved up to Windows 7 in the process. The thought of using Windows 10 filled me with horror so I avoided that as I have always found Windows 7 to be very stable and nonintrusive. What I hadn't anticipated was what a total pain it was going to be to transfer everything across and on top of this I had to install Windows more than once as it took serious exception to some modules and even my regular restore points didn't rescue me - it would be fair to say that I have lost nearly two weeks of my life that I will never get back again, hair that I am in no position to lose and most of what was laughably left of my sanity but, maybe, hopefully, it will be worth it when the last of the bugs are finally sorted out! What is not in doubt is that the original reliability problem, especially issues related to the system accepting that my autofocuser really was physically connected seem to have gone away and I feel that for whatever reason, I am getting better autofocus with the new operating system and PC hardware.

So biting and clawing, I have dragged the automated observatory into the 2010's and avoided using Windows 10 which is a supreme bonus!

It remains to be seen how well the new system operates as currently, a fresh bug seems to jump out at every test session although in a morning of simulations today, it has all worked seamlessly despite the previous night in which it decided that I really didn't have a LodeStar autoguider and I haven't physically touched a thing since then I should have known last night that something was wrong when I noticed a pop-up that stated that a 'new unknown device' had been installed (I'm guessing that this had something to do with the LodeStar!

Although I can't mention him publicly lest he be deluged with requests, I'd like to thank a good friend of mine on here for his generosity in donating both time and hardware to further the cause - you know who you are and I am very grateful. 👍

Onwards and upwards 😎

[Gina]

I find Windows 7 quite acceptable and reliable even if I do prefer Linux.

[barkis]

It is inevitable that putting together such a varied, and intricate system is going to throw up a gremlin or two Steve.  I have followed this thread with much interest and admiration from the start, and you have generated much interest in your project.  I'm sure we all hope you can get rid of the bugs that are frustrating you.   The saving grace for us, is knowing that in spite of the glitch in this project, you are still able to produce the high quality Deep Sky Imagery you  are renowned for.      

Best Wishes matey

Ron.

[hughgilhespie]

I usually upgrade my Windows 10 computers to Windows 7.

 

[Jkulin]

I am very surprised at people not wanting to upgrade to Windows 10, it is beautifully stable, reliable and has never crashed any of our business machines, going back in time to Windows 7 is a derogatory step for upgrades and support.