<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Writing about design and tech...</title>
    <link>https://pavanportfolio.droptools.site/blog</link>
    <description>Read what Pavan Kumar S G has been up to recently</description>
    <language>en</language>
    <lastBuildDate>Sat, 06 Jun 2026 23:09:05 GMT</lastBuildDate>
    <atom:link href="https://pavanportfolio.droptools.site/rss.xml" rel="self" type="application/rss+xml" />
    <managingEditor>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</managingEditor>
    <webMaster>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</webMaster>
    <dc:creator>Pavan Kumar S G</dc:creator>
    <image>
      <url>https://pavanportfolio.droptools.site/images/avatar.jpeg</url>
      <title>Writing about design and tech...</title>
      <link>https://pavanportfolio.droptools.site/blog</link>
    </image>
    
    <item>
      <title>GSoC 2026: Teaching Telescopes to Think with AI</title>
      <link>https://pavanportfolio.droptools.site/blog/gsoc</link>
      <guid>https://pavanportfolio.droptools.site/blog/gsoc</guid>
      <pubDate>Mon, 04 May 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[I'm very excited to announce that I've been selected for Google Summer of Code 2026 with KStars to work on the AI-Powered Guiding Assistant for Ekos. Here's what that means and what I'll be building. What is KStars? KStars is a free, open-source desktop planetarium developed by KDE. But it's much more than just a star map. It includes Ekos, a full-featured astrophotography suite that controls telescopes, cameras, filter wheels, and focusers. Astrophotographers around the world use Ekos to automate their imaging sessions, including a critical feature called autoguiding. The Problem: Why Stars Get Streaked When you take a long-exposure photo of the night sky, your telescope mount needs to track the stars precisely. The mount has motors that rotate to compensate for Earth's rotation, but no mount is perfect. Gears have tiny imperfections, wind pushes the telescope tube, and gravity causes flexure as the telescope moves across the sky. Autoguiding compensates for this by using a second camera to watch a single "guide star" every few seconds. If the star drifts, the software sends a correction pulse to nudge the mount back. Think of it as cruise control for your telescope, constantly making micro-adjustments to keep everything steady. The current system uses a reactive proportional controller it measures the star's drift and applies a correction pulse scaled by an aggressiveness parameter. Star drifts right → push left, proportionally. Simple, but it only corrects after the error has already happened. A wind gust causes a spike, the controller overcorrects, and the system oscillates. Beginners spend hours manually tuning parameters like aggressiveness and hysteresis, and even experienced users struggle when conditions change mid-session. There's also Gaussian Process Guiding (GPG), which uses a composite kernel (periodic + squared-exponential) to model the mount's periodic gear error and predict corrections ahead of time. It's elegant and works well for smooth, repeating worm-gear patterns but it struggles with discontinuous behaviors like gear backlash dead zones, sudden impulse disturbances from wind gusts, or complex non-stationary vibrations that don't fit its kernel assumptions. My Project: An AI That Learns Your Mount Rather than relying entirely on reactive corrections or assuming errors follow smooth mathematical models, my project introduces a machine learning layer that learns the specific mechanical quirks of each user's telescope mount. The key insight: every mount has a unique "mechanical fingerprint" which is characterized by tracking errors from the drive system, backlash dead zones when motors reverse direction, and flexure patterns that shift with sky position. These behaviors vary widely: a traditional worm-gear mount has different quirks than a modern harmonic drive, and even two identical mounts will differ due to manufacturing tolerances. A neural network (GRU — Gated Recurrent Unit) can learn these mount-specific patterns from real guiding data and predict corrections before the error fully manifests without assuming any particular drive type. How It Works The system operates in two distinct modes: Data Collection Mode — During a normal guiding session, KStars silently logs all the telemetry in the background: star drift (dx/dy), time between frames, signal-to-noise ratio, star mass, mount altitude, and the correction pulses the guide algorithm sent. This builds a dataset of the mount's real-world behavior which is its unique mechanical fingerprint. Training the Model One challenge here is that we're logging the guide algorithm's imperfect corrections, not "correct" outputs. The mount's response is non-linear (backlash, stiction, load-dependent friction), so we can't simply assume that adding more pulse always fixes the error proportionally. I plan to explore two approaches: Approach 1 — Retrospective labeling: The training script processes the logs offline, so it can look ahead. For each frame t, it checks the residual drift at frame t+1 and uses Ekos's calibration scale (ms-per-pixel) to calculate what the ideal pulse should have been. For example, if the guide algorithm sent 50ms but 0.2px of residual error remained, and calibration says 100ms/px, the ideal pulse was 50 + 20 = 70ms. The GRU learns to predict that retrospectively computed ideal pulse. This is a simple first approximation, the linearity assumption won't hold perfectly, but over many samples the network should learn the underlying patterns. Approach 2 — Predictive drift model: Instead of predicting the ideal pulse, the GRU predicts the residual drift at the next timestep given recent drift history and pulses sent. The correction delta is derived from that prediction, similar in spirit to how GPG predicts periodic error from observed residuals. This avoids the linearity assumption entirely since we're predicting drift, not pulses. I'll experiment with both and see which handles real mount behavior better. Inference A Python script (PyTorch) trains the GRU model on the logged data offline on the user's laptop. The trained weights are exported to a simple JSON file, which KStars loads and executes natively in C++ using Eigen3 matrix math. No heavy dependencies, no GPU required it runs on a Raspberry Pi. The AI never replaces the existing guide algorithm. It augments it by adding a learned correction delta on top of the standard pulse, clamped to safe limits. If the AI outputs garbage, the proportional controller keeps working. Safety first. Concrete Goals Here's exactly what I'll deliver by the end of GSoC: | Deliverable | Description | |:| | Telemetry Pipeline | A data logger inside Ekos that records guide star drift, SNR, pulses, and mount state to CSV | | Python Training Script | A PyTorch script that trains a GRU model on the logged data and exports weights | | C++ Inference Engine | Hand-written GRU feed-forward math using Eigen3 — lightweight enough for Raspberry Pi | | Pulse Augmentation Layer | Logic to blend AI predictions with the existing guide corrections, with safety clamping | | UI Controls | Training/Inference mode toggles, aggressiveness slider, and RMS comparison plots in the Ekos Guide panel | | Documentation & Tests | Developer docs, KStars Handbook updates, and unit tests for the inference pipeline | Why This Excites Me I'm a fourth-year Theoretical Computer Science student who is very much interested in the field of Machine Learning and Deep Learning. I'm taking a course on Deep Learning this semester which gave me the opportunity to learn more about the RNN architecture and its extensions such as LSTM and GRU. I also participated in Season Of KDE 2026, which introduced me to a lot of new open source software and made me interested in contributing to open source. So this project is a perfect combination of my passion for Deep Learning and my interest in contributing to open source software. Even though I'm very new to astrophotography, I'm very interested in learning more about this domain. Follow Along I'll be posting updates throughout the summer right here on this blog. You can also follow my progress on: - KDE Invent: pavansg - Matrix: @pavankumarsg:matrix.org If you're an astrophotographer, a KDE contributor, or just someone curious about applying ML to real world hardware problems. I'd love to hear from you. Mentor: Jasem Mutlaq (@mutlaqja).]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Wrapping Up Season of KDE 2026</title>
      <link>https://pavanportfolio.droptools.site/blog/sok-2026-wrapup</link>
      <guid>https://pavanportfolio.droptools.site/blog/sok-2026-wrapup</guid>
      <pubDate>Sun, 22 Mar 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[Eight weeks ago, I wrote an excited post about joining Season of KDE 2026. Now, as the program wraps up, it's time to look back at what we built. My project had two goals: make the Mankala AI smarter using parallelism, and give the game a visual refresh. Both are done. What Got Built Digital Assets…]]></description>
      <category>KDE</category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Amdahl's Law in Practice</title>
      <link>https://pavanportfolio.droptools.site/blog/amdahl</link>
      <guid>https://pavanportfolio.droptools.site/blog/amdahl</guid>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[After implementing five different parallel programming models for the Mankala game engine's alpha-beta search, I discovered a fundamental limit: no matter how many cores I threw at the problem, there was a hard ceiling on performance. Our best implementation, OpenMP, achieved 2.73x speedup with 6 th…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Parallelizing Alpha-Beta Search: Five Threading Models Compared</title>
      <link>https://pavanportfolio.droptools.site/blog/parallel</link>
      <guid>https://pavanportfolio.droptools.site/blog/parallel</guid>
      <pubDate>Fri, 27 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[Continuing my Season of KDE work on the Mankala game engine, I've completed a comprehensive implementation and benchmarking of five different parallel programming models for alpha-beta search. This post explores the performance characteristics, trade-offs, and surprising results from parallelizing g…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Designing Mankala Logos</title>
      <link>https://pavanportfolio.droptools.site/blog/logo-design</link>
      <guid>https://pavanportfolio.droptools.site/blog/logo-design</guid>
      <pubDate>Mon, 23 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[While working on the Mankala Next Gen project for Season of KDE, I needed to create two distinct logos: one for the game itself and another for the mankalaengine backend. What started as a straightforward design task in Inkscape quickly became a lesson in SVG optimization when my initial exports bal…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Parallelizing a Game AI Engine: Root-Level Optimization </title>
      <link>https://pavanportfolio.droptools.site/blog/benchmark</link>
      <guid>https://pavanportfolio.droptools.site/blog/benchmark</guid>
      <pubDate>Sun, 22 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[As part of my Season of KDE work on the Mankala game engine, I am trying to impleemnt root level parallelization to speed up the AI's move evaluation.  Here's how I achieved about 2x speedup. The Problem: Sequential Move Evaluation The Mankala AI uses the minimax algorithm to evaluate moves, searchi…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Containerized KDE Development: Building the Mankala Engine with Distrobox</title>
      <link>https://pavanportfolio.droptools.site/blog/distrobox-kde</link>
      <guid>https://pavanportfolio.droptools.site/blog/distrobox-kde</guid>
      <pubDate>Sun, 22 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[As part of my work on the Mancala for Season of KDE, I needed to compile the backend mankalaengine from source. Running Ubuntu 24.04 LTS on my host system, I wanted to keep it clean and avoid dependency conflicts while designing digital assets. I decided to build the C++ engine inside an isolated co…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>Parallelizing Game AI: A Deep Dive into Multi-Threading Libraries for Search Algorithms</title>
      <link>https://pavanportfolio.droptools.site/blog/research</link>
      <guid>https://pavanportfolio.droptools.site/blog/research</guid>
      <pubDate>Sun, 15 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[Game AI engines, particularly those using tree search algorithms like alpha-beta pruning and MTD(f), are computationally intensive. As modern devices from desktops to mobile phones feature multi-core processors, parallelizing these algorithms has become essential for creating stronger AI opponents w…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
    <item>
      <title>I'm Joining the Season of KDE 2026!</title>
      <link>https://pavanportfolio.droptools.site/blog/sok-2026</link>
      <guid>https://pavanportfolio.droptools.site/blog/sok-2026</guid>
      <pubDate>Sun, 01 Feb 2026 00:00:00 GMT</pubDate>
      <description><![CDATA[I'm absolutely thrilled to announce that I've been selected to participate in the Season of KDE (SoK) 2026! It's an incredible opportunity to contribute to the open-source community, and I can't wait to dive into my project: enhancing the classic game of Mancala for the KDE desktop. What I'll Be Wor…]]></description>
      <category></category>
      <author>pavankumargsoundiraraj06@gmail.com (Pavan Kumar S G)</author>
      <dc:creator>Pavan Kumar S G</dc:creator>
    </item>
  </channel>
</rss>