Ardufocus - open source Moonlite compatible focuser

[jbrazio]

Ardufocus is a full open source Moonlite compatible focuser.
The source is still under heavy development so things move around a bit.

To access source code and detailed instructions visit the Github repository, for the 3D objects visit Thing #2446069.

 

Motivation
After buying the CCD, filter wheel and filters I was broke but still wanted to have an automatic focuser.

 

Design Goals

1. Moonlite compatible: This was a very important part of the design as I didn't want to spend time and effort dealing with ASCOM and INDI drivers, the Moonlite focuser is a well known, reputable rock solid focuser. The serial protocol used by them was easily reversed engineered (plain ASCII) and most of it was already documented on the Internet.
2. Cheap: Another big point was to made it as cheap as possible recurring to as few parts as needed. That's the reason why the 28BYJ-48 stepper motor was chosen, out-of-the-box using the ULN2003 gives you a really cheap (less than 2€) focuser for medium loads (380gcm). If you require the focuser to driver heavier loads (800gcm) then the motor itself can be modded into a Bipolar stepper motor and driven by the A4988 step stick which will cost you less than 1€.
3. Builder friendly: Using off-the-shelf components such as the Arduino Nano and easily available parts Ardufocus is aimed to be build by anyone with a soldering iron and some patience, no degree in electronics required.

 

Hardware
It was built on top of a standard ATmega 328 Arduino such as UNO, Pro or Nano; currently it does not support the Mega or any other ARM based board.

 

BOM

• 1x Arduino Nano
• 1x A4988 Stepper Motor Driver Module
• 1x Electrolytic capacitor 10uF
• 1x NTC 10K 5%
• 1x Resistor 1/4W 10K
• 1x DC Power connector (male, female pair)
• 1x DB9 connector (male, female pair)
• 1x 28BYJ-48 Stepper motor

 

3D printed parts
To download and print instructions for the 3D printed parts have a look at the Thing #2446069.

 

A4988 driver with a Bipolar motor
Example schematic how to building and Ardufocus using a modded 28BYJ-48 Stepper motor.

Edited July 22, 2017 by jbrazio

[jbrazio]

Quick update on the project:

To upload the code into your nano/pro/uno it is no longer required to have Platformio installed, just fire up the Arduino IDE and open the .ino file on the project's root.

[NickK]

Ahh I've already done just this! I have the INDI based moonlite controller (ODroid C2) --USB--> Arduino Uno -> DRV 8825 -> 3.8V 650mA stepper motor with 100:1 gearbox

I made the moonlite focuser protocol have a few better commands.

Torque on this is stupidly high - hence the need for a couple of stop switches. However it means I can hang a heavy set of cameras off the focuser. The Pentax only has a 1:1 focuser - hence the need to have both high torque and accuracy. The system can also step in 1/32.

Quite happy to slot into this - can share the code if you'd like. Note entirely finished (ie it won't shift between stepping speeds) so will detect limit stops. Issue here is how to signify to INDI that the limit stop is achieved. These are some of the shortcomings of the moonlight focuser protocol.

 

Edited November 20, 2017 by NickK
8825 not 2285

[NickK]

I'd be happy slotting into to the driver for the DRV8825 - a current chopper driver.

Only thing I couldn't see at the moment in the code is the stepping sync points when micro stepping. So when you change down to 1 then 1/2 then 1/4 .. 1/32 for example the point on the stepper when the stepping align is specific to the microstepping driver.

Thread, development and sources: 

 

Edited November 20, 2017 by NickK
8825 not 2285

[jbrazio]

Hi Nick !

Which stepper driver are you using in your implementation ? Is it the DRV2285 ? I had yesterday night a request to support the DRV8834.

The Moonlite protocol is not a gem, specially if you look at the second motor control.. it looks what it was.. a hack to something already existing, nevertheless is a well known and supported protocol. My intention was not to extend the existing protocol but to be a stand-in replacement for their control box and allow at the same time a low cost DIY entry to auto-focus.

I thought about end-stops, which I believe have a special importance for remote observatory operation using Crayford focusers; Crayford focusers rely on friction between two polished surfaces, one being the control rod and the other one the flat zone on the tube itself, as there are no "sync notches" slippage will occur no matter what, the integral of the slippage during time will start to drift the focus point between sessions, that's why a end-stop or better a home-end-stop was something that already had crossed my mind and in fact the Moonlite protocol supports it with the "PH" command.

If you intention is really to have end-stops (in and out) then I also believe no protocol extension is required, just behave like a "FQ" command stopping the motor and the position counter. But I'd like to have more information on the protocol extension you have built to make them work and all things INDI. :-) I will happily welcome you on board.

> I couldn't see at the moment in the code is the stepping sync points when micro stepping

You're right, I do support micro stepping but I do not change the way the step counter behaves (i.e. 4x 1/4 micro-stepping = 1 step on the counter), I always consider each micro-step a step (i.e. 4x 1/4 micro-stepping = 4 steps on the counter), this was basically because the step counter is a integer thus nor the software nor the firmware are expecting to receive floats. If your suggestion is when changing from 1/1 to 1/4 micro stepping the counter should be updated i.e. multiply by 4 then that's a really insightful suggestion which I will implement ! :-)

[NickK]

Interesting the DRV8834 only does 2.5-10.8V max. The reason I went with the specific stepper and DRV8825 (sorry 2285 was my mistake!) was that it handled 12-14V which means you get good back EMF resist and is easily powered from a car battery/PSU that's powering the rest of the hardware (cameras, filter wheels etc).

"1.9 us; they can be as short as 1 us when using the A4988." this is something to be weary.

"DRV8834 only has two pins for setting its microstep mode" the DRV8825 has three pins M0,1,2 like the 4988.

So basically the DRV8834 is a low voltage high current. Whereas the 8825 is a high voltage and medium current.

You need some voltage headroom to overcome the EMF so the step is a solid positive step rather than having it fail to step when under physical load. The 3.8V stepper is recommended to have 12V to step but you do need to set the chopper part of the driver to limit the current or the stepper gets really hot

 

The other thing I was looking at is adding an IR remote control for INDI for the apple mac IR remote  then you can manually move the focus without touching the scope.

[NickK]

4 hours ago, jbrazio said:

If your suggestion is when changing from 1/1 to 1/4 micro stepping the counter should be updated i.e. multiply by 4 then that's a really insightful suggestion which I will implement ! :-)

Ahhh.. this the twist  I didn't get to make it accelerate or finalise it - life got in the way.

For example - steppers values only sync up at specific steps in the cycle. At 1/32 micro stepping - only at step 17 does the step sync with 1x stepping. So to switch you would need to 1/32 micro step to step 17 before switching the 1/16 etc (which is now step 9)- this also impacts the reset position:

// on reset the step position homed depends on microstep mode
#define RESET_HOME_STEP_POSITION_1 1
#define RESET_HOME_STEP_POSITION_2 2
#define RESET_HOME_STEP_POSITION_4 3
#define RESET_HOME_STEP_POSITION_8 5
#define RESET_HOME_STEP_POSITION_16 9
#define RESET_HOME_STEP_POSITION_32 17

Now imagine switching between micro stepping like an automatic gearbox on the car depending on the velocity of focuser- with the stepping knowing it has 400K microsteps to do it may be better to sync through to 1x stepping then operate in 32 step leaps at 1x speed before slowing down to 1/32 again for the final sets of steps.

Yes - I use micro steps for counting, however the step count is a max of 0x0000-0xFFFF or 65K steps. Which when you have a 1:100 gearbox and 1/32 stepping on a 1.8deg step and 2.8 turns of the focuser .. results in about 1.6 million steps limit to limit  An extreme example.. however 65K for a full range isn't good.

Lastly I was researching an 'automatic' way of detecting the range of the focuser. It attempts to find each limit switch and then calculate the full range of counts. So that way it will not attempt to move and hit the limit - it already knows there's a limit that will be hit before it accepts the move.

 

I agree the MF protocol isn't great - many of the protocols in the industry aren't designed but evolved.. 

Edited November 20, 2017 by NickK

[jbrazio]

So you would like to have a "stepping profile" that would automatically switch between the micro-stepping modes ? This is interesting but is it an overkill ? Specially with your 100:1 setup. The setup I'm using has a 64:1 reduction on the gearbox and then the gears further reduce that 3:1, I don't feel the need to drive to focus motor other than full step mode, I get very fine precision focusing with SGP using 100 step per frame with a minimum of 9 frames it 99% of the time enough for the system to get the optimal intersection point.

[jbrazio]

Happy new year !
Some fresh news to start the year.
 
- Uploaded to Thingverse the .stl files to 3D print the controller enclosure.
- After an overall code refactoring job the v0.1b has been released on Github.
- Documentation improved a lot, it should not be clear what you need to do and how to do it by reading the README file and the config.h file.
 
Important: Please have special attention if you're upgrading from a previous version of Ardufocus as the AREF has changed from External (3.3V) to Internal (1.1V), the physical wiring changed accordingly. You may need to modify your board layout before uploading the new version.
 
 
 
PS: For the eagle-eyed ones.. yes, that on the left is a second focus motor output port, stay tuned. ;-)

[jbrazio]

Fresh update, yesterday I've released Ardufocus 0.1e, the main changes are:
- Improvement on the stepping procedure
- Both A4988 and ULN2003 driver boards now provide exactly the same functionality
- Implementation of acceleration profiles: No-acceleration, Linear, Trapezoid and S-Curve
 
See changelog since last release.
Please report back any issues you may have found.

[NickK]

Hi,

Just had a look at the code whilst I have a biscuit and drink break.

I see you're using SLEEP pin by default:

• power to the H bridges is cut so if the load requires the current rather than friction to hold that could mean the the focuser moving especially with momentum generated by speed with mass.
• re-enabling after a sleep, although it doesn't reset the microstep count in the driver, the stepper motor itself may step to the next winding (ie 1/2 or full step)
• there's a 1ms delay before the DV8825 before the stepper driver is ready to take any instructions such as a STEP operation, there's a 250us delay using operations in call in step() before attempting the step in the 4988 driver. 

In the end the DRV8825 doesn't get that hot, even when micro stepping so it may be better defaulting to not sleep.

It should be an easy exercise to create the 8825 from the 4988 by a subclass and override of a delay method.. (or a little refactoring to make a DRV base class for both drivers).

 

Edited June 21, 2018 by NickK

[swaxolez]

Looks like great work Jbrazio.  I noticed that in your wiring scheme for the unipolar 28bjy-48 that you show a 12V power supply.  My 28bjy-48 is a 5V so perhaps you should make that clear as 12V would run too hot?

Also, I too have the skywatcher ED80 and so am printing out your design.  Do you have any pictures of your final installation?

Appreciate your hard work.  Thanks

[Gina]

There are 12v versions of the 28BYJ-48 though not a ubiquitous as the 5v version.

[swaxolez]

Thanks Gina.  I was aware of the 12V.  I was thinking he might want to specify 5V for 5V and 12V for 12V.  The ULN2003 is a little misleading as it says 5-12V.  

[jbrazio]

Sorry for the late reply but for some reason I'm not getting e-mail notification of the subscribed topics.

@NickK In one hand powering down a stepper driver will make you lose accuracy exactly has you described, on the other hand leaving the driver in holding torque will make the motor heat. My main concern is not the driver itself but the motor, the 28BYJ-48 running at 12V gets pretty toasty. Has this is not a one size fits all situation I leave up to the user to choose by toggling MOTOR1_SLEEP_WHEN_IDLE. However there is a catch, you need to have full accuracy during an auto focus run, i.e. when you're moving on the focal axis and taking measurements and then moving back to the best position; you don't really need that much accuracy between runs, i.e. you auto focus now and then auto focus in one hour. For this reason even if you have MOTOR1_SLEEP_WHEN_IDLE enabled there is an undocumented flag that defines a timeout after the last move before the motor's power is cut, by default this is set to 5 seconds. This should be set to accommodate the time it takes for your setup to take a frame and analyse it before moving into the next position, this way your motor will be powered off during most of the session but still keep accuracy when it is really required to.

If the changes required to make the DRV8825 work are as trivial as increasing the delay after a sleep instruction then I suggest the following:
https://github.com/jbrazio/ardufocus/compare/patch/drv8825

@NickK could you please comment ? Thanks.

@swaxolez in fact there are two versions of the 28BYJ-48, the ULN2003 driver board is the same for both models. You must power the driver board either with 5V or 12V according with the motor type you have, however you should not power a 5V motor with 12V.

Edited September 3, 2018 by jbrazio

[GuLinux]

Sorry, it might be a silly question, but why do you need the thermistor? I can't see any usage in the code, except for just showing the temperature

[jbrazio]

Not a silly question.

The Moonline protocol allows the activation of a temperature compensation feature but this is not implemented on Ardufocus, the reason why ? I find it useless.. the auto focus program should be the one handling the temperature compensation, just like SGP does. The thermistor still has an important role because you need to provide to the AF program the environmental temperature so it can temperature compensate (not that useful IMO) or automatically run the AF routine on each degree change.

[NickK]

On 03/09/2018 at 12:21, jbrazio said:

@NickK could you please comment ? Thanks.

Hi,

Sorry for the delay responding - just back yesterday. I'll have to have a look again when I have time.  I hope soon.

Nick

[jbrazio]

So here you have, the PCB and schematic files for Ardufocus !
Please note this revision is untested but it passes ERC and DRC.

PCB size: 50x55mm

Edited January 26, 2019 by jbrazio

[Chriske]

We abandoned these along time ago because of : way to much friction compared to regular gears. They  do look nice and very impressive but in our 'plastic' world they have no value at all. In the real mechanical world gears with angled teeth are mainly used to reduce noise in a reduction unit, and also because they're stronger.
Most important issue in a project like this : hole should be as concentric as possible with the outer perimeter.

[jbrazio]

And have less backlash.. that's why I used them in this project.
But you're right the best possible solution would be to print hubs and use a belt avoiding printed gears altogether.

BTW, in our plastic world.. they work nice even in PLA, here is a good channel about the topic: 

 

[Chriske]

23 minutes ago, jbrazio said:

BTW, in our plastic world.. they work nice even in PLA, here is a good channel about the topic: 

 

They would work very nice indeed, on one condition only. The perimeters of your print must be ab-so-lu-te-ly perfect..!

[jbrazio]

In the meanwhile [behind the scenes] I've been working at two major changes for Ardufocus.

1. Introduce a new high-resolution position counter mode
2. Finally implement the second motor driver on the same controller
   

I've built a new focusing mechanism prototype which delivers next level precision basically reducing backlash and removing slippage from the equation.
In theory using single stepping (which is the mode were more torque is available) you can archive sub micron move for each step.. I say in theory because the 28byj-48 stepper motor and it's internal gearbox is not the most accurate thing on the world. I would say a more conservative approach would be using a NEMA17 with no gearbox where each step would be in the order of 4 microns. You may now think about micro-stepping thus increasing the resolution per step i.e. by using a 1/4 microstepping each step can reach one micron resolution.
 
The maximum step value allowed by the Moonlite protocol is 65535 steps (uint16), with my prototype bellow the physical movement of the draw tube will be only 12.8mm.
My TS MonorailR96 focuser has a travel distance of 50mm or 256000 steps.
 

 
Breaking the Moonlite protocol in order to use 32-bit positional counter means I need a new ASCOM driver and that's exactly what I have been baking.
The driver will be backward compatible meaning it will automatically detect either the firmware is a original Moonlite or if it is an Ardufocus running at 16-bit or 32-bit protocol.
 
The driver will come with a standalone graphical user interface to replace the standalone Moonlite tool.
Switching to 32-bit will also allow to have single precision floating point temperature.
 
 
 

 
For all the latest updates follow me or star and watch the Github project.

[jbrazio]

Proper documentation is the hardest thing to build.. 🙂
I've been doing a lot of effort to give this project a proper documentation, I believe it's not ready for prime time but for sure has improved a lot.

Have a look at https://ardufocus.com/
This will be the location with the most updated information around this project.

Any [good or bad] suggestions are welcomed.

 

Is that a world first ?
This is my motorized OAG focuser. 

🤓

[Monk314]

I'm working in my own hardware implementation (alternative PCB and gear design) using an old version of the firmware.

I'm using the moonlite driver under INDI...

My questions are:

1- Most recent firmware version is compatible with old cabling (for an alone motor)?

2- Most recent firmware version is compatible with moonlite protocol? I mean: The last firmware version will works with moonlite INDI driver??

Thanks a lot for your work, Joao...