Auto Focus with overshoot

Anything that doesn't fit into any of the other forums
WB91
Posts: 27
Joined: Wed Jun 17, 2020 3:13 pm

Re: Auto Focus with overshoot

#11

Post by WB91 »

Robin, if you think about it, implementing it should be pretty easy, like having an internal sequence routine. if you have the settings within the Focuser setup to turn this feature on with a check box and also have the ability to enter in a value to overshoot and which direction (Like NINA has), then your sub routine would be just like how I explained it.

If 100 steps is entered in on the IN box, leave Out at zero value. or to make it simple in your software, just have a value box to enter in the steps to overshoot and a drop down box to select the direction (IN or OUT option) The subroutine would be:

Current position (P) is 35000. User commands a position (UCP) of 34500, so before the value is sent to the Focuser, run this logic:

IF Overshoot mode is On and Overshoot type is set to "IN" and value is 100 steps, and UCP < P, then send an absolute Focuser position value to focuser of 34400 (UPC+Overshoot value), then send a following focuser position value of 34500 (relative positive movement = Overshoot value "100").

Lets say user wants to move in a positive direction from 35000 to 35500 in "IN" mode, then:
IF Overshoot is On and Overshoot is set to IN and UPC > P, send focuser to 35500 (send value as you would normally). This mean "IN Overshoot" will always over shoot the commanded IN position direction by a value of 100 each time command and then moves out to position value commanded by user. By doing so, backlash is eliminated because theoretically, all focuser position movements are always moving out.

The "OUT" mode overshoot if selected would be handled like this (Example of a movement from 35000 to 34500):

IF Overshoot mode is On and Overshoot type is set to "OUT" and value is 100 steps, and UCP < P, send focuser to 35500 (send value as you would normally).

Lets say user wants to move from 35000 to 35500 in "OUT" mode which is a positive movement, then:
IF Overshoot mode is On and Overshoot type is set to "OUT" and value is 100 steps, and UCP > P, then send an absolute Focuser position value to focuser of 35600 (UPC+Overshoot value), then send a following focuser position value of 35500 (relative negative movement = Overshoot value "100" ). This mean "OUT Overshoot" will always over shoot the commanded OUT position direction by a value of 100 each time command and then moves in to position value commanded by user. By doing so, backlash is eliminated because theoretically, all focuser position movements are always moving in.

If you wanted to make this more simple, you could leave out the IN/OUT option and always overshoot IN and just use that logic. At the end of the day, backlash is eliminated in either direction you want to move, by you or by the user if you have an option available or not. The reason why NINA has the option to choose IN or OUT is because of their autofocus routine which always move in an IN direction, so when running their autofocus routine with an IN overshoot value of 100, each autofocus movement inward would overshoot 100 steps, which can slow down the autofocus routine, but if you set the overshoot to OUT, the autofocus routine moving inwards and doesn't have to overshoot for each focus location, thus speeding up the routine. Just give us users more control. I do not know how your autofocus routine runs yet, but if you can control the direction of which way it runs, you may want to have the options for user to select In/OUT to help speed up the routine.

So coding should be simple, you add this login in between focuser position change controls to the actual focuser. Hope this helps.
umasscrew39
Posts: 408
Joined: Fri Apr 28, 2017 1:28 pm
Location: Central Florida
Contact:

Re: Auto Focus with overshoot

#12

Post by umasscrew39 »

Hi Robin

Here is a nice quick video on the concept used in NINA..... https://www.youtube.com/watch?v=bc70_iFghQc.

The only assumption this approach makes is that the focuser (which most do) has the same backlash in both directions.

Bruce
User avatar
admin
Site Admin
Posts: 13175
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Auto Focus with overshoot

#13

Post by admin »

Hi folks,

yes, I think this is definitely possible - after all, I already have code that does full backlash compensation (which is more complex than overshoot).

Is it important to be able to choose the final approach direction as well as specify the amount of overshoot? Just trying to work out what are the 'must have' parts of this.

cheers,

Robin
umasscrew39
Posts: 408
Joined: Fri Apr 28, 2017 1:28 pm
Location: Central Florida
Contact:

Re: Auto Focus with overshoot

#14

Post by umasscrew39 »

Hi Again Robin

To your questions: Is it important to be able to choose the final approach direction as well as specify the amount of overshoot?

yes- it is important to choose the direction as one using a SCT (like me) wants to finish counterclockwise to push against gravity vs. a refractor where it really does not matter.

well- specifying the overshoot amount does not have to be precise but one has to have an approximation of their backlash and then add about 50% to it. So, that number can vary greatly based on the step size of a particular focuser.


Hope this helps.

Bruce
User avatar
admin
Site Admin
Posts: 13175
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Auto Focus with overshoot

#15

Post by admin »

Hi folks,

please can you try version 4.0.8173, which has a first implementation of this type of correction (set it up in the hardware settings page). I have only tested with the ASCOM simulator and on terrestrial targets, since it has been rather cloudy, but it seems OK so far.

Note that I have also made the autofocus scan code aware of this option if it is enabled - that means that...

* Autofocus scans can only be made in the approach direction (otherwise every step would require an overshoot)
* Sequencer autofocus scans will automatically swap the start and end values to make sure they happen in the approach direction if they would otherwise happen in the other direction.

hope this makes sense,

Robin
WB91
Posts: 27
Joined: Wed Jun 17, 2020 3:13 pm

Re: Auto Focus with overshoot

#16

Post by WB91 »

Robin, just to confirm, this overshoot method will work for autofocus and focusing via a focus button push (manual focusing)? I will test this as soon as these clouds go away.
User avatar
admin
Site Admin
Posts: 13175
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Auto Focus with overshoot

#17

Post by admin »

Hi,

it will work for *every* focuser movement initiated by the application - if you move in the 'approach' direction specified then it will be a normal movement. If the movement is the other direction then it will involve an overshoot and re-approach from the correct direction.

cheers,

Robin
WB91
Posts: 27
Joined: Wed Jun 17, 2020 3:13 pm

Re: Auto Focus with overshoot

#18

Post by WB91 »

Robin,

I managed to test the Overshoot function last night and it worked great!!! Thank you for adding this as it made focusing much more easier!!

On another note, while testing, I think I found a bug using some of the focusing aids like Brightness, contrast, etc. If you have your setting on average or take the best reading but pick over a time frame e.g. 5s, it is recording the values before 5s even when there is an overshoot thus the graph will display a bad reading at the overshoot position. It does not do this when you pick best/average over a set of say 20 frames, etc., only when you have it set to take the average or best value over a set time amount. I actually like using the best value over say 5s as it helps with bad seeing.

I also think it would help if you could add HFR versus FWHM, I had issues with getting a good focus using this method because of how the black threshold is handed in software so I gave up. Might be better to pick the diameter of a star by half brightness value maybe??

Thanks again Robin, very much appreciated :-)

Bill
User avatar
admin
Site Admin
Posts: 13175
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Auto Focus with overshoot

#19

Post by admin »

Hi Bill,

glad that the overshoot is (mostly) working fine for you.

I will have to look into the bad readings - maybe the code spots the moment when the focuser is stationery between the first and second parts of the overshoot movement and decides that the movement is complete and that it can take a measurement?

On the subject of HFR, the measurement (at least for multi-star) is HFR (well, it's HFD actually, but that's just a factor of two different). I changed that between 3.2 and 4.0, but kept the old name for familiarity.

cheers,

Robin
WB91
Posts: 27
Joined: Wed Jun 17, 2020 3:13 pm

Re: Auto Focus with overshoot

#20

Post by WB91 »

Robin: I will have to look into the bad readings - maybe the code spots the moment when the focuser is stationery between the first and second parts of the overshoot movement and decides that the movement is complete and that it can take a measurement?

BB: I don't think so because it didn't do this in the other modes, and it recorded a reading during overshoot. Again, this only happens when you select Average or Best Score when you select a time frame, say 5sec mode. it does not do this when you select 20 frames, only time mode.

Robin: On the subject of HFR, the measurement (at least for multi-star) is HFR (well, it's HFD actually, but that's just a factor of two different). I changed that between 3.2 and 4.0, but kept the old name for familiarity.

BB: Ok, just could not get it to work right in SharpCap so I gave up. Not that I want to make this comparison but in APT, NINA and ASIAir software, their methods work spot on. I would love to see something like this in SharpCap (automated, out of a sequence option) to make it more user friendly during focusing. I still find myself using a bahtinov mask using sharpcap for focusing when wanting to do live stacking.

I did discover something interesting using your brightness focusing method, it works well in inverse for planetary focusing. Seems like best focus comes at lower brightness level. Your hyperbolic curve does not work in inverse but I was able to see the bottom of the valley and use that location, and it was repeatable. Still need to run more tests on this. I tried the contrast method but that only seems to work well on the moon. Pretty cool!
SharpCap-pic001.jpg
SharpCap-pic001.jpg (98.95 KiB) Viewed 897 times
Post Reply