New Focus Algorithm

Sun May 8 20:22:14 BST 2022

Hi John,
Could you please take a look at your MR? It does not compile currently.

Wolfgang

> Am 08.05.2022 um 21:17 schrieb Robert Lancaster <rlancaste at gmail.com>:
> 
> Hi John,
> 
> So what I have been doing recently is very similar to what you said.  I have been keeping the files in AstroRoot as a pristine copy of everything as it is out there in the world from official repositories.  I use that for building my MacOs releases for KStars, StellarSolver, INDIWebManagerApp, and for storing the libraries, include files and all other things.  Then I have been keeping my changes to various repos in a separate place on my computer in the ~/Projects folder where I have both my source folders from my forks and my build folders that I build based on it.  Craft does a very good job of setting things up in the AstroRoot folder and a good job of updating it when you need to.  (You can either use my script or use a craft command to update it)  In your own forked source folders in the ~/Projects folder what I would do is commit any changes in a branch, not in master, and then push those changes to your forks on Github for INDI/StellarSolver and to Gitlab for KStars.  When you make an MR and it gets accepted, your changes will be updated in the master branch of whatever repo you are contributing to, and at that time you can update your master branch in your fork of whatever repo got updated.  And then you can tell craft to update to the new master from git.  I would not recommend manually moving your changes to ~/AstroRoot or the master branch of any of your forks in your ~/Projects folder until those changes get accepted and you can just do a "git pull upstream master” or use a script to update to the master branch.
> 
> This is something I have learned more recently, I haven’t always done it this way, but I have found (through trial and error including a couple of times where I completely borked my forks) that following this plan has left me in the best overall shape.  In my Applications folder, I have the latest stable release of KStars and INDI for my own imaging.  In AstroRoot I have the latest master and all the stable libraries to build against.  And in my Projects folder, I have the latest stuff I am personally working on.  I would like to update my build scripts to help people setup an environment like this, but I have other things to work on first.
> 
> Does this help?
> 
> Rob
> 
> 
> 
>> On May 8, 2022, at 2:51 PM, John Evans <john.e.evans.email at gmail.com <mailto:john.e.evans.email at gmail.com>> wrote:
>> 
>> Hi Rob,
>> 
>> I have another question for you, if I may. I have my environment on OSX Craft which has built everything in ~/AstroRoot which is now out of date as I took a clone of 3.5.8 a few weeks ago. A couple of days ago I made a fork and followed the instructions which created the project in ~/Projects/kstars. So I just copied the files I've been working on in AstroRoot into Projects/kstars, committed them (in a branch) and created a MergeRequest. Now I know a tiny bit more about Git, I can see having an area to work in and a completely different one for Git is probably not ideal.
>> 
>> So, I think what I need to do is:
>> 1. Take a copy of my changed files somewhere safe.
>> 2. Get a version of all of kstars at the time of my fork into AstroRoot. I'm assuming that this would be the best way to get a working environment again rather than getting Projects/kstars working on Craft? But I could well be wrong? Anyway, any suggestions here?
>> 3. Merge my code changes for Linear1Pass Focuser back into AstroRoot. Now Git knows nothing about AstroRoot so is there any way to "move" Git locally from Projects/kstars to AstroRoot?
>> 
>> TIA
>> 
>> Regards,
>> John.
>> 
>> On Sat, 7 May 2022 at 18:59, Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
>> Hi again John,
>> 
>> I have some nice tricks that might help you with #5. If you have been accidentally working in the master branch of the original repo, you can in the terminal go to the Kstars source folder and type
>> 
>> git diff > mychanges.patch
>> 
>> Then copy that file somewhere else on your computer.  Now I assume you have made a fork in gitlab by now?  If you have that downloaded, you can go into that source folder and type
>> 
>> git apply mychanges.patch (or whatever the path to this file happens to be)
>> 
>> I would recommend moving your changes into a new branch so you can keep the master branch of your repo pristine and matching master (something I haven’t perfectly followed in the past, but I have been admonished multiple times for this and finally it caused me bad enough issues with my fork that I am finally listening to this advice!)
>> 
>> git checkout -b newFocuserBranch (or something like that)
>> 
>> Then you can commit your changes to the new branch.  The neat thing is that once you push your changes in your new branch to your fork on Gitlab, when you go online to your forks page on Gitlab, it automatically asks you if you want to make an MR with it.  It is really cool.  The way I used to do it, in the master branch of my repo, it didn’t do this automatically, plus I had to then rebase my fork after it got merged.  And then if my merge request was not accepted for some reason, it caused me big problems.
>> 
>> My hope is that I can update the KStars on OS X Craft repo to have some tools in the future to make this easier to work with.  I have some of that in the KStars INDI Mac Dev Repo, but I would like to add this to the KStars on OS X Craft Repo, along with the default to be to assume that all changes will go into a branch, not master.
>> 
>> Does this help?
>> 
>> Rob
>> 
>>> On May 7, 2022, at 1:37 PM, Hy Murveit <murveit at gmail.com <mailto:murveit at gmail.com>> wrote:
>>> 
>>> 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 <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20220508/694f0c39/attachment-0001.htm>