align issue?
Hy Murveit
murveit at gmail.com
Thu Sep 9 20:22:48 BST 2021
Happy to talk more, perhaps a video chat if you want so we understand each
other better. We're likely talking about two different thing, and perhaps
I'm misunderstanding you, and I don't want to belabor things, but, FYI,
here's how I see things:
Broadly speaking, there are two concepts:
1) (what I think you're talking about): the mount's internal
representation of where it is pointing, which I think is related to SYNC,
and how Ekos should manage that, and how to get the mount to point where
the user wants it to point,
2) (what I think I'm talking about): the user's desired target (a certain
RA and DEC) which is independent of the mount.
I know very little about #1, and so I leave it to you to get that working
well. So, if you think there's a good way to manage that, please go ahead
and do what you think is best.
If, by "Agreed", you are asking "should we store the user's intention
in just one place", for sure my answer is yes.
I do think that the user's target (in RA and DEC) is "simple". It's just
those two numbers. I think that target should be stored as those two
numbers, and should be stored in one place, and should not be changed until
the user (or scheduler) states a new preference.
I leave to you how we translate the user's target to mount movements--that
is "not simple" and I really don't follow all the magic in the code related
to that.
I am just talking about #2. I found a spot in the code where the user's
desired target was changed. The user's target happens to be stored in the
align module's target variable (at least the version of the user's target
that's later used in alignment). I'm not suggesting that that is the right
place to store it, I'm just saying "since it is stored there, we shouldn't
change it".
Hy
On Thu, Sep 9, 2021 at 11:52 AM Wolfgang Reissenberger <
sterne-jaeger at openfuture.de> wrote:
>
> 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?
>
>
> I’m fully with you, unintentional changes in the target through guiding
> drift is simply a bug. But the general answer is not that digital. The
> definition of „the user’s target“ is not that simple - see the point I
> tried to make with the SYNC below. And if we want to have such a concept,
> it should be held in one place, not in more of them.
>
> Agreed?
>
> 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/6096a3ee/attachment-0001.htm>
More information about the Kstars-devel
mailing list