Improvements is estimateJobTime
ClosedPublic

Authored by alexcherney on Sep 5 2019, 2:37 PM.

Details

Summary
  • do not add time for guiding recalibration if resetGuideCalibration is not set
  • take guiding settle times into account
  • increase align time to 60 seconds (online solver or slow pc, such as RPi)
Test Plan

Job parameters: 60s capture, Track + Guide only. Guding with phd2 using 4s exposure; Simulators

Before the change the estimated job duration was 3m30s . After the change the estimate became 2m10s and the jobs completed in around 2m15s;

2019-09-06T00:35:52 Job 'Achernar-Part3' is complete.
2019-09-06T00:34:34 Job 'Achernar-Part3' capture is in progress...
2019-09-06T00:34:34 Job 'Achernar-Part3' guiding is in progress.
2019-09-06T00:33:56 Starting guiding procedure for Achernar-Part3 ...
2019-09-06T00:33:55 Job 'Achernar-Part3' slew is complete.
2019-09-06T00:33:54 Job 'Achernar-Part3' is slewing to target.
2019-09-06T00:33:37 Job 'Achernar-Part23' is complete.
2019-09-06T00:32:19 Job 'Achernar-Part23' capture is in progress...
2019-09-06T00:32:19 Job 'Achernar-Part23' guiding is in progress.
2019-09-06T00:31:41 Starting guiding procedure for Achernar-Part23 ...
2019-09-06T00:31:40 Job 'Achernar-Part23' slew is complete.
2019-09-06T00:31:39 Job 'Achernar-Part23' is slewing to target.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
alexcherney created this revision.Sep 5 2019, 2:37 PM
Restricted Application added a project: KDE Edu. · View Herald TranscriptSep 5 2019, 2:37 PM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
alexcherney requested review of this revision.Sep 5 2019, 2:37 PM
alexcherney edited the test plan for this revision. (Show Details)Sep 5 2019, 2:41 PM
alexcherney edited the test plan for this revision. (Show Details)
alexcherney edited the test plan for this revision. (Show Details)Sep 5 2019, 3:00 PM
alexcherney edited the test plan for this revision. (Show Details)Sep 5 2019, 3:04 PM
alexcherney updated this revision to Diff 65437.Sep 5 2019, 3:11 PM
alexcherney edited the summary of this revision. (Show Details)

fixed the typo to use the right setting - resetGuideCalibration (not alwaysResetSequenceWhenStarting)

Thanks Alex for improving the scheduler!

@wreissenberger @TallFurryMan Please check.

wreissenberger requested changes to this revision.Sep 5 2019, 4:51 PM

Good idea, Alex. And welcome to the Scheduler-Optimizing-Club :-)

One thing I would ask you to revert is the estimation for astrometry. I think 30sec is more accurate.

kstars/ekos/scheduler/scheduler.cpp
5238

I thing 60s is over-estimated. My Raspberry Pi 3b resolves typically in 12s. Most of the time is extracting sources.
Just a hint: since I changed from 2Mass data to Tycho2, which significantly speeds up the resolving time. Typically within 2-4s on that small Hardware.

5256

Very good, agreed.

This revision now requires changes to proceed.Sep 5 2019, 4:51 PM
wreissenberger accepted this revision.Sep 5 2019, 4:53 PM

Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.

This revision is now accepted and ready to land.Sep 5 2019, 4:53 PM
mutlaqja accepted this revision.Sep 5 2019, 5:15 PM
This revision was automatically updated to reflect the committed changes.
alexcherney added a comment.EditedSep 6 2019, 1:18 AM

Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.

Indeed, image capture, download, slew and additional platesolve all need to be accounted for. If no adjustment is necessary then it takes 40-50s on Pi3B+ using Tycho2 index files and 25' x 20' field with simulators. 60s seems a reasonable estimate taking into account additional iterations happening every second slew.

2019-09-06T11:07:43 Target is within 00° 00' 22" degrees of solution coordinates.
2019-09-06T11:07:43 Solution coordinates: RA (16h 13m 53s) DEC ( 03° 39' 43") Telescope Coordinates: RA (16h 13m 55s) DEC ( 03° 39' 45")
2019-09-06T11:07:43 Solver completed in 30 seconds.
2019-09-06T11:07:13 Starting solver...
2019-09-06T11:07:13 Solver iteration #2
2019-09-06T11:07:13 Image received.
2019-09-06T11:07:10 Capturing image...
2019-09-06T11:07:06 Settling...
2019-09-06T11:07:06 Slew complete. Target accuracy is not met, running solver again...
2019-09-06T11:07:06 Slewing to target coordinates: RA (16h 13m 55s) DEC ( 03° 39' 45").
2019-09-06T11:07:03 Syncing to RA (16h 13m 53s) DEC ( 03° 39' 43")
2019-09-06T11:06:57 Target is within 00° 00' 22" degrees of solution coordinates.
2019-09-06T11:06:57 Solution coordinates: RA (16h 13m 53s) DEC ( 03° 39' 43") Telescope Coordinates: RA (16h 13m 55s) DEC ( 03° 39' 45")
2019-09-06T11:06:57 Solver completed in 40 seconds.
2019-09-06T11:06:17 Starting solver...
2019-09-06T11:06:17 Solver iteration #1
2019-09-06T11:06:17 Image received.
2019-09-06T11:06:14 Capturing image...

My opinion on this is that observatory setups are too diverse to use a set predefined durations. Those durations need to be at least customizable via options. We thus get a whole new set of options, incidentally one or two per Ekos module.
Based on this observation, it means the estimation of procedure duration needs to rely on each module instead of being computed by scheduler. By extension, each module has to be responsible for the calculation of those duration, based on the actual work it has to do.
Therefore, I suggest we review that estimation activity when each Ekos module is assigned a blob of settings, as I presented on the forum.
"Hi Ekos module, here's what you need to do!" "- Yeah, that will probably take me <insert double> hours!"
Makes sense?