There are several reports about star trails on images taken during alignments. The reason why it sometimes happens that image capturing starts before a slew is complete, is not fully resolved yet.
This change intends to make alignment robust against scope movements during imaging. As soon as a slew motion is detected, capturing is aborted.
Test case 1: Slew to an arbitrary position and start plate solving. Move the mount while imaging. Observe that imaging gets aborted and plate solving starts again when the slew is finished.
Test case 2: Do the same with the mount model builder. Check whether a movement during imaging aborts capturing and retries plate solving for the current alignment point.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 18957 | |
| Build 18975: arc lint + arc unit |
This looks like a great idea. I haven't had a chance to set up my telescope, but I did try it in the simulator. I held down the arrow button on the Mount Toolbox while it was trying to solve an image, but it still successfully solved the image. I am not sure if the CCD Simulator didn't give the same signal that a real mount would, but I would have expected the solver to not complete until I stopped pressing the slew button based on what you described and what the code looks like.
You are right, the motion commands are not detected, since INDI handles them in a different way. If you issue a slew command in the mount box, it should work.
I think the manual motion commands aren't the core problem here, but I will take a look if I could handle them as well.
Handle mount motions during plate solving and abort when a mount motion is detected. As soon as the motion has finished, aligning continues.
Additionally, I fixed a concurrency problem when an abort occured while a timer is running for a delayed start of captureAndSolve():
Thanks! I have to test this thoroughly. Btw, I believe I encountered the "star trails" issue only a couple of times in the last few years. I believe it is also related to driver race conditions such as what was happening to iOptron:
I propose that in step 5, we do another sanity check. We check if mount is _still_ tracking or not. If not, then we bail and wait until it stops. Does this sounds like a reasonable solution?
@mutlaqja: I think the origin of the star trails is a behavior of many mounts that you fixed for iOptron. I observed a "hickup" in the logs of a 10micron mount, where EQUATORIAL_EOD_COORD shows the following status after a slew is issued:
My explanation is the following: when a slew command is issued, the immediate status response is IS_BUSY - so everything is fine at this stage. This is the standard behavior of inditelescope.cpp, which many mounts use as basis.
The problem comes in when EKOS asks for the scope status shortly after the slew command has been issued. It seems like some mounts then answer with IPS_OK although they has already received a slew command, but has not started to execute it.
If this happens, EKOS gets confused because it could rightfully assume that the slew command is already finished.
So I think the best way to fix this for all mounts is moving your iOptron fix up to inditelescope.cpp, because I would not be surprised if many mounts show this behavior and it is not iOptron specific.
But since I do not have a test scenario where I could reliably reproduce this situation, I postponed my idea fixing INDI and created this fix to make the align module more robust.
I suppose this can be done.. i.e. call readScopeStatus from within SLEW and just confirm the track state is indeed slewing. But ... this could lead to issues.. what if you slew to the same place? or very close by? by the next time you call readScopeStatus, it would be indeed SCOPE_TRACKING and Slew would return failure (after it times out from multiple attempts) even though it completed successfully.
Good point, so let's be careful with the core INDI driver. That's why I thought it would be safer making the align module more robust rather than tweaking the INDI driver, without knowing exactly the consequences...
With this diff I added a set of debugging messages so that we could get more insight how the real behavior is.
What about my idea above that we check against after settle is complete? Could this be incorporated into this PR as well?
- After settle-ms is complete, it captures an image to solve. I propose that in step 5, we do another sanity check. We check if mount is _still_ tracking or not. If not, then we bail and wait until it stops. Does this sounds like a reasonable solution?
I would say that is already covered, since the align module receives all events regarding to the mount status and reacts immediately upon these events. The only thing that might happen is that it receives the update while it is already capturing.
But on the other hand, there is no guarantee that a tracking mount remains tracking. So it could happen after settling that the mount changes its state.
Agreed?
Right now we have this:
QTimer::singleShot(delaySpin->value(), this, &Ekos::Align::captureAndSolve);
What I suggest is that instead of immediately calling captureAndSolve, we make it call another function like verifyAndCapture
in this, we check the _current_ scope status. If it is SLEWING, then we do not proceed to captureAndSolve and we know this only means there was a problem and we can change the status of align status to ALIGN_SLEWING so that it takes care of it once we finally TRACK again.
What do you think?
Good point, this would at least cover the cases where a new IPS_BUSY occurs during settling time. That would mean for users that see this happen they simply could increase the settling time.
Would you add this on top or as a replacement for capturing arbitrary slews?
That's a good question. I'm not sure ... if we add as is, how would interact with your changes since you're already handling arbitrary slews? would it be redundant?
It would not disturb, but it is partly redundant. The current change covers all, but vice versa if the settling time is too short, it will slip through. I only would avoid having both - with the perspective to future maintainability.
Another subtle thing: if we check after the settling time whether the mount is tracking does not obey the original intention of the settling time. Settling time means that the mount needs to have some time after a motion to settle. If we only check after the settling time whether the mount is tracking we do not ensure that the mount had enough time to silence down.
Yes, I agree. But this is just another sanity check. i.e. if the mount is slewing after settling time timesout, then something is very wrong and the state changes to ALIGN_SLEWING... after which is will actually end up calling settling again.
Yes, I agree. But this is just another sanity check. i.e. if the mount is slewing after settling time timeout, then something is very wrong and the state changes to ALIGN_SLEWING... after which is will actually end up calling settling again.
Sorry for being stubborn, but I don't see how this could happen. If the mount changes from tracking to slewing before we reach the end of the settling time, it should have been already detected by processNumber() or processSwitch().
I could add this sanity check here, but I do not see a way how I could test it. Maybe with a polling interval significantly longer than settling time, but it still might happen that processNumber() steps in first.
Ok then it would be redundant in this case, we'll test your changes and can probably diagnose better with the additional logs.
(I originally posted this comment in the wrong diff, sorry)
With that change incorporated (own build of Dec 2), my eqmod-based setup stalled at least once just after the first second alignment.
That second alignment required an additional adjustment, the mount operated the requested slew, but the alignment module didn't proceed further.
I believe this log extract points at the issue, where the align module doesn't detect the slew procedure nor its termination:
[2019-12-03T22:01:57.489 CET INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Slewing mount: RA increment = 341, DE increment = -25 "
[2019-12-03T22:01:57.653 CET DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T22:01:57.655 CET INFO ][ org.kde.kstars.ekos.guide] - "Mount is moving. Resetting calibration..."
[2019-12-03T22:01:57.665 CET DEBG ][ org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":544,\"jsonrpc\":\"2.0\",\"method\":\"clear_calibration\",\"params\":[\"mount\"]}"
[2019-12-03T22:01:57.665 CET INFO ][ org.kde.kstars.ekos.guide] - "Calibration is cleared."
[2019-12-03T22:01:57.669 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 33" startup 2 "03/12 21:44" state 3
[2019-12-03T22:01:57.826 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T22:01:57.828 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2019-12-03T22:01:57.846 CET INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Slewing to RA: 1:34:59 - DEC: 30:45:44 "
[2019-12-03T22:01:57.847 CET DEBG ][ org.kde.kstars.ekos.align] - ## RA "01:34:58" DE "30:45:43" state: Ok slewStarted? false
[2019-12-03T22:01:57.848 CET DEBG ][ org.kde.kstars.ekos.align] - Mount slew planned, but not started slewing yet...
[2019-12-03T22:01:57.885 CET INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Iterative Goto (1): RA diff = 0.80 arcsecs DE diff = 0.01 arcsecs "
[2019-12-03T22:01:57.888 CET INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Telescope slew is complete. Tracking TRACK_SIDEREAL... "
[2019-12-03T22:01:57.889 CET DEBG ][ org.kde.kstars.ekos.align] - ## RA "01:34:58" DE "30:45:43" state: Ok slewStarted? false
[2019-12-03T22:01:57.889 CET DEBG ][ org.kde.kstars.ekos.align] - Mount slew planned, but not started slewing yet...
[2019-12-03T22:01:57.934 CET DEBG ][ org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":0,\"id\":544}\r\n"
[2019-12-03T22:01:58.654 CET DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T22:01:58.657 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 33" startup 2 "03/12 21:44" state 3
[2019-12-03T22:01:58.814 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T22:01:58.815 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2019-12-03T22:01:58.856 CET DEBG ][ org.kde.kstars.ekos.align] - ## RA "01:34:58" DE "30:45:43" state: Ok slewStarted? false
[2019-12-03T22:01:58.856 CET DEBG ][ org.kde.kstars.ekos.align] - Mount slew planned, but not started slewing yet...
[2019-12-03T22:01:59.653 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 33" startup 2 "03/12 21:44" state 3
[2019-12-03T22:01:59.807 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T22:01:59.889 CET DEBG ][ org.kde.kstars.ekos.align] - ## RA "01:34:58" DE "30:45:43" state: Ok slewStarted? false
[2019-12-03T22:01:59.889 CET DEBG ][ org.kde.kstars.ekos.align] - Mount slew planned, but not started slewing yet...
[2019-12-03T22:02:00.675 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 33" startup 2 "03/12 21:44" state 3
[2019-12-03T22:02:00.826 CET DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T22:02:00.933 CET DEBG ][ org.kde.kstars.ekos.align] - ## RA "01:34:58" DE "30:45:43" state: Ok slewStarted? false
[2019-12-03T22:02:00.933 CET DEBG ][ org.kde.kstars.ekos.align] - Mount slew planned, but not started slewing yet...I worked around the situation by restarting the scheduler, and specifying a larger tolerance on the alignment, as I only needed one observation target before fog would roll in the early morning and M33 was already aligned.
OK, problem found. For small slews it might slip through the intervals where processNumber(...) is called. I think a shorter polling period will make this less likely to happen, but it won't heal it.
I'll consider this in a new diff.