First project complete and question

[homebrewed]

A design goal of 10 arc seconds accuracy should be compatible with most common stepper motors -- if one complete revolution of the worm is 8 minutes, you'd only need (8*60)/10 = 48 steps/rev. to achieve that. So your data suggests a mechanical issue of some kind. The fact that the error is periodic relative to the worm seems pretty definitive.

One thing that would be helpful would be to know what the diameter of the big gear is. With the +/-10 arc seconds design target, you can calculate what that means in terms of the required mechanical tolerances needed to get there. For example, if the big gear is 6 inches in diameter, the length of a 10 arc second chord on the circumference is .29 mils, .00029 inch (10 arc seconds = 4.85E-5 radians). Wow!

If you look at the +/- 45 arc second information as an indicator of the tolerance variation you DO have, that comes out to +/- 1.3 mils (again based on a 6-inch diam. gear) -- something that might be about right for a relatively inexpensive off-the-shelf gear set. Not looking good for what you want to achieve, though.

It might not be necessary to use a high-accuracy encoder for this (although that would be the most robust solution). As has already been mentioned, if the error is periodic relative to the worm's rotational position you could characterize it and then compensate for it in software. So how to get the compensation factors? Maybe you could use the telescope itself, since that is where you are observing the problem.

However, running in an open loop mode does have its problems, like determining what the worm's rotary position is the next time you use the telescope, and, of course, mechanical wear. Putting an encoder that retains positional information of the worm gear (if there is such a thing) might address the former issue. Or perhaps having a shutdown procedure in your controller S/W to store the worm gear's rotary position in nonvolatile memory? I believe that can be done on an Arduino; but you'd have to make certain you actually go through the shutdown procedure every time. And how would you handle a power failure? More worms in that can.

You have an "interesting" problem. Please let us know how you address it!

 

[homebrewed]

One way to get around storing the error map of your worm gear, addressing power failures and so on would be to include a calibration function in your telescope controller. Set up on a bright star and use the images from the scope camera to generate the map. This has the advantage of automatically compensating for wear, and avoids the need to store the worm gear's angular position, religiously do a proper shutdown every time, and so on.

Analyzing the images would likely take more processing power than an Arduino. I suspect an RPi could do it, or perhaps a Teensy microcontroller. It really depends on how much S/W stuff you want to do as part of your project.

 

[macardoso]

One way to get around storing the error map of your worm gear, addressing power failures and so on would be to include a calibration function in your telescope controller. Set up on a bright star and use the images from the scope camera to generate the map. This has the advantage of automatically compensating for wear, and avoids the need to store the worm gear's angular position, religiously do a proper shutdown every time, and so on.

I think we are heading down the same thought path here. My only comment to add, is that if this were my project, by the time I added computer vision processing and everything needed to make it happen, I probably would have incurred the cost and time expenditure to justify the encoder installation. It would accomplish everything you are mentioning.

I do think error mapping would greatly improve the accuracy of the telescope, but you would definitely need an absolute position reference to make it work.

Poor OP probably got more than he bargained for when posting this