Adding GOTO to the telescope controller (part 2)

First tests - 12.03.2011

After working a lot on the ‘GOTO’ code during the past two weeks, I decided to run some tests with the real hardware today. Things look promising, but some rough edges remain...

Instead of ‘only’ implementing the ‘GOTO’ mode, I had decided to also apply some improvements in several places of the firmware. For example, the faster link speeds allow for more up-to-date data; the communication between the user terminal and the RA Box has been doubled to 19200 Bd, and the link from the RA Box down to the feedback board in the controller rack is now 57600 Bd. Another small improvement is the way in which data is transferred from the RA Box to the user terminal. In the past, the terminal periodically sent various request packets to the RA Box (for example, ‘send current date and time’ when the terminal is in date/time mode), and the RA Box sent the corresponding response. To avoid some of the traffic from the terminal to the RA Box, I’ve changed the logic in a way that the RA Box now maintains a 16-bit mask. Bits correspond to requests, and if a certain bit in the mask has the value 1, the RA Box sends the corresponding data to the terminal.

The following requests are currently available in this way:

• 'Get encoder angle' (bit 0)
• 'Get AZ / ALT' (bit 1)
• 'Get aligned RA / DEC' (bit 2)
• 'Get LON / LAT' (bit 4)
• 'Get current date / time' (bit 5)
• 'Is the telescope aligned y/n?' (bit 7)
• 'Get encoder intervals per 180 degree' (bit 8)
• 'Get GOTO settings' (bit 12)

During implementation of the ‘GOTO’ mode, I figured out that it would be great to be able to set the speed of the RA and DEC motors independently. Like that, if for example the RA is still far away from the target location but the DEC is already very close, the RA can continue moving with maximum speed while the DEC can use a lower speed for the remaining short distance. This new functionality worked fine on the test bench (where I have only a DEC motor board and motor), but unfortunately had a side-effect when testing with the real hardware: The automatic tracking of the RA axis didn’t work any more. The motor had a complete stand-still when I didn’t use the hand controller. Luckily, the bug was obvious and could be fixed on-site: I had modified the code to send speed information to the motors. In the past, 4 speeds A (slow), B (medium), C (fast) and D (very fast) have been available, in addition to an idle speed. This has a historical reason: Our old motor controller also supported these 4 speeds, and I had decided to keep it that way when developing the motor board firmware several years ago. Now, for the ‘GOTO’ functionality, I had extended the firmware of the motor driver boards to support a new speed ‘E’, followed by number of centisteps per minute for RA and DEC. In the ‘idle’ condition, the terminal board requested a speed of 0 centisteps per minute instead of 60000 centisteps in RA, causing the stand-still.

There are a couple of other open points which need to be fixed before the firmware is ready for using by our team:

• The telescope should disallow ‘GOTO’ requests below a certain number of degrees above the horizon, e.g. below 10°.
• It should also disallow ‘GOTO’ for the ‘forbidden zone’ where the tube collides with the foundation of the telescope. Sure I will have to determine this ‘forbidden zone’ somewhen soon.
• The feedback board should periodically transmit the ‘GOTO’ status to the RA Box. Currently, there is no feedback whether a request has been accepted and is being executed or not.
• 'Align to home position' and 'align to target position' are currently missing in ‘Align’ mode. I had removed those when adding the ‘GOTO’ mode but forgotten to add them back in.
• The remaining distance in RA in ‘GOTO’ mode should also be displayed in degrees. Currently it displays in hours, and it’s hard to compare it with the distance in DEC which is already displayed in degrees (see the intro photo - the telescope is 0.887h and 13.389° away from the target object).

So there remains some work to be done for the next two or so weeks before I will run the next tests with the real hardware.

(to be continued...)