Looking for beta testers of new Polar Alignment utility.

[themos]

3 hours ago, SteveBz said:

I can see that you are correcting using AstroPy, so it should be correct.  However, I looked at Stellarium and it says it's 'Current date'.  RA & Dec (Current date) are (43:78, 89:34).  89:34 is 26' off NCP, so it would seem to be the just past the 20' circle not on the 40' circle.  Have I got that right?

Steve

My Stellarium  (0.17.0) says, when I click on Polaris, RA/Dec (on date): 2h55m07.03s/+89d20m23.7s. So that is nearly 40mins off the current NCP.

[themos]

2 hours ago, SteveBz said:

I would also like it to operate more remotely.  I don't have a goto scope, so I can't slew at speed, but I can probably slew 30 degs in RA in under ten minutes, which is acceptable.  Would a 30 degree separation in planes be enough to polar align, do you think?  Obviously I still need to go outside to twist the alignment screws.

It should be ok, I guess you will need to experiment. But you don't have to slew, you can just undo the RA clutch and swing the axis manually. Atsrotracs can't  do that but your CG-5 should be able to do it.

[SteveBz]

59 minutes ago, themos said:

It should be ok, I guess you will need to experiment. But you don't have to slew, you can just undo the RA clutch and swing the axis manually. Atsrotracs can't  do that but your CG-5 should be able to do it.

Yes, that is what I did last time, but at the moment my whole world is full of mud and builders.  If I can avoid going down the garden, I avoid it.  So running down the garden once to turn alt-az screws, is better than twice for photos and screws.

[SteveBz]

1 hour ago, themos said:

My Stellarium  (0.17.0) says, when I click on Polaris, RA/Dec (on date): 2h55m07.03s/+89d20m23.7s. So that is nearly 40mins off the current NCP.

Hi Themos,

Ok, so my Stallarium is in decimal degress: .34 degrees not 34 minutes (ie 20')!

PPA was right.

Thanks

Steve.

[SteveBz]

Hi Themos,

Thanks for your feedback.

Really what I'd like to do is call PPA from my own python application.

The plan is that I'll point my scope at more or less dec = 90 and any old Easterly RA.  Take a snap. Slew Westerly for as long as I can bear and take another snap.  Plate-solve both images. And then pass to PPA "Find Polar Axis", avoiding the initial screen, then PPA to return an image to be displayed on my app, together with supplementary info, like adjustments to be made, to be displayed by my app.

Then I run down the garden, avoiding the mud, tweak the knobs and run back.

I don't fully understand yet how you can get away with a single photo for the second shot, so that is as far as my thinking goes.  If my PA improves a bit every night that's enough.

My main outstanding issue is, however, that I want two random axes separated by as small an angle as I can get away with, but I think PPA requires a fairly accurate first photo.  I don't understand why this is so.

How I do this on a spreadsheet, and how I imagine you do it, is to take an image, say IMAGE{A, B, C ...}, rotate by n degrees to IMAGE'{A', B', C' ...}.  Then I work out the actual direction of the polar axis on the scope by finding the actual point of rotation on the photos.  I use wcs-rd2xy/wcs-xy2rd to take two points that exist on both plates A and B, rotating to A' and B'.  I take the chords A-A' and B-B', take the perpendiculars to the midpoints of the chords and work out where they intersect to compare with

wcs-rd2xy -w <filename.jpg> -r 0 -d 0

- does PPA do this?

So if I can understand how PPA works, I'd like to remove the dependency that the initial photo be horizontal, which is hard for me to achieve with my Newtonian telescope.

Regards,

Steve.

[SteveBz]

At the moment the difference in corrections due to the PPA result and my own spreadsheet result is:

They are obviously of a similar order of magnitude, I don't know if, as they reduce, they will coincide.

Regards

Steve

PS, Actually, I think I may also have an error in signs.

Edited January 12, 2018 by SteveBz

[SteveBz]

Hi Themos,

So I measured the screw sizes approximately (I'll do it more accurately another time) and the Elevation screw is has a thread of 1.25 mm and the left/right thread is .83 mm.  The elevation axis of rotation is 40mm from the screw and the left/right axis distance is 38 mm.  You can see the 1.25 and 40 sound right, but .83 and 38 sound strange.  The gives up/down a movement of about 1.9 degrees per turn and left/right 1.2 degrees per turn.  The correction according to the PPA calculation would then be less then a 16th of a turn each.  Wednesday looks promising.  I'll see if I can try again then.

Steve

[SteveBz]

On 16/05/2016 at 13:47, themos said:

I have to mount my DSLR with a 135mm lens, piggy-back on the scope, for polar alignment and then take it back to prime focus of the telescope

Oh, wow, I never knew this was how you did it.  I'm using mine at prime focus!  Is that an issue?

Regards

Steve.

[themos]

Hello Steve,

I've avoided using the reflector at prime focus because 1) the image scale is a bit excessive for the purpose ,2) reflector images have the wrong parity which messes up the move instructions and 3) it's more tricky to know what horizontal is. 

Best way of making the mapping from arcminutes to screw turns is to solve images (with PPA!). I guess I would do the first couple to get the polar axis, then give a full turn to raise the polar axis and do an improvement solve, then note the new error (the Up/Down move instruction). Repeat for Left/Right. For this to work, you must make sure your horizontal image is really that.

I used to do it with a spreadsheet and just the positions of Polaris and Lambda UMi (like David Rowe had suggested) doing the geometry you described. Then I realized that the NCP is quite near the line connecting the two and that magnifies errors. The next idea was to use more stars and take an average of the geometric solutions. I finally settled on a numerical method to find the fixed point of the transformation implied by the two solved images. The mapping is (pixel x, pixel y) -> (ra,dec from 1st solve) -> (pixel x, pixel y from 2nd solve). The axis of rotation is the pixel that gets mapped to itself.

When I do the Improvement step, I already know the pixel position of the axis of rotation. That will not change, no more RA/DEC moves allowed. I also know that my camera is horizontal. Any moves with the screws of the mount would just shift the sky in the field of view, so I just move to bring the NCP onto the known pixel position.

Themos

 

 

[Gonzo]

If you download helvO08.pil and helvO08.pbm (Google it) and udpate the code, it looks slightly better.

 

[SteveBz]

21 minutes ago, themos said:

2) reflector images have the wrong parity which messes up the move instructions and 3) it's more tricky to know what horizontal is. 

2) You mean that the reflection is inverted.  Ok, I get that.  I'd just need to measure the movements and invert them if I needed to.

3) I haven't yet understood why horizontal is important.

21 minutes ago, themos said:

The next idea was to use more stars and take an average of the geometric solutions.

Yes, I've done a similar thing.  I'm now using virtual stars at 0, pi/2, pi and 3pi/2 so that the perpendiculars were as far apart as possible and therefore the intersections were as clean as possible.  Four points, four chords, an average of four.  The range of the intersections is about 4 pixels.

22 minutes ago, themos said:

I finally settled on a numerical method to find the fixed point of the transformation implied by the two solved images. The mapping is (pixel x, pixel y) -> (ra,dec from 1st solve) -> (pixel x, pixel y from 2nd solve). The axis of rotation is the pixel that gets mapped to itself.

Genius.  Pure genius.  This has to be the right way.

So as far as I understand, horizontal is only important to avoid starting all over again.  Ie to remove one degree of freedom from the problem.

I'm not sure that it makes things easier for me.  I may do the double photo each time.

And finally, I've now converted my adjustments to "hours" of a turn, rather than 16ths of a turn.  It makes it bit more intuitive.  So in my case, one adjustment is about half an hour of a turn and the other is nearly an hour.  They both seem quite small.  If I could implement a stepper motor on them, it would make it more doable: but that's probably another project.

Steve

Steve.

[SteveBz]

3 minutes ago, Gonzo said:

If you download helvO08.pil and helvO08.pbm (Google it) and udpate the code, it looks slightly better.

 

Nice, I'll do that too.

[Gonzo]

I remember when I worked with Themos on the very first edition of this tool https://github.com/Trigger-broom-289/eq-polar-alignment in good old fashion bash...

I like the graphical interface, but I'd like to have a command line version in python too.

[themos]

Quote

So as far as I understand, horizontal is only important to avoid starting all over again.  Ie to remove one degree of freedom from the problem.

I am sorry, that's not it! The first couple of images will fix the pixel position of the polar axis no matter what orientations you used.  

The requirement for the second image to be horizontal is to translate the x/y correction that is calculated (which is merely along the long side and short side of the sensor) to the left/right and up/down instructions needed for the person doing the mount correction.

[SteveBz]

1 hour ago, themos said:

I am sorry, that's not it! The first couple of images will fix the pixel position of the polar axis no matter what orientations you used. 

Ok, that's good to hear.

1 hour ago, themos said:

The requirement for the second image to be horizontal is to translate the x/y correction that is calculated (which is merely along the long side and short side of the sensor) to the left/right and up/down instructions needed for the person doing the mount correction.

Ok, I didn't realise that, I was going to translate back to RA, Dec and then further compensate from the timestamp on the photo to get the hour angle and use standard geometry to get the correction.

I'll think some more.

[SteveBz]

So this is my proposal for the last few steps, to avoid the need for a horizontal angle.  Please tell me what you think:

Here is a webpage I found, laying out the calcs:

http://www.stargazing.net/kepler/altaz.html

Which translates to:

I'd love to hear your thoughts.

Steve.

[SteveBz]

17 hours ago, Gonzo said:

If you download helvO08.pil and helvO08.pbm (Google it) and udpate the code, it looks slightly better.

 

OK, I tried this and the apostrophe on my setup doesn't show, so I reverted to HelvR10.  However using the smaller font for everything - I agree it looks better.

[themos]

5 hours ago, SteveBz said:

So this is my proposal for the last few steps, to avoid the need for a horizontal angle.  Please tell me what you think:

Here is a webpage I found, laying out the calcs:

http://www.stargazing.net/kepler/altaz.html

Which translates to:

I'd love to hear your thoughts.

Steve.

I think it would be great for someone to add this, but I wouldn't be using it myself. Given that hardly anybody has a mount with motorised elevation/azimuth controls of the polar axis, the PPA process will always involve a human being iterating moves and closing in on the error. People with observatories can take their time and people that set up every night can use a piggy-back camera (even a compact camera will produce good enough stars in 10 seconds or so).

 

[SteveBz]

2 minutes ago, themos said:

I think it would be great for someone to add this, but I wouldn't be using it myself. Given that hardly anybody has a mount with motorised elevation/azimuth controls of the polar axis, the PPA process will always involve a human being iterating moves and closing in on the error. People with observatories can take their time and people that set up every night can use a piggy-back camera (even a compact camera will produce good enough stars in 10 seconds or so).

Nice,  well I shall probably create it as a piece of standalone code that I'll strap onto the output of the PPA calculation.  I have a shed-type observatory with a lift off roof and a concrete floor, but I still have a tripod and not a pier, so occasionally it gets bumped and I have to re-align it.  I want to put an automatic nightly check into my observing check list.

Like Gonzo, I'm Linux throughout with Arduino controllers, but I do a lot of little projects to tighten up elements of observing, like PA, focus, collimation, guding etc.  I was half-way through an HFD auto-focus computerisation when you wrote to me, so I stopped to do this.  When it works, I'm back on HFD.

Regards

Steve.

[themos]

I should add that the method I used in PPA also appears in SharpCap http://www.sharpcap.co.uk/sharpcap/features/polar-alignment so if you like the extra bells and whistles you might like to give that a try.

[SteveBz]

5 hours ago, themos said:

I should add that the method I used in PPA also appears in SharpCap http://www.sharpcap.co.uk/sharpcap/features/polar-alignment so if you like the extra bells and whistles you might like to give that a try.

Even down to your screen layout!  (Plus apostrophes and ncp ).

[SteveBz]

Ok, this is what I have so far.  It's not tested yet.  The output is turns of the Alt/Az screws on an hours scale (that is hours turn of the Alt/Az adjustment screws) and it is not dependent on orientation of scope.  There is no photo, because you don't know the angle of the camera and it would be misleading.  I haven't adjusted the picture of Polaris for the error yet (I plan to).  I also haven't accounted for the time it takes to slew from photo A to photo B, so presumably I'll need to do the clutch release trick, rather than actually slew.  Also the time I've taken is the time of the jpeg, when better times would be the time of the raw photo, or even the time of the button press.

The test data is the two photos I posted earlier in the thread.

Edited January 16, 2018 by SteveBz

[bill rowe]

Just to say that this is still valuable work for DSLR users.  Sharpcap requires a camera with quite a tight field of view.

I'm not sure if there's better info somewhere but to get it working I had to poke my way through this thread for hints.  Most references on the web point only to the github.

Thanks again.