Two phases. First, recreate a reference Raspberry Pi cluster stack — Ethernet fabric, HPL/Linpack, K3s, Prometheus/Grafana — and measure everything, so the platform itself is validated rather than assumed. Second, build a coordinator/worker runtime on top of it that assigns each inference task to the node expected to finish it first.

Cheap heterogeneous single-board computers on commodity Ethernet break the assumptions cluster schedulers usually make. Node capability differs and drifts; fanless boards thermally throttle under sustained load; and moving data is expensive enough that the network term belongs inside the placement decision, not in a footnote. The scheduler has to learn what nodes can actually do — online, from the tasks themselves — and it has to decide in microseconds, because on a fast fabric a slow scheduler is the bottleneck.

The workload model is task-level partitioning: each webcam frame runs full MobileNet-v2 inference on one node. Splitting a single inference across nodes would shuttle intermediate feature maps over commodity Ethernet — the measured network baseline says that trade is a loss, so the design keeps every task whole and lets placement do the work.

The cluster is dual-homed by design: the laptop stays on Wi-Fi for management, while all worker traffic rides a dedicated Gigabit Ethernet data plane (10.0.0.x). The reference recreation follows Jeff Geerling’s public Pi-cluster automation and benchmark workflow, then verifies each layer manually.

Legacy distributed benchmarks carried forward as baselines: prime counting speeds up 1.696× → 1.578× as workloads grow (coordination overhead is visible, then amortized), and a 4000×4000 matrix multiply runs 1.32× faster distributed — a more honest proxy for AI-style arithmetic than embarrassingly parallel primes.

For each task the coordinator estimates every candidate node’s finish time — computation, current backlog, communication cost from measured bandwidth and latency, and a thermal derating factor that shrinks a node’s effective capability past a warning threshold and floors it near throttle. The most distinctive runtime feature is exactly that derating: fanless boards get protected before the silicon throttles them.

• Wire protocol: length-prefixed JSON over TCP — every receive reads one whole message; the control path stays deterministic.
• Workers are plug-and-play: start the process, get profiled on real workload, join mid-run. Failed tasks are requeued for self-healing.
• Two baselines isolate the contribution: RoundRobin (ignores all state) and CapabilityWeightedStatic (initial estimate, never adapts).
• Capability C is learned online and smoothed with EWMA — no hand-assigned node scores anywhere.

This is deliberate scientific sequencing: establish a correct, perfectly balanced baseline first, so any separation measured later is attributable to the policy rather than to platform noise.

• Add Raspberry Pi 3 nodes — genuine heterogeneity, non-trivial policy separation.
• Thermal workload — validate proactive derating on fanless boards where throttling is physically real.
• Communication-heavy tasks — force the network term to earn its place in the cost model.
• Ablations (thermal / communication / online-learning off) and multi-run statistics with variance.
• Power measurement (USB meter or INA219) → energy-aware scheduling and GFLOPS/W.

A deployed chip exposes a handful of noisy on-die sensors, and the physics model driving any reconstruction is itself wrong: the power map is a nominal estimate, and leakage rises nonlinearly with temperature. The chip-thermal PINN literature demonstrates accurate forward analysis — but rarely compares against the classical alternative: solve the nominal physics, fit a Gaussian process to the sensor residual, add it back. This work stages that comparison honestly, three ways.

The GP matches or beats the PINN at four of five mismatch levels — while running in under a second on a CPU against minutes on a GPU. Two to three orders of magnitude in compute for the same accuracy. In the smooth, linear regime the network confers no benefit, and the paper says so plainly.

Temperature-dependent leakage is a positive feedback: heat raises leakage, which raises heat. Model it as an unknown coefficient β, drop to eight sensors, and the PINN — treating β as a trainable parameter constrained through the coupled residual — holds nearly flat (0.82–1.09 K) while pure physics degrades eighteen-fold and even the GP triples (0.40 → 1.34 K). The curves cross near β* ≈ 0.10.

Uniquely, the PINN also returns a physical quantity no baseline can produce: the leakage coefficient itself, recovered from eight noisy sensors while reconstructing the field. Robustness held under an independent bilinear FEM reference (margin widens: 0.95 vs 1.33 K), doubled sensor noise (β̂ within ±0.003), and a five-member deep ensemble whose predictive σ brackets actual error.

On the published 19-block EV6 layout the freeform PINN fails outright — spectral-bias collapse to ≈8 K MAE even with the physics exactly known. The fix is architectural: precompute each block’s Green’s-function response once, write the field as a per-block Green’s expansion, and let leakage live on the same physical basis, solved to self-consistency inside the forward pass (SC-GB-PINN). Hard physics constraints, N_blocks+1 free parameters.

Because SC-GB-PINN reduces reconstruction to a few per-block parameters, its sensitivity at any location is available in closed form — so choosing the eight positions that maximize the Bayesian D-optimal criterion needs no training at all. On EV6 that drives error to 0.60 K — the lowest in the work — and 0.97 K on the simple chip, while shrinking variance roughly six-fold. And a cautionary measured result: clustering all sensors on the hotspots is catastrophic for the statistical baseline (19→24 K), because it starves the cool interior. Coverage, not intuition, matters — the criterion balances it automatically.

• Smooth model error, adequate sensing → physics-mean Gaussian process. Equal accuracy at negligible cost, no training, trivial to deploy.
• Strong nonlinearity, sparse sensing, or a parameter you need → PINN. Stays accurate where residual-smoothing fails and returns an interpretable coefficient as a by-product.
• Complex multi-hotspot floorplans → embed the physics in the architecture (Green’s basis); a freeform network cannot fit the field at all.

The mechanism generalizes: a smoother treats physics as fixed and interpolates what sensors leave over; a PINN reshapes the physics through a trained parameter. Flexibility is dead weight exactly when classical methods already fit the physics.

• 2-D and simulation-based — a real published processor floorplan, cross-checked against an independent FEM solver, but not measured silicon or a 3-D package.
• Assumes a known floorplan and nominal power map — a design-time estimator, not a black-box learner.
• The leakage law is a controlled positive-feedback model; temperatures exceed realistic junction limits to make the nonlinearity visible.
• No runtime speedup is claimed; reconstruction is treated as estimation.

The Mini ROV integrates Blue Robotics T200 thrusters with ESCs, a depth/pressure sensor, an Xsens motion sensor, and a Raspberry Pi 5 controller inside a 4-inch pressure housing — talking to a laptop operator station over RS485, chosen for robust long-distance wired communication.

My work was hardware integration, software interfacing and the operator UI: acquiring depth and motion data on the Pi, streaming telemetry to the laptop interface in real time, and carrying operator commands back down to the propulsion system.

Each subsystem was integrated independently against the same interfaces — which is what made a one-month build feasible, and what the report credits for maintainability. Power design: a 20 V source for the thrusters through ESCs, with the Pi 5 fed by a buck converter so control stays stable while motors draw current.

The companion project: optical wireless communication on Arduino Uno — an LED transmitter and photodiode receiver on AltSoftSerial, run deliberately slow (300 bps on the optical channel) for stability. The interesting part is the fault tolerance added on top:

• Triple-redundancy encoding — every byte transmitted three times.
• Majority-vote decoding with a correction mask that records exactly which bits were repaired.
• Timeouts and automatic retransmission — up to five attempts before giving up.

From the loopback test log in the report — ambient interference corrupts the message on two attempts; bit-level correction plus retransmission recovers it exactly on the third:

Optical loopback with automatic retransmission on error
--- New message: "Rithish" ---
Attempt 1/5
  Char 0 corrected bits: 4 6 · Char 1: 3 5 6 · Char 2: 5 6 7
  Mismatch: sent="Rithish", received="Raÿÿÿ"
>>> Retransmitting in 200 ms...
Attempt 2/5
  Char 0: 1 6 · Char 2: 2 3 4 7 · Char 3: 6 7 · Char 4: 4
  Mismatch: sent="Rithish", received="0i00000"
>>> Retransmitting in 200 ms...
Attempt 3/5
  Char 4 corrected bits: 0 · Char 6 corrected bits: 3
>>> SUCCESS: Message received correctly.
Message successfully transmitted after 3 attempt(s). Final received: "Rithish"

The log makes the design case better than prose could: single-shot transmission fails in ambient light, and the redundancy + ARQ layer turns an unreliable channel into a reliable one.

• Underwater facilities weren’t available during the internship — the ROV was validated by surface-level functional testing: all subsystems integrated, telemetry and commands verified end to end. Underwater performance was not evaluated.
• The optical link is short-range, alignment-sensitive, and susceptible to ambient light — measured honestly and listed in the report; the redundancy layer is the mitigation, not a cure.

Patent PDFs arrive as messy, inconsistent documents — some born-digital, some scanned, some design-only with no utility claim at all. Engineers need the same things from each: metadata, the independent claims, what the invention actually does, its benefits and failure modes, and which engineering team should see it. Doing that manually doesn’t scale; doing it with a single naive LLM prompt hallucinates.

The split is the design decision: anything with a reliable textual signature — application numbers, dates, assignees, claim boundaries — is extracted deterministically and never touches the model. The LLM works only on grounded evidence windows, generates the analytical fields in parallel, and every output passes a validation gate (word counts, no reference numerals, no comparator conflicts with evidence, no prompt leakage) with an automatic repair loop when a rule trips. Typical run: 12–20 LLM calls, 30–60 seconds per patent.

• Full-document OCR arbitration: scanned pages are re-OCR’d at 300 DPI and the cleaner of embedded vs OCR text wins by a garbage-ratio metric — fixing noisy embedded text (“mbtbtcycle comj^rising” → “motorcycle comprising”) and recovering image-only claim pages.
• A cheap 150-DPI probe distinguishes scanned text pages (need OCR) from drawing pages (don’t) — so drawing-heavy patents stay fast and scanned pages stop being misclassified as drawings.
• Design/ornamental patents are detected and routed correctly — extracting the ornamental-design statement instead of failing on a missing utility claim.
• WIPO/JP bracket claim formats (“[Claim 1]”, “Scope of Claims”) and a strong-anchor rule that picks the last real claim heading, so description pages can’t win.

Claims are legal text, so the pipeline keeps the verbatim claim untouched and adds a separate OCR-cleaned rendering — produced by the LLM but accepted only if it passes safety checks: similarity to the raw text ≥ 0.75, no contiguous edit longer than 45 characters, at most one invented numeral. Fail any check and the system falls back to raw. Every analytical field ships with a confidence score and evidence count, and review flags mark anything a human should re-check.

• Streamlit batch UI: multi-PDF upload, live progress, per-patent result cards with drawing previews, consolidated Excel download, search and status filters.
• One-command installer for Windows and macOS that provisions Python dependencies and the Tesseract OCR binary — the difference between “works on my machine” and works on the R&D team’s machines.
• Validated end-to-end against a hand-curated ground-truth set of real Indian patent filings, including scanned and design patents; independent-claim counts verified per document.
• Automatic routing across engineering team categories (thermal, battery, safety, power electronics, controls…) by weighted keyword scoring.

Deployed internally for TVSM R&D teams. Details that are TVS-internal — endpoints, prompts, the full output schema — stay internal; what’s described here is the engineering approach.

Bearing faults write themselves into vibration spectra — but the writing shifts with operating load. A model that memorizes one load’s spectral fingerprint collapses on another. The goal is a classifier that attends to fault-characteristic frequency structure robustly across 0–3 HP, and runs fast enough to live at the machine.

The frequency branch is the contribution: attention at multiple spectral resolutions, rotary position embeddings so harmonic spacing (not absolute bin position) carries the signal, and trainable frequency masks that learn which bands matter — instead of hand-picking envelope bands per fault type. Measured post-bottleneck inference is 0.8 ms, comfortably edge-deployable.

Four fault classes under 0–3 HP variable load. The load variation is the part that matters: it is the condition where naive detectors degrade, because the spectral signature shifts for entirely benign reasons and a model that memorised one load’s fingerprint has nothing left to stand on.

The 0.8 ms post-bottleneck figure is what makes it deployable — fast enough to run at the machine rather than shipping vibration data to a server and waiting on a round trip.

• Four fault classes evaluated across 0–3 HP variable load, on a held-out set of 4,949 samples.
• FD-MRA benchmarked against the time-domain CNN stream alone, isolating what the frequency branch contributes rather than reporting the fused number by itself.
• Ongoing work: leave-one-load-out validation, where the model trains on some loads and is tested on a load it has never seen — the harder question of whether the learned frequency masks generalise across operating conditions.

The conventional approach to bearing diagnosis picks envelope bands by hand from the fault characteristic frequencies — which works until the load shifts and those bands move. Making the masks trainable, and using rotary embeddings so harmonic spacing carries the signal rather than absolute bin position, moves that choice from the engineer’s prior into the data.

The other lasting output is a habit: evaluation design is part of the architecture. Condition-aware partitions and no window overlap across splits are now my defaults, and a surprisingly high score is something I treat as a bug until I have proven otherwise.

Digital stethoscopes solve auscultation with microcontrollers — adding cost, complexity and a power budget. The design brief here: isolate heart (30–140 Hz), lung (140–400 Hz) and murmur (400–1000 Hz) bands, suppress 50 Hz mains interference, and drive headphones — using nothing programmable. Every behavior must come from component values.

Each band is an independent path: a 4th-order Sallen–Key high-pass into a 4th-order low-pass, values derived by hand (f_c = 1/2πRC — e.g. 30 Hz → 5.3 kΩ, 140 Hz → 11.4 kΩ, 400 Hz → 3.98 kΩ, 1 kHz → 1.59 kΩ at 0.1 µF), built around TL072/LM324 op-amps. Slide switches route any combination of bands into a two-stage summing amplifier; the output buffer drives headphones directly, so no separate power amplifier exists to add its own noise.

Obtained corners run a few percent above design across the board — consistent with component tolerance — while band ordering, isolation and the notch all land where the arithmetic said they would. Simulation first; then the oscilloscope has the final word.

The gap between designed and obtained corners is the education: real capacitors and resistors move your poles, and layout choices — ground pour, short high-gain traces, separated analog return — decide whether a high-gain audio chain hums or stays quiet. The final validation was the honest kind: a live acoustic end-to-end test, band switch by band switch.