×

INDI Library v1.9.0 Released (23 Apr 2021)

Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.

Preemptive corrections on tracking speed based on astrometric solution

  • Posts: 30
  • Thank you received: 8
While yesterday fighting with the drift of my mount I got this idea

In cases like mine, the main issue with astrophoto is not really the periodic error, but the non perfect polar alignment, particularly since I don't have access to the polar star region and I am not so sure I want to waste time doing slow iterative methods like drift alignment or DARV.

However, just correcting the order 0, linear, drift (hence ignoring completely field rotation within subs) might be enough for my application. I could imagine something like astrometry running in the background for the last couple of pictures, estimate the drift and distribute guiding pulses or az/dec corrections within the next exposure so that we have some kind of fake guiding to correct such drift in small steps. Would it be doable?
Set 1 -> AZ GTi, redcat51+Canon 6D, guide: 30mm+ZWO ASI 120MM.
Set 2 -> Star Adventurer, lenses+Canon 6D
Set 3 -> NEQ6, LX90-8' OTA/MN150 + 450D peltier, guide: 50mm+QHY5.

1 year 9 months ago #42741

Please Log in or Create an account to join the conversation.

  • Posts: 109
  • Thank you received: 26
I have thought about it before, and I really think it's a good idea to look at.

Especially If it's obtained over a time period, if there was a way to pass a value for how fast/slow it's moving (assuming RA only) then that could allow for some drivers to adjust their tracking rate to correct. (I know OnStep could, and I suspect others.)
1 year 8 months ago #43975

Please Log in or Create an account to join the conversation.

  • Posts: 30
  • Thank you received: 8
Or even, more refined and cool, if we know how the stars trail, estimate the polar alignment error and just adjust the tracking speed in both axes to compensate it, so only the field rotation remains. For short focal lengths I think it will remove the need for a super accurate polar alignment or guiding
Set 1 -> AZ GTi, redcat51+Canon 6D, guide: 30mm+ZWO ASI 120MM.
Set 2 -> Star Adventurer, lenses+Canon 6D
Set 3 -> NEQ6, LX90-8' OTA/MN150 + 450D peltier, guide: 50mm+QHY5.

1 year 8 months ago #43979

Please Log in or Create an account to join the conversation.

  • Posts: 1115
  • Thank you received: 195
Seems a bit convoluted and prone to add additional tracking error.
Perhaps alternative polar alignment strategies could be developed. Such as with celestron mounts that are capable of determining alignment error with a couple align points then slewing a away a little by the amount required to correct it with the latitude and azimuth bolts.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
1 year 8 months ago #44053

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 18
Hello

I'd like to up vote the Ihoujin's suggestionspecially if I consider elakrab's two remarks:
Almost all descriptions of the drift alignment methods I saw so far, misquote Scheiner's original description. That does not mean, that the procedure does not converge, but for sure not on the (refracted) celestial pole.

These alternative alignment procedures have been already described, e.g. in E. S. King's comprehensive paper Forms of images in stellar photography or in a more modern form by Toshimi Taki Matrix Method for Coordinates Transformation . Unfortunately I did not find his web site anymore. Toshimi Taki included calculated examples which may serve as test cases.

Implementing E.S. King's result, here shown as velocity in both directions,

should not be difficult.

My reasons to up vote this topic are
  • these methods are differential
  • can be carried out all over the sky
  • if these corrections, position of the polar axis and refraction, are applied to INDI's JNOW coordinates, they can serve as a first order "pointing model" (without measuring several tens star positions). This could be done already with Ekos' results.
The last point implies, that the measured deviations from (refracted) CP are used to calculate the apparent position. Or saying that in other words, one can omit adjusting the polar axis in cases where only pointing is an issue. E.S. King described in his paper as well how to deal with various deficiencies of a mount itself. If one is interested in accurate tracking, eventually even dropping guiding, E.S. King's paper is an excellent starting point, as he showed it with his 1 hour unguided photograph of M13.

I add another wish. E.g. the telescope simulator driver should then include the mount's altitude and azimuth knobs. These are two writeable variables, where the position of the polar axis can be stored/adjusted.

Kind regards, wildi

P.S. Although I know what to do, I can not start coding right now.
1 year 4 months ago #48181

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
Dynamically correcting for drift caused by polar alignment error will only be partially successful because it can't cope with the field rotation that the polar align error generates. Fortunately this rotation is fairly small over most of the sky.

An alternative polar aligning method is already available, the Ekos Polar Align Assistant. This rotates the mount about the Ra axis, taking and solving three images. These images are all located on a circle the centre of which is the Ra axis pointing direction. Once you know that it should be possible to define the corrections needed to polar align the mount and apply these by centering a convienient star.

There's a bit of devilment in the details because the polar align error is defined in the Ra/Dec coordinate system and it needs to be transformed to the Alt Az coordinate system because those are the axes about which the mount is rotated to do the polar aligning. It's remarkbly difficult to get this transform correct.
Also the current PAA implementation assumes that the mont is pointed close to the pole. I don't think that is essential and hope to have a go at trying to get this to work without that constraint.

Toshimo Taki's Matrix method is still available - www.brayebrookobservatory.org/BrayObsWeb...rix_method_rev_d.pdf

Chris
1 year 4 months ago #48184

Please Log in or Create an account to join the conversation.

  • Posts: 1115
  • Thank you received: 195
Perhaps a strategy that could work for low latitude polar alignment with the PPA is applying atmospheric refraction corrections to the position of the NCP, as is done with traditional celestial navigation.
There are complete reference tables that only need the temperature and air pressure, but can also be calculated.
If I am not mistaken, the Polemaster takes refraction into consideration, and it is the reason they specify the orientation of the camera on the mount. In our case orientation relative to horizontal can be determined with plate solving and hour angle.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
1 year 4 months ago #48187

Please Log in or Create an account to join the conversation.

Time to create page: 0.609 seconds