Meridian flips handled by Mount
ClosedPublic

Authored by wreissenberger on Jan 13 2019, 9:35 PM.

Details

Summary

Currently, meridian flips are controlled by the capture module. This has the limitation, that meridian flips
can only be issued if capturing is running. If the mount is tracking a position without capturing running,
no meridian flip will take place.

With this proposal, the mount controls meridian flips. As soon as the meridian flip limit is reached,
it requests a meridian flip from the capture module. In case that a frame capturing is running, the
meridian flip is delayed until the frame has been captured.

If capturing is not running, the meridian flip is started immediately.

WARNING: This change has not beed intensively tested yet, feedback and testing appreciated.
Test Plan
  1. Test without capturing
    • Slew to a position east, but close to the meridian.
    • Select the meridian flip checkbox on the Mount tab.
    • Expected result: meridian flip executed as soon as the position crosses the meridian.
  1. Test with capturing
    • Create an imaging sequence with meridian flip enabled.
    • Slew to a position east, but close to the meridian.
    • Start the imaging sequence.
    • Wait, until the position crosses the meridian.
    • Expected result: meridian flip executed, image sequence interrupted and continued after meridian flip.
  1. Test with scheduled capturing
    • Create an imaging sequence with meridian flip enabled.
    • Create a schedule using this sequence and a target east, but close to the meridian.
    • Start the schedule.
    • Expected result: meridian flip executed and schedule continues afterwards.
  1. Meridian flip during paused imaging session
    • Similar as 2., but pause the imaging session before the meridian has been reached.
    • Expected result: meridian flip executed, imaging session remains paused.
  1. No meridian flip when mount is not tracking
    • Create an imaging sequence with meridian flip enabled.
    • Slew to a position east, but close to the meridian.
    • Start the imaging sequence.
    • Stop tracking.
    • Expected result: imaging sequence continues, no meridian flip happens
    • Extension: start tracking again
    • Expected result: meridian flip will be executed as soon as the next frame is complete.
    • Extension: park mount
    • Expected result: no meridian flip executed, imaging session continues.

Diff Detail

Repository
R321 KStars
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
There are a very large number of changes, so older changes are hidden. Show Older Changes
wreissenberger marked 8 inline comments as done.Jan 16 2019, 10:38 AM
wreissenberger added inline comments.
kstars/ekos/mount/mount.cpp
46

Ah, damn, I meant two minutes. Currently, I would not put it into the Ekos options but first gain some experience if this feature really makes sense at all.

498

Yes and no. I made currentTarget accessible as a first step when shifting the meridian flip to Mount. Currently, there is one access in Capture when checking, whether the slew has begun (line 4201).

So currently, there is no risk that we step into it in an undefined moment.

I want to remove the external access to currentTarget anyway, since with the new design the mount controls the meridian flip and communicates the state through events.

But nevertheless, good point, I will work on removing the external access to avoid the weakness.

kstars/ekos/mount/mount.h
57

Good idea, that's easy to be changed.

wreissenberger marked 2 inline comments as done.
  • Error handling for failed slew for meridian flip added
  • Mount meridian flip stati renamed to FLIP_... to avoid confusion with Capture flip stages
  • Mount no longer exposes initialHA and currentTarget via D-Bus
wreissenberger marked 3 inline comments as done.Jan 16 2019, 8:49 PM
  • Mount control of meridian flip for schedules added

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

wreissenberger planned changes to this revision.Jan 19 2019, 7:08 PM

I haven't tested this case yet, but no, there is no check yet. Will be fixed soon...

Meridian flip during paused imaging sequence enabled

wreissenberger edited the test plan for this revision. (Show Details)Jan 19 2019, 8:03 PM

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

Could you please be more specific when it happens? When I test it with the mount simulator, no meridian flip happens.

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

Could you please be more specific when it happens? When I test it with the mount simulator, no meridian flip happens.

Nothing. I wasn't even testing this. The mount was parked so I started a 2-image capture process and it said it wants to do a meridian flip! Of course it failed several times in a row while I was simply trying to capture a couple of images in the sequence. The check for meridian flip should never be made when the mount is parked.

I also don't think meridian flip should be done when the mount is NOT tracking.

wreissenberger planned changes to this revision.EditedJan 20 2019, 9:23 AM

I also don't think meridian flip should be done when the mount is NOT tracking.

OK, got the point, I will try to reproduce it. I will add a tracking check before the status changes to FLIP_RUNNING, but maybe more changes are needed. I will try to cover the situations when the mount is not tracking, but is in a position where a meridian flip should be necessary when the mount will track.

wreissenberger edited the test plan for this revision. (Show Details)Jan 20 2019, 9:24 AM

OK, I could reproduce the case. The problems occur when tracking is stopped while Mount is in the state FLIP_WAITING. In this case, things get out of order.

wreissenberger updated this revision to Diff 49962.EditedJan 20 2019, 8:19 PM
wreissenberger edited the test plan for this revision. (Show Details)
  • Meridian flip during paused imaging sequence corrected
  • Meridian flip during capturing sequence corrected

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

wreissenberger added a comment.EditedJan 23 2019, 9:32 AM

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

I had it running during the lunar eclipse on Monday and it ran fine. So for normal operations, it should be stable enough to test it in reality.

The changes for non tracking, parked/parking etc. are not that stable yet and are slightly tricky. It's not only about adding one or two checks. Since I currently work only in the evening and on weekends on it, I cannot promise it.

  • Meridian flip only executed when mount is tracking

diff span corrected

wreissenberger edited the test plan for this revision. (Show Details)Jan 23 2019, 4:43 PM

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

OK, please use the latest update. Now the meridian flip only happens when the mount is tracking.

wreissenberger edited the test plan for this revision. (Show Details)Jan 23 2019, 4:49 PM

There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?
Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long. This situation could be pre-planned by Scheduler.
I'm sorry, I couldn't test all this. But this seems really good.

kstars/ekos/mount/mount.cpp
46

Isn't this period still at 12 seconds?

wreissenberger edited the test plan for this revision. (Show Details)
  • Meridian flip timeout corrected to 2 minutes
wreissenberger marked an inline comment as done.Jan 23 2019, 10:38 PM

There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?

No, we don't. If we stop tracking, the meridian flip state is set back to "none" and nothing happens. As soon as we turn on tracking, a new target position is set. When this target position crosses the meridian, a flip is requested and executed.

Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long.

Nope, that’s why I introduced the request-accept mechanism. The mount requests to execute a flip, as soon as the meridian has been crossed by the given distance. If a capture is ongoing, capture answers with „wait“. As soon as the capture is completed, capture interrupts the sequence and sends an „accept“ to mount. Now mount executes the flip. As soon as the flip is completed, capture continues.

This is nothing new, this behaviour did not change. What changed is that the meridian flip is executed by mount and no longer by capture. The advantage is, that a meridian flip will be executed even if no capture takes place. This is especially important, if a capture sequence is interrupted by clouds. In the past, this prevented a meridian flip. Now, the meridian flip takes place as soon as the meridian has been crossed - no matter whether capturing takes place or not.

This situation could be pre-planned by Scheduler.
I'm sorry, I couldn't test all this. But this seems really good.

Good point. Personally, I would like to shift the meridian flip parameters from capture to the scheduler. But let's come back to this point as soon as we have this diff stable.

Cristal clear, thanks.

Can you please rebase again? I can't apply the patch now to test.

Can you please rebase again? I can't apply the patch now to test.

work in progress, hope to complete it today

  • Manual rebasing through cherry picking
  • Status text for planning pause added

mount.cpp and mount.ui still fail to patch :(

meridianFlipTimeBox is not in the ui file. Also, please don't use C-style casts (int), use static_cast<int>(...)

wreissenberger updated this revision to Diff 50347.EditedJan 26 2019, 7:12 PM

mount.cpp and mount.ui still fail to patch :(
meridianFlipTimeBox is not in the ui file.

Should be corrected now, I chose the wrong commit base for the diff update.

Also, please don't use C-style casts (int), use static_cast<int>(...)

Done.

Thanks, it was applied cleanly now. I had a brief window to test but then clouds rolled in :(

Is the Meridian control in the mount tab synchronized with the one in the capture type? It seems when I activated (checked) the meridian control in capture, nothing happen to the control in the mount tab.

Is the Meridian control in the mount tab synchronized with the one in the capture type? It seems when I activated (checked) the meridian control in capture, nothing happen to the control in the mount tab.

Not yet to the full extend. Currently it is only propagated from Capture to Mount when a sequence file is loaded.

I haven't thought it entirely through what is the best way to keep these parameters in sync. Maybe synching it while loading the sequence file is not be the best place. Would it make more sense to propagate the value when the imaging sequence is started?

Right, maybe if an imaging sequence is started, it should override whatever value in the mount module AND disable the edit in the mount module entirely as long as the sequence is active. This would prevent uses from changing it in mount by mistake while imaging is still active.

wreissenberger updated this revision to Diff 50398.EditedJan 27 2019, 9:33 PM

Meridian limits set when capture starts and not when the imaging sequence is loaded. Nevertheless, the user may change the limits at any time manually. But each time the imaging sequence is started, it is set to the value of the imaging sequence.

Let's try it first that way, since this is easier to implement.

wreissenberger planned changes to this revision.Jan 28 2019, 5:57 PM

Currently, there are problems when you stop tracking. After restarting tracking, the meridian flip is not executed.

wreissenberger updated this revision to Diff 50491.EditedJan 29 2019, 5:41 PM

Next iteration, now with improved handling of stopped tracking during waiting for meridian flip. It's not perfect since capturing is waiting until the meridian flip takes place, but at least worth testing.

Additionally, the meridian flip timer removed, since it creates additional risks

Thanks I just tested this in my observatory. The flip was started, but it got stuck on post-flip alignment. The alignment actually finished OK, but it seems no signal was sent to capture module regarding this. Please check.

wreissenberger planned changes to this revision.Jan 29 2019, 8:17 PM

Thanks I just tested this in my observatory. The flip was started, but it got stuck on post-flip alignment. The alignment actually finished OK, but it seems no signal was sent to capture module regarding this. Please check.

Problem confirmed, I'll work on it.

wreissenberger updated this revision to Diff 50514.EditedJan 29 2019, 8:35 PM

Bug fix for post meridian flip alignment. Hopefully now it's working.

I think we come close to a version that could be integrated into the master.

  • Postponing meridian flip added when mount is not tracking
  • Cosmetic change: meridian flip text message box spans two columns

D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?

D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?

Hm, I did not implement a timeout at all, a slew may take as long as it takes. Do we really need such a timeout that checks, whether the meridian flip slew has completed?

Therefore, my implementation makes this change D18627 obsolete. On the other hand, it depends, how long we need to get the new implementation mature enough for distribution.

In D18235#402892 https://phabricator.kde.org/D18235#402892,
@TallFurryMan https://phabricator.kde.org/p/TallFurryMan/ wrote:

D18627 <https://phabricator.kde.org/D18627> requires attention. Is
it compatible/complementary/unnecessary with this diff?

Hm, I did not implement a timeout at all, a slew may take as long as
it takes. Do we really need such a timeout that checks, whether the
meridian flip slew has completed?

Therefore, my implementation makes this change D18627
https://phabricator.kde.org/D18627 obsolete. On the other hand, it
depends, how long we need to get the new implementation mature enough
for distribution.

I believe yes, this change makes it non necessary. No Timeout, no need
to adjust it :-)

wreissenberger edited the summary of this revision. (Show Details)Jan 31 2019, 8:56 PM

View Revision https://phabricator.kde.org/D18235
wreissenberger edited the summary of this revision. (Show Details)
https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-vg656fdldlbpink/

*CHANGES TO REVISION SUMMARY*
...
If capturing is not running, the meridian flip is started immediately.
...

I just checked the changes and confirm it is running as expected (tests
1 to 4)

I noticed that the capture.ui still contains "Meridian Flip if HA" input
field and interfers with the field in the mount tab when capture
sequence is started.

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

alainz added a comment.Feb 1 2019, 9:32 AM

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

I will do more intensive testing,, I would like to make sure each test is reproducible.
Will ceme back to you in any case.

alainz added a comment.Feb 1 2019, 3:11 PM

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

I will do more intensive testing,, I would like to make sure each test is reproducible.
Will come back to you in any case.

I did run all tests again and found no issue, Must say all the test were done in simulation, it's raining in France :-(

Selecting checkbox in the Capture tab alone is not sufficient, the Mount Tab checkbox must be selected too, Right?

The fact that we have two places whith meridian cflip checkbox and setpoint is a bit confusing to me and will probably raise many questions by other users later on, but this is a cosmetic thing, the code works!

I did not see the meridian flip beeing forwarded from capture to mount tab, I still had one value in capture tab and another in mount tab, and the value in mount tab is the one that triggered the flip. Is my interpretation correct?

Selecting checkbox in the Capture tab alone is not sufficient, the Mount Tab checkbox must be selected too, Right?

At the end, the values on the Mount tab count. But when you start an imaging session from the Capture tab, the values from the Capture tab are forwarded to the Mount tab and overwrite the settings there.

The fact that we have two places whith meridian cflip checkbox and setpoint is a bit confusing to me and will probably raise many questions by other users later on, but this is a cosmetic thing, the code works!

Agreed. I would prefer shifting it from the Capture tab to the Scheduler tab, since the Scheduler contains data of other tabs as well. But I do not want to make the steps too big.

I did not see the meridian flip beeing forwarded from capture to mount tab, I still had one value in capture tab and another in mount tab, and the value in mount tab is the one that triggered the flip. Is my interpretation correct?

The value from the Capture tab is not forwarded immediately when changing the values on the Capture tab but they change, when you press the "Start" button on the Capture tab.

alainz added a comment.Feb 1 2019, 5:38 PM

Le 01/02/2019 à 18:02, Wolfgang Reissenberger a écrit :

View Revision https://phabricator.kde.org/D18235
wreissenberger added a comment.

In D18235#403245 <https://phabricator.kde.org/D18235#403245>,
@alainz <https://phabricator.kde.org/p/alainz/> wrote:

Selecting checkbox in the Capture tab alone is not sufficient, the
Mount Tab checkbox must be selected too, Right?

At the end, the values on the Mount tab count. But when you start an
imaging session from the Capture tab, the values from the Capture tab
are forwarded to the Mount tab and overwrite the settings there.

I see!

The fact that we have two places whith meridian cflip checkbox and
setpoint is a bit confusing to me and will probably raise many
questions by other users later on, but this is a cosmetic thing,
the code works!

Agreed. I would prefer shifting it from the Capture tab to the
Scheduler tab, since the Scheduler contains data of other tabs as
well. But I do not want to make the steps too big.

I did not see the meridian flip beeing forwarded from capture to
mount tab, I still had one value in capture tab and another in
mount tab, and the value in mount tab is the one that triggered
the flip. Is my interpretation correct?

The value from the Capture tab is not forwarded immediately when
changing the values on the Capture tab but they change, when you press
the "Start" button on the Capture tab.

This was what I expected but id doesn't happen, I have to test again!

Anyhow, good job!

*REPOSITORY*
R321 KStars

*REVISION DETAIL*
https://phabricator.kde.org/D18235

*To: *wreissenberger, mutlaqja, TallFurryMan, alainz
*Cc: *kde-edu, narvaez, apol

alainz added a comment.Feb 1 2019, 6:00 PM

I tested again the value forward from Capture tab to Mount Tab,
it works as you said.

mutlaqja accepted this revision.Feb 2 2019, 8:39 AM
This revision is now accepted and ready to land.Feb 2 2019, 8:39 AM

Anyone else has comments/issues with this PR?

Congratulations to all of you, this really is an improvement to the platform.

This revision was automatically updated to reflect the committed changes.