DIY Semi-Automatic Polar Alignment

[russellhq]

I've been looking for ways to automate polar alignment that works well for my site and set-up. I've tried a few methods but never found one that really worked for me.

1. Polar Scope with using the EQMOD technique https://www.youtube.com/watch?v=FZgPZnC7zKc
2. Astrotortilla polar alignment error check 
3. PHD2 drift alignment http://openphdguiding.org/tutorial-drift-alignment-with-phd2/
4. Pole Align Max

What I want is a process that uses plate solving to accurately and quickly calculate Azi & Alt errors and then use a reference point (preferably a star) to aid adjustment. So that's what I'm tying to DIY

For plate solving part I've looked at a the following:

1. Astrotortilla https://sourceforge.net/projects/astrotortilla/
2. PlateSolve 2 http://planewave.com/downloads/software/
3. PinPoint http://pinpoint.dc3.com/
4. Astrometry.net http://nova.astrometry.net/

For me PlateSolve 2 works best and is the one I've been working with so far.

I've been writing the automation using vbs which can interact with my mount over ascom and can also interact with PlateSolve 2 to aid automation. I've got this all working well and I think I am almost there. For instance, I can move the mount to my first reference point, take a picture, plate solve, record results, move to next reference point, plate solve, record results. From here I should be able to compute polar alignment error and come up with an off-set for making the adjustment but I need to get my head around the concept/math for this part.

I've read a few articles but haven't got things to click yet:

http://www.rppass.com/align.pdf

http://celestialwonders.com/articles/polaralignment/MeasuringAlignmentError.pdf

http://celestialwonders.com/articles/polaralignment/StarOffsetPositioning.pdf

What I'm interested in is the following paragraphs:

Quote

Two Star Polar Alignment

Alignment error can be determined by measuring the discrepancy when moving between the known coordinates of two reference points. The procedure works as follows. Point the telescope to a known location. This could be the coordinate of a star or the arbitrary coordinates determined by a plate solve. The mount is calibrated to this location (e.g. a sync operation). The telescope is moved to a second reference point. This could be a second star or an arbitrary move in right ascension and declination. The actual location where the optical axis is pointed is determined. This can be accomplished by recentering the star and noted the difference in coordinates or the coordinates can be resolved by means of a plate solve. The delta in right ascension and declination between the expected location and the actual location can be used to directly calculate the alignment error by means of spherical trigonometry. The interested reader is referred to Pass[3] and Müller[4] for the mathematics and deeper discussion.

Quote

Putting It All Together

Take another look at Equations (4) and (5). Equation (4) results in a movement only in right ascension, while Equation (5) results only in a movement in declination. Therefore if both θaz and θalt are known, the entire correction can be made with one star offset operation! The combined procedure is as follows: 1. Center and synchronize on a star near the meridian at coordinates (α ,δ ). 2. Move the scope to coordinates (α' ,δ ' ) as calculated by Equations (4) and (5). 3. Adjust the mount in azimuth and altitude to bring the star back to center. 4. Re-measure the alignment error and repeat if necessary. If the alignments errors can be measured accurately and the correction performed precisely, the mount’s right ascension axis should be pointing well within an arc minute of the celestial pole with a single adjustment.

Between the 2 papers, I'm sure there is a solution but I'm just not there yet.

[Gina]

Very interesting, thank you for posting   I have thought about the possibility of automatic or at least remote PA but not actually got anywhere with it.

[ngwillym]

Have you tried the polar alignment feature in Sharpcap? and then using the scripting capability?

[russellhq]

57 minutes ago, ngwillym said:

Have you tried the polar alignment feature in Sharpcap? and then using the scripting capability?

Thanks! I must have missed this feature when it was added. I will give it a try.

[russellhq]

I've been reading the articles again this evening but still haven't got it clear in my head how the calculation should work. But while I was playing around with Stellarium to try and understand the relationship between the equatorial grid and alt-azi grid, I think I noticed something interesting... but I could be way off!

If I were to point my scope at the zenith and move only in declination, travelling down the meridian to the celestial equator (scope now pointing south). Then if I was misaligned in azimuth, all I would need to do would be to adjust azimuth until my scope was pointing at the meridian (well original declination). That would fix my azimuth error, I would then need to figure out altitude.

[themos]

Hello Russell, have you tried my photographic method? If you have AstroTortilla installed, you should be most of the way there. I use a Canon DSLR and a 200 mm lens, take two pictures of the Polaris region and then the software tells me what my Az/Alt polar alignment error is. See the thread 

 

[russellhq]

Hi Themos, I had been following your thread but I don't have a camera to attach to the mount, I only have my imaging camera and I don't want to rotate it.

Once I get some clear skies, I'm going to test my method to eliminate azimuth error and in the mean time figure out how to correct altitude error.

[russellhq]

Making some progress, I've managed to follow the steps in Ralph Pass's article to calculate Azi and Alt errors from slewing between 2 stars: 

With these numbers, I should be able to use Frank Barrett's process to off-set a start and adjust alignment by re-centering.

Need some clear skies now to test it out! (also need to write the vb-script to make it all work)

 

[russellhq]

Started to make some headway with this project but it's slow going. I'm using a combination of manual input, vbscripts and Excel: which makes things a little bit complicated but manageable.

My current workflow looks like this:

1) Run first script to slew telescope to first target

2) Capture image in imaging software

3) Run second script to plate solve image and sync telescope

4) Run third script to slew telescope to second target

5) Capture image in imaging software

6) Run fourth script to plate solve image

7) Type in plate solve HA & Dec of 1st target; HA & Dec of second target; plate solve HA & Dec of 2nd target into spreadsheet

8) Adjust mount based on output from spreadsheet

 

This seems to give some repeatability. I captured the following data (mount error in arc minutes), where each run is one pass of the workflow. I added comments when I adjusted the mount. The repeat comment means I re-ran the workflow without adjusting the mount to check for consistency.

	Error (arc min)		
Run	Eliv.	Azimuth	Comment
1	75.15	28.17	First run
2	73.68	30.98	Repeat
3	73.12	32.88	Repeat
4	39.63	40.52	Turn Azi west 1/4
5	39.25	42.33	Repeat
6	-29.49	50.10	Hour angle correction (was using RA in error)
7	-28.96	51.58	Repeat
8	-67.97	72.28	Turn Azi east 1/4
9	-67.85	72.29	Repeat
10	47.89	30.75	Turn Azi west 3/4
11	43.95	7.77	Repeat
12	43.72	7.02	Repeat
13	50.08	2.52	Turn Azi west less than 1/4
14	50.54	4.99	Repeat
15	14.66	10.60	Turn Alti North 1/2
16	14.55	10.67	Repeat
17	35.96	7.70	Turn Alti North 1/8
18	35.79	5.99	Repeat
19	45.15	6.18	Turn Alti North 1/8
20	45.60	8.58	Repeat
21	-66.40	22.40	Turn Alti South 1
22	-66.45	21.51	Repeat
23	-33.37	19.71	Turn Alti North 1/4
24	-33.27	19.66	Repeat
25	-9.32	14.20	Turn Alti North 1/4
26	-8.65	16.50	Repeat
27	-8.25	15.38	Turn Alti North less than 1/8
28	-8.54	13.77	Repeat

I was finding that the elevation error tended to be more repeatable than the azi error and I'm not sure why? The only thing i can think of is the way I am calculating the Hour Angle.

I'm not sure what is the best point in the workflow to take the hour angle for all 3 stages. For example:

Hour Angle of first target: Should I take the sidereal time just before I slew to the second target? Or should i take the sidereal time just before (or after) I capture the image?

Hour Angle of second target: Should I take the sidereal time when the slew finishes? Or should I take the sidereal time just before (or after) I capture the image?

Hour Angle of plate solved second target: Should I take the sidereal time when the slew finishes? Or should I take the sidereal time just before (or after) I capture the image?

 

Ultimately, I want to get away from scripts and excel and have this running from a small windows programme.

[Thalestris24]

Hi

This might be of interest?

Louise

[NickK]

Having built the stepper auto-focus.. an alt-az polar alignment system for the NEQ6 and INDI would also be interesting! Only thing it needs the base replacing todo it (the way the screws work is prehistoric).

[russellhq]

7 hours ago, Thalestris24 said:

Hi

This might be of interest?

Louise

Thanks Louise, I have this one bookmarked but forgot all about it last night! I think I've already written the code to do this anyway though, as i'm using the same articles that were referenced on that webpage. But it would help speed up development through using something ready made to benchmark against.

[russellhq]

51 minutes ago, NickK said:

Having built the stepper auto-focus.. an alt-az polar alignment system for the NEQ6 and INDI would also be interesting! Only thing it needs the base replacing todo it (the way the screws work is prehistoric).

After my efforts last night adjusting the altitude on the HEQ5, a stepper motor would be fantastic.

[russellhq]

On 8/31/2016 at 11:35, ngwillym said:

Have you tried the polar alignment feature in Sharpcap? and then using the scripting capability?

Finally got a chance to try this feature but Sharpcap kept crashing. I'm not sure if my cameras are compatible with it.

[Gina]

Remote PA was something I was thinking about though PoleMaster has made things easier, at least with the EQ8 which has much better PA adjustment than the NEQ6.  Looking at the NEQ6 it occurred to me that it would be easier to make a completely new fork type mount than add stepper motors and drive system to it

[Dr_Ju_ju]

There is always this from Bernard http://www.modernastronomy.com/shop/accessories/mount-accessories/mkii-eq6wedge/

It looks like it would be more amenable to adding some steppers etc.

[Gina]

Probably would be if it wasn't out of stock

[StuartJPP]

I too have looked into this but now that I use something like the PoleMaster or SharpCap, which is almost certainly quicker, I have abandoned the quest (temporarily?). It literally takes me less than 5 minutes from turning on the camera to being aligned. If you need to do polar alignment remotely or if you have no clear views of Polaris then great.

What is needed of the above two pieces of kit/software is the ability to align with no view of Polaris/NCP/SCP...

 

It would still be a satisfying project to complete...I was inspired by this video...

 

[russellhq]

I had another run at this project last night and am making some progress but still have a few bits to iron out.

First off, I have the automation running well for measuring the alignment error. Using MaxIm and vbs, I can start an autosave in MaxIm where MaxIm slews to first target, captures, solves, slews to second target, captures and solves. The scripts record the LST, HA, RA & DEC at each stage and save to a txt file linked to a spreadsheet in Excel which automatically calculates the error when I refresh the new data. The whole process takes less than a minute. The biggest time drain is waiting on Platesolve2's countdown, as it counts down from 10 after a solve completes before it closes.

The trouble I have at the moment, is if I change the starting position, the resulting error changes. I've taken a snapshot of the table to show what I mean, and uploaded a csv file of the data. The csv is ordered by Point 1 true location (plate solve result), Point 2 observed location (target for slew), Point 2 true location.

When I repeat an iteration without changing anything, the errors seem consistent to within 0.1min. But when I change the starting position, the errors start to change by a larger amount. I would like to get the error to be consistently reported regardless of starting point, but I don't know what's causing this.

PA_ErrorData.csv

[russellhq]

Thinking about this further, I'm wondering if there is another way of looking at this problem.

The premise of the the 2 start alignment technique described by Ralph Pass, is that polar alignment is achieved when there is no difference between the target Ra & Dec of the second point and the plate solved solution of the second point. This suggests to me that if after slewing to the second point (say a bright star) the mount's Alt & Azi bolts are adjusted, to bring the bright star into the centre of the frame, then in theory there would be no difference between the target and the plate solved solution and polar alignment would be achieved.

This seems too simple to actually work!

[NickK]

10 hours ago, russellhq said:

Thinking about this further, I'm wondering if there is another way of looking at this problem.

The premise of the the 2 start alignment technique described by Ralph Pass, is that polar alignment is achieved when there is no difference between the target Ra & Dec of the second point and the plate solved solution of the second point. This suggests to me that if after slewing to the second point (say a bright star) the mount's Alt & Azi bolts are adjusted, to bring the bright star into the centre of the frame, then in theory there would be no difference between the target and the plate solved solution and polar alignment would be achieved.

This seems too simple to actually work!

The fun is that everything is still moving and it's all about having a cone of error that you're reducing iteratively - curve fitting.

You can plate solve multiple locations, the time to move, sample and then plat solve needs to be built into the calculation.

The reason that people pick locations on the horizon and zenith is to give the largest movement - thus, in theory, the best accuracy.

 

[russellhq]

I'm giving this another go after finding the following webpage and pdf:

http://www.geocities.jp/toshimi_taki/matrix/matrix.htm

http://www.geocities.jp/toshimi_taki/matrix/matrix_method_rev_e.pdf

I think my originial implementation of the formulae was incorrect, I'm going to need to spend some time going through the pdf but hopefully I'll get there!

[kens]

Have a look at PHD2's Static Polar Alignment tool. I wrote it so at one time it was a DIY for me. It uses a rotational method to identify the alignment error. In terms of automation it automates the slewing of the mount to get the required readings and resolves the PA error into Alt and Az components. Adjustment of the bolts is is manual. It's all open source so you can inspect the code in Github. 

In the code is some hidden functionality (not enabled) that also calculates the camera offset from the pole resolved into declination and cone error

[russellhq]

Thanks Ken, I'll give it a go!

I must admit, the thought of figuring out Toshimi Taki's work is a bit daunting!

 

Russell

[GraemeH]

Hi Russell,

I stumbled across this thread today without really looking specifically for anything related to polar alignment, but it's actually something I've been working on recently too.  I also have been using Toshimi Taki's document on matrix transformations as the basis for my method, but have tried to simplify the approach by trying to calculate the offset between the true celestial pole and the RA rotational axis of the mount.  To do this I have worked on the basis that if you plate-solve 2 images separated by a move in RA only (i.e. strictly no movement in the Dec axis of the mount) you can calculate the pointing direction of the mount's polar axis in terms of RA and Dec.  Taki's matrix transformations allow this to be converted to Alt-Az, thereby giving the polar alignment error.  This was done primarily thinking that you could utilise the GOTO++ function in APT to slew to a calculated offset position from an alignment star, and then manually adjust the Alt-Az bolts on the mount to centre the star.  So far I've been unable to make a test of this myself, but Ivo (APT developer) has tried this out once and found quite good agreement between this method and the polar scope on his mount.  Definitely too early to say that this works well, but I will be making more tests whenever the weather allows.

My calculations have been made in Excel, so there are some limitations in the precision of the trigonometric calculations, and I haven't yet attempted to take account of atmospheric refraction but I'd be happy to share my spreadsheet with anyone interested in testing it out.  There are quite possibly still some errors in my calculations they should definitely be used with caution, and I'm really not sure that I've set it up correctly for Southern Hemisphere use.  So far the spreadsheet requires you to enter your Lat-Long coordinates and time offset from UTC, the RA-Dec coordinates of 2 images separated by a mount move in RA only as well as the local time that they were taken, and then the RA-Dec coordinates of a chosen alignment star.  It will then calculate RA-Dec coordinates to slew to such that the scope should then be offset from the chosen alignment star by the margin of polar alignment error, and manual adjustment of the Alt-Az bolts to bring the star to the centre of view.  I'm not expecting that this will be a means of giving highly precise alignment, but I'm hopeful that it can be a way of achieving 'good-enough' alignment very quickly.

Graeme