×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Always focus from one direction

  • Posts: 421
  • Thank you received: 102
Hello,

I have recently written an INDI driver for a DIY focuser. One thing I've implemented is the ability to always approach focus from one direction, to eliminate backlash. But it seems to me this is the kind of thing that would be universally applicable to almost all focusers. So do you think it would make sense to implement this in the Ekos focus tab? Some extra options under "mechanics" perhaps?

The current anti-backlash implementation in most focus drivers is a fixed number of steps that get added when changing directions. This requires a lot of trial and error, or careful measurement. The approach I've implemented (which I believe is the same method used in Sequence Generator Pro) is to always approach focus from one direction. For example, if the focus needs to move in, then move in the desired number of steps. If it needs to move out, then move out the desired number of steps, plus some arbitrarily large number of steps, then move in to the desired position.

Does this sound like a good idea, and should it be in Ekos focus module?
The following user(s) said Thank You: Jose Corazon
3 years 10 months ago #54644

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20
It sounds like a good idea to me. It eliminates backlash as a problem. I built a focus controller as well, and I incorporated backlash compensation, only to realize that the backlash may not be there in the real world, or may be different at different positions in the sky. The one direction approach makes all of that moot.
3 years 10 months ago #54648

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Kevin,

That is already implemented. That was exactly the rationale on which Hy designed the Linear focus algorithm in the focus module in Ekos. Just change to 'Linear' instead of 'Polynomial' and it will do exactly what you describe.

Look at the 3rd picture in my post here: indilib.org/forum/focusers-filter-wheels....html?start=36#53928

It shows the linear focuser in action. You can follow the incrementally numbered focus measurements as they first establish the U curve and then the focuser moves back again and starts to home in from one direction only onto the calculated minimum in half-size steps.

Jo
Last edit: 3 years 10 months ago by Jose Corazon.
3 years 10 months ago #54649

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102
Excellent! I'm glad I asked before implementing! :)
3 years 10 months ago #54654

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102
Well actually....

I looked at that picture. 21 iterations to reach focus! Wow. Polynomial works pretty well for me, and usually in 7 or 8 iterations.

I suspect a universal anti-backlash mechanism would be useful, so that it isn't tied to one focus algorithm. Or more likely, it will need to be added to polynomial algorithm. (Are there more algorithms? I don't remember).
Last edit: 3 years 10 months ago by Kevin Ross.
3 years 10 months ago #54655

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
IIRC I had placed a wishlist request for this feature some time ago. As in a general option for all focusers to always end moving inwards, ideally with a configurable overshoot amount. I think it would be a very useful thing to have!
So I would definitely welcome it if you go ahead and implement it :D
The following user(s) said Thank You: Jose Corazon
3 years 10 months ago #54664

Please Log in or Create an account to join the conversation.

So you can implement this in your driver with Ekos needing to know about it. Once you detect a switch in direction, you perform the large move and then go back to that position again. As far as Ekos is concerned, it's just waiting for you to finish your move.
3 years 10 months ago #54667

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
But couldn't (shouldn't?) that capability go to the general INDI focuser class, so that any driver can benefit?
3 years 10 months ago #54669

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

I also would love to have that configurable overshoot amount, both on the initial way out (how far from established focus the module moves the focuser before homing in again) and on the return after the U-curve has been established.

In theory, the polynomial algorithm should be faster, but that only applies to a system without backlash or with only minimal amounts. The moment there is any backlash, the linear approach is clearly superior in my hands.
3 years 10 months ago #54671

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

The approach to the minimum is very methodical and does take longer than the polynomial, but it is also very versatile, as it works GREAT with analog focusers and FCUSB. There, the movements of the focuser are highly load dependent, in contrast to steppers. Nonetheless, the linear focuser handles that with flying colors. But making it more configurable, as Peter suggests below, would definitely be especially useful for such analog systems, I agree.
3 years 10 months ago #54672

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102

I've already done that. I was asking if putting this in Ekos as a universal solution was better. :)
3 years 10 months ago #54705

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102

Doing it there, rather than in the Ekos UI, is also an option. I hadn't considered that.
3 years 10 months ago #54706

Please Log in or Create an account to join the conversation.

Time to create page: 0.844 seconds