Applied AI, backend, and product engineering across LLM applications, AI systems, computer vision, and real-time software. 2026-06-18T00:00:00+00:00 https://sbartaula.github.io/ Saroj 2026-06-18T00:00:00+00:00 2026-06-18T00:00:00+00:00 https://sbartaula.github.io/writing/why-i-am-building-motion-intelligence/

Why structured movement data matters, and why video is only the starting point.

<p>Raw video is abundant, but raw video is not a usable interface for most motion-driven software systems.</p> <p>The core thesis behind Tenslam Vision is simple:</p> <ol> <li>video should be transformed into structured movement representation</li> <li>that representation must be stable enough for product workflows</li> <li>reliability matters more than demo aesthetics</li> </ol> <h2 id="what-motion-intelligence-means-in-practice">What motion intelligence means in practice</h2> <p>In this context, motion intelligence is not just pose estimation. It is the full transformation layer from pixels to dependable signals:</p> <ul> <li>landmarks and temporal dynamics</li> <li>repetition and phase structure</li> <li>posture and quality indicators</li> <li>features that downstream systems can consume repeatedly</li> </ul> <h2 id="why-this-matters-across-domains">Why this matters across domains</h2> <ul> <li><strong>Fitness:</strong> immediate feedback and movement-quality guidance</li> <li><strong>Sports:</strong> repeatable motion analysis and progression tracking</li> <li><strong>Digital twins:</strong> structured human state representation</li> <li><strong>Physical AI interfaces:</strong> alignment between human motion and machine systems</li> </ul> <h2 id="architecture-direction">Architecture direction</h2> <p>The build direction is pipeline-first:</p> <ul> <li>extraction from video frames</li> <li>temporal stabilization</li> <li>feature schema construction</li> <li>downstream interface for analytics and real-time products</li> </ul> <p>The goal is composable infrastructure, not one-off demos.</p> <h2 id="measurement-frame">Measurement frame</h2> <table> <thead> <tr> <th>Dimension</th> <th>Why it matters</th> <th>Current public status</th> </tr> </thead> <tbody> <tr> <td>Signal stability</td> <td>Structured data is only useful if stable over time</td> <td>Measurement in progress</td> </tr> <tr> <td>Cross-condition robustness</td> <td>Real-world use includes varied camera/lighting setups</td> <td>Evaluation in progress</td> </tr> <tr> <td>Downstream utility</td> <td>Features must be usable by product modules</td> <td>Integration in progress</td> </tr> <tr> <td>Failure observability</td> <td>Reliability work requires explicit failure taxonomy</td> <td>Ongoing documentation</td> </tr> </tbody> </table> <h2 id="risk-register">Risk register</h2> <p>Key technical risks right now:</p> <ul> <li>domain shift across body types, camera geometry, and environments</li> <li>brittle feature behavior under occlusion and fast motion</li> <li>overfitting the representation to one use case too early</li> </ul> <p>Mitigation strategy:</p> <ul> <li>standardize test scenarios and track behavior by condition</li> <li>separate core representation from app-specific heuristics</li> <li>publish failure classes alongside performance improvements</li> </ul> <h2 id="why-i-keep-building-this">Why I keep building this</h2> <p>I am less interested in proving that a model can run, and more interested in building a representation layer that remains useful when products and conditions change.</p> <h2 id="next-milestone">Next milestone</h2> <p>Next public release will include a case-study style breakdown of the motion feature schema, failure taxonomy, and selected validation scenarios.</p> 2026-06-18T00:00:00+00:00 2026-06-18T00:00:00+00:00 https://sbartaula.github.io/writing/running-small-llms-locally/

What local model experiments taught me about speed, memory, and practical constraints.

<p>I run small LLMs locally because it exposes the engineering truth quickly: every performance claim is bounded by hardware.</p> <p>On constrained Ubuntu machines, the objective is not to run the largest model possible. The objective is to identify practical operating zones for real workflows.</p> <h2 id="evaluation-frame">Evaluation frame</h2> <p>I use the same dimensions in each run so results are comparable over time:</p> <ul> <li>inference throughput</li> <li>memory footprint (RAM/VRAM)</li> <li>response quality under constrained context windows</li> <li>system responsiveness while the model is active</li> <li>setup and operational complexity</li> </ul> <h2 id="benchmark-matrix">Benchmark matrix</h2> <table> <thead> <tr> <th>Dimension</th> <th>Why it matters</th> <th>Current public status</th> </tr> </thead> <tbody> <tr> <td>Tokens per second</td> <td>Determines usability for interactive workflows</td> <td>Measurement in progress</td> </tr> <tr> <td>Peak memory usage</td> <td>Hard cap for local hardware viability</td> <td>Measurement in progress</td> </tr> <tr> <td>Prompt/context sensitivity</td> <td>Impacts output stability and quality</td> <td>Evaluation in progress</td> </tr> <tr> <td>Quantization tradeoff</td> <td>Controls speed-quality-memory balance</td> <td>Comparison in progress</td> </tr> <tr> <td>Runtime overhead</td> <td>Affects repeatable developer workflows</td> <td>Evaluation in progress</td> </tr> </tbody> </table> <h2 id="observed-constraints-that-matter-most">Observed constraints that matter most</h2> <p>These constraints repeatedly dominate outcomes:</p> <ul> <li><strong>Memory headroom:</strong> low spare memory collapses usability before model quality becomes relevant</li> <li><strong>Context inflation:</strong> larger prompts can quietly degrade latency and user experience</li> <li><strong>Quantization choice:</strong> speed gains may come with quality loss that is task-dependent</li> <li><strong>Driver/runtime setup:</strong> small environment mismatches can invalidate otherwise good configs</li> </ul> <h2 id="failure-modes">Failure modes</h2> <p>Common failure patterns during local runs:</p> <ul> <li>throughput looks acceptable in short tests but degrades in extended sessions</li> <li>response quality drops under longer context chains</li> <li>machine becomes operationally unpleasant even when inference technically succeeds</li> </ul> <p>Mitigation direction:</p> <ul> <li>standardize run profiles by task class</li> <li>treat local workloads as budgeted systems (latency and memory budgets first)</li> <li>separate demo configs from sustained-workflow configs</li> </ul> <h2 id="practical-takeaway">Practical takeaway</h2> <p>Local-first experimentation is valuable because it forces architecture discipline. It becomes clear which model/runtime choices can survive repeated use, not just one successful notebook demo.</p> <h2 id="next-milestone">Next milestone</h2> <p>The next update will include comparative benchmark snapshots across selected model sizes and quantization profiles, using one reproducible prompt and hardware baseline.</p> 2026-06-18T00:00:00+00:00 2026-06-18T00:00:00+00:00 https://sbartaula.github.io/writing/building-real-time-ai-gym-trainer/

Lessons from turning a mobile camera into a feedback loop for training.

<p>Tenslam Gym started from one practical question: can a phone camera improve movement quality while a person is still in the set?</p> <p>For this product, detection quality alone is not enough. The system has to close a full loop in near real time:</p> <ol> <li>detect pose landmarks</li> <li>estimate exercise state and repetition phase</li> <li>evaluate posture quality</li> <li>return feedback quickly enough to influence the next rep</li> </ol> <p>If this loop is slow or unstable, the product feels disconnected and users stop trusting the feedback.</p> <h2 id="system-architecture">System architecture</h2> <p>The current prototype architecture is intentionally simple:</p> <ul> <li><strong>On-device pose estimation:</strong> MediaPipe landmarks from camera frames</li> <li><strong>Signal conditioning:</strong> smoothing and temporal filtering to reduce jitter</li> <li><strong>State machine logic:</strong> repetition counting and posture-rule checks</li> <li><strong>Feedback layer:</strong> concise visual cues and counters in-session</li> <li><strong>Session persistence:</strong> lightweight Firebase-backed product state</li> </ul> <p>The non-obvious work is in the transition logic between these stages, especially when inputs are partial or noisy.</p> <h2 id="benchmark-frame">Benchmark frame</h2> <p>The table below is the benchmark frame I use during iteration.</p> <table> <thead> <tr> <th>Metric</th> <th>Why it matters</th> <th>Current public status</th> </tr> </thead> <tbody> <tr> <td>End-to-end feedback latency</td> <td>Determines whether feedback can change user behavior in-session</td> <td>Measurement in progress</td> </tr> <tr> <td>Rep-count consistency</td> <td>Core trust metric for training use</td> <td>Validation in progress</td> </tr> <tr> <td>Posture alert precision</td> <td>Reduces noisy or incorrect corrections</td> <td>Validation in progress</td> </tr> <tr> <td>Out-of-frame recovery behavior</td> <td>Real users move unpredictably</td> <td>Mitigation in progress</td> </tr> </tbody> </table> <p>I am publishing this structure now so future updates can be compared on the same measurement frame.</p> <h2 id="failure-modes-observed">Failure modes observed</h2> <p>These are the highest-impact failure classes so far:</p> <ul> <li><strong>Partial body visibility:</strong> causes unstable landmark geometry and false transitions</li> <li><strong>Tempo changes:</strong> can trigger double-counting in naive phase boundaries</li> <li><strong>Camera angle drift:</strong> reduces reliability for fixed threshold logic</li> <li><strong>Jitter bursts:</strong> produce posture warnings that feel inconsistent to users</li> </ul> <p>Current mitigation direction:</p> <ul> <li>temporal smoothing tuned by exercise class</li> <li>state-transition hysteresis to reduce flip-flop behavior</li> <li>confidence gating before issuing posture alerts</li> </ul> <h2 id="product-lesson">Product lesson</h2> <p>Real-time fitness AI is a systems reliability problem, not a single-model problem. Useful behavior comes from coordination across inference, timing, heuristics, UX signaling, and recovery from imperfect inputs.</p> <h2 id="next-milestone">Next milestone</h2> <p>The next milestone is a publishable case-study release with:</p> <ul> <li>measured latency envelope on target devices</li> <li>rep-count reliability on selected movement patterns</li> <li>explicit failure-mode matrix and mitigation status</li> </ul>