×

INDI Library v1.9.7 Released (29 Jul 2022)

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

New Focus Algorithm in Ekos

  • Posts: 92
  • Thank you received: 28

Replied by John on topic New Focus Algorithm in Ekos

I'm in the process of rewriting the code for the original release of Linear1Pass to fit in better with the kstars codebase. One of the more experienced developers is helping me.

The first release will have the existing functionality as per the document at the top of the thread.

I intend as a phase 2 to look at the topics raised in this thread along with some other things. My idea is to include a "helper" function to suggest values for some of the parameters, like step size. GoldAstro haven't as yet got back to me, but neither have I as yet chased them. It would be good to collaborate if they are interested but if not I can probably do something without them (obviously I wouldn't just take their algorithm without permission).

Since I'm not a professional developer there are no timescales for any of this. Its ready when its ready.
The following user(s) said Thank You: Tim
2 months 1 week ago #83374

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

  • Posts: 913
  • Thank you received: 121
Oh, an interesting thread that I somehow missed so far :ohmy:
So far, I'm using Linear, and get good results with it. I did, however', also notice that it has a slight tendency to overshoot a tad (by doing another step when I would say it's already at the best position). However, those last steps are (with the latest versions) a quarter of the initial step size.

I did have a look at this NCFZ article. Very informative. Maybe some input here from my side: I used the formula, and my setup and site details, to compute a value of 31μ. My step size of the EAF is 2.8μ, so that is 11 steps. For comparison, my initial step size is 20, i.e., 2 times the NCFZ. In good conditions that allows a very good estimate of the focus from the first pass. I don't think setting the initial step to 1 NCFZ (or even less) will improve things, and for less good conditions (variable seeing) the (only?) solution anyhow is to do more than one measurement per position, and average.

I do quite sometimes see that the first pass produces an (almost) perfect curve, and then also think 'now you should just go to the computed value, and be done'. Sometimes it's obvious (to me....) that the first pass isn't great, and the second one will improve things. So ideally I'd like to see a combination of both approaches, in finding some criterion on how well the first pass is, and then having an option in Linear to stop after that if it is good enough.
I'm not sure that always only doing one pass is as stable as the current Linear method.
My current setup will do the first pass in about 11 positions. It typically finishes the whole AF run in 15-20. More only in very variable conditions, but there I wouldn't trust a 1-pass run much, either. This means for me, I could save maybe 1 minute per AF run in good conditions. I would do rather 'pay' that as an insurance in case of bad conditions. But as you already mentioned in the first post, those that don't have issues with focus as it is can skip.
So my post isn't there to discourage the new method - the contrary! I just thought maybe my view on this is of some use :)
I do still wonder why the current Linear isn't working for some, and extremely well for others..... :blink:
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 months 1 week ago #83392

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

  • Posts: 100
  • Thank you received: 11
Hi,

John, thanks for the update! :)

Peter, that‘s indeed an interesting point. My observation is that I have a very smooth and plausible V curve in the 1st pass in most cases, and often a bad and jumpy 2nd pass curve. Never saw it the other way round, which is of course strange and doesn't make much sense, but that's the way it is. Maybe a mechanical issue of my Crayford focuser (backlash? slip?). Have to investigate more.

CS, Bernd
10" F5 Newton and 130mm F7 Apo on EQ6-R, ZWO EAF focusers, DeepSkyPro 2600c, ASI183MM, RPi4b 8GB
Last edit: 2 months 1 week ago by Bernd Limburg. Reason: typo
2 months 1 week ago #83395

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

  • Posts: 913
  • Thank you received: 121
Well, 'jumpy' would rather point at BL (IMO). Slip (with a Crawford) is of course a possibility, but should rather produce a shifted second curve (unless there's a lot of random slip - but that would affect the first run, too). For BL, be sure to take care of (most of) it in the EAF driver, a possible small rest should be handled by the one-direction logic of the focus routine.
You do have the EAF on the main focus axis, not the (10:1) microfocus one, yes?
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 months 1 week ago #83396

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

  • Posts: 100
  • Thank you received: 11
The EAF is on the 1:1 axis, not the 10:1 axis, yes. Right now, I don't have BL compensation activated in the driver. But in the linear method, BL should only affect the one travel-back step between 1st and 2nd pass? (I thought...)
10" F5 Newton and 130mm F7 Apo on EQ6-R, ZWO EAF focusers, DeepSkyPro 2600c, ASI183MM, RPi4b 8GB
2 months 1 week ago #83398

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

  • Posts: 913
  • Thank you received: 121
Yes, but if it is larger than what is done there, it might make the first few points of the second pass quite random.
It would also affect the first pass, but much less: Steps are twice as large, and usually you are still farther away from focus. But the second pass has half-sized steps (-> twice as many steps needed to compensate a remaining BL), and you are usually closer to focus.
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 months 1 week ago #83399

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

  • Posts: 183
  • Thank you received: 12

I could be wrong, but I thought that the backlash number is not used in the linear process. That is why it moves a large amount outward and then moves inward to eliminate backlash.

However, as I've written before, I'm not sure that the "outward/inward" move is effectively removing the backlash in my setup. I don't know how to prove it, but when EKOS sends the outward command it immediately sends an inward command. Based on simple observation, it feels like the focuser hasn't completed the outward move before receiving (and moving) inward. Therefore, the focuser is not at the expected position when it starts the second pass. Just my humble opinion. I wish there was just a brief pause between commands.

I also would really like to see a single pass process. The second pass never improves my focus point and often confuses the process, causing a redo.

Ron
Mounts: Sky-Watcher EQ6-R Pro, Meade LX85, Celestron NexStar Evolution Alt/Az
OTAs: Celestron 8" Edge HD w/Celestron Focus Motor, Meade 80mm APO Triplet Refractor w/ZWO EAF
Cameras: ASI533MC Pro, ASI183MC Pro, ASI224MC, ASI120MC-S, ZWO ASI290MM
Raspberry Pi 4 with Stellarmate OS, MacBook Pro
2 months 1 week ago #83401

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

  • Posts: 913
  • Thank you received: 121
Two (Edit: Three) things:
The Linear method does not depend on a backlash correction. It tries to overcome that by the first-out-then-in movement. But a BL correction in the driver of the focuser will not be deactivated by it, so it will just see a smaller (or non-existing) BL.

As for your issues, one thing might be to verify what is 'in' and what is 'out'. What actually counts is that the element that moves should move against gravity. For classical refractors and SCTs (etc.) with a focuser in the back that is easy.
With an SCT and the internal mirror focusing that gets reverted, as you have to end the move moving the mirror up, which will move the focus point away from the telescope. And with a Newton, it will depend on where the exit is positioned (and might then even change depending on pointing)

Finishing the move - as mentioned here, try to increase the polling time in the driver. If you set that to, e.g., 2000ms, there should be at least 2s between start of the first move and start of the second move. That would at least prove that (also) your focuser works as expected. Also - have you checked the INDI tab of your focuser? IIRC that one should always report that it has reached the requested position before it accepts new commands.

And of course I agree such a 1-pass is a good idea to help those having issues. It's just that I think most of those issues are not with the algorithm itself, but rather with the setup. And finding out what causes the problem is always a good idea - regardless how you're going to handle it :)
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
2 months 1 week ago #83403

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

  • Posts: 183
  • Thank you received: 12
Peter,

Thanks for the explanations!

Good to hear on the backlash... as you say, it shouldn't really matter with linear.

On focus with a SCT... I can understand the difficulty with the focusing mechanism. For me, it's all the more reason to keep it simple. First form a good curve on the first pass, then move out a large amount and back to that position.

On the polling time... This may be where I'm having issues. Mine is set at 1,000 ms (1 sec). Based on what I hear when it moves out and then moves in, it is nowhere near a 1 second delay. I'll need to check the messaging to see if it reports reaching the position. Next time, I'll try an exaggerated polling time (like 3,000) to see if I can discern a true delay.

Thanks again!

Ron
Mounts: Sky-Watcher EQ6-R Pro, Meade LX85, Celestron NexStar Evolution Alt/Az
OTAs: Celestron 8" Edge HD w/Celestron Focus Motor, Meade 80mm APO Triplet Refractor w/ZWO EAF
Cameras: ASI533MC Pro, ASI183MC Pro, ASI224MC, ASI120MC-S, ZWO ASI290MM
Raspberry Pi 4 with Stellarmate OS, MacBook Pro
2 months 1 week ago #83404

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

  • Posts: 745
  • Thank you received: 85
What I have found is that if the focuser was already near the best focus point to begin with, then the first pass (linear) calculates the best focus point quickly. The second pass is often worse. I don't know why.

But if the focus was off by a little, then the first one will get very close, but not perfect. Then, a second run of the Autofocus will nail it on the first pass.
But this is different than just letting the autofocus run two passes. With two passes in one run, the results are not consistent. Stopping the autofocus, and then restarting it after that first attempt is always better.

In all cases - the current routine always stops AFTER it detects an increase in HFR, but then uses that incorrect focus point instead of simply moving back to the best calculated spot and using that.

iOptron CEM120 EC2 and CEM25P
Celestron C11 EdgeHD
William Optics Star71
ASI 1600Mm Pro, ASI 462MC
Moonlight motorfocus & Esatto focuser
LodeStar X2 and ZWO OAG
DewBuster
NANO PC-T4
2 months 1 week ago #83406

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

  • Posts: 816
  • Thank you received: 133

Replied by Alfred on topic New Focus Algorithm in Ekos


Peter, you nailed it! This is EXACTLY my experience. The 2nd run always stops too far on the "left side" and doesn't return to the point of best focus.

During the first run a vertical line is shown, together with a numerical focus position. Once the first run is complete, the vertical line and number show the best focus position IMO. Often times, after the first run completed, I just hit the STOP button, enter this number in the "desired absolute focus position" field and move the focuser there by clicking at the "go to an absolute focus position" button. Done!
2 months 1 week ago #83412

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

  • Posts: 92
  • Thank you received: 28

Replied by John on topic New Focus Algorithm in Ekos

Just to be clear Linear1Pass (L1P) is a new focus algorithm, so the existing algorithms will operate unchanged when L1P is released. So those happy with Linear or any of the other algorithms will be able to continue using them as they do now.

Linear starts the 2nd pass by going 2 * Initial Step Size further out than it needs to, to start the 2nd pass, then steps back in 2 * Initial Step Size and starts the second pass. If you have more backlash than this 2 * Initial Step Size then you might see a flat line at the start of the second pass whilst the remaining backlash is "taken up". Linear should be able to deal with this though.

L1P will operate like this if you set the Backlash field to zero. If its > 0 then the step out then in movement will use what you enter in the Backlash field, so you'll have a bit more control over it.

L1P will also compare the HFR prediction from the curve fitting process from pass 1 with the HFR measured after the focuser has moved to the solution (and an extra subframe taken and processed). It will put out a log message comparing the expected vs actual HFR. You will also be able to compare the 2 values on screen (the curve fitting prediction on the graph and the measured HFR in the HFR box under the curve.

Before L1P goes live you could compare these values for the existing algos by doing an Autofocus run and getting the HFR at the optimum focus point and noting the HFR. Then when Autofocus finishes, hit the "take a subframe" button, let the processing complete and see what's in the HFR box at the bottom of the graph. There will be some randomness so the numbers will never match exactly but will give you a feel for whether there's an issue or not.
The following user(s) said Thank You: Peter Sütterlin, colin rooney, Rafa Barberá
2 months 1 week ago #83415

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

Time to create page: 0.538 seconds