<div dir="ltr"><div>Hello Akshay,</div><div><br></div><div>Just wanted to follow up on the ML Guider concept. Do you think it's doable? If yes, what do we need to do next? What kind of training data is required?</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 18, 2025 at 10:05 AM Akshay Subramaniam <<a href="mailto:akshaysubr@gmail.com">akshaysubr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Regarding the ML guider concept, all of these ideas sound good. I don’t quite have a handle on what the “ground truth” data would be though. If we just use guiding pulses from the logs, we can only ever match the performance of existing algorithms, right? I think it might be prudent to do a bit of a literature survey on ML based control algorithms generally. One specific paper comes to mind where they trained an ML control algorithm that can hover a helicopter upside down but I can’t remember the title of the paper off the top of my head.</div><div dir="auto"><br></div><div dir="auto">I agree that the model must be specific to a users setup, but I also feel like having a base model that has learnt fundamental guiding characteristics would be very useful so a user can fine tune that on their specific setup rather than train an all new model from scratch. Anyway, I’ll do some literature search over the next week or so to have a more informed opinion on this topic.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Akshay</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 16, 2025 at 11:50 PM John Evans <<a href="mailto:john.e.evans.email@gmail.com" target="_blank">john.e.evans.email@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">My 2c on the ML/AI guider concept. It seems a good choice as we already have guide logs that detail the pulses sent to the mount so there is a ready source of data for training although perhaps a first step would be to review these logs with a view to their suitability for AI.<div><br></div><div>The procedural approach currently is 2 fold:</div><div>1. Standard Correction. Calculate the deviation and from the calibration send a correction pulse. Then repeat.</div><div>2. Pre-emptive Correction. Based on periodic error, calculate repeatable deviation and send these corrections at the appropriate time to minimise deviation in the first place. This is PEC / PPEC / GPG.</div><div><br></div><div>It kind of feels like a good opportunity for an AI algorithm although as others have suggested maybe not as a first step. Maybe however it would be OK to start thinking about how we could go about this in the future and see what prerequisites we'd need (e.g. additional data in the guide logs)?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Mar 2025 at 03:52, Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank">mutlaqja@ikarustech.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello Akshay,</div><div><br></div><div>Welcome abroad! I find that Machine Learning powered guiding is indeed very exciting but as you rightfully indicated, very challenging for a first time task! You are indeed correct, we used AI+RAG to answer FAQs and other knowledge based articles related to StellarMate. </div><div><br></div><div>The binning statistics sound good. There are also many KStars issues reported here that would be of interest: <a href="https://invent.kde.org/education/kstars/-/issues" target="_blank">https://invent.kde.org/education/kstars/-/issues</a></div><div><br></div><div>Regarding the ML Guiding, I'm not sure if this is something we can crowdsource per se. My intuition is that it should learn on the user's own setup due to many contributing factors in seeing, mount, camera, and optics that can vastly differ from one user or another. It would be possible to start "training" after a guiding session is over for example, or while it is running, or in a special "train mode". At any rate, I am by no means an expert on this, so feel free to suggest a better model to approach this issue!</div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 17, 2025 at 4:52 AM Akshay Subramaniam <<a href="mailto:akshaysubr@gmail.com" target="_blank">akshaysubr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Firstly, I want to say I really appreciate all of your work developing kstars and INDI and for putting out a ton of education material as well. And thanks for all the suggestions on how to get started. Just as a warning, I've never contributed to a full stack application and have no clue how frontend development works so I might be very slow to implement things in kstars 😅</div><div><br></div><div>The AI based guiding algorithm sounds fun but also daunting as a first effort. I assume the biggest challenge would be inferencing the model in real time faster than a single guide exposure at the very least. Maybe the first step to tackle that would be to add a harness that outputs a bunch of guiding data along with all the relevant mount parameters. That way, we can crowd source data from people that would be willing to share. That would be necessary to train a base model which folks can then finetune that model for their specific mount either as an offline step or on the fly. I'd also imagine there would need to be some guardrails around the predicted guiding pulses just so things don't go off the rails because of some instability mode of the model. Another idea is a simple LLM+RAG model that a kstars user can chat with to answer simple questions like "What should my meridian flip settings be for an OnStep based mount?". I believe Jasem and the Stellarmate folks already have something similar and it can even take actions based on natural language commands!</div><div><br></div><div>The binning conditional statistics enhancement seems like a simpler starting point so I can maybe start with that.</div><div><br></div><div>Thanks,</div><div>Akshay</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 16, 2025 at 6:10 PM Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Akshay,<div><br></div><div>and I'll throw one in too, related to John's suggestion. How about a adaptive guider based on machine learning? E.g. it decides on the correction pulses based on how well recent pulses have corrected the guide error--so presumably learns about periodic error and backlash. I suppose it could be pre-trained and/or adapting on the fly, or more likely both. I'd be happy to collaborate on that.</div><div><br></div><div>Hy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 16, 2025 at 1:28 PM John Evans <<a href="mailto:john.e.evans.email@gmail.com" target="_blank">john.e.evans.email@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Akshay,<div><br></div><div>Welcome to the project, great to have you on board! </div><div><br></div><div>I had a quick look at the links Hy enclosed and see you’re working on AI related topics. I’m sure there are some interesting things in this area that could be brought to KStars. I personally know very little about this field but would be very interested to collaborate if you think it would be appropriate.</div><div><br id="m_2226147968272227370m_-3785610459576971154m_-803237447272860009m_-3818985224171090146m_-2526973845854182178m_4197839815689966001lineBreakAtBeginningOfSignature"><div dir="ltr">Regards,<div>John.</div></div><div dir="ltr"><br>On 16 Mar 2025, at 18:53, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br><br></div><div dir="ltr"><div dir="ltr">Folks,<div><br></div><div>I bumped into Akshay (cc'd) today at a local astro-club function. </div><div><br></div><div>Akshay is an aeronautical engineer at NVidia, with a PhD in physics from Stanford</div><div>and a KStars user, who's interested in contributing to our project.</div><div>If you have any suggestions on projects which might help start to contribute, please feel free to reach out to him at <a href="mailto:akshaysubr@gmail.com" target="_blank">akshaysubr@gmail.com</a></div><div><br></div><div><div><a href="https://developer.nvidia.com/blog/author/akshay-subramaniam/" target="_blank">https://developer.nvidia.com/blog/author/akshay-subramaniam/</a></div><div><a href="https://scholar.google.com/citations?user=hNhELoYAAAAJ&hl=en" target="_blank">https://scholar.google.com/citations?user=hNhELoYAAAAJ&hl=en</a></div></div><div><br></div><div>Hy</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium;padding:0px"><div>Hey Hy,</div><div><div><br></div></div><div><div>Nice meeting you today and I really enjoyed our chat. You mentioned a kstars framing workflow video you had made, I’d love to watch that incorporate that into my process.</div></div><div><div><br></div></div><div><div>Also, I’m enthusiastic about contributing to kstars/ekos. If anything specific comes up, let me know. Maybe something simple to start with so I get a bit more familiar with the kstars development process before trying to tackle anything more complicated. I was thinking adding an offset between plate solving and the mount location might be a nice easy one so one could use a guide camera and finder scope for plate solving with the main scope used for visual.</div></div><div><div><br></div></div><div><div>Thanks,</div></div><div><div>Akshay</div></div></blockquote></div>
</div></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>