Loop until success
Issue #1119
closed
The UK’s maritime climate means that often a night can start cloudy but will become clear later. It is impossible to forecast with any accuracy as to when (or indeed if) if becomes clear. I have a dome linked to an AAG Cloudwatcher, this automatically closes the shutter in unsafe conditions. In order to prevent the dome from opening and closing every 5 minutes my cloudwatcher’s definition of unsafe is quite loose. It will always close immediately at the 1st sign of rain but will stay open if clouds and or light are a bit border line.
My default sequence uses ‘Slew and centre’ in three scenarios; 1) for initial target acquisition and b) if clouds temporally send guiding off course and c) on reopening of the dome if had closed due to ‘unsafe’ conditions.
In each case I can’t ‘loop for iterations’ as it may only take one iteration to acquire the target or it may take ‘all night’. It’s the same problem with ‘loop for a timespan’ as conditions may allow a quick acquisition or it may take hours for the clouds to clear.
On discord/suggestions eigenVector-(darkflats.com) was kind enough to suggest a workaround involving increasing the number of tries ‘Slew and centre’ makes to a very large number. The problem with that is last night my dome closed while a ’Slew and centre’ was taking place. This left my setup taking pictures of the inside of my dome. Also there may be a problem with this workaround in the case of a meridian flip.
My suggestion is the addition of a another loop condition….. Loop until success. In this case the subsequence would loop over (for example) “switching filter, set tracking, run autofocus, slew and centre, start guiding” until all were successful. It would then exit the loop.
I can see that this loop would be useful in a number of circumstances and it would not cause a conditional fork in a sequence (which I regard as very important).
Comments (16)
-
-
reporter
Thanks Marc. You are right, it does sound like a “many tries slew and centre” command should be in effect the same as a “loop until success”, however there is a compromise , a definite problem and a potential one involved in the workaround.
- An efficient plate solve (normal) would have a delay of a few seconds. An efficient plate solve (many tries in a slew and centre) would be (say) 5 minutes. A compromise to get ‘many tries’ in a slew and centre command to work as a ‘virtual loop’ means that at the beginning of the night (when sometimes conditions are oscillating a bit between safe and unsafe) is unnecessarily long. Not a huge issue, but we don’t get many clear nights in UK so I like to waste as little time as possible.
- There is no way out of a “many times slew and centre loop” other than a successful plate solve. This seems fine but if (for example) the camera losses focus while carrying out this ‘virtual loop’ or (as happened to me two nights ago) the dome shutter then there is no way out of it until all the failing tries are used up. In normal circumstances there is no point in continuing if slew and centre fails and so my sequence is set to shut down. A “loop until successful” would allow for short plate solve tries and the possibility of using an autofocus trigger (or event) or open shutter command to get out of the loop.
- What happens if the mount needs a median flip whilst it is in this ‘virtual loop, I genuinely don’t know, but I suspect it wouldn’t get one in which case it would be back into a loop with no way out.
I hope that clearly explains the issue and thank you for taking the time and trouble to comment.
Ian
-
I’m not sure why we’re trying to compensate for equipment that’s doing its programmed job. Using a cloud sensor to infer the presence of rain, when it might just be a passing cloud or contrail on an otherwise fair night, seems like you’re starting off on the wrong foot. If you wish to detect rain and guard against it, then you ought to employ an actual rain detector. The only thing a cloud sensor is good for is knowing if your view is clear, not if it’s about to pour. Lunatico provides an IR rain sensor upgrade (based on the RG-11) for the Cloudwatcher. I have one of these (not connected to a Cloudwatcher) and it can be set to be sensitive enough to trigger on spittle. The upside to this is that you are reacting only to specific conditions (it’s actually raining) rather than inferred conditions, which might very well be wrong.
The meridian flip question is important to consider because any missed flip can run the mount into its set limits, which can respond with anything from stopped tracking to a full-on parking of the mount. This will bring the session to an abrupt and unrecoverable halt (by design; these are safety limits after all.) Every time a solve-until-success cycle stars, it must look sufficiently forward in time to know if there is the possibility of the limit being busted while it’s working.
-
reporter
Thank you Dale. I don’t think “we’re trying to compensate for equipment that’s doing its programmed job” neither are you suggesting (I’m sure) that NINA only works if you buy certain equipment.
I have a rain detector built into the cloudwatcher. Like you I have it set up so that ‘unsafe’ is triggered at the first sign of rain. I also have unsafe triggered if light or clouds make imaging a waste of time (not borderline - a total waste of time), but it doesn’t really matter how unsafe is triggered. For example let’s say that ‘unsafe’ is triggered by a passing shower during a ‘slew and centre’ command. The dome shutter closes automatically but ‘slew and centre’ carries on all night taking pictures of the inside of dome. Of course these circumstances are unlikely but they are possible. Made more possible by the inclusion of cloud and light triggers.
The circumstances I am trying to cover are typical in UK. The night is going to improve but timing is impossible to predict. I want to set my sequence going knowing that when conditions improve the sequence runs. No matter where I set (the safe / unsafe conditions) there will always be a borderline between the two and the potential for a “slew and centre many times” virtual loop to entered with no triggers for exit.
A ‘loop until success’ condition would not break the principle of not having conditional breaks and I guess would have many other uses.
-
The one thing I can’t piece together from your description is how you’re even getting to Slew and Center with the shutter closed and the safety monitor driver reporting an unsafe condition. A safety monitor driver that reports Unsafe=true should trigger a cancellation of all running instructions and force an exit of the container that contains the Loop while safe condition. The container after that would contain your dome close-up tasks. Slew and Center should have either not been reached or was cancelled if the unsafe condition occurred in the midst of it running. If Unsafe=true is asserted and your sequence isn’t cancelling the running task and exiting the container, then I’d want to see how you have things set up to make sure you are following the intended design and that there’s no bug being tripped over.
After entering your unsafe condition container, which contains the shutter closing, mount parking, and any other things you need to do to close up, the last thing it should do is Wait until safe. Things should pause right there for the duration of the unsafe state. There should not be any slewing or centering or anything of the sort going on while the driver reports unsafe=true. When things become safe, the loop starts moving again, wrapping back up to the top where you have your dome opening, then your DSO container with your target and any slewing/centering commands. This is why I’m perplexed as to how you’re getting into the situation where you’re running Slew and Center but with things obviously closed up.
The one unfortunate thing about the ASCOM safety monitor specification is that it’s purely binary - It’s just “Is it unsafe? Yes/No.” There is no way for it to report a more of a guarded condition that can advise an app to suspend what it is doing (ie; just stop exposures) without triggering a full closing. In this case, it would be nice if the spec were flexible enough to allow the Cloudwatcher to report a guarded state when it’s just clouding up, but then report unsafe if rain is actually detected.
You mentioned using Slew and Center for cases where guiding has taken things off course. Are you running this for every image? If so, a better instruction is the Center after Drift trigger. This plate solves every image and will trigger a recentering if the coordinates of the images' center stray farther than a set distance from the target coordinates. This way, you’re doing a centering operation only when you need it, not every time, even if you don’t need it.
I’d really like to see an example of the template you’re working off of for this.
-
reporter
Thank you Dale. I will answer your question but first let me go back a few stages. I don’t know where you live but the UK has a typical maritime climate where the weather can be very changeable. It is quite typical that a night can start off completely overcast but be very clear later on. The timing of the change is impossible to predict with any certainty. So the issue is when to start ? I could wait up but, what’s the point of automation software if you have to wait up for good conditions before you start a sequunce.
So sometime in the night the clouds will (probably) clear, but as you have spotted, regardless of how sensitive or lax you make the safe / unsafe decision it is only binary for a short time around the cusp. There is virtually always a period (of indeterminate length) when the sky oscillates between safe and unsafe. My sequence has all the start up done ready for nautical dusk. Then it waits for safe conditions before it enters a centre target routine which includes a slew and centre command. The first time this happens conditions are going to be both borderline and changeable. On a balance of probability the plate solve is going to fail. My original sequence decision was to either let if fail and carry on imaging a non-centred target or exit the sequence and close down. It was suggested to me that if I increased the retries, my sequence would enter into a virtual loop. The problem is that this loop could be virtually infinite if focus is lost or the dome closes (as happened to me) and there remain meridian flip issues.
I am not the one doing the coding so I completely understand reluctance but it seems to me that actually a “loop until success” completely mirrors the real life decision making logic, making anything else a ‘workaround’. I feel sure it would be useful in a number of scenarios and does not offend a completely understandable ‘red line’ of not having conditional forks in the sequence.
Please find attached a link to my sequence, I will remove it once you have viewed it. sequence
Thank you for taking the time and trouble to look at this issue.
Ian
-
reporter
Dale, I wondered if you had a chance to look at my sequence ?
I have looked at it again and tried to work out how I could satisfactorily get around the issue I have without a “loop until success”. Everything I come up with is a clumsy workaround.
The circumstances I am trying to cope with are not uncommon i.e. a night that starts cloudy but is due to clear up. I have a cloudwatcher and it is set to call ‘unsafe’ if light or clouds are marginal or at the first sign of rain. So, it if ‘quite’ cloudy, raining or too light it calls ‘unsafe’ (and a sequence that copes with this condition is very easy to write (e.g. wait until safe).
It is also relatively easy to write a sequence that copes with worsening conditions (having once found the target) e.g. resume guiding and / or centre after drift.
So ,I could define “unsafe” much closer to “no clouds” but regardless of what setting I use there will be a time (on the cusp) where conditions fluctuate around safe / unsafe. OK , so I could add a delay after unsafe->safe, but how long ? I could even restrict ‘safe’ to virtually cloudless nights but in UK that would mean very few nights imaging at all.
Also ‘on the cusp’ cloud watcher could declare ‘safe’ but the target could have clouds preventing a plate solve. Again, I could get the plate solver to try many times, but how many? Is this blocking the sequence from refocusing, meridian flip etc ? Of course, the opposite could be true and cloudwatcher could remain ‘unsafe’ with the area around the target being relatively clear.
Maybe I am just seeing confirmation bias in all these thoughts, but I keep coming back to “loop until success”: A) It would be an elegant solution; the alternatives being ugly workarounds, B) It would be a solution that accurately reflected the real life “start imaging / don’t start imaging” decision and C) It would not offend the important principle of not allowing conditional branches in a sequence.
Thank you
Ian
-
repo owner
Ian have you looked in Discord at Jerries Dome Automation Sequence?
It is pinned in the Sequencer2 Channel: https://discord.com/channels/436650817295089664/769608646215598101/928047826036994078This basically covers the scenarios of switching SAFE and UNSAFE conditions. In addition it also requires that the safety monitor reports at least 10 minutes of safety before restarting the imaging.
-
reporter
Thank you Stefan, I will take a look in the next day or so.
Ian
-
reporter
Thanks Stefan
That’s very similar to my sequence with the same issue.
On a night that starts cloudy but becomes clear there will be a time when safe / unsafe fluctuates. As you say Jerrie covers this with a 10 minutes of safety before continuing the sequence. 10 minutes is arbitrary; some nights it may be too much others not enough. It wouldn’t matter so much but if conditions are fluctuating it may go safe / unsafe a few times. So that’s 10 minutes every time.
Jerrie’s sequence doesn’t stop if autofocus, slew and centre or guiding fail it goes straight into taking images. Nothing lost as they can always be deleted but given I have an ASI6200 that’s a lot of data to transfer across my network and open in Pixinsight blink only to be rejected.
I guess the bottom line is …….. there are of course workarounds and I truly appreciate all the suggestions that have been made to me. If no one is prepared to write the code, then I will have to make do with workarounds. I’m not complaining, NINA is brilliant, and I am very grateful to all those who put time and effort into maintaining it. It just seems to me that a “loop until success” would be a valuable addition. Unlike a workaround this loop would truly reflect the real life “image / don’t image” decision under fluctuating skies.
Ian
-
The safety monitor device should “debounce” the safety state that it’s charged with determining to prevent a rapid succession of safe/unsafe state changes. This 10 minute wait is an example of the need to work around that lacking in a sort of ham-fisted way. Ham-fisted, because that timer will reset every time there’s a transition from unsafe to safe. It would be much better if the device managed it in ways that are suitable for each kind of sensor it might have, where rain sensors would have a longer trigger period than the cloud sensor might, for example. Luckily, you can change that 10 minutes to something that is perhaps more palatable for yourself.
It would also be better if there was a guarded status that could be conveyed by the ASCOM safety monitor interface, such as if the cloud sensor senses that it’s cloudy but the rain sensor (and perhaps the dewpoint+ambient temp) agree that it’s not raining. This guarded state could be used to suspend imaging operations, maybe even go as far as to park the mount, but not close up the observatory which would save time when the clouds pass and it’s “safe” to resume imaging again.
I’d much rather see those systemic improvements than attempt to divine the state of the sky based on the failures and successes of a gaggle of unrelated instructions and a very coarse and contextless safe/unsafe state of the safety monitor. And, to be frank, we presume that the user has decided to image under clear, or expected-to-be-clear, skies. A passing cloud should be a temporary and occasional disruption; not a chronic occurrence. We include triggers to recover quickly from these events, with Resume Guiding and Center After Drift.
I get it that you are where you are and have to deal with your local weather patterns, but the rapid and, I guess prolonged(?) clouded state is not the common case that things have been designed to. Perhaps you can use the Image History viewer in NINA to triage obviously clouded images with the
/
button that’s available on each, and renames the ‘d file accordingly so they can be easily excluded from transmission later. You can also consider using the Remote Copy plugin to copy images to your processing PC as they’re taken over the course of the night, so you don’t have to endure a single bulk file transfer of everything in the morning and make blinking them in PI a task you can immediately start. Since you use PI, you can save the files in XISF format in NINA, with LZ4-HC compression on, so that your normally 120MB ASI6200 images are compressed, usually, by 40%-50%. -
reporter
Thank you Dale I really appreciate you taking the time and trouble to reply in such detail.
I understand your position.
“It would also be better if there was a guarded status that could be conveyed by the ASCOM safety monitor interface…….” This is perfectly possible (it’s what voyager does) by loading and reinterpreting the json file produced by a cloudwatcher, but that (it seems to me) is a huge amount of coding. I prefer NINA’s more simplistic approach if only I could capture the safe \ unsafe transition on a cloudy becoming clear night.
“And, to be frank, we presume that the user has decided to image under clear, or expected-to-be-clear, skies”……. This is perfectly true and a very sensible assumption on your part.
“I guess prolonged(?) clouded state is not the common case that….” My guess it is more common than you think especially in Western Europe.
As I have said I will have to look at workarounds, but I reiterate the point that a “loop until successful” is a truer reflection of the logic involved. Everything else is working around the problem not dealing with it. On the face of it, a simple elegant solution. In the sequencer one loop replaces a more complicated series of safe / unsafe loops. Although I fully admit have no idea how difficult it would be to code.
To be frank I don’t want to waste your time any further by arguing in favour if there is no chance of the team adding this facility. Should I give up gracefully ?
-
repo owner
- removed version
Removing version: 2.0 Beta (automated comment)
-
“Loop Until Success” is on my radar for an upcoming version of Sequencer Powerups (for NINA 3.0)
-
“Repeat Until All Succeed” is an instruction in Sequencer Powerups, available for 3.0
-
repo owner
- changed status to closed
supported by Sequencer Powerups Plugin
- Log in to comment
I’m not sure how this is different from having a huge number of attempts for slew and center. Wouldn’t the loop you’re suggesting just continue to attempt slew and center indefinitely as well?