New Focus Algorithm

Sat May 7 18:37:30 BST 2022

Thanks John,

I just commented on the MR, and we should probably mainly communicate there
from now on. Just to answer a few of your points above:

#1: Thanks! Tests are good!

#2: I appreciate that you don't want to break Linear, and I'm thankful for
your caution. However, as I said in the MR comment, why not try and use the
FocusAlgorithmInterface from focusalgorithms.h? You can still put your
Linear1Pass implementation (inheriting from that interface) in a separate
file.

#3: We usually put constants that are not user-changeable in the .cpp file
near the top, or in the .h file. I totally agree that too many parameters
for users to adjust can be counter-productive, but I also guarantee that as
soon as you release this, some user will request the ability to change some
of your parameters ;) I think in the end you release and see, and perhaps
allow user modification later.

#4: Up to you if you want to include this in your algorithm. As you say, it
might make sense to get the basic thing in good shape first.

#5: you need to become familiar with git rebase. Please take a good look at
https://invent.kde.org/education/kstars/-/blob/master/README.md and find
the section called 'rebasing your changes'. Honestly there are much better
sources on the web for learning git, but this is a start. You should
probably brush up on git from one of the web tutorials, but feel free to
ask questions here. I'm far from an expert myself, but have learned enough
to get by.

#6: to fix compiling: grep through the CMakeLists.txt files in KStars, and
anywhere you see, e.g. focusalgorithms.cpp, add your new cpp files in the
same way. I think that would be just in KStars/CMakeLists.txt.

Hy

On Sat, May 7, 2022 at 7:05 PM John Evans <john.e.evans.email at gmail.com>
wrote:

> Thanks all,
>
> I've created a MR, so you should be able to see the code. I had a bit of a
> struggle with Git (first time using it) but hopefully OK now.
>
> Couple of points:
> 1. I'll update kstars/Tests/focus/testfocus.cpp as Hy suggests to include
> some L1P tests.
> 2. kstars/ekos/focus/focusalgorithms.cpp/h has not been changed. I cloned
> this to focusalgorithmslinear1pass.cpp/h in order to minimise the chances
> of breaking the linear algorithm.
> 3. Currently there are 3 parameters for the solver algorithm that control
> the number of iterations and the precision required for a "solve". I've
> picked values that work on my equipment and the simulator but may not be
> appropriate for all equipment. These parameters are hard-coded into
> curvefit.h but would probably be better in a config file so could be
> changed without a rebuild. I don't think exposing these to end users would
> be a great idea. What would be the best way to do this? (put them in
> kstarsrc?)
> 4. Hy, I have currently bypassed the HFR adjustment algorithm for most of
> L1P. This may not be best but for now it avoids a lot of work that's hard
> to verify to get a star subset to do further processing on. It will be
> unchanged for the other focus algos (Linear, etc) though. Whether its worth
> doing more work on this is probably dependent on how much benefit people
> are getting out of it, so I'd appreciate any thoughts on this?
> 5. I started working on the code before forking Git (school boy error I
> know) so I'll need to make sure I don't blat anybody else's changes. Can
> Git help me here? (I've manually diff'd the 6 changed files and think 5 are
> OK - all the changes look to be mine) but manager.cpp has been changed.
> What's the best way to sync this up?
> 6. The build process will need to change to include the new files:
> curvefit.cpp/h focusalgorithmslinear1pass.cpp/h. So locally I've changed
> CMakeLists.txt but I haven't included anything with the MR as I don't know
> what to do?
>
> Regards,
> John.
>
> On Sat, 7 May 2022 at 09:38, Hy Murveit <murveit at gmail.com> wrote:
>
>> John,
>>
>> Thanks very much for doing this. Here are a few quick notes:
>>
>>    - Please check out kstars/Tests/focus/testfocus.cpp. You'll find some
>>    unit tests for the Linear algorithm there, and you can model unit tests for
>>    your new scheme after that. You can also use that test to help check that
>>    you haven't changed the standard Linear.
>>    - Please include the new scheme in
>>    kstars/ekos/focus/focusalgorithms.cpp/h which is where most of Linear is
>>    implemented. (Haven't had a chance to look, I assume you're already doing
>>    that, but just in case.)
>>    - I'd be happy to help code review, as will some of the others, I'm
>>    sure.
>>    - Feel free to continue asking questions on this email list, and
>>    later on the merge review (MR) page once you've started that. Any question
>>    is welcome. There are some instructions on the kstars README page about git
>>    and MRs if you want to refer to that.
>>
>> Looking forward to it,
>> Hy
>>
>> On Sat, May 7, 2022 at 10:24 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
>> wrote:
>>
>>> Hello John,
>>>
>>> I've been following your progress on INDI forum and this is indeed
>>> looking very good. I believe after this is merged in KStars, we need to
>>> create a table for the different algorithms used to explain use cases,
>>> pros/cons for each, which type of equipment they are mostly suited
>>> for..etc.. This should help clear up any confusion for end users.
>>>
>>> We can only comment on the code after you submit an MR to KStars, and
>>> then we'll start the review process. This is very exciting and I'm looking
>>> forward to it.
>>>
>>> --
>>> Best Regards,
>>> Jasem Mutlaq
>>>
>>>
>>>
>>> On Sat, May 7, 2022 at 11:06 AM John Evans <john.e.evans.email at gmail.com>
>>> wrote:
>>>
>>>> Hello Everyone,
>>>>
>>>> Hope you're all well? I have been working on a change to improve focus
>>>> on my rig. Iterative and Polynomial don't work so well for me on the ASI
>>>> EAF, due, I think to backlash. The Linear algorithm works best but the
>>>> second pass usually overshoots the ideal focus position.
>>>>
>>>> So I built a "Linear 1 Pass" algo, that is based on Linear for the 1st
>>>> pass, but instead of doing a second pass it moves straight to the minimum
>>>> of the first pass.
>>>>
>>>> I've implemented a couple of curve types (Hyperbola and Parabola) using
>>>> a generic GSL curve fitting algorithm which could be extended in the future
>>>> if necessary. The fitting can be done either giving each point equal
>>>> weighting or weighting them based on the HFR standard deviation of the
>>>> stars.
>>>>
>>>> See the enclosed document for more details.
>>>>
>>>> I have written most of the code and it basically works on my rig and
>>>> the simulator. I have a couple of things still to work out though, and more
>>>> testing to do.
>>>>
>>>> Since this is the first Kstars change I have done (using QT on Mac) I
>>>> have been following Ron Lancaster's work on getting Kstars running on Mac.
>>>> In terms of coding standards I've just followed what's been done in the
>>>> areas I've changed. If there are any resources that someone could point me
>>>> to, that would be great.
>>>>
>>>> If anyone has any feedback on the change that would also be great (I'll
>>>> also post on the forum to see if there are any suggestions).
>>>>
>>>> I estimate I'll be finished with coding and testing in a couple of
>>>> weeks. I would like feedback on deployment as I'm not familiar with the
>>>> process at all. So if anyone can point me to any resources that would be
>>>> very helpful.
>>>>
>>>> At the moment I'm thinking:
>>>> 1. Release 1 - deploy Linear 1 Pass code but concentrate on minimising
>>>> risk to breaking existing code, esp the Linear algorithm. I have cloned
>>>> some Linear code for this.
>>>> 2. Release 2. When Release 1 is working as expected, interface Linear 1
>>>> Pass code with Linear in a more integrated way, removing cloned code. If
>>>> any features of Linear 1 Pass would be useful for other focus algos, this
>>>> could be done here.
>>>>
>>>> The reason I'm thinking of doing this in 2 steps is that I'm a novice
>>>> with C++ and this seems the best way to minimize the risks of breaking
>>>> existing code. However, I'm happy to take advice from more experienced
>>>> people here.
>>>>
>>>> If anyone would like to offer to help me, do a code review, etc., that
>>>> would be really appreciated. As I mentioned I'm a novice with C++ so
>>>> probably not doing things in the best way, but happy to be guided. Also,
>>>> any suggestions on:
>>>> 1. Test cases to write for this change.
>>>> 2. Best way to profile the code, test for memory leaks, etc.
>>>> 3. Since this would run on a range of different machines, how to
>>>> configure for different setups, things to watch out for, etc.
>>>>
>>>> Thanks for reading!
>>>>
>>>> Regards,
>>>> John.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220507/2d94859b/attachment.htm>