SGPro+AAG Cloudwatcher (Safety option)


#44

This is the sort of Observatory Control I was thinking of:
image
The dome shutters are animated of course.
Or a ROR:


Closing the roof doesn’t work well.
image

That’s fairly easy to fix but at present it crashes if you try to use an ObservingConditions monitor, possibly because that was a precursor to the Weather monitor and was never released. It was the Weather/Safety that killed this, it became impossibly complex to implement or to design a UI that was comprehensible to me - and if the developer can’t understand his own interface there’s no hope for anyone else.

I might revisit this over the winter, if I get sufficiently bored, but quite probably not. I’m not inclined to open the can of worms that supporting something like this would be.


#45

I went through what is needed for a safety monitor based restart last night. I think we can get something pretty minimal up in the next couple of weeks. You’ll need to set the Start/Stop times on each target and the existing logic for choosing a target will be used. Essentially SGP will abort and restart the sequence if an unsafe condition occurs. The unsafe state will keep the observatory closed and mount parked. Once it becomes safe again SGP will pick a target and start imaging again.

To be able to successfully use this you will need to:

  • Set start/stop times on all your targets
  • Have all options set so that clicking “Run Sequence” will start your guider, center/slew, etc (essentially if you can run a time delayed sequence successfully this should work for you)

I have yet to determine where this option lives. But it will likely be part of the Equipment Profile/Sequence.

I’ll also be looking for a couple of testers who are already using a lot of automation with observatories @joelshort @buzz ?

Thanks,
Jared


#46

Happy to help. I have independent failsafes on my observatory roof and mount that should trap any potential kissing. Not much in the way of night time in the UK at the moment…
regards


#47

Haa… now that is the Spirit! Thank you for bringing this solution and creative idea on the table. Jared & Buzz thanks for your recent massages guys. It has made a difference for me.

We should all try (on this forum) to keep an open Agile mindset and stay genuinely focused on finding solutions (rather than arguing all the time or focussing on the problem).

Let’s look for solution, solve one problem at a time, make hypothesis, build, test, learn, prioritize, iterate and repeat until we find the right approach that suites our needs. That’s the Spirit we need in my opinion.

Thanks again for the above solution. That is a great first step in the right direction!

Have an awesome day everyone!

André :slight_smile:


#48

We almost always try to. We’ve been doing Lean/Agile/Kanban for many years and certainly find value in “putting things out there” early rather than attempting to find the best solution first. Perfect is not the enemy of good!

Sometimes things go off the rails and some nights I’m going through a LOT of messages at once so don’t always catch when things start to go in that direction and instead end up focusing on the bad. Certainly not the best approach, but I’m human after all.

Thanks,
Jared


#49

I totally understand Jared.
Thanks again for your message and have a great day.
André


#50

Just thinking about this. If it requires start and stop times then one thought says the option to start again would reside in the target planning dialogue. I’m guessing that SGP would go through the same logic as when you hit the initial run sequence. If that is the case you may need to check the PHD2 resume logic. At the moment, this has some gremlins and can leave PHD2 behind in some cases after a pause/abort.


#51

Another thought occurred Jared while setting up the new beta and disabling light level as a critieria - Chris wrote both an ‘OK to Image’ and an ‘OK to Open’ monitor . Using both of these allows one to set some hysteresis between a clear unsafe condition and a ‘its worth a try’ condition?


#52

Yes, there are likely a lot of things that this will unearth. Essentially any dialog box that pops up at sequence start would cause a problem for a restart. Although you should have already worked out all those issues. It will certainly test how robust restarting PHD2 is as well as your ability to get back on target and start “from scratch.”

Yes, maybe something we can look at later on but for now I would prefer to keep things as simple as possible. Adding other permutations and logic will just muddy the waters initially. Right now there is only a single boolean that the safety monitor has to consider. I think this is going to be tricky enough without adding anything else to it :grimacing:

I could certainly see a state where we would disable tracking and guiding to wait for clouds to pass and then start again without parking and closing up shop while we’re waiting though…just not for the initial pass.

Thanks,
Jared


#53

Yes… I was just musing. There are a lot of ex engineers who are astrophotographers!
Just let me know what you want me to test - I can start a sequence and fabricate an unsafe condition with a watering can and then dry off the sensor to see what happens, keeping log files along the way. It might make sense to run a screen capture video at the same time- that can be quite informative.


#54

Jared - the most obvious of these is the ‘telescope detected but parked’ dialog - I’m assuming SGP will park the mount when unsafe conditions occur, but it requires manual agreement to unpark the mount when you run a sequence.


www.mainsequencesoftware.com