Search the Community
Showing results for tags 'automation'.
Found 6 results
Hi all I am finally getting to the point of having a working dome and shutter driver from an electronics point of view: I have alpaca controllers and drivers for both, sensor switches in place for the shutter travel, encoder for the dome rotation, relay latch for unlocking the shutter, motor drivers for the opening motor. I've also put in place a bicycle-wire based winch system to raise and lower the lower shutter on an endless rope system. What's missing is this: When winching, the lower shutter rises on the rails up the slot and under the lower shutter to a certain point and then brings the upper shutter with it by virtue of pressing under the bottom edge. When the lower shutter raises to a certain point on the cycle, gravity takes over, the top part of the shutter unhooks from the lower part and slides down the back of the dome with a a crash into the buffers. I'd really rather that didn't happen, since the buffers and the dome they are attached to wont last long doing that regularly. I tried putting shock cord elastic between the two so the larger upper part couldnt run away but the lengths are wrong and wouldnt allow the shutters to close properly with the right length to prevent or at least dampen runaway. What I am looking for is ideas to prevent this happening in a reliable way so the dome automation can do its job, night after night. What I find is writing about the problem also helps me think about it, so hope this is useful. The winch system: The bicycle wire system has rollers on the inside of the shutter rail that guide the wire that is pulling the shutter up , which is fastened to the lower edge of the lower shutter. The wire goes up to the top of the dome, round a pulley and then back again, this time inside bicycle wire guide tube which mean I can more or less run it where I like with a small amount of give. In this case it runs back along the rail down to the winch. The wire wraps around the winch about 3 or 4 times and then fastens on the shutter again. Ideas: Something to make the upper shutter stick to the driven lower shutter on the way up and come apart on the way down ... Something to dampen the crashing of the shutter into the buffer... hope this stirs your creative engineering juices. Mike
I need some help from the automation gurus here to understand what I need to do to link observatory control with weather conditions. Having got my first observatory up and running, I immediately started to think about improvements (sigh!). I had not been thinking much about automation as I actively enjoy being out under the sky. So while running an astrophotography sequnce, I will often be using my Dob or binoculars to just look around in wonder. However, whilst this is great for the first four or five hours it palls if you go on too long. I had a nearly 8 hour session over the New Year that was satisfying, but exhausting. I know I can't do that too often. But here in North Wales the weather changes suddenly and forecast or not, I can't trust that I won't get a sudden shower hitting my lovely, sensitive kit. Clearly, at a minimum I need cloud/rain sensors and a way to park up the scope and close the observatory. My confusion is that I can't get my head round which bit of software/electronics does what when. Relays can provide the switching signals to open and close the observatory. Rain and cloud sensors can detect changing conditions to trigger action. But how do I link them together? My current arrangement has a mini-PC on the mount running NINA for control and acquisition and PHD2 for guiding. It works well. NINA has a Switch facility that I think can send signals to make things happen and detect conditions (also has a weather hub), but these seem to work through ascom. So although USB relay boards are widely and cheaply available, it doesn't look like they have ascom drivers. Do I need to run a set of relays via an RPi or Arduino to make it ascom compatible? I have read a number of references to client and server architectures so that one computer is monitoring the weather and controlling the obsy mechanics, and another is managing the imaging rig, but I don't understand how they talk to each other. People say INDI is the answer, but I can't visualise the layout and the relationship between the various bits. I read with interest (and with hope) the thread started by @steppenwolf on unattended observatories, but I could not follow it completely. It seems to be exactly what I was looking for, with the option to restart if the weather improves. But I don't understand how it was done. Specialised astro-control computers like the Eagle 3 might be the answer, but the price is steep. Can anyone point me to a resource that shows how these automation systems operate and what kind of kit beyond a mini-pc I might need? I am not wedded to NINA if Voyager or SGP will do a better job. I have no problem setting up and coding (within reason) a RPi or Arduino, and I am reasonable comfortable with scripting. I just have a mental block about how it all works. Once I have a thought model that works for me I am sure I can sort it out, but right now I am confused. Help! Please!
It's now been a year since my obsey was installed, so I thought I'd post a few details about how things have gone. I've focused on the automated parts....rather than me digging holes in the ground and pouring concrete... Firstly, a bit of background: about a year ago I decided that I wanted to move to automated observing which was motivated by the poor UK weather and the fact that I like my sleep - so, after a bit of research, I decided to go for an Ian King Roll Off Off Observatory - mainly due to Ian's excellent reputation and the fact that it came with various options such as an electric roof and a cloud sensor/electric roof controller that was Ascom and ACP weather alerts compatible. I decided on the smallest size available since I wanted it to blend into my garden to the maximum extent. Since I was interested in automation, I decided on a very small warm room, basically just large enough for someone to get inside. My design philosophy was that mains power and ancillary equipment would, as far as practical, go in the warm room and low voltage equipment would go in the main obsey. The picture below shows the external view of the obsey and the main interior. Since my telescope can hit the roof, I incorporated two safety switches on the RA and DEC axis, these switches are closed when the telescope is in the "telescope safe" position (see below). I've also incorporated a third safety switch on the drop down wall (above picture). So for the roof to open or close, all three switches must be in the closed positions. My second safety feature is designed to minimize the chance of rain from entering the obsey when the roof is open. I went for a total of three rain sensors, all of which are independent of each another. The main rain sensor is integrated into the cloud sensor and so far this has never failed. However, it is dependent on my obsey PC working correctly. I therefore decided that I needed a back up sensor that would trigger an alarm in my house if it detected rain when the roof when open- so I went for a battery powered wireless weather station approach - whilst this works, on testing it I was concerned that it requires quite a bit of rain before the sensor is triggered. I therefore decided on a more sensitive rain alarm sensor which sits on my warm room roof. This sensor also incorporates a heater, so needs to mains powered, it is interfaced it to a battery powered wireless alarm link to my house. For the time being, I've decided not to install a UPS but I do have a mains power detector alarm in the house. So, when I'm observing it's normally from a PC screen in the house. I recently decided to purchase CCDNavigator which has recently been upgraded to be ACP Compatible which makes programming an observing session very easy. Overall, I've been impressed by the physical build quality and the stability of the controlling software, which has proved very reliable. Alan
In 2015 I decided that I wanted to move to automated observing (basically due to the UK weather and the fact that I like my sleep) - so, after a bit of research, I decided to go for a Ian King Roll Off Off Observatory - mainly due to Ian's excellent reputation and the fact that it came with various options such as an electric roof and a cloud sensor/electric roof controller that where Ascom and ACP weather alerts compatible. I decided on the smallest size available since I wanted it to blend into my garden as much as possible. Since I was interested in automation, I decided on a very small warm room, basically just large enough for someone to get inside. My design philosophy was that main power and ancillary equipment would, as far as practical, go in the warm room and low voltage equipment would go in the main obsey.
I have finally got my automatic Flat-flap design up and running. This will be an integral part of my Observatory Automation project. The concept is that I want to be able to capture flat calibration files for each filter and to collect them immediately after an imaging sub-session before moving on to the next filter run. The auto-flat flap will be controlled by a VBScript from CCD Commander that will call on LesveDome software to operate a 'spare' switch on the observatory control motherboard. This switch will trip the onboard relay to turn on the Earlsmann EL panel's inverter and then move the panel into position in front of the telescope under servo control. The PWM (pulse width modulation) servo controller is programmable to allow the setting of servo start and end positions as well as transit speed. Control Panel Internal Components Servo Linkage A short Video Demonstrating the Action
Hi Everyone. I'm almost finished building a new dome and I have installed 12 volt motors / gear boxes to drive the dome. Now I am wanting to control the dome from my computer, so that the opening on the dome is always in line with the telescope. At this stage, thats all I want - I don't need the computer to open / close the shutter or to install a weather station or anything like that. My question is, what would be the simplest / cheapest option to achieve syncronisation between the pointing of the dome and telescope? I was wondering about using a raspberry pi or something like that? I've never done anything like this before, so if anyone has an idea, I'd be really keen to hear it. Thanks very much! Ross