Jump to content


Photo

Intelligent motor controller ideas

  • Please log in to reply
16 replies to this topic

#1 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 20 May 2012 - 07:42 PM

Folks,

EQMOD has been very successful in enabling the very powerful Synscan microstepper based GOTO mount to be extended with many powerful features.

Since Synta/Skywatcher has released its intelligent motor controller API into the public domain: http://code.google.com/p/skywatcher/ there will be many new opportunities.

To name a few:
- use smartphone or embedded controller to control the GOTO mount
- understand the inner working of the intelligent motor controller
- use an additional add-on module (software or hardware) to make a DC-servo based motor controller to be equally capable as intelligent microstepping motor controller
- understand what would be the better configuration to adapt to a different mount with different gear ratio
- many others

In the next few posst, I'll describe the motor controller, math calculations, and the protocol used to communicate with it.

Clear Skies!

ccs_hello

#2 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 20 May 2012 - 08:42 PM

To start, I'm describing how the intelligent microstepping motor controller can be controlled.

Electrically, a 3-wire, TTL level RS232 serial signal is required, namely Ground, Rx, and Tx. Typically, a Synscan handbox (HBX) is connecting to this motor controller. Alternatively, a Windows PC can use its serial RS232 port (if the PC has it) dropping down to TTL level (by a level shifter/transceiver). A more popular option is to use a USB-serial RS232 TTL-level dongle to perform such function. (One popular commercial product for that is an EQUSB device.)

Communication-wise, the communication is always initiated from the handbox side. The control word starts with a ":", followed by one character (as Op code), then either a "0" (for RA) or "1" (for DEC), followed by the optional parameter, then end with \r (0x0d) character to the end the command.

The motor controller will take in the command and execute it, if the command is coherent with the intelligent controller's internal state.

Note 1: although some command (e.g., GOTO a new position) may take time to complete, the motor controller will still return with the acknowledgement immediately. Affirmative return started with "=" (followed by optional status/parameters). This only confirms that command is received okay and is not violating the motor controller's state. Negative/error would return with a "!".
Note 2: there is no queue in the action-command queue. A new action type of command will supersede the previous action type of command.
Note 3: there is no call-back from the motor controller side (e.g., GOTO command completed). So the handbox side has to poll for the current status from time to time.

The command Op code can be lower case alphabet, which is to get information or status. Some of them are simply getting pre-stored mount basic parameters (they are hard-coded, defined in the motor board firmware, and not changeable). Others are used to query intelligent motor board status (e.g., current position).

The command Op code can also be upper case alphabet, which is reserved for action type of commands. E.g., "L" is for emergency stop (when mount-hit).

Next post: the meaning of static mount configuration information.

Clear Skies!

ccs_hello

#3 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 20 May 2012 - 09:57 PM

Query mount configuration:

"a" is total microsteps per 360 degree (RA-axis).

Both EQ6 and HEQ5 mounts' value is 9024000 which is 705 (mechanical gear ratio) x 200 (stepping motor's 200 steps/rotation) x 64 (microsteps per step).

"s" is microsteps per one worm rotation cycle. It is used for handbox based PEC adjustment.
For EQ6 (180:1 worm), the value is 50133.
9024000 / 180 = 50133.3333
For HEQ5 (135:1 worm), the value is 66844.
9024000 / 135 = 66844.4444

"g" is high-speed ratio which is 16. This value has nothing to do with fastest slew speed (EQ6 is capable of doing 800x sidereal speed.) I think this value simply means is high speed slewing, the stepper is operated in quarter-step mode. I.e., 1/64 (step/microstep) x 16 = 1/4 (quarter step mode). The motor controller needs that (to shift electronic gear) to (1) reduce stepping pulse count and (2) gain higher torque in high-speed slewing (quarter step stepping is more powerful).

"b" is PIC Microcontroller's interrupt frequency.
This value is calculated and set carefully by the intelligent motor controller's designer. The value is 64935.

I'll explain this "b" value in details in the next post.

Please note these are all hardcoded value and not changeable. They are very useful for a Synscan handbox since the handbox is generic thus has to learn these parameters from the motor controller. On the other hand, if the control side is a PC, it can potentially get these data from its own configuration file and completely ignore the information supplied from the motor controller.

Clear Skies!

ccs_hello

P.S. a flavor of EQ5 (705:1 gear) "a" value is 4512000 (only use 32 microstep/step, only one PIC microcontroller is used as oppose to the normal 2) Also "s" value is 31333.


Another flavor of EQ5 (704:1 gear) "a" value is 4505600. Its "s" value is 31289.


#4 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 20 May 2012 - 10:41 PM

Let's first figure out how the motor controller get its sidereal tracking frequency.

A sidereal day (86164.0905 sec) is one RA rotation which requires 9024000 microsteps to turn the motor.
This means the motor has to run at 9024000/86164.0905 = 104.7304039 microsteps/sec.

This is a tough value to generate. So here comes the "b" value.

"b" is PIC Microcontroller's interrupt frequency.
(b = 64935)

The PIC micro oscillator is 20 MHz (internally run at divide by 4 to run the device at 5000000 cycles/second).

The PIC is using its PWM hardware to generate a fixed frequency as the time base to generate microsteps (or quarter steps).

The value 64935 is the actual PWM frequency of 5000000 / 77 = 64935.06494
I.e., 65935.06494 software interrupts/sec.
The value 77 is set by the firmware.


Then this 64935.06494 value is further divide down by counting in software inside the ISR (interrupt service routine) by a value set externally. This value is set by the Ops code "I" which usually is set to 620. (I.e., I = 620).

64935.06494 / 620 = 104.733871
This value is close enough to the theoretical value.

Of course the "I" value is adjustable. Each increment is about 0.16%.

Changing the "I" value is the method of changing mount's tracking speed, if custom gear is used.

Actually, changing "b" and "I" values might be the best for custom mount. However, "b" is not user-settable.
As a matter of fact, "b" cannot be even an any number. "b" is derived from using the divisor 77. So (hacking the firmware to change it), the next "b" value will be a different number. E.g., divisor 76 will yieid the new "b" value of 65789.47368.

Clear Skies!

ccs_hello

#5 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 21 May 2012 - 12:22 AM

Now let's go over action type of commands which we will hear the motor humming happily...

Basically, this type of intelligent motor controller is known in the industry as the indexer. The motor moves by following step pulses it is applied to. More pulses it moves more. Counting number of pulses the motor receives, we'll know exactly where is motor is moving to.
If we need to get the motor at a cruising speed, just need to apply the pulses at a fixed rate. This is used in sidereal tracking.

Several preparation commands:

"E" to preset the pulse counter to a value. This is equivalent to say where the mount position currently is. (Say just about to taking mount out of Parked position.)

"H" to set how many microsteps from the current position (motor is still at this point) the motor should reach to. I.e., tell the motor the GOTO target location.

"G" command has 4 options, it's just a mode selection; not moving yet
- G 0 is fast GOTO (i.e., GOTO to target position, set by "H")
- G 2 is low speed GOTO (only used when short-distance GOTO)
- G 3 is fast slewing (i.e., move this mount, typically a button push to slew
- G 1 is low speed slewing (seems not used)

"J" now we're ready to go, move the motor

If it's a button push type of slewing, you want to gracefully slowing down and then stop when button is released. That what the "K" command for.

There are other commands related to "break point" setting. These are related to ramp-down (and ramp-up) setting.


Clear Skies!

ccs_hello

#6 John Carruthers

John Carruthers

    Skiprat

  • *****
  • Posts: 3543
  • Joined: 02 Feb 2007
  • Loc: Kent, UK

Posted 21 May 2012 - 02:18 AM

Tom on Astroshed has been working on an Arduino controller for Synscan.

His latest code and hardware schematics are here;
https://github.com/TCWORLD/AstroEQ

#7 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 21 May 2012 - 07:49 AM

John,

I noticed his work in Y!group there.
As I understood, Tom's code currently does not have the proper sidereal tracking speed.
{edit} somewhat corrected now
I hope my explanation (formula and constant frequency design by ISR) could help him or other designers.

Clear Skies!

ccs_hello

#8 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 21 May 2012 - 10:44 PM

Let's do one custom gear calculation:

Let's say we'll use a 4:1 belt-n-pulley arrangement on a EQ6, then mechanical gear down is 720:1 (180 x 4).

A sidereal day (86164.0905 sec) is one RA rotation which requires 9216000 microsteps (720 x 200 x 64) to turn the motor.
This means the motor has to run at 9216000/86164.0905 = 106.9587104 microsteps/sec.

We know the "b" value is fixed at 64935, which is PIC Microcontroller's interrupt frequency.
This translate to I = 607.1034306 thus we pick I=607.
(In original 705:1 EQ6, the "I" value is 620.)

So teh actual timing is 64935.06494/607 = 106.9770427

This value is not too much apart from the theoretical value of 106.9587104.
(Note: the 20MHz crystal itself also has some frequency deviation, say 20ppm.)

Clear Skies!

ccs_hello

#9 TCWORLD

TCWORLD

    Lift Off

  • -----
  • Posts: 5
  • Joined: 22 May 2012

Posted 22 May 2012 - 11:04 AM

Hi all,

Thought I would join in the conversation as I wrote AstroEQ.

At the moment, the system is very much in the early stages, though I have been working on it in and around Uni work. I have however now finally fixed the tracking speed issues with my code. I managed to track Saturn last night for around 20 minutes, before it vanished behind a tree.

My software is not quite following how a real Synscan mount would work as I don't have one - everything I have done is based solely off EQMOD and the source code for the Synta protocol.
In order to achieve proper tracking, ideally the I value should be kept at 620 in my code. In order to do this, the other values are changed around it. Granted if it is not 620 it isn't really too much of an issue, but it is a good guide.

In my code, aVal = number of microsteps per rotation. That depends on the mount. If the number is too high, (>10million by rough estimate), the number needs to be scaled in order to prevent EQMOD having a hissy fit as the number is too high. In the case of my mount aVal = 26542080 ((144*120*24*64) which is too big, so I set a scalar value of 10 to counteract this (all scaling is done internally in the program).

bVal is based of the aVal and the sidereal rate. Such that:
bVal = 620 * aVal / 86164.0905

This number is then used to calculate the tracking speed. The interrupt frequency of the Arduino is adjusted to bring in the correct rate.

Now for an example,
Rate = iVal * clockRate / bVal

For you, bVal = 66314, based on the formula I gave, so, the clockRate is automatically adjusted to be 2MHz so that a larger range of speeds is possible (anything <160000 uses 2MHz, anything larger uses 16MHz, this is done to prevent the delay from being too large for a 16bit timer).

So at Sidereal tracking,
Rate = 620 * 2000000 / 66314 = 18698 clock cycles per microstep.
at 2MHz, that is 0.009349458 seconds per microstep.
Multiply this by the aVal, you get 86164.61 seconds per RA. Which is pretty darn close to the correct speed.



I have been working also to improve the accuracy by varying the speed of each microstep to account for the lost time, though the amound needed to be fixed is so small that you dont notice the change anyway. The latest version is not yet uploaded.


I have also redesigned the hardware (will be ready in a few weeks if my prototype works - yet to build it).
Once done, the circuit can be built entirely out of PTH components, so could easily be built on veroboard, or I plan to make available a kit complete with PCB to build your own.
I have been doing some costings, and for components and boards, it works out in the region of ~70-80 GBP for everything needed.



Any questions let me know. I will keep you up to date with progress.




Tom.

#10 TCWORLD

TCWORLD

    Lift Off

  • -----
  • Posts: 5
  • Joined: 22 May 2012

Posted 22 May 2012 - 12:07 PM

Worth noteing is that the calculation I gave there did not take into account the rounding of variables during calculation. The actual error is larger.
I have created an Excel spreadsheet that calculates the correct values for Scalar, and bVal based of the aVal of a mount. It also calculates the error.

http://www.railways-...Calculator.xlsx

I will upload it to gitHub once I upload the latest firmware revision.
In the spreadsheet, two errors are given: 'With Correction' and 'Without Correction'.
'With Correction' is the result of the latest beta firmware (will be available soon).
'Without Correction' is the result of the current firmware.

For your mount, based on these calculations:
'With Correction' = 0.4695 (s)/RA
'Without Correction' = -3.7065 (s)/RA

So as you can see the correction in the new firmware will dramatically reduce rounding error in some cases.

#11 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 22 May 2012 - 10:47 PM

Hi Tom! Welcome to Cloudy Nights!

Great project!
One area I'd like to know is about how the timing is maintained. Are you using hardware timer for all the counting or its partially software (due to # of counter bits). Also are you using ISR from the timer to ensure the microstepping pulses are generated evenly?

One important topic is about the actual motor drive mechanism.
Per your parameter (24 steps/rotation stepper, 120:1 gearbox, and in addition, EQ5's 144:1 worm), I am guessing you are using the classic tracking-only stepper+gearbox in your mount.
That classic design worried me since it won't go faster than about 40x sidereal. (An EQ6 GOTO's max. slewing speed can be as fast as 800x). Many had tried to push the old design but it really met its design limitations. Modern microstepping GOTO uses a high-torque 200-step (some 400 steps/rev which lack torque, IMO) hybrid stepping motor, little gear-down (e.g., about 4:1) to drive the worm.

Another part is the motor driver. The step rate rarely can go very high (during high-speed slewing). Typical design is to do "electronic gear shift", i.e., change from microstepping driving mode to quarter or full-step driving mode. This makes the design easier and at the same time generates more torque (full step is stronger and in fast slewing situation, you need it). Think about how one would drive a stick-shift car.

Along the same note, motor drive has to have a ramp-up and ramp-down design to overcome the stiction and inertia. If not, stepper will "miss" few steps (the horrible pseudo-gear-grinding sound) in start-to-move phase and "continue to move" when you try to stop it. (Think about how to drive a car :) ). Missing steps is not a good thing for an open-loop design.

I hope you don't mind the inputs. I am just describing the lesson learned or existing designs.

Clear Skies!

ccs_hello

#12 TCWORLD

TCWORLD

    Lift Off

  • -----
  • Posts: 5
  • Joined: 22 May 2012

Posted 23 May 2012 - 05:30 AM

Yeah, I'm not to impressed with these motors, but I managed to get the dual axis motorising kit for £50, so it was nice and cheap. I can get it up to 56X sidereal rate before noticing any issue.
In the future I may upgrade the motors to higher torque 1.8* steppers, but not just yet.

As for accellerate/decellerate, they are both covered in the code - the new version I am working on has improved on it. Basically in goto mode, about 40 steps from the goto distance is used to speed up, and another 40 used to slow down to prevent it overshooting.


All timing is done by hardware alone. The number of clock cycles between each step is calculated and that is fed into a 16bit timer. When the timer interrupts, a step signal is triggered to the corresponding motor driver.
As it is a 16 bit timer, it can count up to 65536. By changing the clock speed of the counter, this is plenty. For mounts with bVal < 160000, a range between 0.5x - 800x is possible by using a clock rate of 2MHz. For mounts with an higher bVal, a 16MHz clock rate is used to allow more steps in a shorter period, without affecting the range.
Note there are two 16 bit timers used (one for each axis) which is why it requires an Arduino Mega - although in the new hardware version, I have modified the bootloader to work with an Atmega162, which is alot cheaper and comes in a DIP40 package so is easy to solder.

As for changing gear so to speak, that is not currently in the design. I haven't linked the stepper motor drivers mode pins to the Arduino. I may have a go trying this.
In terms of programming, no recalculation would be needed. At the moment, 1/16th microstepping is used. So by switching at high speeds to half-stepping, the timer speed would simply need to be changed from 16MHz to 2MHz, or from 2MHz to 250kHz depending which it was using to begin with. With the arduino timer, the clock scalar is multiples of 1/8, so this would be fairly trivial to do. However it would change the way steps are reported to EQMOD, so maybe it would be better to have a variable in the ISR that counts 8 interrupts before sending a step to the motor, but still updates EQMOD every interrupt.
I am always happy to recieve input :)

#13 TCWORLD

TCWORLD

    Lift Off

  • -----
  • Posts: 5
  • Joined: 22 May 2012

Posted 07 June 2012 - 07:08 PM

I have managed to port the Arduino Bootloader to work with the Atmega162. The IC is half the price of the Atmega1280 which was being used before but still has the two 16bit timers required, and best of all, it is a nice big DIP package, so it is DIY friendly :D.

I am currently working on a new prototype board which I will be milling out soon. If that works fine, I have managed to source almost all of the circuit components to be through-hole (easy to hand solder), and plan to make available a DIY kit if all goes to plan.

I have costed it up, and for all the parts including a professionally made circuit board, it comes to approximately £80, which is a darn sight cheaper than the Synscan handset.

Firstly though I need to build the prototype and check that all works as expected.

Tom

#14 Deeleins

Deeleins

    Lift Off

  • -----
  • Posts: 1
  • Joined: 19 Jan 2014

Posted 19 January 2014 - 09:05 PM

Sounds just what I need. I have different stepper motors though, they are 1.8 deg sanyo denki 103H548- 04500. Would your kit work with them or require me to modify something?

#15 Geo.

Geo.

    Mercury-Atlas

  • *****
  • Posts: 2791
  • Joined: 01 Oct 2008
  • Loc: Upstate NY

Posted 20 January 2014 - 01:20 PM

[quote}The PIC micro oscillator is 20 MHz (internally run at divide by 4 to run the device at 5000000 cycles/second).
[quote/]

Wasn't 5Mhz what the first IBM ATs ran at :question: And you had to slow the PIC down - I'm getting old :foreheadslap:

#16 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5355
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 20 January 2014 - 08:23 PM

I'm getting pretty interested in the Intel Galileo. 400 MHz! Arduino Uno pinout! 5V compatible!

#17 ccs_hello

ccs_hello

    Fly Me to the Moon

  • *****
  • Posts: 6373
  • Joined: 03 Jul 2004

Posted 20 January 2014 - 10:37 PM

The trick is to proper balance the work load. Put real-time intensive to the intelligent motor controller, and do the math calculation elsewhere (the intelligent handbox or a PC.)

For the former, the timer based interrupts governs the tracking precision while GOTO is just a simple pulse counting. Add trapezoidal speed profile, microstep step-changing (i.e., electronic gear shift), and simple command parsing, it still can fit the PicMicro's RISC core.

Clear Skies!

ccs_hello






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics