×

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

Bi-monthly release with minor bug fixes and improvements

Focus backlash issue

  • Posts: 155
  • Thank you received: 12

Replied by Nigel Dunmore on topic Focus backlash issue

Looks like I was misunderstanding NINA.

The relevant page is nighttime-imaging.eu/docs/master/site/advanced/autofocus/

They have two types of compensation.

1.Absolute where it adds on a set of steps at a change of direction - looks to require knowing quite accurately your backlash. Not sure if this can have different numbers of steps for in and out as it doesn’t say but the gui having both seems to point to a possibility.

2. Overshoot which moves past the point then back to it. This has either in or out steps set but only one. This is so the focuser always completes its movement in one direction.


There’s a tip later in the manual - “ Overshoot can be very useful for SCT users to avoid mirror flop. In fact, when setting the Backlash Compensation to IN, the last focuser movement will always be outwards.”. Looks like NINA uses this rather than a switch like I was suggesting. I suppose the extra back and forthing is of little consequence just doesn’t seem tidy to me.

Now time for me to check whether the Celestron sct does the backlash compensation wiggle each move or not..
1 year 4 months ago #88423

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

  • Posts: 155
  • Thank you received: 12

Replied by Nigel Dunmore on topic Focus backlash issue

ok the relevant code looks to be :-
——-
// implement backlash
int delta = targetTicks - FocusAbsPosN[0].value;
if ((FocusBacklashN[0].value < 0 && delta > 0) ||
(FocusBacklashN[0].value > 0 && delta < 0))
{
backlashMove = true;
finalPosition = position;
position -= FocusBacklashN[0].value;
}

if (!startMove(position))
return IPS_ALERT;

———
so the answer looks to be yes. If it’s moving inwards - delta <0 and focusBacklash is positive then it will subtract the backlash ie move further inwards, then later in another bit of code move outwards to the final position. This occurs for both absolute and relative moves. Doesn’t seem to worry about whether this is a change of direction or not which in this case is for the good.No idea why it would want to have backlash compensation in the other direction but the code seems to allow that.
1 year 4 months ago #88426

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

  • Posts: 593
  • Thank you received: 276

Replied by John on topic Focus backlash issue

Thanks for your thoughts both.

Peter, I'm still a little unclear what the benefit of using both driver backlash and AF backlash compensation is? Let me replay what I think you're saying and you can correct me. Lets define:
"consistent" = backlash in equals backlash out
"predictable" = backlash value is always the same everytime the focuser is moved.

Now "predictable" isn't really black or white but more shades of grey. On my focuser 1 or 2 ticks makes no different to focus so if my focuser is unpredictable by 2 ticks then as far as I'm concerned thats good enough to be called predictable. One may be able to argue that as long as the focuser is accurate to within +/- half the critical focus zone then as far as focusing is concerned it can be thought of as predictable.

1. If your focuser has consistent and predictable backlash then just set the number in the driver and all's good. Overscan provides no benefit.
2. If your focuser has consistent and unpredictable backlash then you could set an average value in the driver but moves will be wrong by +/- half the range of values of deltas of backlash. A better approach here is to use the overscan method as it will be more accurate. Combining overscan with driver backlash will also work.
3. If your focuser has inconsistent and predictable backlash then you'll need to set different backlach in and backlash out numbers. Since there is only 1 field in indi this isn't possible (unless the driver stores the values somewhere else, like for example, the firmware of the focuser). Overscan won't work as it assumes a consistent focuser. It could be changed of course, but probably better to add this to the driver and keep overscan simple (just my opinion).
4. If the focuser has inconsistent and unpredictable backlash. You're not going to get good results with this so upgrade the focuser!
1 year 4 months ago #88446

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

  • Posts: 1009
  • Thank you received: 133
Hi John,

Your item number 2 already is the case where both methods are used, and to the benefit of the user IMO.

Also, we clearly have two approaches that do different things. So - again IMO - they should stay separate and independent, especially when one of them is only used in a subset of applications (i.e., the linear algorithms). So just make it optional to use the overscan method (either with a check box, or just by setting the field to 0), but without changing anything in the driver settings.

The use case then is if I don't trust the accuracy of the focus position (be that with or without internal compensation) then I use the overscan, else not. Even if the focuser is absolutely perfect the additional overscan will only cost you some time, but not degrade performance/accuracy.

Definitely in the current state things can/will go badly wrong because the value entered there is copied to the driver setting. For overscan, one usually sets the number higher than the actual BL of the unit. If you do that, also the driver will be set to this (too high) number. This will not affect the linear algorithms, as they always do out/in combinations. But if you manually move the focuser, or switch to another algorithm, that (wrong) correction will stay active, and mess up your focusing.

As I see it, currently the only safe method is to have overscan active, and use the correct value of the BL. This will do the correction twice, yes, but at least the behavior will be the same for other algorithms, too.
1 year 4 months ago #88448

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

  • Posts: 593
  • Thank you received: 276

Replied by John on topic Focus backlash issue

Hi Peter,

So in case 2 it wouldn't it be better to drop the driver backlash and just use overscan, as by definition driver backlash has been deemed poorer than overscan. You can do this today by setting backlash to 0, setting AF Backlash Compensation on. Linear and L1P will use overscan of 5 * Step Size.

Out of interest are you using the ZWO EAF?
1 year 4 months ago #88451

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

  • Posts: 155
  • Thank you received: 12

Replied by Nigel Dunmore on topic Focus backlash issue

Let’s split things down a bit.

1. You have the algorithms - they take a set of data and work out where the optimal focus point is. The data could be a set of images plus focuser position or something like the current temperature and some preprocessed info for it to work out where the focus point is.

2. Backlash - this occurs afaik on change of direction of the focuser mechanism. Simplest solution appears to be to overshoot by some amount greater than the max backlash then move to the real position. It doesn’t really matter if the backlash varies each time or in either direction as long as the overshoot is greater. (I’ve no idea why NINA looks to have settings for both - this could just be the gui misleading me and only one is actually used).

3. Final move direction - in the case of sct’s with a focuser moving the mirror final the move direction needs to be against gravity. This move would also need to apply backlash compensation if it was a change of direction.

Current setup seems to not be quite right as it different parts seem to try and solve problems of other parts. I think the link between the backlash setting in the main gui needs splitting off from the focuser indi driver. Then the backlash compensation done independently of the algorithms and drivers if wanted by the user. The algorithms shouldn’t have anything to do with backlash. The indi driver could implement some focuser specific compensation if needed. The final move direction I think would be in the driver and would be active on every move that’s not in the ideal direction. This would shield the algorithms from bad positions without them having to know about it.
1 year 4 months ago #88453

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

  • Posts: 593
  • Thank you received: 276

Replied by John on topic Focus backlash issue

Just testing this change on the simulator.

So the backlash field remains as is and is linked to the Indi field (so can be changed from either the focus screen or Indi for convenience).

Backlash field - used by device drivers as today (no change), not used by autofocus routines with this change.
AF Overscan field - new field so provide "overscan" by the Linear and L1P algorithms. Set to 0 to disable.

The Backlash and AF Overscan fields now operate independently so either, neither or both can be used (depending of course on your device driver's capabilities).
The following user(s) said Thank You: Peter Sütterlin
1 year 4 months ago #88476
Attachments:

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

  • Posts: 155
  • Thank you received: 12

Replied by Nigel Dunmore on topic Focus backlash issue

What is this overscan thing? Is it just backlash compensation implemented in the lp1 algorithm? Wouldn’t that be the same as breaking the link between the current backlash entry and any driver backlash? What about the other algorithms? Isn’t there a way to implement backlash compensation somewhere between the algorithms and driver? If that was done all focusers would have bc even if their indi driver didn’t implement any and it would work for all algorithms. People whose focuser drivers had a more sophisticated/specific bc setup could use that and switch off this one.
1 year 4 months ago #88478

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

  • Posts: 593
  • Thank you received: 276

Replied by John on topic Focus backlash issue

What is this overscan thing?
I've called it Overscan as the existing field retains the title "Backlash".

Is it just backlash compensation implemented in the lp1 algorithm?
Backlash compensation as in the Overscan method for outward movement in Linear and L1P.

Wouldn’t that be the same as breaking the link between the current backlash entry and any driver backlash?
Yes.

What about the other algorithms?
Iterative and Polynomial are unaffected by this change.

Isn’t there a way to implement backlash compensation somewhere between the algorithms and driver?
Well its all code so anything is possible with enough time and effort but currently this isn't a simple task.
1 year 4 months ago #88484

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

  • Posts: 1009
  • Thank you received: 133
@John: So the two settings are in two different places? The overscan in Settings, and BL in Mechanics? I'd rather have them in the same tab, to indicate it is two different/separate things. But yes, this looks fine (maybe except for the 20000+ outward steps, they'd move my focus tube some 50mm :woohoo: ).
Oh, and what is than CFZ thing?
Are you locally testing that, or is it already pushed to git?

@Nigel: Not sure if 'overscan' is the proper phrase for it, but yes, it's that method that Linear and L1P use, by moving further out and then return inwards when an outward move is requested.

And yes, it would be great to have that as a general feature of EKOS, and is what I had asked for in the Whishlist forum. It seems to be difficult to do this, IIR the reply correct it 'would have to be in the driver'. I'd interpret that as 'the modules talk directly to the driver'. I guess what would be needed is an abstract layer between the driver and whatever uses it, that forwards settings to the driver, but has the additional possibility to do such an overscan move. Then any algorithm, and even manual moves from the focus tab, would benefit from it. But I know too little (read: nothing) about the internal structuring to judge if that would be possible or not.
1 year 4 months ago #88485

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

  • Posts: 593
  • Thank you received: 276

Replied by John on topic Focus backlash issue

The parameters in general need tidying up... I'll hopefully get to that 1 day.

Don't worry about the big step movements, its just my config on the sim.

CFZ is part of the next phase of focus developments that I'm working on. Its early days so won't be coming out for a while as I keep getting sidetracked by production support ;) Just kidding. The changes cover quite a bit more than just the CFZ (hope you like the yellow moustache on the graph). These changes aren't in git yet.

When I get a bit further with the spec I'll post to the forum.
The following user(s) said Thank You: Peter Sütterlin
1 year 4 months ago #88486

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

  • Posts: 155
  • Thank you received: 12

Replied by Nigel Dunmore on topic Focus backlash issue

CFZ - don’t suppose you are working on some way of putting the central focus area towards the back of the cfz so those who either don’t have flatteners or whose flatteners don’t quite work have more of their image in the cfz? Or is that a daft thing?

How are you working out the cfz? I’ve seen different ideas for working this out which for my setup seem to range from over 150 microns down to 20.

Regards

Nigel
1 year 4 months ago #88492

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

Time to create page: 1.202 seconds