Where it all started

The email that started this off is attached below. I have chopped the originbal straw man off the end as the design has deviated significantly from that!

Hi Jerry,

I have finally got round to reading your post in detail. I must admit I
have been getting a bit alarmed at the way this thread has been going. I
suppose that I somewhat to blame for that as I did not clearly state
what my starting parameters were. My idea was to produce a very
simplified alignment solution for "recreational astronomy" using a
simple AZ goto scope. I am not as mobile and flexible as I used to be
and I find aligning a small scope through the eyepiece a real pain.

Before I go any further let me say that I think that your proposed
methodology would fit well with what I want to do. "Recreational" use
could stop after two reference points have been defined! In what follows
I have set out in a somewhat rambling way a suggested set of standard
properties that would provide a flexible basis for alignment implementation.

My first goal was to set was to set up a system so I could evaluate
using a low cost webcam for plate solving using bright stars. I wanted
to check whether it was even feasible with a detector that cost less
than the scope! My test platform was a Skywatcher Synscan AZ mount and
MK127 scope with a trusty Philips SPC900 webcam. I intended the software
to be Linux based so that led me straight away to think about how I
could get the information I needed for alignment back from the mount,
and then insert the alignment matrix into the path that standard
applications (KStars, Stellarium, etc.) would be using to slew the
scope. It was this last point that led me to think that the current
alignment matrix needed to end up in the driver, as those applications
would use the EQUATORIAL_COORD_REQUEST (or EQUATORIAL_EOD_COORD_REQUEST)
standard property name to tell the mount to move and the best place to
intercept this and translate to axis encoder values was in the driver
(this could be done by snooping, but I will cover that later).

The next thing I came across was there did not seem to be a standard
property for communicating axis angles (encoder values) out of drivers.
The HORIZONTAL_COORD standard property is specifically stated to be
topocentric(i.e. zenith aligned). For whatever architecture is arrived
at (if any) I suggest a standard property for reading axis angles is
required (e.g AXIS_ANGLES). If this is to be really general purpose then
a corresponding property for axis directions (clockwise,
counter-clockwise) will also be needed (e.g AXIS_DIRECTIONS). This would
allow AZ mounts to be treated as really poorly polar aligned equatorials!

For plate solving the other thing that needs to be communicated as a
standard property is the local sidereal time (or any time that has a
linear relationship to it) for use a reference time for plates. There is
already a standard property name that defines this (TIME_LST). However
this is not implemented in the INDI::Telescope class and as far as I can
see the only driver that implements this itself is the LX200 driver.

As far getting the matrix into the EQUATORIAL_COORD_REQUEST processing
path I suggested yet more new standard properties to support the sending
of a current transform matrix and a reference time to the driver and
using a subclass of the INDI::Telescope class that provided member
functions to translate between axis and angles and equatorial
coordinates using the supplied data. However if snooping were to be used
instead of subclassing then a writeable AXIS_ANGLE_REQUEST property
would need to be supported.

On 16/10/12 22:11, Gerry Rozema wrote:

Now, enter the real world. So, we want the telescope to point directly
at a point, call the co-ordinates x,y . We feed x,y into our model,
and, it spits out a set of encoder co-ordinates, which will include some
amount of error due to fitting constraints. BUT, also consider, x,y
turn out to be precisely one of our sync points. Which is more accurate
for pointing, slew the mount to the model produced results, or, simply
slew to the points in our sync database, which are known to be correct
already ?

Where I'm going with this, no matter how hard you try, you can model all
night long, but, you will NEVER completely, and accurately account for
every possible error in the system. So, why even try ? There is a much
quicker and easier way to accomplish the same goal, with more accuracy,
and it works like this.

Start by slewing to some position, a known position. This is equivalent
to the 'one star align', and common amongst all mounts. Generate the
first sync point, and now you have a system that is exact on one sync
point, and will be off by various errors going elsewhere, the most
significant of which is polar alignment for most common amateur gear.
So slew to a second point, and, generate another sync. Now you have
enough data points for what is equivalent to a 'two star align', and,
using the taki transform matrix, you can make slews that will account
for polar alignment error. So, use this result, make a third slew, and
take another sync point.

The Taki transform is really a three star alignment but with the third
"star" usually artificially derived as the vector product of the
direction cosines of the first two stars. I am not sure if using a third
real star is any more "accurate". However see below.

So, moving forward in time from here, to get relatively accurate
slewing, go to the list of sync points, find the two that are closest to
your target, then use them to do a two star calculation via the taki
algorthims, and slew to those encoder co-ordinates. Once there,
generate another sync.

This concept, of constantly adding to the database of sync points, is
something that can work well in the field, with portable equipment.

Once you get 3 or more sync points, then I suggest that they can be
treated as a spherical TIN (triangulated irregular network) and the
three points defining the triangle containing the target used to
calculate the transform matrix. I am sure a set of optional standard
properties could be defined to allow the database management and matrix
selection to be done inside the driver if required, or in the client. If
done inside the driver maybe the code to do this could be isolated
inside a library that could be used by a real telescope driver or by a
snooping driver sat on top of it.

To make this system work well, one needs a way to generate accurate sync
data, essentially on demand. That's the part of the project I've
committed to taking on here, and, over the next few weeks hope to have
code functional for this. I've developed a plate solving system in the
past, which I am starting to re-work into a generalized solution, right
now that code is all hard wired to the camera systems my wife and I have
been using the last few years, and not easily useable in a general case
setup. When I have this functional and generalized, the process of
generating sync points for the mount alignment will become simple and
expedient. Take an image with the camera, solve plate, and generate a
sync point, lather, rinse and repeat. Assuming your starting point is
close enough we can get an accurate solution quickly, without degrading
to an all sky search, then the problem becomes really simple. With one
accurate sync point, the key is to do a little math on frame size and
alignment accuracy, then figure out just how far we can slew, yet stay
'accurate enough' to get a reliable sync quickly. Generate another
point at that spot, and repeat, expanding the reach.