Hi all!

I'm considering building a motorfocuser capable of autofocus, using the arduino unit. I found this project: sourceforge.net/projects/arduinofocuscontrollerpro/

However, in this project there seems only to be a focus on Windows and ASCOM. Anyone here who uses a similar setup with INDI/Ekos? Should I have some special concerns and considerations, or would this be unproblematic for INDI/Ekos too?

I've found the description on www.indilib.org/support/tutorials/143-di...cuser-with-indi.html, however, this uses not stepper motors and does not support automated focus, as I understand it.

Magnus

I created a focus drive with an arduino nano and stepper motor; so it supports absolute positioning.
With advice from knro I wrote my own INDI driver.
Works fine mechanically and the software is clean. It does the job. I don't, however, expect a prize for its appearance.
The only big problem is that there is nothing to prevent damage if things are not calibrated correctly and the motor overruns the
travel of the focuser.
I destroyed one stepper finding this out so intend to prevent recurrence with some form of slipping drive.
Happy to share the experience.

I am using arduino here for a number of things as we progress toward finishing our observatory project. One of the items I started looking at recently was a focussing setup for one of the telescopes we have, that doesn't have a decent motor focus. I'm going to base it on a little 5v geared stepper motor I can buy for about 10 bucks, connected to an arduino type of board. My plan is to just implement the serial protocol for robofocus, then I wont need to write any drivers at all for it, just use it with drivers other folks have already implmented, windows, linux, mac, makes no difference really.

In my case, this will be for use on a C8, but, it could / would apply to any telescope, the physical mounting is the hard part. For the arduino program, it's just a case of adjusting variables etc to match whatever stepper motor / driver is used.

I'm doing the same for a dome controller I have prototyped on my desk. Arduino will drive the stepper motor, and for that one, I'll implement the maxdome protocols. With that implemented for the serial port connection, again, dont have to write any drivers for it, indi, ascom, whatever, it'll all just work. Any program that can talk to a maxdome, will be able to run the dome once it's in place.

FWIW, if your arduino based focusser has robofocus protocols implemented on the arduino serial port, then it'll work with indi / ekos right out of the box, just select the robotfocus drivers. Same can be said of any of the absolute focus gadgets that have a full open source implementation within indi, just implement that protocol on the usb connection to the host computer, and it'll all 'just work', no need to write new drivers.

sourceforge.net/projects/arduinomoonlite...ne/?source=directory
Here you can find a software to enable moonlite protocol. I have the same project as yours and will test this software with indi driver when I will be ready to do it. I have stepper motor, and ULN2003 as described in the sourceforge page I need now to assemble all the parts. I hope I will have something working in 2 month.
Maybe we can share our experiences on this topic.

CS
Patrick

Great, thanks!

I'll check the Moolite project out, and will be back to talk more about it, when I get going. But now at least I know it's doable...

Magnus

I recently built a focuser for my SCT and its currently working very well with Ekos. Auto focus works great.
It has backlash compensation and an always approach counter-clockwise motion strategy implemented which is useful when attaching to an SCT mirror shift focus knob. Code and some more details here >> github.com/dokeeffe/ip-focuser

That's an interesting one, but I have no intention of getting quite so complex, ie, why put ethernet on it, when there is already a perfectly good serial->usb connector on the board? I haven't wired it up to test yet, but I've got a little 5v stepper that in theory, can work without even bringing more power, usb connection should have enough power available to drive it. Time will tell, but I have a couple other higher priority projects to get going first.

Gerry,
"why put ethernet on it" Yes thats a good question and does deserve some explanation. I have 2 other arduino devices in my observatory. A roof controller and power switcher, Both use firmata over usb. I've had many problems with this protocol/interface so I decided to use HTTP instead for the focuser. Long term I'm planning on modifying these devices to have an HTTP interface too.

Now it could be my lack of experience with firmata thats causing the issues.
I have experienced the following problems:
1 Intermittent connection failures.
2 Failure to re-connect to the device after restarting indi after a kstars crash. (needs an arduino power cycle)
3 Failure to read digital input sometimes. (the roll off roof limit switches!!!)

I like your solution. It inspires me to implement your anti-backlash measures immediately.

I clearly need temperature compensation too; but have not thought that through.
Have you any advice on the matter or can you, please, point me at any references that I can explore?
Thank you

Robert,
Yes temperature compensation is something I want to include in future. I dont have much experience or knowledge other than the fact I keep needing to refocus as the temperature drops Probably I need to collect data on temperature vs ticks and then derive the function to calculate the ticks-delta based on temperature-delta. Its not trivial but I'd like to get it done at some stage. One problem I will have is that I have the focuser attached to the SCT focus knob. Mirror shifting mid exposure may be a problem for me if the focuser decides to apply a change mid capture.
Derek

What's the time scale of the focus shift? I usually take 5 minutes frames and use Ekos in-sequence-focus to keep focus during the whole night. So after each exposure, focus is checked and if it is lower that threshold HFR, autofocus operation kicks in and once it is complete capture resumes.

That's a good point. This would probably be a better option than built-in temperature compensation because its actually checking the image data.