<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Perception on Mahdi Sarfarazi</title>
    <link>https://mahdisf.ir/tags/perception/</link>
    <description>Recent content in Perception on Mahdi Sarfarazi</description>
    <image>
      <title>Mahdi Sarfarazi</title>
      <url>https://mahdisf.ir/images/social-card.png</url>
      <link>https://mahdisf.ir/images/social-card.png</link>
    </image>
    <generator>Hugo</generator>
    <language>en-US</language>
    <lastBuildDate>Sun, 01 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://mahdisf.ir/tags/perception/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Camera-only 3D tracking and velocity estimation</title>
      <link>https://mahdisf.ir/projects/vision-3d-state-estimation/</link>
      <pubDate>Sun, 01 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://mahdisf.ir/projects/vision-3d-state-estimation/</guid>
      <description>Course project: a Python pipeline that tracks people and vehicles in 3D from a single phone camera, estimating position and velocity with a Kalman filter. Benchmarked components; limits documented.</description>
      <content:encoded><![CDATA[<p>In this machine-vision course project, I estimated where people and vehicles are in 3D, and how fast they&rsquo;re moving, using only a phone camera without LiDAR or a stereo rig.</p>
<h2 id="what-i-built">What I built</h2>
<p>YOLO11n detects objects and ByteTrack keeps their identities across frames. The metric outdoor variant of Depth Anything V2 then turns each detection into a 3D position.</p>
<p>A recursive Kalman filter tracks motion with a six-value state (position and velocity in x, y, z). It uses wall-clock time between frames, so velocity stays consistent when the frame rate varies, and it keeps predicting through missed detections.</p>
<p>I calibrated the camera (a Samsung A34) with a checkerboard, and used a second phone&rsquo;s IMU (a Samsung A54, via Phyphox) to sanity-check the estimated velocities.</p>
<h2 id="how-i-chose-the-components">How I chose the components</h2>
<p>I benchmarked the detectors myself on the target laptop (RTX 3060, 6 GB):</p>
<table>
  <thead>
      <tr>
          <th>Detector</th>
          <th style="text-align: right">Measured speed</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>YOLOv8n</td>
          <td style="text-align: right">≈ 16 FPS</td>
      </tr>
      <tr>
          <td>YOLO11n</td>
          <td style="text-align: right">≈ 20 FPS</td>
      </tr>
      <tr>
          <td>YOLO26n</td>
          <td style="text-align: right">≈ 23 FPS</td>
      </tr>
  </tbody>
</table>
<p>I picked YOLO11n. It wasn&rsquo;t the fastest, but it gave the best balance of detection quality, installation reliability and speed. The depth model was the real bottleneck at about 0.22 s per frame (≈ 4.5 FPS).</p>
<h2 id="results-and-limits">Results and limits</h2>
<p>The Kalman filter typically converged within three to five frames of a new detection. I tested qualitatively on crowded pavements, street traffic and mixed traffic.</p>
<p>The report states the main limitation. Without LiDAR or stereo ground truth, I could not measure end-to-end depth error, and metric scale needed manual calibration. The depth model&rsquo;s published benchmark (0.454 m MAE on its own validation sets) does not measure this system.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
