Explore Projects

<p>The animation portion of the MIT App Inventor, that includes the Canvas, ImageSprite and Ball components, currently has a lot of room for improvement. This project improves the following aspects of the animation portion of MIT App Inventor.</p> <ol> <li>Enabling users to choose a custom origin for image sprites using a drag-able marker. The origin of a sprite is the root of the sprite's coordinate system. All of the interactions of the sprite that may include collisions, positioning etc. is with respect to the origin. This project implements the desired functionality of custom origin in the appinventor system and adds an interactive way, via a drag-able marker, for selecting this origin easily. </li> <li>Improving the algorithm used to detect collisions among sprites. Right now appinventor uses a naive algorithm to detect collisions between sprites. This collision detection does not work correctly for rotated image sprites and they are treated as if they were unrotated. This projects implements the SAT collision detection algorithm that replaces the naive implementation. This helps detect collisions in rotated image sprites and is more extensible.</li> </ol>

<p>The aim this project is to develop a system that, making use of the Liquid Galaxy capacity to display information over an interactive map obtained from a big data analytics and mining process. Firstly, the data will be gathered from public data APIs and stored in a database to be processed later. This information will be related to historical weather conditions, water and energy reservoirs, earthquakes and other weather related information. Secondly, the data will be analysed under some kind of data analysis algorithm such clustering with K-Means algorithm or Regression Models making use of a Spark Uni-Node System running on the cloud and Python ( pySpark library). The conclusions obtained from this data analysis will be shown on a external interface, such a website running in a server connected to the Liquid Galaxy. This website will offer to the end-user, the possibility to seamlessly display the chosen information into Liquid Galaxy. Then the system will automatically send the corresponding KML files to Liquid Galaxy in order to display this information in a descriptive and visual way, for example percentual polygons, polylines, etc.</p>

My project will be Making a New Documentation Site Engine for Keptn which can handle a large number of documentations projects of Keptn. Currently, the Keptn documentation site is based on Hugo based theme called hugo-serif-theme. For tutorials, Codelabs is also used. While extremely handy for smaller projects and initial versions of Keptn, this toolchain has serious deficiencies for larger-scale projects like Keptn. I am going to propose a New Documentation Site Engine that will be based on Docusaurus. Docusaurus is an optimized site generator in React. Docusaurus helps you to move fast and write content. Build documentation websites, blogs, marketing pages, and more. The main focus of Keptn New Documentation Site Engine will be managing large-scale documentation and complex documentation projects. So two major things which are needed in the documentation engine are Multiple repository docs support and Versioning of Docs support. Find my detailed GSoC 2022 Project Proposal at https://github.com/iamrajiv/GSoC-2022/blob/main/GSoC_2022_Project_Proposal.md.

<p>Artificial Intelligence (AI) presents an opportunity to accelerate and de‑risk mainframe data modernization by automating the most complex and labor‑intensive aspects of understanding, extracting, and rebuilding legacy workloads.</p><p>This project will deliver a comprehensive framework that guides organizations through understanding legacy mainframe data structures, mapping those datasets to modern cloud‑based platforms, and applying effective methods for data transfer, quality checks, and validation. As part of this effort, the participant will also develop a demonstration application that showcases the practical implementation of key elements of the framework, illustrating how each component works together to support a successful modernization journey.</p><p><br></p><p>Deliverables:</p><p>A technical framework</p><p>A whitepaper to be published under the modernization working group banner.</p><p><br></p><p><strong>Applications closing date: 25-Apr-2026</strong></p><p><br></p><p><strong>Mentee confirmation: 10-May-2026</strong></p>

<p>The current version of GNSS-SDR supports GPS, GALILEO, GLONASS and BeiDou Global Navigation Satellite System signals. Right now in BeiDou signals, GNSS-SDR fully supports BeiDou B1l and BeiDou B3I. The primary goal of this project is to make the software receiver compatible with the BEIDOU B1C signals. This project will enhance the software receiver to aid acquisition and tracking of BEIDOU B1C signals that would further expand the receiver's capabilities and would facilitate research on multi-constellation, multi-frequency receiver working with real signals. The demodulation of the B-CNAV1 navigation message of BEIDOU B1C will open the door to innovation in multi-constellation receivers. Along with the fully functional implementation of a GNSS receiver working with BEIDOU B1C signals, this project will help to address topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning. Additionally, the integration of BEIDOU B1C observables into the position, velocity, time (PVT) solutions will allow the achievement in a diverse range of applications and components.</p>

Build a Headlamp plugin to surface Kubeflow resources (Pipelines, Katib, PipelineRuns, Notebooks, TFJob/PyTorchJob/TrainJob, Spark) so operators and ML engineers can discover, monitor, and manage ML workloads alongside standard K8s resources. Link to Kubeflow UIs when deeper functionality is needed. - Expected Outcome: - New Kubeflow sidebar with cross-namespace lists for Pipelines (Experiments, Runs), Katib experiments, Notebook servers, Training and Spark jobs. - Detail pages per resource showing metadata, status, metrics, logs and common actions (start Run, open Jupyter, view best hyperparams). - Links/embed to Kubeflow Central Dashboard or Pipelines UI for advanced tasks. - Headlamp Map integration: show relations to Deployments/Pods, Argo workflows, Spark driver/executors. - Metrics via Prometheus or /metrics: basic charts for experiment objectives and pod resource use. - Polished UX: icons, pagination, filtering, error handling. - Outreach: README/User Guide and a demo blog post with screenshots.

<p>ODK-X Survey is a data collection Android application, similar to ODK Collect. Users can create forms using XLSX spreadsheets and are then rendered to them on their mobile device. It is built with HTML, CSS, and JavaScript in replacement for native Android development. Forms are synchronized to a server and support various prompt types including but not limited to free text, numbers, geo-points, and audio.</p> <p>Currently, the form accepts the date and DateTime prompts. The date prompt gets the date from the user using dropdown menus whilst the DateTime prompt gets the date and time in a similar manner.</p> <p>The goal of this project is to include more prompt types including month only, year only, month and year only, and non-Gregorian calendars for users to choose from. The programming languages used to develop these include HTML, CSS, and JavaScript. The project also ensures that once implemented, these new prompt types are compatible with the ODK-X XLSX Converter. The new prompt types are then added to the converter’s documentation including how to make custom prompts.</p>

<p>ODK Collect is an open-source Android Application available on Google Play Store. It helps the users to collect data through survey forms and to manage the data by sending the forms to the server.</p> <p>I will be focussing primarily on two aspects of the project.</p> <p>First is to rewrite the tests of the widgets, focussing on making them less time consuming and potentially expanding the test coverage so that the core framework remains stable. I will be using the Roboelectric test framework for this purpose and replacing already implemented Espresso tests with the same.</p> <p>Second is to rewrite the Collect’s widgets using the new “widget framework”, which will be followed by updating the UI of the widgets, following the style guide and Material Design guidelines (only after having proper discussion and approval of the mentors for the proposed UI changes). The UI of the widgets should be redefined in XML files, rather than in java classes.</p> <p>Lastly, there are some opportunities in ODK Collect, where we can improve the UI of the app, and implement pre-built UI modules, to improve the user experience of the app.</p>

This proposal aims to update the User Interface and add new features to catch up with the Android version of VLC, enhancing and making the user experience safer and easier. The main feature of this project will be adding to VLC iOS app the Parental Control feature already available on the VLC Android app. This will enable iOS users to restrict access to the app settings and to sensitive actions, such as deleting media files or modifying playlists, unless the user successfully authenticates via a PIN code or biometrics. This is particularly useful in environments where children or unauthorized users might otherwise access media libraries unsupervised. This feature will ensure that VLC for iOS offers the same level of protection and control alongside consistent design guidelines and accessibility currently available in VLC for Android. As part of this effort, some components of the settings interface and media actions will also be reviewed and updated to align with modern iOS UI patterns. Implementing these improvements will strengthen the app’s usability in shared environments and contribute to a safer, more polished experience for all users.

Modern printers usually are driverless IPP printers, and those get discovered fully automatically by CUPS; no CUPS queue needs to be explicitly created. Same for remote CUPS printers and also Printer Applications . They are all discovered as IPP print services. And listings of IPP print services have different requirements: One server can have more than one individual print service and these should get listed together. This could be a print queue and a fax out queue of the same multi-function printer, or two physical legacy printers supported by one Printer Application. Also the user interaction coupled to each listing is different. We do not need to configure PPD option settings, but instead, we need access to the IPP service's web administration interface and also to an IPP System Service configuration panel by a simple mouse click. Several parts of this were already coded in previous GSoCs, but we need to get everything smoothly integrated in the “Printers” part of the GNOME Control Center. I will work together with the upstream maintainer of the “Printers” module, Marek Kasik and also with the UI/UX design teams of GNOME and of Canonical.

This project aims to build a faster, lightweight, user-friendly, mobile-friendly, and cross-browser-compatible UI library as a stand-alone dependency for moja global projects. Moja global User-interface (UI) library project aims to bring forward an intuitive, consistent, and easy-to-use interface that can help the developers within the User-Interface working group and users to quickly accomplish their tasks. The UI library aims to considerably improve the design & development workflow and meet the acceptable web accessibility requirements for potential users. A UI library helps to mitigate popular UI-development issues like inconsistent user experience, performance issues, accessibility requirements, and more. To achieve this, a centralized collection of components would be developed which will encompass the color branding of moja global, typography, spacing, buttons, modals, and forms. The big picture is that the UI library will allow all the upcoming moja global projects, with a client-facing focus, to have a consistent design language that will help us to quickly and easily build their user interface.

This project will involve refactoring the Human Neocortical Neurosolver (HNN-core) codebase to enable flexible development of neural circuits with customizable cell types. Currently, HNN-core contains hard-coded assumptions about cell types, locations, and connectivity that limit researchers' ability to implement networks with different architectures. I will restructure key modules to replace these hard-coded constraints with dynamic definitions, allowing users to flexibly select and connect cell types with different morphologies and electrophysiological properties. The solution involves refactoring cells_default.py for dynamic cell creation, modifying network.py to handle arbitrary cell types, and updating related components to support custom cell types. The proposed plan includes dynamic cell type implementation, updated network connectivity handling, a demonstration model with custom cell types, comprehensive documentation, and unit tests ensuring backward compatibility. This work will significantly enhance HNN's capabilities for hypothesis testing in EEG/MEG research while maintaining its user-friendly approach for neuroscientists.

This project aims to develop an agentic AI system for predictive maintenance of urban infrastructure using OpenVINO. The goal is to enable intelligent monitoring and decision-making by combining multimodal perception with reasoning capabilities on edge devices. The proposed solution integrates a vision-language model to detect defects (Deformation, Obstacle, Rupture, Disconnect, Misalignment, Deposition) from visual data and a language model to interpret these defects in terms of severity, risk, and maintenance priority. These components will be connected through an agentic pipeline that performs perception, reasoning, and action in a unified workflow. The system will be implemented using OpenVINO-optimized models and deployed on Intel edge hardware to ensure efficient, low-latency inference. Open datasets will be used to validate the system in realistic scenarios. Expected deliverables include: - An end-to-end agentic AI pipeline for predictive maintenance - Integration of multimodal perception and LLM-based reasoning modules - Deployment and optimization using OpenVINO on edge platforms - Benchmark results evaluating performance and system effectiveness - Comprehensive documentation and reproducible codebase

<p>The Node Disk Manager (NDM) daemonset runs on every node in the Kubernetes cluster, discovers and monitors various storage devices connected to the node. It exports these devices as BlockDevice (BD) custom resources on the Kubernetes cluster, which are then used by other OpenEBS stack components. The NDM currently supports the detection of various storage devices connected to the node. However, it cannot detect specific changes that may happen to the block devices while connected to the node. Specifically, the NDM cannot detect changes in the mount-point(s) and the filesystem associated with a device. It also cannot detect a change in the capacity of the block device.</p> <p>The mount-point(s) of a block device can easily be changed on a system. It is easy to change the disk size on the cloud too. This causes issues in the Kubernetes cluster using OpenEBS as the changes in the device properties will not be reflected immediately in the BD resource.</p> <p>This proposal aims to solve the issue above by adding functionality in the NDM to detect changes in the mount-points and capacity of supported block devices and propagate them immediately to the corresponding BD resource.</p>

This project will create a Kubernetes deployment for the full stack: the OpenTelemetry Demo application, the Jaeger backend components (Collector, Query), and OpenSearch as a storage backend. The environment will be automatically redeployed weekly to ensure it is always fresh and to solve the problem of data retention. The entire stack will be hosted on a managed Kubernetes cluster (Oracle Kubernetes Engine) within an Oracle Cloud environment generously donated to the project. Expected Outcome: 1. A working, publicly accessible Jaeger demo featuring the OpenTelemetry Demo application, deployed on Oracle Cloud. 2. Fully automated, weekly deployments using the existing Helm- based automation and GitHub Actions. 3. The entire environment defined as "Configuration as Code". 4. A secure deployment following best practices for public-facing services. 5. The UIs for Jaeger, the OTel Demo, the load generator, and OpenSearch Dashboards exposed -publicly via the existing demo.jaegertracing.io URL. 6. Public-facing documentation on the Jaeger website explaining the demo architecture and linking to the automation code.

With today's dynamic technology , people interact more with their phones and tablets and in order to adapt with this change , PWAs offer a great solution with their ability to leverage the resource of a website and provide a cross platform experience on any device with almost all features a mobile app has to offer , like push notifications etc. One of essential prerequisites for PWAs is good integration of the web app in various resolutions. Submitty already has good support for most of it’s web features on mobiles and tablets and I would like to carry the work forward in the assimilation of more of its features and webpages in variety of display resolutions. With this done we can experiment and analyze various platforms in order to successfully implement the creation and maintenance of PWA for submitty , this will include exploring a platform that provides best support for all feature on variety of devices in the most optimal way. After we are done with selection , work on essential components like Manifest, Service worker , Caching and fetching of the assets, Optimal UI/UX for installation and other features could we worked upon. Then the work on some errors and compatibility issues could be done. Atlast the proper documentation for all the work including the usage , installation etc could be done.

Multiple robotic spacecraft have been sent by NASA to collect orbital remote sensing data, which is used to analyze surface composition. Gamma-ray spectrometers are among the sensors used for this task. They collect position-dependent energy spectra whose shape is a function of the components from different elements present in the area observed by the sensor at a particular time. This data can be used to infer the relative abundance of each element (through a process called unmixing) and to map their distribution across a planet’s surface. However, accurately deriving abundance just from gamma-ray spectra is an intractable problem. Machine learning (ML) has been widely used to address intractable problems, including the unmixing of spectral signatures in the visible and near-infrared (VNIR) region of the electromagnetic spectrum. Therefore, this proposal outlines the development of an ML model for estimating elements from gamma-ray spectra. This goal consists of two sub-objectives: (i) identification of the best model/architecture using data from the Lunar Prospector Gamma-Ray Spectrometer (GRS); (ii) a trained model for estimating elemental abundances from GRS data.

This project modernizes the classic Kennedy Approach air traffic control game by rebuilding it as a custom, multi-screen interactive experience on the Liquid Galaxy platform. Rather than emulating the original Commodore 64 version, the game is being ported from scratch, allowing for enhanced features and seamless integration across multiple synchronized displays. The system is designed around a master-slave architecture, where the master node handles game logic and display rendering. The visual output is split and distributed to multiple slave nodes on the network, creating a panoramic and immersive gameplay view across multiple screens using the Liquid Galaxy setup. Players interact with the game using a mobile controller app built in Flutter, which communicates with the master system over a local network. A Node.js backend on the master node manages incoming control commands via WebSockets/Socket.IO, ensuring smooth, real-time interactivity. Optional UI dashboards built in React or Next.js can be used for monitoring system status, visualizing live data, or enabling multiplayer interaction.

Onboarding new end users into a sophisticated system like Knative Eventing presents significant challenges, especially as it involves understanding not only the operational components but also a distinct architectural style - event driven architecture (EDA). These issues are also seen in the current documentation which is often too technical and not geared towards practical guidance. This project seeks to perform a thorough investigation into the barriers that prevent smooth user onboarding and sustained engagement. By identifying these obstacles and developing clearer, more actionable onboarding materials, we aim to enhance the ease of entry and ongoing use of Knative Eventing for all users. Expected Outcome: 1. Produce a detailed report based on user research that outlines the current onboarding experience for new users of Knative Eventing. This report will highlight key barriers and challenges in the documentation and setup process, and recommend actionable improvements to make the onboarding process more user-friendly and less technically daunting. 2. Implement the proposed changes within the Knative community by developing comprehensive onboarding materials and enhancing existing documentation to better support new users.

This project aims to decouple PEcAn’s dependency on BETYdb—a centralised PostgreSQL database used for storing trait data, yield data, and provenance tracking—by introducing a flexible, file-based fallback system. This enhancement will allow PEcAn workflows to run seamlessly in environments without PostgreSQL access, such as CI pipelines, offline setups, educational use-cases, or cloud-execution environments. The solution involves auditing current modules (query.traits.R, query.yields.R, query.citations.R, etc.) to identify database-dependent components, and systematically refactoring them to support alternative data sources like CSV, JSON, or lightweight SQLite databases. Additionally, tools will be developed for syncing offline results back to BETYdb when needed, preserving compatibility. Key deliverables include a standalone trait dataset, workflow execution independent of PostgreSQL, improved module interoperability, and documentation updates to support adoption. This work will significantly improve PEcAn’s accessibility, portability, and usability across a broader set of environments and users.

<p>GeneTech allow users to develop genetic logic circuits only by specifying a Boolean function. The tool first performs Boolean optimisation, followed by synthesis and technology mapping. Currently, a user can define the desired behavior in the standard Boolean notation. I would like to add the support for designing a circuit via drag and drop method on a design canvas. This functionality would allow users, specially electrical/electronic engineers, to design a genetic circuit by constructing the circuit schematic on a design canvas using drag-drop-wire approach. GeneTech will then transform the circuit schematic into the corresponding genetic circuit and represent it in the standard SBOL notation. The results produced by the current version of GeneTech do not include the DNA basepair encoding of circuit components. I would like to update the tool to be able to embed the DNA sequence of generated circuits in the SBOL file.</p> <p>Most of the code-base of GeneTech is currently a pre-compiled version of the Java code which adds additional overhead and dependencies. We would also like to convert the Java code to Python and reduce dependencies along the way</p>

While Open Library excels at patron aquisition, it struggles with retaining the patrons- this happens due to a break in flow as post sign up patrons are met with an empty dashboard and lack of personalization. Without clear guidance, patrons struggle to find 'What to do next?' and drop off without engaging with the library or features such as reading lists and social connections. This project aims to bridge that very gap between 15 million patrons and 40 million works by introducing a progressive onboarding flow and a highly personalized dashboard for its patrons. By capturing user preference on sign up, we can personalize their dashboard ridding of the empty experience and providing clear Next steps, along with redesign of the dashboard to emphasize the high value features. Deliverables: Progressive Onboarding Flow (A 3-part form that captures and stores broad patron taste, specific book taste and yearly reading goal), Personalized Dashboard (Overhaul of the present 'My Books' page to priortize high-value features and addition of the 'Next reads' system), and the Recommendation Engine that powers the 'Next Reads' components using existing solr infrastructure.

GDB-UI currently supports only one user at a time because the backend shares a single global GDB controller across all requests. When two users debug simultaneously, the second session silently destroys the first with no error or warning. This proposal implements a three-phase solution. Phase 1 replaces the global controller with a thread-safe SessionManager that gives each user their own isolated GDB instance via a UUID session_id. A working implementation is already open as PR #131 with 15 passing tests, security fixes, and a live demo page. Phase 2 introduces WebSocket streaming with a per-session reader thread architecture so GDB output reaches the frontend in real time without blocking the server. Phase 3 moves each project into an isolated Docker container using the Docker SDK exec_start socket API for interactive GDB attachment, solving file descriptor exhaustion at the OS level. Deliverables: merged SessionManager with full test coverage, WebSocket streaming with reconnection handling, Docker sandbox with resource limits, security audit, and handover documentation.