(poorly) re-setting the target

[Jasem Mutlaq]

Basically the current way it's intended to work is this:

1. Capture and solve.
2. Guide
3. Start sequence in capture
4. Moment that #3 starts, the target position is captured from the
mount at this stage. Since this is what you will be imaging, this is
the target (even after guide pulses initial drift).
5. This is kept as long as the capture sequence is not reset.

If you're not using a scheduler, how do you define a target? A target
could be any sky coordinates, and not necessarily a sky object. It's
also not necessarily whatever object you slew the mount to, the user
could make slight adjustments to frame the target and it would be
slightly off. Maybe the check we perform in align can be improved?
Right now, it only syncs the target to mount position when the new
state is capturing and the previous state is NOT suspended. However,
we can make it so that it only syncs the target when the previous
capture state is IDLE?

--
Best Regards,
Jasem Mutlaq


On Mon, Sep 20, 2021 at 1:25 AM Hy Murveit <murveit at gmail.com> wrote:
>
> Wolfgang,
>
> The problem is that when we call syncTargetToMount(), we replace the target position stored in align (that the user originally specified) with the position that the mount currently has. The mount's position, right after an align and sync will be that same target position, but after guiding will have drifted a bit (because of the guide correction pulses), especially guiding for a few hours with a little drift. My intention is to reset the target position that is used for align to the position the user originally specified.
>
> So, in a sense, yes it would be storing a 2nd version. I totally agree with you that we shouldn't have 2 versions, but the reason the second one is that we're losing the first one (as I describe above)  for reasons I don't quite understand (but I trust you ;)
>
> I strongly believe we should not forget where the user wants to point.
> If you don't think I should store that in the scheduler job, then what would you recommend?
>
> Hy
>
> PS Sorry I didn't follow the conversation. Perhaps we can have a short video face-to-face to understand each other better.  You said:
>     syncTargetToMount() is necessary to define the position the mount should be, i.e. the position that the mount reports. The subsequent plate solving determines, where it is pointing to in reality.
>  As I understand it SyncTargetToMount doesn't change the mount's position, it gets a.position from the mount, and it sets the target to that position. Therefore in the next align, we will drive the mount to that position.
>
>
> On Sun, Sep 19, 2021 at 3:06 PM Wolfgang Reissenberger <sterne-jaeger at openfuture.de> wrote:
>>
>> syncTargetToMount() is necessary to define the position the mount should be, i.e. the position that the mount reports. The subsequent plate solving determines, where it is pointing to in reality.
>>
>> Please be aware that the mount module already has a target position, so please do not introduce a second one.
>>
>> A possible attempt could be first using the target position of the mount. If that is not available, use syncTargetToMount().
>>
>> But I’m not sure, if this covers all use cases.
>>
>> Wolfgang
>> --
>> Wolfgang Reissenberger
>> www.sterne-jaeger.de
>>
>> Am 19.09.2021 um 23:15 schrieb Hy Murveit <murveit at gmail.com>:
>>
>> 
>> I was planning on addressing this in the scheduler in the next couple weeks, e.g. by storing the target value and resetting the target when the scheduler wants to re-align.
>>
>> However, check out https://indilib.org/forum/ekos/10399-plate-solving-changed-coordinates-of-object.html#75668 which is the same issue, however, the way Jürgen uses it, wouldn't get fixed by storing the target in the scheduler (he isn't using the scheduler).
>>
>> Honestly, I don't understand why syncTargetToMount() is being called there (e.g. if I removed that, then Jürgen's issue as well as mine would be fixed).
>>
>> Jasem, Wolfgang: Can you please remind me again why we're calling syncTargetToMount here?
>>
>> Thanks,
>> Hy
>>
>> On Fri, Sep 3, 2021 at 11:20 PM Wolfgang Reissenberger <sterne-jaeger at openfuture.de> wrote:
>>>
>>> Even better :-) So I will wait for the fix...
>>>
>>> Am 04.09.2021 um 08:16 schrieb Hy Murveit <murveit at gmail.com>:
>>>
>>> Wolfgang,
>>>
>>> Sorry I didn't mention this earlier, but Jasem and I hashed out what the issue is, based on some extra logging I inserted, and Jasem is working on a fix.  In short:
>>>
>>> In align.cpp, https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3841
>>> syncTargetToMount() gets triggered  https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3291
>>> when capture goes through a state sequence, that I believe is triggered when the scheduler repeats a sequence that finishes and the scheduler is in "Repeat Until Terminated" mode.
>>>
>>> What syncTargetToMount does is set the align target (e.g. the target that would be used after the next meridian flip) to the current mount's (internal) position instead of setting it to the target that was specified by the user in the scheduler job's setup.
>>>
>>> One might think those are the same things, since the mount is sync'd after the alignment succeeds, but if the job ran for a while, and there is some drift that is corrected by the guider, as the guider sends correction pulses, then the mount's internal position will vary from the original target/sync.
>>>
>>> I believe the align target should be reset to the original user-specified target (or the solution to the FITS file target) and not the mount's internal position.
>>>
>>> Hy
>>>
>>>
>>> On Fri, Sep 3, 2021 at 10:48 PM Wolfgang Reissenberger <sterne-jaeger at openfuture.de> wrote:
>>>>
>>>> Had the same problem last night. I will try to find out what happens.
>>>>
>>>> Am 02.09.2021 um 19:34 schrieb Hy Murveit <murveit at gmail.com>:
>>>>
>>>> The other night I saw my image move several arc-minutes after a meridian flip.
>>>> After putting in some extra log statements and re-running last night, I traced the image issue to the following.
>>>>
>>>> Align::syncTargetToMount()
>>>> https://invent.kde.org/education/kstars/-/blob/master/kstars/ekos/align/align.cpp#L3825
>>>> resets the target on some capture status change (which I'm assuming happens because I was running with scheduler mode "Repeat until Terminated" and the scheduler job completed and started its repeat, and that caused the capture status change). If the target isn't used anymore, then this target change is harmless, but if there's a meridian flip, then it would be used again and can move the image position.
>>>>
>>>> I don't understand this code well, but it seems to me that this is a bug. The target is set by the user in the scheduler -- e.g. a certain coordinate, or the solution of a certain fits file -- and the mount has nothing to do with that, at least if we're plate solving to refine the position.  Is there any good reason to reset the target position in the above code link?
>>>>
>>>> Hy
>>>>
>>>>
>>>>
>>>>
>>>