×

INDI Library v1.9.8 Released (29 Sep 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

For those with focus issues

  • Posts: 554
  • Thank you received: 138
This is a common way of implementing backlash. All moves approach the final position from the same direction and distance. This eliminates backlash by ensuring that all moves finish in the same direction. Backlash is your M parameter.

The example shown seems to have found the minimum with the focuser moving out instead of in but there is nothing except friction stopping the camera moving out the 100 steps of the backlash and being out of focus by 100 steps. If the focuser finishes by pushing the camera in which, with the telescope looking at the sky, will be up there will be less chance of unepected focus shifts.

Chris
2 years 9 months ago #47169

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

  • Posts: 19
  • Thank you received: 3

Replied by Frank on topic For those with focus issues

this is a great step forward for all SCT owners!

Thank you for your work !

Frank
2 years 9 months ago #47171

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

  • Posts: 931
  • Thank you received: 127
Hy,
imaging went so-so. Seeing was horrible (for my site), but I got almost 6 hours on LDN1584. Will have to see.
Yes, that is what I sugested. As Chris wrote, it is one standard way of handling backlash in absolute position units:

It has the advantage that any value larger than the actual backlash will give you correct performance (maybe at the price of moving too much). This is however different from the BL handling within the focus units themselves. They usually move the additional amount if the direction is changed, and then change the reported position. This one only works correct if the amount you specify is exactly the BL. So IMO it is even superior to the driver-supplied BL.

In principle it's something that should be in the general focus module, a radio button to activate the always-end-with-inward-movement behavior, and an amount for the overdrive (because that can largely vary depending on the focuser). (I had tried to change the focus movement code to implement this, but I don't speak C++ and gave up quickly :sick: )

I'll have a look. Maybe it's easier to test/modify in the focus module

While you're right in principle, with a large BL that can get extremely unhandy for the refinement steps, even more if you still take measurements at each of those positions. That is why I'd prefer to have this as a separate configuration option. And ideally (as pointed out above) not even in (your) focus module, but in the general focus driver - then all focus algorithms will benefit.

Yes indeed, it did. It's not a desirable thing, as you point out. I might try to look at that again - but maybe you can also investigate how to implement that correction type in the general focuser class?
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 years 9 months ago #47174

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

  • Posts: 554
  • Thank you received: 138
All the drivers I've written have implemented backlash as I describe, see the CelestronSCT focuser driver for an example.

Doing it as you describe will be a nightmare for the user because it depends critically on the user setting the backlash parameters exactly right and the hardware retaining that backlash value regardless of position and temperature changes.

Yes, in principle but I have a bad feeling about this, it could get far more complex than it appears. The code for a single focuser isn't complex and can be tailored to that exact focuser hardware.

Feel free to prove me wrong though!

Chris
Last edit: 2 years 9 months ago by Chris Rowland.
2 years 9 months ago #47185

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

  • Posts: 931
  • Thank you received: 127

Good to know!

Indeed, but (unfortunately) it seems to be how units like the DMFC or the ZWO EAF do it (in firmware, I assume). They do the correction both ways, and (just) add the BL without counting it. The method you describe would only do compensation when moving out, no? And of course you can see the movement of the motor.

Well, you (obviously) have (a lot more) experience there, so I'll trust you ;)
But it means you only get it for drivers that actually implement it. So in my case, I would prefer setting the driver-internal BL compensation to zero and use such a global end-inwards mode....
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 years 9 months ago #47188

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

  • Posts: 885
  • Thank you received: 420
Chris, Peter,

Here's my reaction/interpretation of this conversation. I'm flexible, and of course want to implement the algorithm as best as possible. However, I'm being conservative, and until we prove we have an improved algorithm, I'm trying not to change the existing focus behavior (e.g. if you select the iterative or Polynomial algorithms, things will still work as they were). Those algorithms move in both directions. I intended for the Linear algorithm to just move in.

So, when I get a chance, I'll make a change to Linear, where, at the start of the 1st and 2nd passes, it will move out N+M, not take any exposure, and then move back in by M and start the exposure sequence. I'll set M at, say 5 steps. I don't think Peter's concern that a large M might affect refinement steps, because this is just applicable to the start of the two passes, which are not refinement moves. The half-step inward moves during the 2nd pass are my only refinement moves at this point, and they are all moving in after this backlash-removal moving is done. Hopefully the current change, and this modification, will improve things enough so that folks can test out the in-only "Linear" auto-focus algorithm, and demonstrate improvement over the previous algorithms.

I'm sure I can implement the above "N+M change", but I checked and it isn't a trivial mod (it may be small in number of lines, but not trivial in getting it right) so I want to do it carefully,

Let me know if this plan is OK,
Hy

PS Out of curiosity, I've read from Jasem, and Frank above, that this change should especially help SCT owners. Why is that? What is it about SCTs that is different than, say, refractors with respect to auto-focus?
AP1100 & Orion Atlas Pro, WO/ZS105 w/Moonlight V2 focus, GSO RC10 w/RSF focus
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Greedy Scheduler, Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
The following user(s) said Thank You: Alfred
2 years 9 months ago #47237

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

  • Posts: 885
  • Thank you received: 420
FWIW, here's the code change for that
phabricator.kde.org/D26218
Jasem will review it.
AP1100 & Orion Atlas Pro, WO/ZS105 w/Moonlight V2 focus, GSO RC10 w/RSF focus
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Greedy Scheduler, Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
2 years 9 months ago #47239

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

  • Posts: 554
  • Thank you received: 138
The reason that SCTs benefit from backlash correction is that they focus by moving the primary mirror. The mechanism has a lot of backlash, I've seen as much as one turn of the focus knob although more recent scopes are better. Focus is best done by pushing the mirror up against gravity because then it holds focus. If you focus downwards the mirror has a tendency to drift downwards through the backlash. Most people end up getting a secondary focuser and locking the mirror.

Having backlsh can't do any harm and I'd be inclined to implement it independently for all focus methods. I'd have a signed value where the sign controls the direction in which backlash is done and the user can set the amount, zero would be no backlash. I wouldn't have a separate switch. This is too radical for now though.

i've been looking at implementing backlash in the base indifocuser.cpp and the difficulty is that many focusers check that the move has finished in a timer and then do something like this:
FocusAbsPosNP.s = IPS_OK;
FocusRelPosNP.s = IPS_OK;
IDSetNumber(&FocusAbsPosNP, nullptr);
IDSetNumber(&FocusRelPosNP, nullptr);
LOG_INFO("Focuser reached requested position.");
IDSetNumber goes directoy to indibase. Can indifocuser.cpp intercept the IDSetNumber call so it can start the second move?

Chris
2 years 9 months ago #47247

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

  • Posts: 19
  • Thank you received: 3

Replied by Frank on topic For those with focus issues

Hi Hy,
as Chris said, my Celestron can have BL but especially the problem of the flip mirror when you change direction for focusing. This is the reason why I can not do autofocus, but maybe I do it wrong especially over the duration of the subs?

Merry Christmas to all !

Frank
2 years 9 months ago #47250

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

  • Posts: 931
  • Thank you received: 127
Hy, thanks for this change, and Jasem already approved your submit :)
I'm having clouds (of course - it's New Moon.... :( ), but tomorrow night is predicted clear. I'll try the changed routine then and report back.

Chris: Yes, I agree BL compensation should eventually work independent of the focus algorithm (and, as I mentioned, probably also independent of the driver). One reason for that IMO is that the concept of 'outward' and 'inward' is really only known to EKOS (or am I completely wrong there?). But for now, the linear algorithm is a perfect test bed to check the best implementation. And getting it in the device independent part has several traps (like what to do with a driver-internal BL compensation? Should it be switched off when end-inwards is active?). So it's good to have one algorithm that uses it already now...
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 years 9 months ago #47251

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

  • Posts: 931
  • Thank you received: 127
Hi Hy!

Just playing with the new version. The plateaus are now gone, that's very nice. Attached are three runs, the first with a step of 30, the second and third with 20.
The derived focus positions were 45638 (step30), 45648 (step20 1) and 45608 (step20 2). That the last one is lower for sure is a (real) temperature effect, it's currently dropping at 2 degrees/hour. So that's nothing to worry about.

But the stop criterion is still a bit sharp - it will largely be affected by seeing. Especially the second and third run got a good frame and stopped, both times I'd say a bit too early. Not sure though how to catch that other than doing a polynomial fit including all points after also the fine scan went (clearly) through the minimum. The latter might suggest to wait even one exposure longer for both repeats to make sure it wasn't seeing bending it up (I think this happened in the second scan). And in that scenario it would also need a final move-out and then back in to the detected focus.

But the general shape of the curves looks promising to me :D

Cheers,

Pit

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 years 9 months ago #47276
Attachments:

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

  • Posts: 1117
  • Thank you received: 182


I am using a self-built, timed DC motor driven autofocuser. This is my decidedly low-tech solution how I overcame the friction/focus shift/slippage problem.

A couple of rubber bands:

Atlas Pro AZ-EQ, ASI1600MM-Pro, ASI120MM-S, ES102ED, WO-Z61, Nikon D3300, ASI-EFW, ZWO LRGB,Ha,O3,S2 filter set
Last edit: 2 years 9 months ago by Jose Corazon.
2 years 9 months ago #47328
Attachments:

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

Time to create page: 2.099 seconds