search

rmorgan001 / GSServer

ASCOM Synta protocol driver for SkyWatcher and Orion telescope mounts
GNU General Public License v3.0
40 stars 16 forks source link

Adding EQMOD alignment logic #39

Closed JPhilC closed 1 year ago

JPhilC commented 1 year ago

The original machine learning, best fit , approach to alignment has been removed. The DLL projects have been deleted.

In its place the Alignment folder in the GS.Server project has been extended to include all alignment logic.

At it's code the new alignment logic uses the same approach as EQMOD. When calculating the axis positions for a slew the logic looks for 3 alignment points near to the target position. The three points (or rather the corrections recorded at the 3 positions) are then used to calculate a transformation matrix which is used to determine the actual axis position required.

When determining the currently coordinates for the mount a reverse transformation matrix is calculated that is applied to the actual (raw) axis positions of the mount. The resulting axis positions are the fed into the existing logic for determining RA/Dec etc.

Using options on the alignment tab the user control how the 3 alignment points are calculated. It can use take the nearest 3 points or it can take the nearest 3 points that create a triangle enclosing the target position (n-Star). The can also choose with n-Star they can also choose whether to use the nearest 3 points than for a triangle enclosing the target position or they can use the points that create a triangle whose centroid is nearest the target position. Then can also choose whether to limit the search for alignment points to just the same pier side, the same quadrant or to consider all alignment points.

It is also possible to set a tolerance in arcseconds to allow alignment points to be replaced. When an alignment point is created any existing points closer than the tolerance distance will be removed. Effectively replace them with the new alignment point.

ozarchie commented 1 year ago

Many years ago, when the alignment was first discussed, the issue of observation errors in three-point alignment was raised. I don't recall the exact details, but the Taki method includes an investigation of the errors introduced by the point selection. Is that what you are referring to when you mention "the tolerance distance "? In the Taki method, small differences between the RA's or DEC's of the chosen alignment points can have a large effect on the accuracy of the transformation matrix. So points chosen should have the largest RA difference and DEC difference for all three points to minimise the effect that the observation errors have on the calculations.

On Mon, Jan 16, 2023 at 9:53 PM JPhilC @.***> wrote:

The original machine learning, best fit , approach to alignment has been removed. The DLL projects have been deleted.

In its place the Alignment folder in the GS.Server project has been extended to include all alignment logic.

At it's code the new alignment logic uses the same approach as EQMOD. When calculating the axis positions for a slew the logic looks for 3 alignment points near to the target position. The three points (or rather the corrections recorded at the 3 positions) are then used to calculate a transformation matrix which is used to determine the actual axis position required.

When determining the currently coordinates for the mount a reverse transformation matrix is calculated that is applied to the actual (raw) axis positions of the mount. The resulting axis positions are the fed into the existing logic for determining RA/Dec etc.

Using options on the alignment tab the user control how the 3 alignment points are calculated. It can use take the nearest 3 points or it can take the nearest 3 points that create a triangle enclosing the target position (n-Star). The can also choose with n-Star they can also choose whether to use the nearest 3 points than for a triangle enclosing the target position or they can use the points that create a triangle whose centroid is nearest the target position. Then can also choose whether to limit the search for alignment points to just the same pier side, the same quadrant or to consider all alignment points.

It is also possible to set a tolerance in arcseconds to allow alignment points to be replaced. When an alignment point is created any existing points closer than the tolerance distance will be removed. Effectively replace them with the new alignment point.

You can view, comment on, or merge this pull request online at:

https://github.com/rmorgan001/GSServer/pull/39 Commit Summary

File Changes

(44 files https://github.com/rmorgan001/GSServer/pull/39/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/rmorgan001/GSServer/pull/39, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRN2J26IDXDJ4VLB5WCEZTWSUZCPANCNFSM6AAAAAAT4U2X7A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

JPhilC commented 1 year ago

No it is simply to allow you to correct a mis-synced point. If you sych again on the same star and the included arch distance between the original and the second sync is less than the value set then the first point is removed.

Interestingly you mention the Taki method. This is only used when calculating the transformation for gotos. See the Delta_Matrix_Map method in the AlignmentModel_Math.cs file. When going from the sky back to the mount the logic calculates an Affine transformation matrix, see Delta_Matrix_Reverse_Map in the same file.

I don't know why this is the case, possibly someone around at the time will remember. Possibly it was a performance thing. I would be interested to know the reason why.

I have no great theoretical understanding of the logic used. So far I have simply taken the EQMOD code, converted the salient parts to C# and made it more object orientated and data binding friendly. I also modified it where necessary to work with GSS axis positions that are already in degrees or radians whereas the VB code is working in encoder step positions. What is not reflected in the checked-in code are the unit tests that I ran on an earlier draft of the code to make sure that at a functional level the C# code returned the same results for the same input as the VB code.

If you read Toshimi Taki's original paper he works with Alt/Az angles. The EQMOD code works with Cartesian coordinates for both the Taki calcs and the Affine calcs. Years ago when I first attempted a conversion of the EQMOD code this threw me. At that time I could only read the code, not run it in the VB6 development environment and step through it. This time I have just accepted that it works without questioning why!

ozarchie commented 1 year ago

I think the original code from Mon was based on RA/DEC. The encoder counts directly translate to RA/DEC since they are zeroed when pointed to the celestial pole. I have attached the earliest code that I kept (~2006) where the Taki method using n-star alignment basic functions were being integrated. The functions include cartesian co-ordinate translation and RA/DEC based alignment. A comment from the code:

'Implement a TAKI transformation on a Polar coordinate system
'This is done by converting the Polar Data to Cartesian, Apply TAKI transformation
'Then restore the transformed Cartesian Coordinates back to polar

A little bit historical and probably not relevant to the current code base. Thankyou for the great work, Cheers Archie releasenotes.txt [From_V112l.zip](https://github.com/rmorgan001/GSServer/files/10429890/From_V112l.zip)