My rudimentary DragScript to check for clouds

geastro · September 11, 2020, 9:02pm

Hi all

tonight I gave DragScript a first go. My needs are quite simple, I usually (for now) shoot one target per night. But I want to be able to leave things outside at dusk, aligned and focused, and pick it up following morning parked with some sky flats done as well.

Living in the UK it means weather can be tricky, I have a simple rain/wind sensor outside that alerts me if it rains for emergency, so only problem are clouds.

I wanted a script that somehow tries to guess if there are clouds, it waits, start the sequence if it’s clear (I manage everything from the pointing/guiding to meridian flip -forced- within the sequence), ends it at end of night, does as well some flats (using the flats sequencer) and then park.

The way I thought about checking for clouds at start of the session (the most important part as I think the sequence keeps trying if guide fails??) is to point roughly where it is my target, check if it can find a guide star, check if it can plate solve, and if both these are ok then it assumes there are no clouds…if any of the previous checks fails, it assumes there are clouds, and keeps trying every 10 minutes.

All the rest of failsafes are in the sequence I think, that it keeps trying on errors (unless I miss something!).

Sorry for the lack of Remarks/comments that might make it easier to read, but for me was more urgent to start testing it in the field (tonight is clear and it worked so far!) and most of all be alerted in Telegram more than in the console (see my other post to check my script to send Telegram notifications). Once I make it more final, will add Remarks so I can share it and can be more readable to others.

Do you have any suggestions? Improvements and other things I could introduce/try? I’m no expert just started, but would like to build a “default dragscript” to use with my “default sequence” and simply change the target(s) via Roboclip (like I did tonight).

Looking forward to comments/suggestions!

yzhzhang · September 13, 2020, 9:23pm

I haven’t done this myself but thought about this; Do you have access to OpenWeatherMap? You can create an account/API key with them, then you can set it up in “Observation Condition” in Voyager; Once you do that you will get updated (every 15 min I believe?) weather condition at your location, including cloud coverage; After that in DragScript you can create an variable to read from “CloudCover”, and you can build your logic from that variable… I think that’s easier.

geastro · September 13, 2020, 11:56pm

I wasn’t aware of that! I’m surely going to try it and see how reliable it is…I never found a reliable cloud cover service…Clear Skies and the others often say cloud coverage and is perfectlt clear, so i’ll check if this service is another one that predicts or is one instead telling me what’s the actual situation (that’s what I need).

I would probably anyway just add it as a check, till now letting my system check for cloud coverage has worked VERY WELL.

It helped both at start and during session after restart on guide failing to hold the sequence till the sky was clear again.

I’ll post updated version of the script and will try this, thanks a lot!

geastro · September 14, 2020, 12:46pm

Ok, OpenWeatherMap works VERY WELL! I added it to Weather Conditions and most of all to SQM, because via SQM and Update Decimal from SQM is possible in Dragscript to get all I need.

@yzhzhang thanks for the tip, implemented in my Dragscript for now just as Telegram warning, but depending on how it works I might add it to the variables of the decision process for weather. I actually think checking guidestar+solve+openweather is a really nice way to check for weather.

I do have a question: is there any way, during a sequence launched from within a Dragscript, to have a watchdog that for example checks every X poses (or every pose) how’s the weather executing another Block from the same Dragscript?

yzhzhang · September 14, 2020, 3:01pm

You can probably break your sequence to fewer frames but make it a large-number loop in DragScript, and insert a variable update/check as I described earlier before calling up the sequence in a loop?

geastro · September 14, 2020, 3:16pm

Yeah I thought about it but the Sequence is a very convenient and safe way to let Voyager deal with things like problems, flips etc., so I could break it in smaller chunks and repeat the block checking every time, but I’m not sure at that point is worth doing it.

Sequence works reliably for me and it handled nicely clouds, so I’d rather keep it like that.

Will see if there’s a way and will report back!

yzhzhang · September 14, 2020, 4:08pm

Sure, but just to clarify, what’s in my mind is: you still use sequence to manage all of those, but just limit your sequence to like 6 exposures only, and repeat that sequence all the time after a cloudcheck in DragScript (not in Sequence repeat setup). I don’t think you lose any native management Sequence provide.

geastro · September 14, 2020, 5:18pm

Actually is not a bad idea…I wouldn’t want to rely only on OpenWeather or only on my homemade system as one is not local and the other is, well, homemade solution, BUT having both checking every now and then and alerting me would be great.

I have anyway a weather station/sensor outside so if it rains that will alert me quickly!

steve · November 22, 2020, 5:49pm

Thanks for the sharing above @geastro, @yzhzhang. Voyager has completely changed my imaging routine, from nursing my rig through the night, to sitting comfortably in the easy chair wondering if the weather is conspiring to ruin delicate electronics.

Building on your thread, I’m experimenting with an early-warning setup, which consists of a WiFi Arduino module with an IR sensor pointed skyward (MLX 90614); A Python script pings the Arduino / IR sensor every 5 seconds via HTTP, reads measurements, and a simple regression on the most recent several minutes of data can predict when the trend will cross the ‘Clouded Over’ threshold temp; if clouds are approaching, send a Telegram (another great tip from you - thank you!) a desired number of minutes in advance, allowing me to get in front of potential rain event. I’m planning on coding this information into a string / file that Dragscript checks with relatively short sequences (yzhzhang idea above). Goal is to have the rig covered before clouds threaten. I just ordered a simple rain sensor which I will attach to IR rig as additional backup; total cost for rig will come in for under 50 USD (not including a battery I will add later).

Be happy to share details and IR data if interested; might be fun to integrate the OpenWeatherMap data, and beef-up the Python routine with a little ML routine to integrate & weight the inputs to make suggestions that manage the ‘wash rig risk’ using local & regional data.

Voyager · November 22, 2020, 6:10pm

Really happy to see you all using DragScript in those different ways … we have opened a trend with this technology approach. This is one of the reason why Voyager was born. Steve share your project if you want , I’m sure this can grow the community interactions.

All the best
Leonardo

steve · November 22, 2020, 8:27pm

Thanks Leonardo - combination of Dragscript and running homemade scripts gives us infinite possibilities!

IR data example from last night is here, and is interesting because clouds moving in are captured by the data; sensor collects 2 temps: 1 of the ambient temp of the device (brown line), and the other is the IR temp reading of the sky (or wherever it is pointing - blue line); I added a third, green line showing the difference between the 2 measures, which would seem to make sense as a measure of the difference between ground and sky temps. Very easy to see what is going on visually, though to predict cloudiness we will need to do some smoothing of short term ups and downs. Apologies to my friends outside of US - the vertical axis is degrees Farenheit:

geastro · November 23, 2020, 10:36am

I’ve actually done something very similar, with some more stuff. Based on Arduino as well, it does read IR of ground and sky, it measures sky SQM as well (as a double check because if there are clouds SQM will always drop as IR sky temperature rises).

I also have a rain sensor that’s heated so it doesn’t trigger for humidity/ice. It triggers after the first few drops.

It has two wireless connections: one via radio (no wifi) to the inside client (an arduino nano in the white box), that shows me everything and warns me with an alarm (for night when sleeping) if it rains, and I’m now implementing a lower alert if it sees clouds are rolling.

The other connection that blackbox has is on wifi, as it uploads in realtime all the data to thingspeak.com and from there I have other alerts (clouds) and an archive of all nights (useful to tweak the algorithm).

I still didn’t connect them to Dragscript because I want this system to be computer independent, it must work at any condition even if wifi/power goes down (they’re both powered by usb banks inside the box easy to recharge, they last for a few nights).

It saved me several times, if rains fall then I have time to cover it and have it no more wet than what would be during a humid night.

I noticed that is not so straightforward to understand when clouds are just passing (not a problem and Voyager is a champion at dealing with that) or when rain is coming. I have also humidity/pressure sensor in that box, and I see that there’s a relationship with that…but I have to collect more data.

Once I find a more reliable way of knowing when clouds are bringing rain, I’ll connect it to Dragscript so it can do my custom parking position to protect the lens, and warn me before first drops start. Any idea?

steve · November 23, 2020, 5:49pm

That is awesome rig - thanks for sharing, you are way ahead of the curve I’m on now. Some questions for you:

From big picture viewpoint, how is Voyager participating in the monitoring? So let’s say clouds roll in, I’m assuming that you will lose guide star, and the sequence will exit with the appropriate error. I’ll assume Voyager will Telegram you with this info on your phone (with Dragscript configured to do so). No rain yet so that part of your rig is idle, but your IR device is detecting clouds. How do you manage the different sources of data about potential for rain?
Radio - that is way cool! You’re probably reducing the number of devices that can fail in the communication chain - is that your thinking? My rig currently requires a working network for communication and connection to that network by both my rig and client to receive data and sound alarms. Would it be equivalent to set up the Arduino as a Wireless Access Point, and essentially create it’s own network?
Does your white box have an alarm? Does it distinguish the seriousness of the weather threat (e.g. raining now vs clouds detected vs Voyager lost guide star). Can it wake up a heavy sleeper, perhaps with light electric shock ;-))

It would be fun to collaborate on your query about distinguishing sporadic cloud cover from the rain producing variety. It sounds like you have IR data along with humidity and others; perhaps looking at the IR time series in the frequency domain would discriminate between the two types. Might be fun to take the data (including presence or absence of Voyager alerts), add whatever attributes we think might be useful and create an ML algorithm to generate a ‘weather threat’ state. This is something to do between the rare clear nights that we get here this time of year. . .

Thank you for sharing your experience @geastro.

geastro · November 24, 2020, 11:01am

Hi Steve,

replying to your points, all very good:

Voyager is not working “with” my rig, not yet, because understanding when the clouds bring rain or not is not possible at the moment, and I had many nights with some clouds rolling in and staying, only to clear up later on to leave a good few hours of clear skies. I use only Voyager watchdogs. The “cloud” management is all done in Voyager: if there are good continuous clouds, I’ll loose the guide, Voyager will keep trying, at some point if Sequence fails, it exits but Dragscript is instructed in that case to restart it again. And at the start of night or new object, my Dragscript waits until it can acquire a guide star and can solve a position in the sky near the target, if it cannot it assumes there are clouds, waits 10 minutes and re-tried. So basically if the whole night is cloudy, Voyager will keep trying till end of Astronomical night, then will park. Having watchdogs in guide and in focusing routine to not accept bad values, is all I need. Can’t forecast, but we can act on it quickly with Voyager using Dragscript to manage a Sequence.
the point of radio is, whatever it happens, I need to know if it’s raining while I’m sleeping or doing something else, because clouds are managed by Voyager, but rain needs me to cover the telescope. Even if the whole power of my house goes down, it can rain, so I need to know, hence the radio and the battery powered devices. Having Arduino as WAP in theory is the same, BUT you have two main problems: range of wifi is smaller, more tricky to fine tune transmitting and receiving amps power. With the NRF24L01 module is instead much easier and I have powerful signal even through many walls. Second point is: a wifi connection adds a lot of layers for tcp that are not needed, add complexity, and make reliability and speed lower. I want a 100% reliable rain alert, independent from network/phone (that is in not disturb while I sleep), hence radio is the simplest and most reliable way to cover that.
the box is a radio client, it does not connect to wifi, it only connects via radio with the box outside. Yes the audio speaker is in the client, and it doesn’t tell me if there are clouds, I don’t need to know, Voyager deals with them very well. I only need to know if it’s raining, as soon as possible. So on the box display I can see sky quality SQM and IR and all readings and know if there are clouds, but important is its audio alert if it rains. The speaker can be very loud and annoying, I’m light sleeper so I set the frequency very high (lower volume and less disturbing as the speaker can’t really go loud past 1/2khz).

Basically is the box outside the only one that connects to wifi to transmit the data readings to the cloud, and if wifi goes down it doesn’t care, it will simply keep going on. Priority number one is to know if it rains, so all code is done for me to know if it’s raining.

I now finally have good night sleeps while imaging, it happened a few times I was woken up and had to cover the telescope, so I know it works. A few drops are dry by the morning simply leaving scope head down under the cover and with dew heaters on.

So using apps like DarkSky to know if there will be a likely chance for rain, and then this system, is all I need…and Voyager deals with clouds. If I had an obs, I would connect it all to the rolling roof and Voyager, but because I don’t, I don’t think I need to connect the two…

Having studied a lot of statistics and math, I don’t think there’s any reliable way to ‘predict’ rain from a system like this…I think is better to optimise it to act on what’s really happening as soon as possible instead of trying to predict, if it makes sense?

steve · November 28, 2020, 5:40am

@geastro, thanks again for the detailed reply. The good night’s sleep is the common goal, so I very much appreciate your strategy here. By letting Voyager continually watch for clear sky, you need nothing more than a reliable and direct wireless rain alarm. Using radio is brilliant.

Thank you for sharing - with your permission I may p.m. you for further details as I get further down the road.

geastro · November 28, 2020, 10:45am

No problem please do. I’m now using a similar system as I moved my setup outdoors where I live the heavy duty pillar tripod and mount.

So I’m making an Arduino that is on the mount, checks humidity and temperature (it’s on only when setup is covered with bed sheet plus weatherproof cover closed at bottom but not too much to let air flow). The arduino has also a wifi connection to let me know situation under the cover.

There’s a relay connected to it that powers a car 12v fan/heater (summer/winter), and turns it on when temperature or humidity go over certain values.

And with wifi lets me know always what’s situation. Works brilliantly, outside has been down to 0 and under the cover was a nice 10 degrees and humidity between 50% and 70%, and all with just one 12v cable going outside.

Love Arduino!

geastro · December 12, 2020, 10:29am

A new evolution of the system I showed here. The black box has been moved into a transparent junction box powered by 12v, functions are the same but now there’s also a Raspberry4 with an 160 degrees allskycam active automatically at night with photos uploaded on my server every 5 minutes with all the sensors data written on it.

Sensors are still on Arduino, so the two communicate via usb serial, useful as well because I can program the Arduino from the Raspberry in the same box without ever opening it.

So from that junction box I get IR temperatures of sky/ground, sqm, lux, humidity, pressure, rain, every few seconds, plus a photo every 5 minutes.

I still have also a radio (not wifi) client indoors with an acoustic alarm for rain and a display showing me in real time all the sensors data, as at night or when sleeping I keep phone on silent.

Next step is going to be a simple connection from all this to Dragscript/Voyager so that if rain sensor is triggered (it never produces false positives as it’s the more expensive warmed one) then the scope is parked automatically. Not sure yet how to do this communication, but will investigate should be simple.

The languages used are C for Arduino, Python for communication between the two and Bash scripts for coordination of everything on the Raspberry.

Talking of automation, if interesting I could do a separate post about another Arduino project that literally changed my astronomy: an automatic system to keep humidity and temperature under control to be put under cover for the mount that I leave now always outside. It’s made of Arduino and a 12v fan/heater and a temperature/humidity sensor, code keeps humidity always around 60% and temperature always around 10 degrees higher than outdoors, and during summer it uses the fan to keep it drier and cooler. At the same time it uploads measurements and heat/fan statuses on cloud to keep records and possible alerts of extreme conditions.

It’s now out since two months, managed lots of rain, humidity, some snow, it’s fantastic and I can leave all outside (if multiple nights seem good I leave ota as well), and a simple combination of cheap hanging chairs weatherproof cover+old bedsheets closed (but not super tight) at bottom of pillar, and it’s always nice and dry, and during the day or when conditions are not extreme it stops automatically and starts as needed, with histeresis implemented to avoid on/off across the thresholds.

Both systems are powered by 12v so a nice long 12v flat cable is simple to leave outside and pass through windows without having to leave main power outside.

Voyager · December 12, 2020, 2:36pm

Create an ASCOM Safety Monitor driver and setup here:
https://wiki.starkeeper.it/index.php/Safety_Monitor_Setup

geastro · December 13, 2020, 12:45am

That’s exactly what I thought I saw in Voyager and couldn’t remember…perfect!

As usual, Voyager thinks about everything before I even think about it myself

peter_4059 · December 13, 2020, 7:11am

I’ve gone down a similar path with Arduino based IR sky temperature and ambient to predict cloud and measure other observing/weather data including light, rain and wind. I also have relative humidity in my cloud model as I found the simple temperature difference wasn’t sufficiently accurate at predicting cloud here in Brisbane. I’ve written a PC app that picks up the sensor data from the Arduino, completes the calcs, writes a single line file (that can be read by the observing conditions Ascom driver) and handles display and alarming.