DIY Automation of Pulsar 2.7m Dome Rotation, Shutter and Weather Monitor

[NigeB]

Hi All,

After months of faffing about, I've finally got a reliable, working solution to full automation of my 2.7m Pulsar dome which I thought I'd share here. 

The automation of rotation using a timing belt and pulley is well documented elsewhere. In particular I made a lot of use of the detailed threads and discussions by Steve @sloz1664  (along with a few pm's - thanks Steve!). This uses the LesveDome driver and electronics scheme, based around a Velleman VM110N USB Experiment Interface Board (see http://www.dppobservatory.net/DomeAutomation/DomeDriver.php). I won't dwell on that part of the project - see Steve's posts, and others on SGL, for lots of details on that. The only modification I made was a different choice of motor - instead of a windscreen wiper motor which is commonly used, I ended up fitting a Planetary Gear Motor with 369:1 reduction gear sourced from Gimson Robotics (https://gimsonrobotics.co.uk/categories/dc-electric-motors/products/gr-ep-45e-medium-power-45mm-12v-planetary-gearmotor).

Where things got really "interesting" is shutter automation. Looking at SGL and elsewhere, there's a wider range of solutions for this, and it seems to be the part of the project which causes the most issues. Initially I went for a timing belt + wiper motor approach, but this proved problematic. The 2.7m shutter is heavy, and the load on the motor changes significantly from fully closed, through mid-travel, to fully open. I had lots of problems with slippage, stalling and runaway, as I posted on September 10th 2020 on Steve's thread here: 

So I went for another 369:1 motor from Gimson, which has more than enough torque to deal with a shutter twice the weight, and fitted an 18 tooth pulley which engages with the AT10 timing belt strip that is secured to the inside of the shutter using "Sticks Like Turbo".

Mounting the shutter motor assembly securely was a challenge - I wanted to avoid drilling holes in the dome. The central seam provides one possible anchor point, but the motor assembly needs to be supported at both ends to provide enough contact pressure on the belt to work properly. On my version of the dome, there's a convenient channel on the inside, approx. 2 cm tall and 2 cm deep, that runs all the way around the slit edge - a consequence of the shape of the recess which holds the shutter in place - as shown on the image below. I use this to route the power and signal cables feeding the shutter motor and "open" microswitch - but it also provides a mounting opportunity.

So I exploited this by making a spring-loaded motor bracket which, on one end, bolts to a plate mounted on the central seam, and on the opposite end has a 1.9 x 1.9 x 5 cm aluminium block that fits snugly into this recess. The following photos show my bracket and the block (the white stuff on the block is adhesive which I used in a temporary fit check to mark up some screw holes). The spring is a 3.5mm diameter carbon steel spring, outside diameter 25.4mm, length 40mm. The hinge is a strong Eclipse fire door hinge.

 

The length of the bracket is precisely cut so that, when one end is bolted to a plate on the central seam, the block at the other side fits firmly into the recess. I originally made this mounting bracket out of 3mm Al plate, but the contact pressure with the shutter needs to be very firm, and the 3mm plate wasn't stiff enough. So I changed to a plate made of 4mm aluminium angle (sides 100 mm x 50 mm), which solved the problem. The plate on the central seam is 3mm Al, and that's working fine. This plate was originally designed for the wiper motor, but I've re-purposed for the new approach. You can still see the wiper motor mounting points on the plate. It's not elegant and I may re-make at a later date, but it works.

I was still getting a couple of slips near the extremes of travel, which I tracked down to shutter flexure - in the middle of the shutter there's plenty of rigidity, but at the extreme ends there's more flexure. I fixed this by fitting a 5mm thick Aluminium strip of width 50mm across each end of the shutter - you can see one of them at the end of the movie in this post (they're painted in white Hammerite). These strips remove flexure from the shutter, and the slippage is fixed.

The shutter is controlled with the fantastic MagicWire system designed by @hughgilhespie  , which works like a dream. It's powered by a 12V 9Ah battery which charges every day via a solar panel mounted on the lower shutter. There's a manual open/close switch on the control box, but for normal operation everything is controlled via Voyager. Microswitches provide open/close confirmation and power control. I wanted to provide a way of triggering the switches but allowing a few mm of extra travel just to bring everything to a standstill gently, so used some kitchen cupboard soft closing pistons as the "probe" to activate the microswitches. That seems to be working nicely.

 

Here's a video of the whole thing in action. "Sequences shortened" as the adverts say; with the DC soft start unit in-line, shutter opening or closing takes around 100 seconds in this configuration.

I was planning to fit an AAG Cloudwatcher for protection from weather conditions during robotic operation. But over the past few weeks I've been monitoring the data coming from https://openweathermap.org , and the current weather conditions reported are in excellent agreement with what I see at my site (there are clearly several reporting stations nearby which feed into openweathermap). So I've written a bit of Python code which calls OpenWeatherMap via an API to read the current conditions every 90 seconds, and generates a Boltwood-compatible file that Voyager reads and uses to trigger safe/suspend/shutdown signals in the event of cloud/rain/wind warnings. As a last resort safety measure there's a physical sensor - a Hydreon RG11 rain sensor on a post next to the observatory which overrides anything coming from the PC controller and uses MagicWire's safety sensor inputs to close the shutter in the event of rain being detected. On that same mast is a solar panel which charges a 12V battery for an uninterruptible power supply that ensures the system continues operate in the event of a mains failure, along with a long-range wifi access point that provides data link with my house about 50 m away. 

 

 

So far so good - remote operation is working well. There are a few improvements in the pipeline - I've repurposed brackets which were used for the original wiper motors, whose geometry is quite different (drive axis at 90° to the motor axis, unlike the planetary motors which are inline). The dome rotation bracket needs to be modified so that the hinge is rotated by 90° to give better rigidity on start/stop. I also plan to separate the dome rotation encoders from the drive pulley, onto an un-driven wheel in contact with the dome. This way the system measures dome rotation rather than motor rotation, which seems like a better solution. And I'm going to upgrade to heavier duty microswitches for the open/closed position signal - these ones work, but they feel a bit small and flimsy.

I hope this helps anyone considering shutter automation on their observatory. I have to say that I started this project to save some money - the Pulsar off-the-shelf solution seemed to be very expensive for what it is. The solution above has achieved the same results, and I've certainly saved money. But I've also spent a lot of time, and in retrospect I no longer regard the Pulsar product as unreasonably expensive. That said, this approach has the advantage that if/when things go wrong, it's very easy to diagnose and fix yourself, and there's some satisfaction to be had in that.

Thanks to @sloz1664 and @hughgilhespie for their advice during this project!

Nigel

   

[sloz1664]

Hi Nigel,

Fantastic news and great to see the project completed and working well. Humble thanks for the recognition, but glad it helped. Glad you have a rain sensor, I've been  thankful on more than one occasion with short sharp showers that were not supposed to be present. C/W actuated the dome closure within seconds and saved a soaking. Like you, without Hugh's MagicWire system I wouldn't be fully automated and yes it works a dream.

I've been using Voyager for around nine months and absolutely love it. It just works and I've now upgraded to the Array system to run two scopes in tandem.

Again, great to see you have completed, which is not an easy task and applaud  you on your finished project. I'll probably upgrade my shutter motor to your design this summer. The extra umph may be needed.

 

Steve

[steppenwolf]

Well done, this is a great and successful endeavour👍

[hughgilhespie]

Hi Nigel.

A very well thought out shutter automation project! I am really impressed with some of your innovations, particularly the use of the kitchen cabinet bits to give a 'soft' close action to the microswitches.

A nice sense of deja vu looking at your motor drive. Mine is below, motor mounted on aluminium angle, spring-loaded pivot point.......

Although my use of chain works well, it was a lot more difficult to implement than I expected and I if I had to start again I would definitely use the timing belt route now.

So, thank you for your kind words about MagicWire and my congratulations on a really nice project.

Hugh

 

[skybadger]

Interesting and well done. Almost finished mine which has been hanging around for a while now and uses an alpaca driver under voyager.

I'd make several suggestions- .

I find that the hygreon doesn't recognise snow.  Yesterday was a blizzard at times and the shutter stayed open. It's really good at rain mind. 

The 9ah battery May not be enough if you need to open and close on safety events during the night several times. 

Get rid of your pwm solar charger and get a mppt charge controller. They are more expensive but much better at charging and keeping your battery healthy. 

 

I have found the same soft of accuracy with the open weather api as you. To the extent that short lived gusts are measured as forecast. It doesn't do rain though !.

 

[NigeB]

Hi All,

Many thanks for your comments ( @hughgilhespie that does look quite familiar!)

@skybadger thanks for those suggestions. Interesting observation on the Hydreon - I went out yesterday when it was snowing and checked it - indeed, the telltale green light wasn't on, yet it's able to detect the slightest bit of rain. That makes some sense based on the detection method - a useful heads-up which I'll monitor carefully).

Re: the battery, I've got the charge controller set so that the electronics are not powered between dawn and dusk, which improves the charge/discharge ratio somewhat. I've managed 5 open/close cycles of an evening so far but not tested how far I can go before it fails (the motor is drawing about 3 amps on average). Weather permitting I'll see how many times I can cycle this weekend during the day.

Good point on the MPPT - I think the shutter charge controller is working well enough for the battery capacity, but I had hoped to run the 'scope, cameras and dome rotation from a 100 Ah battery, and the panel/charger really struggled to keep that battery topped up even with quite demand - the PWM charger could well be the weak point here so I'll try a MPPT unit - thanks for that pointer.

One final point, what OpenWeather API are you using? I'm using the OneCall API and rain data is definitely included, and seems to track local conditions here pretty well. However, the "rain" keyword is not always present in the JSON structure - it's only there when there's a non-zero value for rain, at which point it appears in both the "Minutely" and "Hourly" sections of the JSON structure. So in the Python script, I use a "try" operator, and set the rain condition according to the value in the ["hourly"][0]["rain"]["1h"] field.

Best Regards

Nigel

 

[skybadger]

Ah that explains why I get the occasional odd value . I've just never seen an openweather rain value in the raw json. 

that small panel will struggle to charge that battery once you start using it more.  My main dome battery is a 70Ah battery with a 130W panel (admittedly vertical on the outside wall so take cos( solar altitude) off the available power)  but I also have a second panel feeding the same charge controller for that battery. By the time the All sky camera, the weather station & rain gauge , the camera heaters, the ccd(s), the mount power and the dome interior lights are coming off that, it doesn;t last long.  I found the mppt about 30% better than the original PWM charge controller. Even so , I have a remote control charger on the battery as a last gasp which tops up the charge on a grey day. 

cheers 

Mike

[skybadger]

Here';s a pic of the difference between open weather and measured on site. light blue are my measurements, dark are the api.

I'd like to do the same for the cloud cover but havent worked out a way to extract it from teh all sky images yet.

[NigeB]

Hi Mike

That's a really useful comparison. Clearly there's no substitute for a weather station right next to the observatory, but the general trend in the wind speed looks consistent, and I'd feel confident in using the API wind data on the basis of what you're showing. It makes sense that the gust data are different - those measurements must be strongly dependent on the local environment in which the sensors are mounted.  (Aside: I speak as someone who, many years ago, received a text from a neighbour telling me how my home-made dome had just been seen floating across the fields. It was lifted clean off the walls and didn't touch the LX200 inside - despite there being about 30 cm clearance between dome and scope. The aluminium dome was dumped about 50 metres away. The cause was failure of the shutter, which flipped off, and allowed the wind to get inside the enclosure and lift it - but in any case, I regard wind measurement as essential now, along with some good clamps...).

Where I'm less convinced about the API is the cloud monitoring. From what I've seen, the OpenWeather API can report >75% cloud, when what I see here is more like low altitude mist or very thin, high cirrus that I'd consider imaging through in some cases. I'd be very interested in seeing the comparison with your All Sky Camera, and perhaps implementing something similar if you find good results from it. 

I'm not yet convinced that I need to buy a physical weather station given how useful some of the API data seem to be - I see many good reviews of systems like AAG Cloudwatcher, but also plenty of discussions about sky clarity calibration etc, so it seems that neither solution is free of issues, but the API is at least free...

I looked at the image-based approaches to cloud detection previously - I came across a solution from Tektite Skies that looked interesting:

http://www.mcdougalltech.com/page1/page1.html

Is this the approach you're taking? I'd be interested in hearing more about your system.

Thanks

Nigel

 

[skybadger]

Ooh. Ive seen that before but it would save me time if it worked. AI cloud detection is a faff.