For those with focus issues
This new code was just submitted tonight, so it will be in the next nightly build, or, if you compile from source you could git pull it now. To see if your new code has it, go to the Focus tab, find the "Process" tab near the middle-left of the page, and in there, under the "Algorithm" drop down, select "Linear (Experimental)". If you don't see "Linear (Experimental)" in the Algorithm drop-down menu, then you don't have the software you need to test this (the other choices in the drop-down are Iterative and Polynomial).
Here's how I recommend you use it.
Choose the following in the Focus Tab:
- Process sub-tab: Algorithm: Linear (Experimental)
- Process sub-tab: I'd recommend Detection: SEP and Tolerance 5%, or perhaps a little higher
- Settings sub-tab: Full Frame (definitely recommend this)
- Settings sub-tab: I'd recommend Annulus to 25% 75%
- Mechanics sub-tab: Choose Initial Step Size and MaxTravel as described below.
- Exposure: this is up to you, but for my f/5.6 refractor and an ASI1600mm, I'm successfully using 5s for RGB and 10 for Narrow Band filters. I have not tested with a DSLR.
- Set up your system so you have rough focus. If you are far out of focus, it won't work. - Click AutoFocus and watch it (hopefully) work!
Please turn on verbose focus logging: In the main Ekos tab (on the left) click on logs, then in the logging page, check verbose, and focus, and file output. When you send me a note, please include the log.
Note: this will fail if you are not "near focus". I define that by being within 5 Steps (InitialStepSize) of the minimum-HFR position.
The way the algorithm works is: after you click AutoFocus, it moves from the current focus position to a new position that is 7 steps outward (the camera is moved further away from the telescope). It then samples HFR, moving inward by InitialStepSize, looking for a minimum HFR. If it doesn't find a minimum within 20 steps or so, it will fail. If/once it finds the minimum, it moves outward to 2 steps past the minimum position, and then re-samples back inward, but moving by half-steps, until it measures a HFR within tolerance of the best measured HFR in the first pass. When it finds that, it's done.
My theory is that current failures may be due to too-much changing of direction, and I'm hoping this more steady "always in" approach will improve things.
You may have to experiment, but, I roughly focus, and set initial step-size to something like 1/3 the distance between Red and Green Focus in my refractor (or perhaps a little larger).
MaxTravel won't have much impact unless you set it too small. I start with something like 4x the distance between my Red and Green focus.
This algorithm will no doubt be slower (more iterations) that the existing ones. If the other ones work for you, great, use them. The goal here is to get something that works for more people, and once we have that, then to try and speed things up and make it more tolerant of starting position, without losing reliability.
This is not the end, but rather the start of the process, so please be gentle
Please let me know how it goes,
PS It is certainly the case that autofocus can be affected by star detection and by HFR calculation. This change does not address that. Star detection and HFR calculation may be the next things to look into, but I believe it makes sense to start this way.
I assume by just changing the direction in the focuser your algorithm would then get (another?) focus when always moving outwards, and this can be used to actually measure the backlash, yes? Thats a really great addition to EKOS' capabilities!
GPDX+EQMOD, CEM60EC, ASI1600+EFW+ASI290 mini
Nice work! I like your approach of 'moving in one way' as it reduces hysteresis effects. Even if a system has no backlash from mechanical play, it can have lost motion due to sticktion, slightly bending of parts, etc.
What do you think of using a scheme in which the auto focuser automatically sets the camera gain/ ISO and the exposure time, based on SNR of detected stars.
This would help in making sure stars can be detected, even when being quite far from optimal focus and at the same time prevents clipping (if this is ever a problem).
I have experience in data analysis with Python, I can write an example script if this is interesting.
I would like to try out your algorithm, unfortunately it's cloudy cloudy cloudy...
It would have added a line to the log which output the focus position, temperature and filter on every successful auto focus. It was designed to be easy to grep for, with the data in a CSV format so easy to extract for analysis.
Still, not to be. Shame.
Did you try sending it to KStars github? If yes then that explains it since KStars github is just a mirror. To submit patches to KStars, they need to be sent to KDE's Phabricator system (until they migrate to Gitlab later).
You'd probably want to install Arcanist and set it up to ease this process. Mr. Hy been through this setup process so he is best to explain it.
If they don't want PRs through GH then they need to be more up front about it. At least say so in the MD file or preferably not have a PR button there.
I don't want to have to install and use yet another incompatible tool, I'll abandon Ekos development for now.
Nothing is lost, I just checked Github and applied you diff to KStars, it's in master now
All KDE projects use Phabricator to submit patches. Once it is set, it's very easy to create patches, even easier than Github. At any rate, thank you for the code, it should help the logging tremendously. If you do not feel like setting up Pharbicator, you can share the diff directly here or to the KStars mailing list.
EDIT: I also updated KStars README to indicate that PRs on Github will not work. Please accept my sincerest apologies on this matter.
Bart--I'd be happy to take suggestions, and sure sending me python code would make it clear. However, I want to start with this now, see how it works, and then improve.
Peter--it's basically one direction. After the first sweep it makes a move back out and then again sweeps in to find the solution. It's possible one could estimate backlash from this, but you may remember my last attempt in another thread where that seemed not straightforward. You should get the numbers in your log, so see what you can make from them.
Hopefully the clouds go away and we can all test.
hy wrote: Peter--it's basically one direction. After the first sweep it makes a move back out and then again sweeps in to find the solution. It's possible one could estimate backlash from this, but you may remember my last attempt in another thread where that seemed not straightforward. You should get the numbers in your log, so see what you can make from them.
Yes, the code always thinks it is moving in. But at least my DMFC has a setting to reverse the direction internally (which makes sense, as the 'in/out' directions will depend on which side of the focuser you attach the motor..). I hope to get two numbers that way that - if I on first hand disable BL correction - should give me the proper number. We'll see. Everything is compiled, just waiting for sunset (in 20 minutes...) and hoping the wind doesn't get too strong - I'm seeing gusts up to 50km/h
GPDX+EQMOD, CEM60EC, ASI1600+EFW+ASI290 mini
It seems you immediately capture an image after moving out. This will die on focusers with backlash, at latest when the reduced step size gets smaller than the BL. You can see that in this run. By BL is around 110, but I had it disabled, and ran the AF with a step of 50. So the first three points are basically the same value. Then a nice curve starts, that gives a very nice minimum. But then the refinement is supposed to start, it moves 200 out again, and directly captures an image. Together with the BL those 200 have actually only moved the focus some 90-100 units, and that happens to be the minimum of the curve, as seen from the leftmost point. It actually finds the lowest value so far, and decided to stop there.
So I think you should modify the algorithm to always move out past the intended position by an (optimally user definable) amount, then approach the first point also by moving inwards this additional overhead. Same should happen when you do the refinement steps.
So: define an overhead of 200 and step of 50. Start at X. Move out by 7*50+200=550, then move in by 200. Only then capture the first image. Same then again when reversing. Go out 4 steps plus overhead (=400), then back in again the 200, then start the refinement with step of 25.
Let me know what you think. I'll try to get some images now
GPDX+EQMOD, CEM60EC, ASI1600+EFW+ASI290 mini
I've posted my notes on how to get started developing
PS The forum software, I guess to prevent spam, caused me to break-up my message into 5 or 6 parts (because of all the links).
Let me know how your imaging went.
I'd like to paraphrase your post, to make sure I understand. You suggest that whenever I move the focuser out N steps, I should actually move it out N+M steps, and then move it back M steps (either in pass 1 or pass 2). You'd also like the M to be configurable. The rationale is that (a) If there was no backlash in the system, then this extra movement would have no impact other than a very slight delay, and (b) if there was backlash, then it would eliminate a few possible noisy measurements (where the algorithm thinks the system is moving, but really it's not and just measuring noise and possibly/through-rarely tricking itself).
This makes sense to me . However, I won't be near my telescope for another week and a half, so won't be able to test. Feel free to modify your local code, if possible, and let me know.
I don't think making "M" configurable really is worth it, though. Don't you think that we could get all the value we'd need by setting M=4 or 6 extra steps (something that hopefully is beyond the backlash for most everyone) and it would work without adding more to an already large number of focuser parameters?
I love your pretty V-curve! This gives me hope that the overall algorithm has a reasonable chance of succeeding, though, perhaps I under-estimated how much I needed to focus back out in pass 2--though it did catch the minimum, if not by the skin of its teeth.