Alt-azimuth tracking speed formula?

[Brutha]

Hi All,

Somewhat inspired by the Open Astro tracker (that I am currently building) and Astroberry, I'm kicking around the idea of an alt-azimuth version with field derotation (achieving the field rotation by mounting the camera inside a kind of cage made from large "lazy susan" bearings. The idea being that via Astroberry and plate solving I could build something that doesn't need polar alignment.

Whether this proves possible or worthwhile is another question of course, but it's a fun project to plan!

I have the formula for field rotation (deg/hr) based on altitude, azimuth and observers latitude - but I am missing those for altitude and azimuth tracking speed.

Can anyone point me in the right direction?

Thanks!

Brutha

[vlaiv]

You want to know for a given position in the sky what is current tracking speed in altitude and azimuth that corresponds to sidereal tracking rate?

Maybe easiest way to derive that would be to take vector in RA direction that is sidereal long and decompose it into alt and az components. Imagine sphere, you are standing in center of the sphere / coordinate system origin. Object is moving along the circle on that sphere which has center on line connecting origin to NCP of the sphere.

This is a good image to explain what I mean. EW direction is X axis. NS direction is Y axis and Z axis is marked. All objects that track at sidereal rate follow circles marked on the image. Speed along the circle on the sphere is circumference_of_circle / 24h - that is your vector intensity.

Express that vector in XYZ space and then project it onto sphere along azimuth (direction of NWSE) and altitude (in direction towards Zenith).

[Brutha]

Hehe, thanks Vitaly! May need to improve my maths skills a little in order to attempt that - but this is probably a good thing!

Edit: maybe I found it in fact - think the equations are here for anyone else looking! http://www.ing.iac.es/~docs/tcs/software/TCS_PAPER_RL.pdf

Edited December 26, 2020 by Brutha

[malc-c]

I do love all these DIY experiments... but in all honesty would it not be simpler to use an EQ mount, or in the case of a dobsonian, wedge the base !

[Brutha]

2 hours ago, malc-c said:

I do love all these DIY experiments... but in all honesty would it not be simpler to use an EQ mount, or in the case of a dobsonian, wedge the base !

Oh yes, I'm sure it would be simpler! But this is more of an interesting project to pursue and hopefully learn some stuff along the way - with a very vague chance that I produce something useful in the end!

[Seelive]

I'm not sure if there are any equations that will automatically create the desired movements. To correct for a misaligned mount you would need to know the tracking error for an object at the field centre, then knowing that, the field rotation required can be calculated. But if the measured tracking error is not taken at the field centre then the tracking measurement error will also be affected by the field rotation. I'm sure it is possible to solve by iterative methods - but it's Boxing day and the bottle of wine has already been mostly consumed!

[Brutha]

15 hours ago, Seelive said:

I'm not sure if there are any equations that will automatically create the desired movements. To correct for a misaligned mount you would need to know the tracking error for an object at the field centre, then knowing that, the field rotation required can be calculated. But if the measured tracking error is not taken at the field centre then the tracking measurement error will also be affected by the field rotation. I'm sure it is possible to solve by iterative methods - but it's Boxing day and the bottle of wine has already been mostly consumed!

I guess the problem can be split into two parts. Part one is to create an alt-az based tracking mount, like that on my telescope for example.

The second part is to calculate the field rotation rate, using my latitude and the altitude and azimuth figures that the mount is pointing to. From here the calculation is:

Rate of field rotation (degrees / hour) = COS(observers latitude) * angular rate of rotation of earth (degrees / hour) * COS (Azimuth in degrees) / COS (Altitude in degrees)

That second bit should be straight forward... BUT I am realising the first part, creating an alt-az based tracking mount is not that trivial! The tracking rates vary depending where you are pointing; so if you simply update the tracking rates e.g. every minute based on where you think the mount is, it will wander off target fairly quickly I suppose.

Of course, the fact that there are loads of alt-az tracking mounts about, and that my Celestron seems to work very well means the problem has been solved before!

I think the Astropy project may be of use here - let's see!

[vlaiv]

1 hour ago, Brutha said:

That second bit should be straight forward... BUT I am realising the first part, creating an alt-az based tracking mount is not that trivial! The tracking rates vary depending where you are pointing; so if you simply update the tracking rates e.g. every minute based on where you think the mount is, it will wander off target fairly quickly I suppose.

Why would you update tracking rate so rarely?

In each iteration - move mount where you think it should be, update its coordinates accordingly and then continue iterating. This should really be millisecond period (depending on resolution of stepper motors).

I have AzGti mount and it has very nice feature - it is called point and track. It does not need alignment in order to be able to do that.

For example - you point the mount to Jupiter and you say - I pointed mount to Jupiter now and I need it to track (you select Jupiter / point and track in SynScan app).

What that does is set initial coordinates as app knows where Jupiter is at the moment - it knows its alt/az so if scope is pointing at Jupiter - it must have those alt/az coordinates and it then just starts tracking. That is all it needs to know - start alt/az and it will continue for hours without making too much error (provided you have your mount level).

 

[Brutha]

1 minute ago, vlaiv said:

Why would you update tracking rate so rarely?

In each iteration - move mount where you think it should be, update its coordinates accordingly and then continue iterating. This should really be millisecond period (depending on resolution of stepper motors).

I have AzGti mount and it has very nice feature - it is called point and track. It does not need alignment in order to be able to do that.

 

This is a good point! I had imagined the Raspberry Pi as the "brains" of the outfit who knows where the scope is pointing, and an Arduino or similar just running the steppers at the speeds it is told to.

But maybe you're right; actually I guess the Arduino can handle both tasks fairly easily - perhaps with stuff like error correction and so on in Raspberry Pi.

[vlaiv]

5 minutes ago, Brutha said:

This is a good point! I had imagined the Raspberry Pi as the "brains" of the outfit who knows where the scope is pointing, and an Arduino or similar just running the steppers at the speeds it is told to.

But maybe you're right; actually I guess the Arduino can handle both tasks fairly easily - perhaps with stuff like error correction and so on in Raspberry Pi.

Good thing about stepper motors is that you can actually count the steps - you don't need encoders to do that.

With servo motors, I think you have shaft encoders that help drivers put servo in proper position - and I believe those can be used for counting purposes as well.

HEQ5 for example - has no encoders but it "knows" where it is pointing - at least when you align it properly and start off from home position. If you want to move scope manually - you loose pointing information.

AzGTI on the other hand has freedom find - which is exactly opposite - as it has (low precision) absolute encoders - you can turn the scope and it can figure out where it is pointing.

It would be interesting exercise to calculate how much tracking error there would be if you had very loose pointing information.

I was thinking of getting myself SkyTee 2 mount. It uses same worm gears as EQ5 so steppers are easily added. I just want point and track feature with a simple controller, but I don't want to have database of objects and have the need to select them. What I figured is this:

- I create simple manual setting circles with 1-2° precision in both alt and az

- I point the scope where I want and then read off two numbers - az 0-360 and alt 0-90 and enter those in hand controller and hit go - it will start tracking. I wonder how good the tracking will be if there is uncertainty of 1-2° in initial position?

Additionally - I would want correction feature - so I let the mount track and I have up/down/left/right commands. So after a while - my target is drifted a bit and I recenter it and hit "sync" - and firmware figures out from initial position and tracking and correction - how to correct for everything and reduces error significantly.

[Seelive]

3 hours ago, vlaiv said:

Why would you update tracking rate so rarely?

In each iteration - move mount where you think it should be, update its coordinates accordingly and then continue iterating. This should really be millisecond period (depending on resolution of stepper motors).

I have AzGti mount and it has very nice feature - it is called point and track. It does not need alignment in order to be able to do that.

For example - you point the mount to Jupiter and you say - I pointed mount to Jupiter now and I need it to track (you select Jupiter / point and track in SynScan app).

What that does is set initial coordinates as app knows where Jupiter is at the moment - it knows its alt/az so if scope is pointing at Jupiter - it must have those alt/az coordinates and it then just starts tracking. That is all it needs to know - start alt/az and it will continue for hours without making too much error (provided you have your mount level).

 

The important point their is that the mount must be exactly level for it to correctly succeed. Alignment would still need to be carried out if it isn't (not that different from an eq mount and polar alignment really, just that most spirit levels are designed to be used on horizontal or vertical surfaces).

[Brutha]

1 hour ago, Seelive said:

Alignment would still need to be carried out if it isn't (not that different from an eq mount and polar alignment really, just that most spirit levels are designed to be used on horizontal or vertical surfaces).

This is part of my thinking around this: an alt-az tracking mount could be calibrated entirely with software via plate solving (just like the celestron star sense).

[Seelive]

1 hour ago, Brutha said:

This is part of my thinking around this: an alt-az tracking mount could be calibrated entirely with software via plate solving (just like the celestron star sense).

Agreed, just like an eq mount you have 2 (at least) unknowns so you need at least 2 measurements to solve the equations.

[Brutha]

So, have discovered that the OnStep project (an open source goto/tracking mount driver) has the possibility to drive an alt-az mount with a field rotator; I guess this is the way to go for the electronics side of the project!

[BernieCz]

Regarding altitude and azimuth tracking speed; I've been working on a similar project, and have a set of Python functions which call on astropy and astroquery to return alt,az and alt,az rates of change, given an objects name or ra,dec coordinates. I've just put the file up on github if you're interested, at https://github.com/bernie-skipole/astroaltaz