My background is in electrical and electronics engineering. I work on applied AI, computer vision, backend pipelines, and data tools by building systems that handle real inputs, produce outputs a person can check, and stay clear about their limits.
Road Risk Review: a local-first beta for reviewing recorded road footage and producing reviewer-ready evidence.
I work best when a project has pressure from the real world: noisy inputs, limited evidence, edge cases, and the need to explain what the system is doing. Road Risk Review is the clearest version of that direction, but the same pattern shows up in my satellite tools, weather prototype, GLOBE data work, and SPR simulation work.
I am building toward applied AI and product engineering work: tools that ingest messy data, run useful analysis, expose uncertainty, and leave a reviewer with something they can inspect. I keep claims tied to code, tests, documentation, and repeatable outputs.
The first project is the one I am actively shaping as a beta: a review workflow with evidence a human can inspect.
Main project in beta
I am building Road Risk Review as an early beta for reviewing recorded dashcam, helmet-mounted camera, and other vehicle-mounted camera footage. The goal is to help a person review a clip faster, find risky moments, see why a moment was flagged, and export an investigation pack that can be checked later.
Right now it is a local-first product workflow: a FastAPI backend, a Next.js review interface, OpenCV-based interpretable detectors, incident-phase timelines, case-study proof videos, and a verification gate in CI. I am keeping the claims careful. It is not ADAS, not collision prevention, and not a substitute for human judgment.
Current stage: Quiet beta. I am testing the review workflow, tightening the evaluation gates, and turning the prototype into a product-shaped tool for people or small teams who need to inspect recorded road footage.
What I am working on now: Better investigation packs, clearer verification reports, stronger limits around false positives and misses, and a cleaner path from uploaded clip to reviewer-ready evidence.
A small weather app that tries to be honest about where its numbers come from. It shows a seven-day forecast from Open-Meteo, which is driven by the ECMWF IFS model and needs no API key. Your city is worked out on the server from your IP address using ipapi.co, and the IP is thrown away straight after; the page never asks the browser for your precise location. If a public webcam covers the same area, the app can pull a recent frame and run a simple brightness and edge check against the forecast for that moment, so you can see whether the sky in the image looks roughly like what the model predicts. The live page below loads a fresh webcam frame and a fresh forecast for the same coordinates at the same UTC timestamp, so the cross-check is actually real-time rather than a screenshot.
What I built: Built the frontend in Next.js 15 with Tailwind and Recharts, and the backend in FastAPI. Wrote the server-side IP-to-city resolver that discards the IP after use, the Open-Meteo client, and a small computer-vision routine (HSV colour statistics plus a Sobel edge check) that compares a webcam frame against the forecast for the same coordinates. Added an ensemble-fusion layer with stub adapters for OpenWeatherMap, NVIDIA Earth-2, and Google MetNet-3 so additional sources can be plugged in later. Limited the webcam sources to feeds that are explicitly public, including Statens vegvesen under NLOD, NOAA GLERL, and US DOT 511.
What this shows: A practical interest in trustworthy user-facing systems: where the data comes from, how location is handled, and whether a live visual signal agrees with the forecast. It is smaller than Road Risk Review, but it points in the same direction: inspectable outputs over black-box claims.
Earlier projects where I built technical systems around orbital mechanics, satellite planning, data visualization, computational optics, and public data workflows. I keep them here because they show how my work moved from isolated prototypes toward applied systems with verification, documentation, and usable outputs.
A hands-on orbital propagation toolkit built around SGP4 and dSGP4. I use it to work with TLE data, track satellites, visualize orbits, and test how drag affects the results. If SGP4 fails on a particular input, it falls back to a simpler two-body model so nothing crashes.
What I built: Implemented TLE parsing and validation utilities, an educational reference SGP4 propagator with extra numerical-stability checks, a DifferentiableSGP4 PyTorch module for gradient-based analysis (inspired by ESA's dSGP4 project), and a LiveSGP4 tracker with automatic two-body fallback, detailed error history, and a validation test suite.
What this shows: Comfort with mathematical models, failure modes, validation, and building engineering layers around proven libraries instead of pretending every core algorithm should be rewritten from scratch.
These are self-directed projects, not formal research appointments or professional aerospace experience.
A mobile-first planning tool that predicts LEO satellite passes for any location and calculates whether the link margin is strong enough to hold a connection. Given a satellite by NORAD ID or name and an observer position, it returns pass times, SNR and link-budget curves, timeline charts, ICS calendar export, and PDF reports. Built with a FastAPI/Python backend and a Next.js frontend.
A web application that fetches live TLE data from CelesTrak and visualizes thousands of satellites orbiting in real time. It uses Skyfield for orbit computation and adaptive time stepping for pass prediction, with a React frontend and a Python backend. The main challenge was keeping the rendering responsive while tracking thousands of moving objects.
A data workflow and dashboard around NASA GLOBE Observer cloud observations. The useful part of the project is not only the map: it is the habit of treating data provenance, filters, notebooks, and public-facing explanations as part of the product surface.
A computational optics project around transfer-matrix SPR biosensor simulation. I used it to reproduce a paper, compare outputs against an established TMM package, write tests, and document where the reproduced values diverged from the published reference.
Applied AI, backend, computer vision, and product engineering roles where the work involves real inputs, evaluation, and clear user-facing evidence. I am especially interested in teams building tools that shorten review, analysis, or operations workflows.