ZBasic Forum

Over in the RoboScope Yahoo group there is a discussion about developing an open-source GOTO controller for telescope mounts and I am wondering about the suitability of the various Zbasic micons for this project and am interested in any feedback (and help!) I can get here.

http://tech.groups.yahoo.com/group/RoboScope

The controller would have to drive two DC gearhead motors via PWM and able to keep track of the two telescope axis positions down to the arcsecond by the use of some type of optical encoders on the drive shaft of the DC motors or on the telescope mount axes themselves. There is a defacto-standard RS-232 command set that could be used for the dual-axis motor controller system called LX-200, that was developed by Meade Instruments.

Challenges:

* There is a wide margin between sky tracking motor speeds and "slewing" speeds, when the telescope mount is commanded to point at a different part of the sky. Excessively slow slewing speeds are very annoying to users.

* The controller would have to be aware of several coordinate systems (Altitude-Azimuth and Right Ascension-Declination) simutaneously and be able to drive the motors correctly to track sky objects when in either axis orientation mode.

* Gear backlash compensation in software is desirable but can come later.

* Various tracking speeds are desirable (celestial, lunar, solar and satellites)

* PPEC (Programmed worm gear Periodic Error Correction) is desirable but can come later.

* RTC and GPS support is highly desirable but can come later.

I would LOVE to be able to do all of this with a ZX-24P or maybe even a ZX-1280n.

And does anyone know of a good PWM-driver/optical-encoder-reading chip that uses I2C that might be useful in a project like this?

Thoughts and opinions?

Thanks in advance for any and all replies.

-Christopher Erickson

cerickson wrote:I would LOVE to be able to do all of this with a ZX-24P or maybe even a ZX-1280n.

Given that you need two PWM channels, I would think that the ZX-1280 or ZX-1280n would be better suited due to the greater on-board resources. In particular, use of the 16-bit PWM channels on the ZX-24 series is mutually exclusive with many of the other time-based I/O routines. While it is true that you could use the 8-bit PWM channels (assuming that that resolution is sufficient) those are mutually exclusive with the use of the software UART channels (Com3 to Com6) which you may want to use to communicate with external devices.

cerickson wrote:Over in the RoboScope Yahoo group there is a discussion about developing an open-source GOTO controller for telescope mounts and I am wondering about the suitability of the various Zbasic micons for this project and am interested in any feedback (and help!) I can get here.

The ZBasic platform is certainly up to the job and the ZX-24P could be used as it has two hardware serial ports. However, I would like to point out that the ZBasic platform itself is closed. That means it would be difficult for other people to reproduce your solution. While I would love to see more sales of ZBasic devices, I think it doesn't meet the spirit of an open source solution.

Instead of ZBasic, how about simply using an AVR? Based on the same hardware platforms as its ZBasic devices, Oak Micros sells a number of different AVR-based devices that have a bootloader. One of them (om328p) is Arduino compatible which might be a good open source platform to use.

Edit: Having now read the Yahoo group message and opinions, I will still say that an AVR isn't a bad choice and the WinAVR tools including the GCC compiler are all open source and free.

The arduino platform (or for that matter any AVR based development board) just makes it easier to get started. Then later you can create a custom board for the auxiliary components that you need. For example you might put the motor controllers and optical encoder support on a separate board for example and link the two together using I2C. Yes this does mean two micros but that is not unusual in this type of application.

Hey, this is a very interesting thread. Starting in about 1977 I was considering building my own guider after being excited by an article in Sky & Telescope. It would have used stepper motors and 2 photomultiplier tubes. I was not too thriled by the photomultipliers. I did not putsue the project.

In about 1983 I went back to the project after I got a quadrant photodiode to use instead of the photomultipliers.

I got the sensor working OK, but since I did not have an oscilloscope, I had reservations about how well I handled the SIGNIFICANT amplification that was required. I only had a small amount of space for the amplifiers (two stages!) The signals were to be few into 2 voltage-based variable frequency oscillators to drive AC motors. Needless to say, I blew out too many drive transistors in my 110v push-pull driver. I was also very afraid of working with mains voltage directly, and I again did not pursue the project.

I have always had that project in the back of my mind, and I have been playing with stepper motors for just this purpose!

It seems to me that it makes a LOT more sense to use steppers for moving the telescope than PWM of DC motors. With the proper gearing you can get any arbitrary degree of position accuracy AND you automatically know the position without using encoders!

I presume that people on the yahoo group must have thought about stepper motors. Why use PWM'ed DC motors? And with all that drive hardware and software, what about more than just a GOTO (moving to a new postition relative to the current position) controller? How about locking on to a guide star for astrophotography? Actually, I presume that is also a function of the hardware, but I did not see that explicitly in my brief review of the Yahoo forum.

-Tony

This might be a show stopper or at the very least very expensive.

telescope axis positions down to the arcsecond

I have wanted to build a digital sextant that could be used for standard navigation. I have yet to find a way to measure angles electronically and accurately to this sort of accuracy.

I would love to hear about a cost-effective solution to this problem. How does Meade do it?

Vic

victorf wrote:I would love to hear about a cost-effective solution to this problem. How does Meade do it?

Vic

My guess is that it is achieved with sufficiently gearing-down the motors.


-Tony

Okay, I waited a bit before replying so as to not to discourage anyone from making initial comments on this project.

I will now answer the questions as best I can with my incomplete knowledge of the subject.

Steppers vs. "continuous" servos (PWM DC gearhead motors + motor shaft optical encoder wheels)
Both seem to be popular for driving telescope mounts but servos seem to be the superior choice for GOTO systems. GOTO being the popular acronym for "computer controlled pointing." Meade, Celestron, Losmandy, Vixen, iOptron and Software Bisque all seem to have chosen servos for their GOTO drive systems. Servos seem to have a wider range of drive speeds, allowing them to quickly slew around the sky as well as to precisely track celestial objects and even to allow for closed-loop tracking corrections using "autoguiders." Steppers have simpler driver requirements and seem to be the most popular choice for basic (non-GOTO) sky tracking and manual pointing corrections through a single or dual-axis hand control. When properly deployed, servos have traditionally been less likely to lose sync with the sky than steppers. Many stepper-driven products over the years have had problems with losing steps under certain conditions, such as axis imbalance or at certain drive speeds. Steppers have also had problems over the years with smooth driving at high optical magnifications. Steppers also have a reputation of requiring much higher voltages and being much more power hungry than servos.

Only one serial port should be needed for this application.
It will be part of a modular system of modules performing various tasks, such as optical focus motor control, observatory dome control, dew heaters control, camera control, etc.

Meade and iOptron both appear to use slave micons
to control the axis motors and I2C to communicate to a master micon in a hand controller that contains a keypad and LCD display. The axis motor micons both drive the DC gearhead motors at various rates as well as keep precise count of the motor-axis optical encoder tics, which indicate axis pointing position as well as provide closed-loop feedback for the PWM speed control.

Each axis in a modern GOTO telescope mount
seems to consist of a cheap DC motor with an optical encoder disc on it's back-end and a plastic or metal gear head reduction unit on it's front end. The output of that gear reduction unit then typically connects to a ultra-high precision metal worm drive that has a gear ratio somewhere between 120:1 to 360:1. The DC motor is driven by PWM. The central micon has to know what the ultimate ratio is between the optical encoder tics and the axis position. This is usually quite high, allowing for axis position resolution down to the sub-arc second. Even though the axis position is tracked to the sub arc second, mechanical limitations like gear backlash and material flexure prevent $100 telescope mounts from performing as well as $10,000 telescope mounts.

I hope this helps!

Please keep the comments flowing!

-Christopher Erickson

Is it possible to buy a component(s) that I could use to position something to a precision of 1 arc second? If so, could I seriously afford it? This is a subject that has interested me for many years and the last time I researched this, I was unable to find a solution.

Any enlightenment will be appreciated.

Vic

Vic,

As I said before, with sufficient gearing you can achieve any arbitrary degree of precision.

The hard part would be the packaging and attachment to the existing telescope mount.

As I recall there are 60 arc seconds per arc minute, and 60 arc minutes per degree, and 360 degrees in the whole circle. Is this correct? Or is it hours-minutes-seconds?

If this is correct, you need to be able to position the telescope to 1 part in (60*60*360) which is 1:1,296,000.

Steppers often have 96 steps per revolution, so in that case you would need to gear down further by a factor of 13,500 I believe that 10:1 gear ratios are reasonable, so you would need about 4 of these sequentially to get the overall ratio you are looking for.

This all looks potentially feasible, but the real question is what is commercially available (to make it affordable and durable).

-Tony

> ... with sufficient gearing you can achieve any arbitrary degree of
precision.

On paper that's true. In practice, gears don't mesh perfectly well and
shafts aren't zero-clearance; both leave room for backlash errors.
Achieving accurate and repeatable 1000000:1 in small gears will be
challenging, I'll bet, regardless of the motor type you use. I see
backlash errors in my steerable light, and it's geared only 80:1.

Initially, I placed a fine quadrature encoder on the light shaft, the
output after the gearing, so backlash was ahead of the encoder and was,
thus, inherently corrected - but every time the motor reversed it needed
to take up the slack gearing before output motion started, and a
position could only be accurately reproduced when approached from the
same direction. Putting the encoder on the output shaft requires
resolution equal to your tolerable position error, but it will be accurate.

Putting the encoder on the motor shaft (or using a stepper) yields
higher apparent resolution but doesn't correct for downstream gear
lash. The output accuracy is then limited by gear lash regardless of
the motor.


Tom

It's degrees/minutes/seconds so your calculations are correct but this is an application where servos are superior. Servos and rotary encoders have long been used on machine tools to position large loads through ball-screws with accuracies better than 0.0001" with rapid starts and stops. However, the fact that there's no off-the-shelf servo system for telescopes is undoubtedly due to the high cost.

Since the backlash only shows itself when changing directions (or when external forces are applied to the driven object), it can be canceled out by always traveling the same direction. As this is impossible in this application, the solution is to overshoot the intended destination, and then go back, but only for one direction. The other direction is simply driven to the final position. If the final pivot/shaft/etc in the system has enough drag, the backlash won't cause the mount to move once the desired position is obtained. Since the gearset is always rotated in a single direction to come to the final position, the backlash is effectively eliminated, no matter how much there is. As long as you know how much backlash there is, the software can easily calculate your exact position using an encoder at the input (motor side) of the gearset.

Obviously, it's not an ideal solution, but it is a relatively simple method for dealing with less than ideal hardware.

-Don

Don_Kirby wrote:[T]he solution is to overshoot the intended destination, and then go back [...].

This is the technique that machinists use when manually positioning a machine tool, e.g. moving a milling machine table. The same technique is used in the automation of such machine tools. I used the strategy in the controller that I built for a dividing head/indexer. One of the configuration parameters for the controller is the amount of backlash removal motion is desired.

GTBecker wrote:In practice, gears don't mesh perfectly well and
shafts aren't zero-clearance; both leave room for backlash errors.

@Tom
Knowing you had spent a little time in the machine tool industry, I wondered why you hadn't responded as I was composing my response. Now, I see you beat me by a few minutes.

Backlash can be eliminated with ballscrews. There's a good. brief explanation of ballscrews on Wikipedia.

• http://en.wikipedia.org/wiki/Ball_screw