- 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)
- Group Reviewers
- R321:3973c3b89b7c: Improvements is estimateJobTime
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.
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.
I thing 60s is over-estimated. My Raspberry Pi 3b resolves typically in 12s. Most of the time is extracting sources.
Very good, agreed.
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 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!"