search

OpenPHDGuiding / phd2

PHD2 Guiding
https://openphdguiding.org
BSD 3-Clause "New" or "Revised" License
255 stars 115 forks source link

Differential-flex correction as dither #900

Closed interplanetarychris closed 3 years ago

interplanetarychris commented 3 years ago

For scopes that aren't able to use OAG's (i.e., RASA), differential flexing is a source of tracking error in long imaging sessions.

A nice enhancement for PHD2 would be do something like adjust the lock position on a dither event, based on knowledge of the measured shift between the main camera and the guiding camera.

It would appear that a feature like this would not be possible until plate solving is implemented within PHD2. Further, the dither event would either need to pass along the plate solve for its most-recent image, or PHD2 would need to request a "guide image" from the main camera to perform this step itself.

Last, it seems to make sense to tie this to the "dither" event in the imaging sequence, as it accomplishes a similar function for the imaging, and doesn't further interrupt the imaging sequence with the event.

Either way - just putting this on the "wish list" for the long term development of PHD2.

bwdev01 commented 3 years ago

This strikes me as very impractical and not well-suited for PHD2. If it's desirable at all, which is an open question in my mind, it's better implemented in the imaging/automation app which should already have plate-solving capability and has exclusive control of the main imaging camera. I'll also point out that any differential flexure correction would require a detailed pointing model for the imaging system because the vector of flexure is depending on pointing position.

d33psky commented 3 years ago

I agree with bwdev01. For instance 10Micron mounts can correct for flexure in their pointing/tracking model. I think that is the right place for these corrections. -- Hans

interplanetarychris commented 3 years ago

Mount flexure is separate from Main Scope / Guide Scope flexure, and I agree that many mounts have their own model for that.

Differential flexure between the main scope and guide scope requires some type of collaboration between the main imaging sequence and the guiding capability.

Perhaps, as @bwdev01 points out, the process in charge of the main imaging camera could monitor the drift over time, and request a dither command with pixel quantities to correct the drift (plus whatever desired amount of dither from track-point). But based on this discussion, agree that its probably not PHD2's responsibility to figure out that correction...

I'll submit a similar request over at Kstars/Ekos/INDI.

interplanetarychris commented 3 years ago

Opened at: https://invent.kde.org/education/kstars/-/issues/60

bwdev01 commented 3 years ago

I think you'll have to explain a lot more about your use case if you want this to get any attention. I really don't get it. If you're doing conventional imaging and you have differential flexure, I don't see any way for modeling or software-based algorithms to do anything for you. With differential flexure, the tracking error is continuous, it's only a question of how long you can expose an image before the error becomes objectionable. Beyond that length of time, you have unusable images. Whether that's 2 minutes, 5 minutes, 10 minutes.. depends on the specifics of the mechanical problem that creates the differential movement. If you stay below that time limit, then the effects of df will be a very slow drift of the target in the field of view over long time periods. Is that what you're worried about? Unless the amount of differential flexure is huge, the apparent tracking error is usually on the order of a few arc-sec per minute at most. Are your framing requirements so tight that you can't tolerate that? If so, I still don't see that you need anything new. You would simply force a plate-solve, re-synch, and re-slew to the original target coordinates whenever you think the amount of drift has become too large. Those functions are or should already be available in most of the imaging/automation apps. So what is it that you are asking for?

By the way, we'd prefer to have these initial conversations on the PHD2 Google forum as opposed to generating all this traffic through the Github. That forum is very actively supported.

Cheers, Bruce

From: interplanetarychris [mailto:notifications@github.com] Sent: Sunday, January 24, 2021 1:49 PM To: OpenPHDGuiding/phd2 Cc: bwdev01; Mention Subject: Re: [OpenPHDGuiding/phd2] Differential-flex correction as dither (#900)

Opened at: https://invent.kde.org/education/kstars/-/issues/60

You are receiving this because you were mentioned. Reply to this email directly, view https://github.com/OpenPHDGuiding/phd2/issues/900#issuecomment-766438078 it on GitHub, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV4CVERFNFUDI4LROW3S3 SIVRANCNFSM4WQY35PA . https://github.com/notifications/beacon/ADDHSV6FHPIADIMO3Y73T7DS3SIVRA5CNFS M4WQY35PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFWXOVPQ .gif

interplanetarychris commented 3 years ago

effects of df will be a very slow drift of the target in the field of view over long time periods. Is that what you're worried about?

Yes - this drift is irritating when working with mosaics, or wide-angle targets that I'd like to get the maximum available pixels. For reference, the drift rate in my system accounted for loss of about 10% of the FOV in a 3-hour track. This is about ~130 arc-sec/hr. My attitude is if the correction is possible, then why not do it?

You would simply force a plate-solve, re-synch, and re-slew to the original target coordinates whenever you think the amount of drift has become too large. Those functions are or should already be available in most of the imaging/automation apps.

These functions are available, but in my software environment (Kstars) it requires:

  1. (Track) Gross slew of the mount, involving an off-point and slew back to target:
  2. (Align) Verification of that rough-pointing by a plate solve. It leaves it be if it is within tolerance (Mine is typically 30 arc-secs), otherwise, GOTO 1.
  3. (Guide) Re-requesting PHD2 to guide again, with whatever its current startup preferences are.

The "Hammer" of the Track/Align step is imprecise, if the GOTO performance is a factor of 10 worse than the guide performance.

All of this also requires the tedium of planning out these activities within the sequencing.

A lot of steps, sequence disruption and lost imaging time, and room for things to go wrong.

I'd be nicer if if could just correct for a few arc-sec/minute drift in the guide/pulse correction domain and avoid everything above...

Of course, this may trigger future problems for PHD2 if the aggregate dither requests push the guidestar(s) off the FOV.

By the way, we'd prefer to have these initial conversations on the PHD2 Google forum as opposed to generating all this traffic through the Github.

Thanks - will start there next time!

I'll add the above context to the Kstars feature request.