align issue?

Thu Sep 9 19:40:09 BST 2021

I have no doubt there are other problems ;)
However, don't you agree that we should never over-write the user's desired
target position?
Hy

On Thu, Sep 9, 2021 at 11:37 AM Wolfgang Reissenberger <
sterne-jaeger at openfuture.de> wrote:

> Aaah, sorry, now I got the point. In this aspect, the alignment module
> behaves differently to the mount module. The mount module keeps always the
> last position that it had slewed to as target position. The alignment
> module does it differently.
>
> But both have their ups and downs. If the last step a user does is a SYNC,
> the mount module still keeps the position of the last slew. This can lead
> to other problems with the MF. For this I have a MR!265 pending, since we
> are not sure what the right solution might be.
>
> Wolfgang
>
> Am 09.09.2021 um 20:01 schrieb Hy Murveit <murveit at gmail.com>:
>
> You are misunderstanding the original conversation.
>
> What I was complaining about is this: the code is changing "the original
> *target* position" by setting it to the mount's current position. This
> happen during a call to syncToMount, and that syncToMount happened at a job
> restart (e.g. the scheduler job was using "repeat until termination", and
> on the repeat, some change in capture status caused align to call
> syncToMount). So, syncToMount called at that time wound up changing the
> variable storing the user's target to the mount's current position, which
> had drifted from the user's target position. I claim we should never change
> the variable containing the user's target position once we know it. So, the
> user's target position was lost, and the subsequent alignment used the
> wrong target.
>
> Hy
>
>
> On Thu, Sep 9, 2021 at 10:47 AM Wolfgang Reissenberger <
> sterne-jaeger at openfuture.de> wrote:
>
>> Hm, not sure if I get your right.
>>
>> This drifting, that you are describing, will be forgotten after the
>> meridian flip, since the mount uses for the MF slew the original *target*
>> position. The syncToMount happens *after* this slew of the MF, i.e. the
>> position the mount should point is the original target position, not that
>> one which happened through drifting.
>>
>> Or am I wrong?
>>
>>
>> Am 09.09.2021 um 19:25 schrieb Hy Murveit <murveit at gmail.com>:
>>
>> Wolfgang,
>>
>> This is what I think is happening.  For the sake of argument, let's say
>> that the mount is perfectly sync'd with the target after some startup plate
>> solving.However, then a job begins and the guider starts up, and sends
>> guiding pulses for the next few hours. If there is some drift in DEC, let's
>> say for the sake of argument 1 arc-second per minute of time, then after 3
>> hours the mount has been sent 180 arc-seconds of guide corrections or 3
>> arc-minutes of pushes in that DEC drift position, and the mount's internal
>> representation of the position will differ from the target position by
>> those 3 arc-minutes, even with all other things otherwise working
>> perfectly.  When we then meridian flip and align, we would not want to
>> align to the mount's position, which is 3 arc-minutes off of the user's
>> desired position, and in fact 3 minutes off of what the mount is really
>> pointing to just before the meridian flip.  Therefore we should not adjust
>> the target position to where the mount is pointing at that time.
>>
>> Hy
>>
>> On Thu, Sep 9, 2021 at 10:14 AM Wolfgang Reissenberger <
>> sterne-jaeger at openfuture.de> wrote:
>>
>>> I agree with you, Jasem, from my perspective this behavior of the align
>>> module makes perfectly sense. This reflects the position where the mount
>>> *thinks* it is pointing due to its internal pointing model.
>>>
>>> When a meridian flip is issued, the mount module takes the last position
>>> it slewed to and re-issues a slew. Drifts during guiding should have no
>>> effect on this position. At its end, when the mount is tracking, it should
>>> be (again due to its internal model) at the target position, so a
>>> syncTargetToMount() should get exactly the target position.
>>>
>>> Maybe a wild idea, but it would explain the behavior (and I didn't check
>>> it yet): if a slew command is issued to the mount and the mount ends the
>>> slew, are we 100% sure that it reports exactly the position we sent it to?
>>> I’ve never checked that, whether my mount reports exactly the coordinates
>>> after a slew where I sent it to.
>>>
>>> But in the logs, I see slight variations, without any move in between:
>>> [2021-09-08T21:03:46.172 CEST INFO ][     org.kde.kstars.ekos.align] -
>>> "Slewing to target coordinates: RA (20h 00m 33s) DEC ( *22° 46' 59*\").“
>>> … slew + plate solving (no sync) ...
>>> [2021-09-08T21:03:56.228 CEST INFO ][     org.kde.kstars.ekos.align] -
>>> „Solution coordinates: RA (20h 00m 32s) DEC ( 22° 47' 09\") Telescope
>>> Coordinates: RA (20h 00m 33s) DEC ( *22° 47' 09\*“)“
>>>
>>> Its strange… And I can confirm, I observe a similar behavior, after a MF
>>> the position does sometimes not match perfectly.
>>>
>>> Cheers
>>> Wolfgang
>>>
>>> Am 02.09.2021 um 22:38 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>:
>>>
>>> Good question.
>>>
>>> This was actually a solution to a problem we had. Align was always
>>> working on current telescope coordinates. When capture and solve is
>>> executed, and if SLEW to target is selected, the target was whatever the
>>> mount coordinates were WHEN you capture & solve was invoked. However, this
>>> DID result before in changing the actual target post alignment either due
>>> to mount drift or guiding pulses ..etc. This eliminates the issue, and sets
>>> an explicit target for align to SLEW to.
>>>
>>> So when a user starts a sequence, the target is locked to whatever the
>>> mount is at that particular point in time and this is used throughout the
>>> session. This is intended for use with plate solving. Remember that after
>>> platesolving is done, the mount coords indeed matches the target (within
>>> the tolerance) because we perform SYNC followed by GOTO. I hope this clears
>>> things up.
>>>
>>> --
>>> Best Regards,
>>> Jasem Mutlaq
>>>
>>>
>>>
>>> On Thu, Sep 2, 2021 at 9:22 PM Hy Murveit <murveit at gmail.com> wrote:
>>>
>>>> If you want, comment on my kstars-devel thread, but I want to ask you,
>>>> why would we ever do what's on this line?
>>>>
>>>> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3291
>>>> I can see that you wrote or re-factored at least the last version of
>>>> this in 65b0f85d535d179d1e11c22f7841527c49b15dda
>>>>
>>>> We're changing the target to where the mount thinks it currently is,
>>>> but, if we then align, then it doesn't matter what the mount thinks,
>>>> what matters is what the plate-solver thinks. But since we've changed
>>>> the target coordinates, the plate solver will now move the image.
>>>> I think that's wrong, as far as I understand it--unless the user is
>>>> running without plate solving. But I think everyone runs with plate solving
>>>> these days.
>>>>
>>>> What would go wrong if that line was eliminated?
>>>>
>>>> Hy
>>>>
>>>>
>>>> On Wed, Sep 1, 2021 at 9:52 PM Jasem Mutlaq <mutlaqja at ikarustech.com>
>>>> wrote:
>>>>
>>>>> Hello Hy,
>>>>>
>>>>> That's right, setTargetCoords is what actually changes what align
>>>>> module aligns to. So the question now is why does the repeated job command
>>>>> a different coords?
>>>>> --
>>>>> Best Regards,
>>>>> Jasem Mutlaq
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 2, 2021 at 5:48 AM Hy Murveit <murveit at gmail.com> wrote:
>>>>>
>>>>>> Hope you don't mind me sending you progress notes--it's
>>>>>> therapeutic for me to debug this way ;)
>>>>>>
>>>>>> So far, it seems like it isn't the meridian flip at all.
>>>>>>
>>>>>> It turns out that the jobs is a scheduler "repeat until terminated"
>>>>>> job.
>>>>>> It completed its first schedule about 10 minutes before the meridian
>>>>>> flip, at around 2:36am.
>>>>>> At that point, the target coordinates are reset to this other spot.
>>>>>> (Could it be a J2000 vs. JNow issue?)
>>>>>> Also, mountmodel.cpp may call setTargetCoords()--I'm not familiar
>>>>>> with that code.
>>>>>>
>>>>>> startup
>>>>>> [2021-08-31T22:28:12.385 PDT DEBG ][     org.kde.kstars.ekos.align] -
>>>>>> Target Coordinates updated to JNow RA: "00h 04m 23s" DE: " 16° 15' 52\""
>>>>>>
>>>>>> scheduler repeating job:
>>>>>> [2021-09-01T02:36:56.423 PDT DEBG ][     org.kde.kstars.ekos.align] -
>>>>>> Target Coordinates updated to JNow RA: "00h 04m 33s" DE: " 16° 21' 09\""
>>>>>>
>>>>>> I put some logging in, and will re-run tonight.
>>>>>>
>>>>>> Let me know if you have any insight into this,
>>>>>> Hy
>>>>>>
>>>>>> On Wed, Sep 1, 2021 at 6:20 PM Hy Murveit <murveit at gmail.com> wrote:
>>>>>>
>>>>>>> Jasem,
>>>>>>>
>>>>>>> Wanted to let you know that I saw an align issue that came up in my
>>>>>>> testing last night.
>>>>>>> After a meridian flip, the align succeeded, but the resulting image
>>>>>>> was shifted too far away from the pre-flip image.
>>>>>>>
>>>>>>> I think there's something wrong with the targets.
>>>>>>> There are only two alignments in the log, the first one at the start
>>>>>>> of the evening (scheduler setting up the job),
>>>>>>> and the alignment after the meridian flip late at night.
>>>>>>>
>>>>>>> 1st successful align shows:    Solution coordinates: RA (00h 04m
>>>>>>> 24s) DEC ( 16° 15' 51\") ... Target is within  00° 00' 18\" degrees of
>>>>>>> solution coordinates
>>>>>>> 2nd successful align shows:   Solution coordinates: RA (00h 04m 34s)
>>>>>>> DEC ( 16° 21' 03\") ... Target is within  00° 00' 19\" degrees of solution
>>>>>>> coordinates.
>>>>>>>
>>>>>>> The target itself is not shown in the log, but as far as I know, it
>>>>>>> should be the same target for the two aligns.
>>>>>>>
>>>>>>> *Since the two solutions are a little more than 4 arc-minutes apart,
>>>>>>> they can't be within 18" and 19" of the same target.*
>>>>>>>
>>>>>>> Here's the lines near the last iteration of the original alignment
>>>>>>> early in the evening:
>>>>>>>
>>>>>>> [2021-08-31T22:28:02.727 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "40 stars, 27 quads selected in the image. 30 database stars, 20 database
>>>>>>> quads required for the square search field of 0.4°. Search window at 192%
>>>>>>> based on the number of quads. Step size at 100% of image height"
>>>>>>> [2021-08-31T22:28:02.793 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
>>>>>>> [2021-08-31T22:28:02.798 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field center: (RA,Dec) = (0.818908, 16.1438) deg."
>>>>>>> [2021-08-31T22:28:02.801 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field center: (RA H:M:S, Dec D:M:S) = (00:03:16.538, +16:08:37.712)."
>>>>>>> [2021-08-31T22:28:02.803 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field size: 30.3647 x 22.9561 arcminutes"
>>>>>>> [2021-08-31T22:28:02.805 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Pixel Scale: 0.391297\""
>>>>>>> [2021-08-31T22:28:02.808 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field rotation angle: up is 59.3579 degrees E of N"
>>>>>>> [2021-08-31T22:28:02.810 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field parity: neg\n"
>>>>>>> [2021-08-31T22:28:02.812 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Loading WCS from file..."
>>>>>>> [2021-08-31T22:28:02.813 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Finished Loading WCS..."
>>>>>>> [2021-08-31T22:28:02.815 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solver completed after 8.67 seconds."
>>>>>>> [2021-08-31T22:28:02.817 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solver RA (0.81891) DEC (16.14381) Orientation (59.35789) Pixel Scale
>>>>>>> (0.39130) Parity (neg)"
>>>>>>> [2021-08-31T22:28:02.851 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solution coordinates: RA (00h 04m 24s) DEC ( 16° 15' 51\")
>>>>>>> Telescope Coordinates: RA (00h 04m 23s) DEC ( 16° 15' 52\")"
>>>>>>> [2021-08-31T22:28:02.858 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Target is within  00° 00' 18\" degrees of solution coordinates."
>>>>>>> [2021-08-31T22:28:02.871 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Target is within acceptable range. Astrometric solver is successful."
>>>>>>>
>>>>>>>
>>>>>>> and here are the corresponding lines at the end of the post-flip
>>>>>>> alignment:
>>>>>>> [2021-09-01T02:47:35.334 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "57 stars, 44 quads selected in the image. 43 database stars, 33 database
>>>>>>> quads required for the square search field of 0.4°. Search window at 151%
>>>>>>> based on the number of quads. Step size at 100% of image height"
>>>>>>> [2021-09-01T02:47:35.370 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
>>>>>>> [2021-09-01T02:47:35.371 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field center: (RA,Dec) = (0.864281, 16.2303) deg."
>>>>>>> [2021-09-01T02:47:35.371 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field center: (RA H:M:S, Dec D:M:S) = (00:03:27.428, +16:13:48.980)."
>>>>>>> [2021-09-01T02:47:35.371 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field size: 30.3658 x 22.957 arcminutes"
>>>>>>> [2021-09-01T02:47:35.372 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Pixel Scale: 0.391312\""
>>>>>>> [2021-09-01T02:47:35.372 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field rotation angle: up is -120.366 degrees E of N"
>>>>>>> [2021-09-01T02:47:35.372 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Field parity: neg\n"
>>>>>>> [2021-09-01T02:47:35.373 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Loading WCS from file..."
>>>>>>> [2021-09-01T02:47:35.374 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Finished Loading WCS..."
>>>>>>> [2021-09-01T02:47:35.375 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solver completed after 3.60 seconds."
>>>>>>> [2021-09-01T02:47:35.375 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solver RA (0.86428) DEC (16.23027) Orientation (-120.36600) Pixel Scale
>>>>>>> (0.39131) Parity (neg)"
>>>>>>> [2021-09-01T02:47:35.382 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Solution coordinates: RA (00h 04m 34s) DEC ( 16° 21' 03\")
>>>>>>> Telescope Coordinates: RA (00h 04m 34s) DEC ( 16° 21' 09\")"
>>>>>>> [2021-09-01T02:47:35.382 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Target is within  00° 00' 19\" degrees of solution coordinates."
>>>>>>> [2021-09-01T02:47:35.388 PDT INFO ][     org.kde.kstars.ekos.align]
>>>>>>> - "Target is within acceptable range. Astrometric solver is successful."
>>>>>>> [2021-09-01T02:47:35.389 PDT DEBG ][   org.kde.kstars.ekos.capture]
>>>>>>> - Align State changed from "In Progress" to "Complete"
>>>>>>>
>>>>>>> Here are the images:
>>>>>>>
>>>>>>> Just before the meridian flip
>>>>>>> <Screen Shot 2021-09-01 at 5.48.34 PM.png>
>>>>>>>
>>>>>>> just after the meridian flip
>>>>>>> <Screen Shot 2021-09-01 at 5.49.24 PM.png>
>>>>>>>
>>>>>>> The entire log is here:
>>>>>>>
>>>>>>> https://drive.google.com/file/d/1T1jvXM12s7ZQKjKjwSSPU0Wl1MbacUV_/view?usp=sharing
>>>>>>>
>>>>>>> I'll let you know if I find something as well,
>>>>>>> Hy
>>>>>>>
>>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210909/a41fc370/attachment-0001.htm>