كشف الأجسام Object Detection في Frigate: تنبيهات أدق

لنفرض أن شركتك الناشئة ركبت Frigate على كاميرات المستودع كما في دليل Frigate، وكان الطلب الذي من أجله اخترتم Frigate دون غيره واضحاً: «أريد تنبيهاً على هاتفي عندما يقترب شخص من باب المستودع ليلاً، ولا أريد تنبيهاً كلما مرت سيارة في الموقف أو تحركت الأشجار». وبعد أسبوع من التشغيل جاء الواقع مختلفاً: الكاميرا التي تنظر إلى الموقف أرسلت تنبيهات كثيرة عن أشخاص يمشون بين السيارات، والكاميرا البعيدة لم تر شخصاً واحداً مع أن التسجيل يظهر عاملاً يمر أمام الباب، وصفحة النظام في Frigate تكتب بلون أحمر أن الكاشف بطيء، وأن أغلب الإطارات تتخطى دون تحليل. فالبرنامج يعمل، ولكن الذي يجعله مفيداً، أي دقة الكشف وقلة الإزعاج، يحتاج فهماً لما يحدث داخله.

وفي هذا المقال نفتح هذا الصندوق خطوة خطوة، ونجرب على Frigate 0.18.2 بكاميرا تصور موقف سيارات مزدحماً أمام متجر، فيه أشخاص وسيارات في كل لحظة، ونقيس أثر كل إعداد بالأرقام: دقة الكشف، والأقنعة، والمناطق، والمرشحات، ثم نجيب عن السؤال الذي يسأله كل من وصل إلى هذه النقطة: هل أشتري Coral أو بطاقة رسومية، وأي مسرع يناسبني؟

وسوف نناقش في هذا المقال ما يلي:

• لماذا لا يكفي كشف الحركة، وكيف يصل Frigate من إطار فيديو إلى تنبيه في ثماني خطوات، ومعنى درجة الثقة.
• النماذج الموجودة داخل الصورة، وما الذي تعرفه ولا تعرفه، ومتى تحتاج نموذجاً آخر مثل YOLOv9.
• ثلاث تجارب على نفس الكاميرا: دقة الكشف 640×360 مقابل 1280×720، ثم القناع والمنطقة والمرشحات معاً.
• السيارات الواقفة، والتعرف على الوجوه واللوحات، والمشكلة التي واجهناها: كاشف لم يبدأ العمل.
• المسرعات: لماذا لم يعد Coral موصى به، وما الأرقام المنشورة ل Intel وHailo وNVIDIA، وكيف تمرر الجهاز إلى ال Container.
• طريقة عملية لضبط كاميرا جديدة، وقائمة تحقق.

لماذا لا يكفي كشف الحركة وحده؟

قبل أن نكمل، لنضع المشكلة في مكانها الصحيح، لأن أغلب الناس يأتون إلى Frigate بعد تجربة سيئة مع كشف الحركة في جهاز NVR جاهز. فكشف الحركة يقول لك «تغيرت بعض البكسلات»، ولا يقول ما الذي تغير، فالريح التي تحرك الشجرة، والغيمة التي تمر أمام الشمس، والقطة، والمطر، وأضواء السيارة ليلاً، والحشرة على العدسة تحت ضوء IR، كلها حركة. وفي مقال التخزين من هذه المرحلة قسنا كاميرا خارجية «هادئة» فوجدنا أن الصورة لا تسكن في أي ثانية تقريباً، أي أن تنبيه الحركة في كاميرا كهذه إما يرن طوال اليوم، وإما تخفض حساسيته حتى لا يرى الشخص الحقيقي. والنتيجة المعروفة أن الناس يطفئون التنبيهات بعد أسبوع، ويعود النظام إلى مسجل لا ينظر إليه أحد إلا بعد وقوع الحادثة.

وكشف الأجسام يضيف السؤال الناقص: ما الذي تحرك؟ فبدل «تغيرت بكسلات» يصبح «ظهر شخص بثقة 89% عند مدخل المتجر في الثانية الثالثة بعد منتصف الليل»، وهذا تنبيه يستحق أن تقرأه. ولكن تذكر أن النموذج يخطئ أيضاً، فقد يرى في ظل أو كيس قمامة شخصاً بثقة 60%، أو يفوت شخصاً بعيداً في الظلام، لذلك ما نفعله في بقية المقال ليس «تفعيل الذكاء الاصطناعي»، وإنما ضبط كل خطوة حتى يرى النموذج المكان الصحيح بالدقة الصحيحة، وحتى تصلك من نتائجه التي تهمك فقط.

من الإطار إلى التنبيه: ماذا يحدث داخل Frigate؟

الطريقة البسيطة لكشف الأشخاص أن تمرر كل إطار من كل كاميرا على نموذج ذكاء اصطناعي، ولكن كاميرا واحدة بخمسة إطارات في الثانية تعني 432 ألف إطار في اليوم، وثماني كاميرات تعني أكثر من ثلاثة ملايين، وهذا عمل لا يتحمله جهاز صغير. لذلك يعمل Frigate بطريقة مختلفة تبينها الصورة التالية:

1. الإطار: Frigate يفك البث الذي أعطيته دور detect، ويصغره إلى الدقة التي كتبتها في detect.width وdetect.height، بعدد الإطارات في detect.fps.
2. كشف الحركة Motion Detection: مقارنة رخيصة بين الإطار والذي قبله في صورة رمادية مصغرة، تعطي صناديق حول المناطق التي تغيرت، ومن إعداداتها كما في صفحة كشف الحركة الحد threshold بقيمة افتراضية 30، أي الفرق الذي يعتبر عنده البكسل متغيراً، وcontour_area بقيمة 10، أي أصغر مساحة تحسب حركة، وlightning_threshold بقيمة 0.8، أي أن تغير أكثر من 80% من الصورة مرة واحدة، مثل البرق أو إضاءة مفاجئة، يوقف تحليل الحركة حتى يعيد ضبط نفسه.
3. المناطق للنموذج Regions: حول كل مجموعة حركة يقص Frigate مربعاً، ثم يصغره إلى حجم مدخل النموذج، وهو 300×300 في النموذج الموجود في الصورة.
4. الكاشف Detector: يشغل النموذج على المربع، فيعيد صناديق لكل جسم مع تصنيفه، مثل شخص أو سيارة، ودرجة ثقة بين 0 و1.
5. التتبع Tracking: يربط الصندوق في هذا الإطار بالصندوق نفسه في الإطار السابق، فيعطي كل جسم رقماً واحداً طوال ظهوره، ويعرف أنه تحرك أو وقف.
6. المرشحات Filters: تستبعد ما لا يصدق: درجة أقل من min_score، أو صندوق أصغر من min_area، ولا يعتبر الجسم حقيقياً حتى يصل وسيط درجاته إلى threshold.
7. المناطق Zones: تسأل هل دخل الجسم منطقة رسمتها، مثل مدخل المتجر.
8. المراجعة Review: تحول النشاط إلى عنصر مراجعة، إما تنبيه Alert تريد أن تراه فوراً، أو اكتشاف Detection تراجعه عند الحاجة، وهو الذي ينشر عبر MQTT ويصل إلى الهاتف.

والنقطة الأهم في هذا التسلسل أن النموذج لا يرى الصورة كاملة أبداً، وإنما يرى المربعات حول الحركة فقط، وهذا ما يجعل Frigate يعمل على عتاد صغير، وهو أيضاً سبب أخطاء كثيرة: فالشخص الذي يقف ساكناً لا يولد حركة، والحركة الكثيرة في الأشجار تولد مربعات كثيرة يضيع عليها الكاشف وقته، والجسم الصغير جداً في مربع كبير يصغر إلى 300×300 فيصبح بضع نقاط لا يعرفها النموذج.

النموذج: ما الذي يعرفه، وما الذي لا يعرفه؟

صورة Frigate تحمل نماذج جاهزة، وهذا ما وجدناه داخل الصورة 0.18.2 نفسها:

docker run --rm --entrypoint sh ghcr.io/blakeblackshear/frigate:0.18.2 -c \
  'ls -la / | grep -iE "model|tflite|labelmap"; ls -la /openvino-model /labelmap'

-rw-r--r--   1 root root    4965 Oct  6 12:38 audio-labelmap.txt
-rwx------   1 root root 4126810 Feb 23  2023 cpu_audio_model.tflite
-rw-r--r--   1 root root 4281768 Oct  6 12:40 cpu_model.tflite
-rw-r--r--   1 root root 5371304 Oct  6 12:40 edgetpu_model.tflite
drwxr-xr-x   2 root root    4096 Oct 15 12:02 labelmap
-rw-r--r--   1 root root    1054 Oct  6 12:38 labelmap.txt
drwxr-xr-x   2 root root    4096 Oct  6 12:41 openvino-model
/labelmap:
total 16
drwxr-xr-x 2 root root 4096 Oct 15 12:02 .
drwxr-xr-x 1 root root 4096 Oct 28 15:13 ..
-rw-r--r-- 1 root root  928 Oct 15 12:02 coco-80.txt
-rw-r--r-- 1 root root 1054 Oct 15 12:02 coco.txt

/openvino-model:
total 9132
drwxr-xr-x 2 root root    4096 Oct  6 12:41 .
drwxr-xr-x 1 root root    4096 Oct 28 15:13 ..
-rw-r--r-- 1 root root     715 Oct  6 12:41 coco_91cl_bkgr.txt
-rw-r--r-- 1 root root 8986090 Oct  6 12:41 ssdlite_mobilenet_v2.bin
-rw-r--r-- 1 root root  349666 Oct  6 12:41 ssdlite_mobilenet_v2.xml

في المخرج أعلاه لاحظ التالي:

• ثلاثة نماذج للصور بحجم أربعة إلى تسعة ميجابايتات: cpu_model.tflite لكاشف المعالج العادي، وedgetpu_model.tflite المترجم خصيصاً لمسرع Coral، والنموذج ssdlite_mobilenet_v2 بصيغة OpenVINO، وهو الذي استخدمناه. والثلاثة من عائلة MobileNet SSD، وهي نماذج صغيرة وسريعة صممت للأجهزة الضعيفة، ودقتها مع الأجسام الصغيرة والبعيدة محدودة.
• قوائم التصنيفات Labelmaps من مجموعة بيانات COCO، فيها 80 أو 91 صنفاً، مثل الشخص والسيارة والدراجة والقطة والكلب، والنموذج لا يعرف إلا ما في هذه القائمة، فلا يعرف مثلاً «شاحنة توصيل» من «سيارة».
• نموذج للصوت cpu_audio_model.tflite، لأن Frigate يستطيع أن يكشف أصواتاً مثل النباح وصفارة الإنذار إذا فعلت ذلك.

ومن قائمة التصنيفات تختار في objects.track ما يتتبعه Frigate لكل كاميرا، والقاعدة أن تتبع ما تحتاج إليه فقط، لأن كل صنف إضافي يعني أجساماً إضافية في المراجعة وفي قاعدة البيانات، وقد يعني أخطاء إضافية، فالنموذج الصغير قد يرى في كيس أسود كلباً، وفي ظل طويل شخصاً. ففي المستودع يكفي الشخص والسيارة، وربما الدراجة النارية عند البوابة، أما في حديقة بيت فقد تضيف الكلب والقطة حتى تعرف من الذي يحفر في الحديقة ليلاً. والتصنيف الذي تتبعه شيء، والتصنيف الذي يصنع تنبيهاً شيء آخر، فالسيارة في تجربتنا متتبعة، ولكنها في review.detections لا في review.alerts، أي أنك تجدها عندما تبحث، ولا تصلك عنها رسالة.

وعندما تحتاج دقة أعلى من MobileNet، يذكر توثيق الكواشف نماذج أحدث وأكبر من عائلات YOLOv9 وYOLO-NAS وRF-DETR، تعمل عبر الكاشف ONNX، وأن OpenVINO يكتشف ويستخدم تلقائياً مع ONNX في الصورة الافتراضية. ونموذج YOLOv9 مثلاً ليس داخل الصورة، والتوثيق يعطي طريقة لتصديره بنفسك إلى ملف ONNX عبر docker build يحمل مستودع النموذج وأوزانه، ثم تضعه في /config/model_cache/ وتغير قسم model إلى model_type: yolo-generic مع أبعاد المدخل التي صدرت بها، 320 أو 640. وتذكر أن النموذج الأكبر أدق ولكنه أبطأ، وصفحة العتاد التي سنعود إليها تعطي أزمنته على كل جهاز. وFrigate يقدم أيضاً خدمة مدفوعة اختيارية اسمها Frigate+ لنماذج مدربة على صور الكاميرات، والبرنامج يعمل كاملاً دونها.

ماذا تعني درجة الثقة؟

كل صندوق يعيده النموذج يحمل رقماً بين 0 و1 يسمى الدرجة Score، وهي ثقة النموذج في أن هذا الصندوق من هذا الصنف، وليست احتمالاً بالمعنى الرياضي الدقيق، ولا تعني 0.8 أن الشخص موجود في 80% من الحالات. وFrigate لا يحكم من إطار واحد، فالتوثيق يشرح أن الدرجة في كل إطار تقارن ب min_score، فإذا كانت أقل منه تعامل كصفر في ذلك الإطار، ثم يحسب «الدرجة المحسوبة» Computed Score وهي وسيط آخر الدرجات، ويعتبر الجسم حقيقياً فقط عندما يصل هذا الوسيط إلى threshold. ومثال التوثيق بقيم 0.6 و0.85 يبين أن إطاراً واحداً بدرجة 0.55 يهمل، وأن الجسم لا يعتمد إلا في الإطار الرابع عندما يصل الوسيط إلى 0.875. والفائدة من الوسيط أن صندوقاً خاطئاً يظهر في إطار واحد بدرجة عالية لا يكفي وحده لصنع تنبيه، وأن شخصاً حقيقياً تنخفض درجته في إطار بسبب ظل لا يختفي. لذلك عندما تقرأ في نتائجنا أن وسيط أعلى درجة للأشخاص ارتفع من 0.73 إلى 0.89 بعد المرشحات، فهذا يعني أن ما بقي هو الأشخاص الذين بقي النموذج واثقاً منهم عبر إطارات متعددة.

التجربة: نفس الكاميرا بثلاثة إعدادات

كاميرا التجربة هي مقطع لموقف سيارات مزدحم أمام متجر من هيئة المتنزهات الوطنية الأمريكية في الملكية العامة، مدته 30.73 ثانية ويعاد في حلقة، ضغطناه مقدماً إلى بث رئيسي بدقة 1080p للتسجيل، وبث للكشف بدقة 720p و10 إطارات، وينشرهما خادم MediaMTX كما في مقالات المرحلة، بملف mediamtx.yml:

# The fake camera for this article: a busy public-domain car park (people and cars all the time),
# main stream 1080p 15 fps for recording, sub stream 720p 10 fps for detection, both without re-encoding.
paths:
  gate:
    runOnInit: ffmpeg -re -stream_loop -1 -i /samples/tf-main.mp4 -c copy -f rtsp rtsp://localhost:8554/gate
    runOnInitRestart: yes
  gate_sub:
    runOnInit: ffmpeg -re -stream_loop -1 -i /samples/tf-sub.mp4 -c copy -f rtsp rtsp://localhost:8554/gate_sub
    runOnInitRestart: yes

وثلاث تجارب، كل منها من حالة نظيفة: Container جديد، وVolume جديد للتسجيلات، وقاعدة بيانات Frigate محذوفة، ثم دقيقة حتى يستقر، ثم أربع دقائق من قراءة docker stats كل 15 ثانية، ثم أرقام Frigate من واجهته البرمجية:

• A: الكشف بدقة 640×360 بخمسة إطارات في الثانية، بإعدادات الأجسام الافتراضية.
• B: الكشف بدقة 1280×720، وكل شيء آخر كما هو.
• C: مثل B، مع قناع حركة على الأشجار والتلال والشجيرات أمام الكاميرا، ومنطقة اسمها store_entrance أمام المتجر، والتنبيه فقط لشخص دخلها، ومرشحات أشد للأشخاص.

والإعداد يولده سكربت صغير make-config.py، وهذا الجزء الخاص بالكاميرا في التجربة C كما كتبه:

cameras:
  gate:
    ffmpeg:
      inputs:
        - path: rtsp://scv-cam:8554/gate
          roles: [record]
        - path: rtsp://scv-cam:8554/gate_sub
          roles: [detect]
    detect:
      enabled: true
      width: 1280
      height: 720
      fps: 5
    objects:
      track: [person, car]
      filters:
        person:
          min_score: 0.6
          threshold: 0.75
          min_area: 1500
    motion:
      mask:
        hills:
          friendly_name: "Trees and hills"
          coordinates: "0,0,1,0,1,0.22,0,0.22"
        bushes:
          friendly_name: "Bushes in front of the camera"
          coordinates: "0,0.45,0.42,0.45,0.42,1,0,1"
    zones:
      store_entrance:
        coordinates: 0,0.25,0.45,0.25,0.45,0.47,0,0.47
        objects: [person]
    review:
      alerts:
        labels: [person]
        required_zones: [store_entrance]
      detections:
        labels: [person, car]

version: 0.18-0

وفي الإعداد أعلاه ثلاث ملاحظات كلفتنا وقتاً حتى وصلنا إليها:

• السطر detect.enabled: true ضروري، ففي تشغيلنا الأول دونه كان /api/stats يكتب "detection_enabled": false للكاميرا، ولا يكشف شيئاً، مع أن الواجهة تعرض البث بشكل طبيعي، والإعداد الذي في دليل Frigate السابق كان يكتبه صراحة.
• الأقنعة في هذا الإصدار قائمة بأسماء، لكل قناع اسم وحقل coordinates، كما في صفحة الأقنعة. وفي المحاولة الأولى كتبناها قائمة نصوص كما في الإصدارات القديمة، فرفض Frigate الملف بالرسالة Key: cameras -> gate -> motion -> mask وMessage : Input should be a valid dictionary، ثم بدأ في الوضع الآمن Safe Mode دون كاميرات.
• الإحداثيات نسبية من 0 إلى 1، فالنقطة 0.45,0.47 تعني 45% من عرض الصورة و47% من ارتفاعها، وبهذا تبقى صحيحة إذا غيرت دقة الكشف.

تشغيل كل تجربة

السكربت run-exp.sh ينفذ التجربة من البداية، ونشغله ثلاث مرات بالحروف a وb وc:

# Run one experiment from a clean state: fresh Frigate container, media volume and database, 1 min warm-up,
# then 4 min of CPU sampling, then the API numbers.
exp=$1
python make-config.py $exp
docker rm -f scv-frigate >/dev/null 2>&1; docker volume rm scv-frigate-media >/dev/null 2>&1
rm -f config/frigate.db config/frigate.db-* config/backup.db  # the database lives in /config: remove it so each experiment starts empty
docker run -d --name scv-frigate --network scv-frnet --shm-size=256m -p 127.0.0.1:19175:8971 \
  -v "$PWD/config:/config" -v scv-frigate-media:/media/frigate --tmpfs /tmp/cache:size=1000000000 \
  ghcr.io/blakeblackshear/frigate:0.18.2 >/dev/null
until docker exec scv-frigate sh -c 'curl -sf http://127.0.0.1:5000/api/stats >/dev/null' 2>/dev/null; do sleep 5; done
sleep 60
echo "### experiment $exp"
sh stats.sh 16 scv-frigate
sh measure.sh

ولاحظ سطر حذف قاعدة البيانات، فقاعدة Frigate frigate.db تعيش في مجلد /config لا في مجلد التسجيلات، وفي جولتنا الأولى حذفنا ال Volume فقط، فتراكمت الأجسام من تجربة إلى التي بعدها، وظهرت أعداد في التجربة الثالثة أكبر بكثير مما يمكن أن يحدث في أربع دقائق، فعرفنا السبب وأعدنا التجارب كلها. والسكربت measure.sh يقرأ من الواجهة البرمجية الإحصاءات، والأجسام المتتبعة بحسب نوعها مع وسيط وأعلى درجة ثقة، وعناصر المراجعة:

docker exec scv-frigate sh -c '
curl -s http://127.0.0.1:5000/api/stats | jq "{camera: .cameras.gate | {camera_fps, process_fps, skipped_fps, detection_fps}, inference_ms: .detectors.ov.inference_speed, detector_cpu: .detectors.ov.cpu}"
echo "### tracked objects (label, count, median and max top_score)"
curl -s "http://127.0.0.1:5000/api/events?limit=2000" | jq -r "group_by(.label)[] | [.[0].label, length, (map(.data.top_score) | sort | .[length/2|floor]), (map(.data.top_score) | max)] | @tsv"
echo "### review items by severity"
curl -s "http://127.0.0.1:5000/api/review?limit=2000" | jq -r "group_by(.severity)[] | \"\(.[0].severity): \(length)\""'

التجربة A مقابل B: دقة الكشف

المخرج في التجربة A، أي الكشف بدقة 640×360:

scv-frigate      avg CPU  245.6%  avg RAM  1052.8 MiB  (16 samples)
{
  "camera": {
    "camera_fps": 5.1,
    "process_fps": 2.3,
    "skipped_fps": 2.8,
    "detection_fps": 12.8
  },
  "inference_ms": 58.3,
  "detector_cpu": "178.6"
}
### tracked objects (label, count, median and max top_score)
car	84	0.83221435546875	0.9495227038860321
person	4	0.7917132377624512	0.7972893416881561
### review items by severity
alert: 3
detection: 1

وفي التجربة B، أي الكشف بدقة 1280×720:

scv-frigate      avg CPU  279.7%  avg RAM  1138.6 MiB  (16 samples)
{
  "camera": {
    "camera_fps": 5.1,
    "process_fps": 1,
    "skipped_fps": 4.2,
    "detection_fps": 15.3
  },
  "inference_ms": 55.48,
  "detector_cpu": "190.1"
}
### tracked objects (label, count, median and max top_score)
car	66	0.8372654616832733	0.9834562242031097
person	13	0.7328679263591766	0.8252787292003632
### review items by severity
alert: 1

في المخرجين أعلاه لاحظ التالي:

• عدد الأشخاص المتتبعين قفز من 4 إلى 13 بمضاعفة دقة الكشف، والسبب أن الأشخاص في هذا المشهد صغار وبعيدون، يمشون عند المتجر وبين السيارات، وفي صورة 640×360 يصبح الشخص البعيد بضع نقاط، ثم يصغر مرة أخرى عندما يقص Frigate المربع حوله إلى 300×300، فلا يعرفه النموذج.
• عدد السيارات لم يزد، بل كان 84 في A و66 في B، وهذا لا يعني أن الدقة الأعلى أسوأ مع السيارات، وإنما أن السيارات كبيرة وواضحة في الدقتين، والعدد يتأثر بانقطاع التتبع وتكرار المقطع كل 30 ثانية، فلا تقرأ الفرق الصغير في السيارات كنتيجة.
• زمن الكشف الواحد inference_ms قرابة 55 إلى 58 مللي ثانية في الحالتين، لأن النموذج يرى دائماً مربعاً 300×300 مهما كانت دقة الكشف، والذي يتغير هو عدد المربعات، فارتفع detection_fps من 12.8 إلى 15.3، والمعالج من قرابة 2.5 نواة إلى قرابة 2.8 نواة.
• والرقم الأهم skipped_fps: في A تخطى Frigate 2.8 من كل 5 إطارات، وفي B تخطى 4.2، أي أن أكثر من 80% من الإطارات لم تحلل أصلاً، والسبب أن الكاشف على المعالج لا يلحق، فكل كشف 55 مللي ثانية يعني قرابة 18 كشفاً في الثانية في أحسن الأحوال، وصفحة الواجهة كانت تكتب أثناء التجربة Ov is slow (52.62 ms). والإطار الذي يتخطى قد يكون الإطار الوحيد الذي ظهر فيه الشخص.
• عدد التنبيهات قليل، 3 ثم 1، لأن المراجعة تجمع النشاط المتصل في عنصر واحد، والمشهد مزدحم لا يهدأ، فكل تنبيه هنا فترة طويلة فيها أشخاص كثيرون.

التجربة C: القناع والمنطقة والمرشحات

الصورة التالية تبين القناعين والمنطقة على إطار من نفس الكاميرا، بنفس الإحداثيات النسبية التي في الإعداد:

والمخرج في التجربة C، مع النتيجة الإضافية لعدد الأشخاص الذين دخلوا المنطقة:

scv-frigate      avg CPU  278.6%  avg RAM  1185.1 MiB  (16 samples)
{
  "camera": {
    "camera_fps": 5,
    "process_fps": 1.3,
    "skipped_fps": 3.7,
    "detection_fps": 14.1
  },
  "inference_ms": 56.74,
  "detector_cpu": "186.4"
}
### tracked objects (label, count, median and max top_score)
car	74	0.8507154583930969	0.9849616587162018
person	6	0.8928693532943726	0.9386708736419678
### review items by severity
detection: 1
persons tracked: 6, persons that entered store_entrance: 0
detection	car,person

في المخرج أعلاه لاحظ التالي:

• المرشحات خفضت الأشخاص من 13 إلى 6، ورفعت وسيط درجة الثقة من 0.73 إلى 0.89، أي أن ما بقي هو الأشخاص الذين كان النموذج واثقاً منهم، وما استبعد هو صناديق صغيرة أو بثقة أقل من 0.6. وهذا بالضبط عمل المرشحات كما يشرحها توثيق المرشحات: الدرجة الأقل من min_score تهمل في ذلك الإطار، والجسم لا يعتبر حقيقياً حتى يصل وسيط آخر درجاته إلى threshold، والمساحة الأقل من min_area بالبكسل تستبعد. والثمن أن شخصاً بعيداً حقيقياً قد يستبعد أيضاً، لذلك ضبط المرشحات موازنة بين الإزعاج والفوات، لا قيمة صحيحة واحدة.
• لم يدخل أي شخص من الستة المنطقة store_entrance بحسب Frigate، فصارت التنبيهات صفراً، وتحول كل النشاط إلى عنصر اكتشاف واحد فيه سيارات وأشخاص. وهذا هو المطلوب في المستودع: لا تنبيه إلا إذا اقترب أحد من الباب. ولكن انتبه لسبب الصفر: توثيق المناطق يقول إن وجود الجسم في المنطقة يحسب بالنقطة السفلية في منتصف صندوقه، أي قدميه، لا بتداخل الصندوق، وإن الجسم يجب أن يبقى فيها ثلاثة إطارات متتالية افتراضياً، وهذا ما يسمى Inertia. فإذا رسمت المنطقة على جدار المتجر بدل الأرض التي يقف عليها الناس أمامه، فلن تتحقق أبداً، لذلك ارسم المنطقة على الأرض حيث تقع الأقدام، وجربها بالمشي فيها بنفسك.
• القناع لم يخفض المعالج، فبقي قرابة 2.8 نواة، والسبب أن الكاشف هو الذي يستهلك أغلب المعالج، قرابة 1.9 نواة وحده، وهو مشغول بالمربعات حول السيارات والناس في الموقف، والقناع أزال المربعات في الأشجار فقط. وفائدة القناع الأكبر ليست في المعالج هنا، وإنما في أن الكاشف لا يضيع كشوفه المحدودة على أوراق الشجر، وأن حركة الشجر لا تسجل كنشاط في التسجيل عند الحركة.

والصورة التالية تجمع التجارب الثلاث:

انظر بعين Frigate: صورة التصحيح

أفضل أداة لفهم ما يحدث في كاميرا معينة هي صورة التصحيح، أي آخر إطار مع ما رسمه Frigate عليه، وتطلبها من الواجهة البرمجية بخيارات تحدد ما يرسم:

docker exec scv-frigate sh -c 'curl -s "http://127.0.0.1:5000/api/gate/latest.jpg?bbox=1&motion=1&regions=1&timestamp=0&height=720" -o /tmp/l.jpg'
docker cp scv-frigate:/tmp/l.jpg latest.jpg

والصورة التالية هي ما أعاده Frigate أثناء التجربة B:

في الصورة أعلاه لاحظ أن الحركة الحمراء في الأشجار والشجيرات أكثر بكثير من الحركة الحقيقية للناس والسيارات، وكل مربع منها قد يصبح منطقة خضراء يصرف عليها الكاشف 55 مللي ثانية، وهذا سبب القناع في التجربة C. ولاحظ أيضاً الأشخاص عند المتجر بدرجات ثقة قريبة من 59%، أي تحت min_score الذي وضعناه في C، وهؤلاء هم الذين اختفوا من العدد بعد المرشحات، فإذا كانوا مهمين لك فخفض الحد، أو قرب الكاميرا، أو كبر الدقة. ولكي تقيس نسبة الحركة في مشهدك قبل أن تضبط أي شيء، قسنا بأداة ffmpeg نسبة البكسلات التي تتغير بأكثر من 30 بين إطارين بخمسة إطارات في الثانية، أي نفس فكرة كشف الحركة في Frigate بقيمته الافتراضية:

# What share of the picture changes between two frames at 5 fps? Grey, small frame, a pixel counts as
# "changed" when it differs by more than 30 (Frigate's default motion threshold), then the share of changed pixels.
ffmpeg -hide_banner -i /samples/tf-sub.mp4 -vf "fps=5,scale=320:180,format=gray,tblend=all_mode=difference,lut=y='if(gt(val,30),255,0)',signalstats,metadata=print:key=lavfi.signalstats.YAVG:file=/tmp/m.txt" -f null - 2>/dev/null
grep -o 'YAVG=[0-9.]*' /tmp/m.txt | cut -d= -f2 | awk '{ s=$1/255; n++; if (s>0.8) big++; if (s>m) m=s; t+=s } END { printf "frames: %d, average changed share: %.1f%%, max: %.1f%%, frames above 80%%: %d\n", n, t/n*100, m*100, big }'

frames: 153, average changed share: 9.1%, max: 19.5%, frames above 80%: 0

أي أن قرابة 9% من الصورة تتغير في المتوسط بين إطارين، وأعلى قيمة 19.5%، ولا يوجد إطار واحد يقترب من حد البرق 80%، فهذا مشهد مزدحم بحركة حقيقية لا بتغيرات إضاءة، وكل ما يمكن فعله هو توجيه الكاشف إلى المكان الصحيح.

السيارات الواقفة والأجسام الساكنة

في المستودع والموقف أغلب السيارات واقفة أغلب الوقت، فلو عاملها Frigate كأجسام جديدة كل ثانية لامتلأت المراجعة والقرص بلا فائدة. لذلك يتعامل مع الأجسام الساكنة بطريقة خاصة يشرحها توثيق الأجسام الساكنة: الجسم الذي يبقى ثابتاً تقريباً عدداً من الإطارات يعتبر ساكناً، وبعد ذلك لا يشغل عليه الكشف باستمرار، وإنما كل عدد من الإطارات ليتأكد أنه ما زال موجوداً، والقيمة الافتراضية لهذه الفترة في الواجهة 50، ويعود الكشف المستمر عليه عندما تظهر حركة داخله أو يغير مكانه. وهذا ما يجعل الموقف المليء بالسيارات الواقفة لا يستهلك الكاشف إلا قليلاً.

ولكن هذه الميزة لها جهة أخرى يجب أن تعرفها: الشخص الذي يقف ساكناً عند الباب طويلاً يصبح أيضاً جسماً ساكناً، وهذا مقبول لأنه تتبع منذ دخل، أما الشخص الذي يظهر في الصورة دون أن يتحرك أصلاً، مثل شخص كان واقفاً عندما تشغل النظام، فلا يولد حركة ولا يرسل إلى النموذج، وهذا من حدود الطريقة التي ذكرناها في التسلسل. وفي تجربتنا لم نقس الأجسام الساكنة لأن المقطع يعود كل 30 ثانية فتبدو السيارات وكأنها وصلت من جديد في كل دورة، وهذا أيضاً سبب أن أعداد السيارات في نتائجنا أكبر بكثير من السيارات الموجودة فعلاً في الصورة.

التعرف على الوجوه واللوحات: ميزة أم مسؤولية؟

الإصدارات الحديثة من Frigate تضيف ما يسميه التوثيق إثراءات Enrichments، منها التعرف على الوجوه وقراءة لوحات السيارات، وكلاهما معطل افتراضياً ويحتاج تفعيلاً وموارد إضافية. وهنا الفرق الذي ذكرناه في مقال الخصوصية من هذه المرحلة: كشف «شخص» يقلل التنبيهات الكاذبة، أما التعرف على «من هو هذا الشخص» فمعالجة لبيانات السمات الحيوية التي يعتبرها نظام حماية البيانات الشخصية بيانات حساسة، واللائحة التنفيذية لنظام كاميرات المراقبة الأمنية تقصر تحليل التسجيلات الذي يتعرف على الهوية على الجهات المصرح لها. لذلك في منشأة تجارية لا تفعل هذه الخصائص لأنها موجودة، وإنما بعد أن تعرف ما تسمح به الأنظمة لحالتك، وقراءة اللوحات لبوابة سكن أو منشأة لها مقالها الخاص في بوابة تفتح تلقائياً بقراءة لوحة السيارة.

ما واجهناه: كاشف لم يبدأ العمل

في عدة تشغيلات من التجارب حدث شيء غريب: الواجهة تعمل، والبث يظهر، وصورة التصحيح ترسم مربعات الحركة الحمراء، ولكن لا يوجد أي جسم متتبع، والإحصاءات بعد دقيقة كانت هكذا:

"detection_enabled": true
{
  "ov": {
    "inference_speed": 10,
    "detection_start": 0,
    "pid": 814,
    "cpu": "0.0",
    "mem": "0.9"
  }
}

والعلامة هنا أن inference_speed بقي عند 10 بالضبط، وهي القيمة الابتدائية قبل أول كشف، وdetection_start صفر، واستهلاك الكاشف للمعالج صفر، أي أن عملية الكاشف تعمل ولكنها لم تستقبل أي مربع. ولم يكن السبب في الإعداد، فنفس الملف عمل في تشغيل وفشل في آخر، وإعادة تشغيل ال Container بالأمر docker restart لم تصلحه في المرة التي جربناها، أما إعادة إنشائه من جديد فأصلحته بعد محاولة أو أكثر، وفي إحدى المرات احتجنا ست محاولات. لذلك أضفنا إلى سكربت التجربة فحصاً بعد الدقيقة الأولى يعيد إنشاء ال Container حتى يصبح detection_fps أكبر من صفر:

# In several runs the detector never received a frame (detection_fps 0, inference_speed stuck at its initial 10 ms)
# although motion boxes were drawn; recreating the container fixed it. Check, and retry up to 6 times.
for try in 1 2 3 4 5 6; do
  d=$(docker exec scv-frigate sh -c 'curl -s http://127.0.0.1:5000/api/stats | jq ".cameras.gate.detection_fps"')
  echo "start check $try: detection_fps=$d"
  [ "$d" != "0" ] && break
  # remove the container, the volume and the database, then start it again and wait 60 s
done

ولم نعرف السبب الدقيق، ولا نريد أن نخمنه، والدرس العملي لمن يشغل Frigate في الإنتاج أن تراقب هذين الرقمين بعد كل تشغيل وكل ترقية: إذا بقي detection_fps صفراً في مشهد فيه حركة، وبقي inference_speed عند 10، فالكشف لا يعمل مهما بدت الواجهة طبيعية، والتنبيه على ذلك جزء من المراقبة التي سنبنيها في مقال ربط الكاميرات بالمنزل الذكي. وإذا تكرر عندك فاقرأ ملاحظات الإصدار وقضايا المستودع، وأبلغ المشروع بسجلاتك.

المسرعات: هل تحتاج Coral أو GPU؟

رأينا في التجربة أن المعالج وحده، بعد أن فقد أكثر من 80% من الإطارات، كان يصرف قرابة 1.9 نواة على كاشف واحد لكاميرا واحدة، وهذا هو السبب الذي يجعل ملف المشروع يوصي بشدة بمسرع. والمسرع يأخذ تشغيل النموذج عن المعالج، فيصبح زمن الكشف الواحد بضع مللي ثوان، والصورة التالية تجمع أرقاماً من صفحة العتاد الموصى به في توثيق Frigate، مع رقمنا:

وفي هذه الأرقام والتوصيات لاحظ التالي:

• Coral لم يعد الخيار الأول: صفحة العتاد تقول صراحة إن Coral لم يعد موصى به لتركيبات Frigate الجديدة، وإن Frigate سيستمر في دعمه، وإنه يبقى من أكثر الخيارات كفاءة في استهلاك الكهرباء، وتنصح به فقط لمن يحتاج استهلاكاً منخفضاً جداً. والسبب أن نماذجه القديمة مقيدة بما يترجم لشريحته، بينما الخيارات الأخرى تشغل نماذج أحدث وأدق مثل YOLOv9.
• معالجات Intel الحديثة غالباً تكفي: البطاقة الرسومية المدمجة في معالج Intel مع OpenVINO تعطي قرابة 15 مللي ثانية مع MobileNetV2 حتى في الجيل السابع HD 630، ووحدة NPU في المعالجات الأحدث قرابة 6 مللي ثانية، فجهاز صغير بمعالج Intel حديث قد لا يحتاج أي مسرع إضافي. وصفحة العتاد تذكر جهازاً صغيراً بمعالج N100 كخيار مفضل للمؤلف لعدة كاميرات 1080p بنشاط منخفض إلى متوسط.
• Hailo بديل Coral: وحدة Hailo-8 قرابة 6 مللي ثانية مع ssd mobilenet v1 و7 مع YOLOv6n، والنسخة Hailo-8L قرابة 10 و11، والصورة التالية لوحدة Hailo مركبة على Raspberry Pi 5.
• بطاقات NVIDIA: تشغل نماذج أكبر مثل YOLOv9 بسرعة، فبطاقة RTX 3050 قرابة 8 مللي ثانية مع YOLOv9 t-320، وهي الخيار الطبيعي إذا كانت عندك بطاقة في السيرفر أصلاً، مع صورة Frigate الخاصة stable-tensorrt.
• قارن داخل النموذج نفسه: الأرقام في الصورة لنماذج مختلفة، فلا تقارن زمن MobileNet على جهاز بزمن YOLOv9 على جهاز آخر، وصفحة العتاد تعطي لكل جهاز الأزمنة بحسب النموذج.

حساب ميزانية الكشف للمستودع

لنحول الأرقام إلى قرار للشركة بثماني كاميرات. في تجربتنا المزدحمة طلب Frigate قرابة 15 كشفاً في الثانية لكاميرا واحدة، وكل كشف على المعالج أخذ قرابة 55 مللي ثانية، أي أن الكاميرا الواحدة في ذروة نشاطها تحتاج قرابة 15 × 55 = 825 مللي ثانية من الكشف في كل ثانية، وهذا يعني عملياً نواة كاملة تقريباً للكاشف وحده، ولم يلحق مع ذلك، فتخطى أغلب الإطارات. أما مع مسرع زمنه قرابة 6 مللي ثوان، مثل Hailo-8 أو NPU بحسب صفحة العتاد، فالكاميرا الواحدة في الذروة تحتاج قرابة 15 × 6 = 90 مللي ثانية في كل ثانية، والكاميرات الثماني لو كانت كلها في الذروة في نفس اللحظة تحتاج قرابة 720 مللي ثانية، أي أقل من طاقة المسرع الواحد. وفي الواقع لا تكون الكاميرات كلها مزدحمة معاً، فكاميرا الممر الهادئ لا تطلب كشفاً إلا عندما يمر أحد، لذلك الحساب الأهم هو عدد الكاميرات المزدحمة في نفس الوقت، لا عدد الكاميرات كلها.

وهذا الحساب تقريبي عن قصد، لأن عدد الكشوف في الثانية يعتمد على المشهد والأقنعة والدقة، وقد رأينا أنه بقي بين 12.8 و15.3 في تجاربنا الثلاث، لذلك الطريقة الصحيحة أن تشغل الكاميرات أسبوعاً، ثم تقرأ detection_fps لكل كاميرا في أكثر ساعاتها ازدحاماً من صفحة System أو من الواجهة البرمجية، ثم تضرب المجموع في زمن الكشف على المسرع الذي تفكر فيه.

كيف يرى ال Container المسرع؟

المسرع جهاز في السيرفر، وال Container لا يراه حتى تمرره له في قسم devices في ملف Compose، وتوثيق التثبيت يذكر المسارات التالية: /dev/bus/usb لمسرع Coral عبر USB، و/dev/apex_0 لنسخة PCIe بعد تثبيت تعريفها، و/dev/dri/renderD128 لبطاقات Intel وAMD الرسومية، و/dev/accel لوحدات NPU، و/dev/hailo0 لوحدة Hailo. ثم تغير قسم detectors في الإعداد، فبدل device: CPU في OpenVINO تكتب device: GPU أو device: NPU، وتتحقق في صفحة System أن زمن الكشف انخفض. ولاحظ أن التسريع في فك ضغط الفيديو شيء آخر يضبط في ffmpeg.hwaccel_args كما شرحنا في دليل Frigate، وفي مشهد مزدحم مثل تجربتنا يحتاج الاثنان معاً.

وأما عدد الكاميرات التي يتحملها المسرع، فالحساب تقريبي من زمن الكشف: كشف كل 10 مللي ثوان يعني قرابة 100 كشف في الثانية، وهذا مثال التوثيق نفسه لمسرع Coral، فإذا كانت كل كاميرا تحتاج في الذروة 15 كشفاً في الثانية كما في تجربتنا المزدحمة، فالمسرع يكفي قرابة ست كاميرات مزدحمة، وعدداً أكبر بكثير من الكاميرات الهادئة التي لا تحتاج كشفاً إلا عند الحركة.

والليل؟

كل التجارب أعلاه في مقطع نهاري، أما في الليل فالكاميرا تنتقل إلى الأبيض والأسود مع إضاءة IR، وترتفع حساسية الحساس فيزيد الضجيج، كما رأينا في مقال التخزين أن مشهد الضجيج المضاف رفع معدل البت إلى حده الأعلى. وهذا يغير ثلاثة أشياء في الكشف: الضجيج نفسه يولد حركة في كل مكان، فيزيد المربعات المرسلة إلى الكاشف، والأشخاص في الأطراف البعيدة خارج مدى IR يصبحون ظلالاً لا يعرفها النموذج، والحشرات التي تنجذب إلى ضوء IR قرب العدسة قد تظهر كأجسام كبيرة متحركة. لذلك لا تكتف بضبط الكاميرا في النهار، وإنما كرر خطوات الضبط في الليل: صورة التصحيح بالخيار motion=1 لترى كم تتحرك الصورة من الضجيج، وصفحة Explore بعد ليلة كاملة لترى ما الذي ظنه النموذج شخصاً. وأغلب ما يصلحه هو رفع threshold في إعدادات الحركة قليلاً، وإضافة إضاءة خارجية بسيطة عند الباب، وإبعاد الكاميرا عن الأسطح القريبة التي تعكس ضوء IR، كما ذكرنا في مقال المصطلحات.

الإعداد النهائي للمستودع

بعد كل ما سبق، هذا ما نوصي به للشركة، كاميرا كاميرا:

• كاميرا باب المستودع: الكشف على بث بدقة 1280×720 لأن الشخص يجب أن يرى من بعيد قبل أن يصل، ومنطقة door مرسومة على الأرض أمام الباب، والتنبيه للأشخاص فيها فقط، ومرشح min_area يستبعد الصناديق الصغيرة جداً في الشارع البعيد، وقناع على الشارع العام إن كان في الصورة.
• كاميرا منطقة التحميل: منطقتان، واحدة للشاحنة وأخرى للرصيف، والتنبيه لشخص على الرصيف خارج ساعات العمل فقط، وهذا شرط زمني يضاف في Home Assistant كما سنرى في مقال المنزل الذكي، والسيارات اكتشافات لا تنبيهات.
• كاميرات الممرات الداخلية: البث الفرعي يكفي لأن المسافات قصيرة، والتنبيه لأي شخص خارج ساعات العمل، ولا حاجة لمناطق.
• كاميرا الموقف: اكتشافات فقط دون تنبيهات، لأنها مزدحمة دائماً، وفائدتها في البحث بعد الحادثة لا في الإشعار.
• العتاد: مسرع واحد، أو معالج Intel حديث مع OpenVINO على البطاقة المدمجة أو NPU، ثم قراءة skipped_fps بعد أسبوع للتأكد.

طريقة عملية لضبط كاميرا جديدة

بعد التجارب، هذه هي الطريقة التي نقترحها لكل كاميرا تضيفها، بالترتيب:

1. اختر بث الكشف: البث الفرعي إذا كانت الأجسام قريبة وكبيرة، وبثاً بدقة أعلى إذا كانت بعيدة، كما رأينا في الفرق بين 4 و13 شخصاً، وفعل detect.enabled: true صراحة.
2. تحقق أن الكشف يعمل: افتح صورة التصحيح، وانظر في /api/stats إلى detection_fps وinference_speed وskipped_fps.
3. ارسم الأقنعة: على كل ما يتحرك ولا يهمك، الأشجار والسماء وشريط التاريخ على الصورة والشارع العام إن لم يكن من حدود الموقع.
4. ارسم المناطق على الأرض: حيث تقع الأقدام، واجعل التنبيهات تتطلب المنطقة، وجربها بالمشي فيها.
5. اضبط المرشحات بعد أسبوع: افتح صفحة Explore، وانظر إلى الأجسام الخاطئة ودرجاتها ومساحاتها، ثم ارفع min_score أو min_area بقدر ما يستبعدها دون أن يستبعد الحقيقية.
6. قرر بشأن المسرع من الأرقام: إذا بقي skipped_fps كبيراً والمعالج مشغولاً بالكاشف، فالمسرع هو الخطوة التالية، لا تخفيض الدقة.

بعد كل ترقية: تحقق من الكشف لا من الواجهة

خطآن من الأخطاء الثلاثة التي واجهناها في هذه التجربة سببهما تغير في صيغة الإعداد بين الإصدارات: الأقنعة التي صارت قائمة بأسماء، والكشف الذي لم يعمل حتى كتبنا detect.enabled: true صراحة. وهذا طبيعي في مشروع يتطور بسرعة، فكل إصدار رئيسي من Frigate يغير شيئاً في الإعداد أو في الواجهة البرمجية، وملاحظات كل إصدار، مثل ملاحظات 0.18.2، هي المكان الذي تقرأ فيه ذلك قبل أن تحدث. والمشكلة أن أخطاء الإعداد لا تظهر كلها بنفس الطريقة: الخطأ في الصيغة يوقف Frigate ويدخله الوضع الآمن، فتلاحظه فوراً لأن الكاميرات تختفي من الواجهة، أما الإعداد الصحيح صيغة والمختلف معنى، مثل كشف معطل، فيبقي كل شيء يبدو طبيعياً: البث يعمل، والتسجيل يعمل، والواجهة خضراء، والتنبيهات فقط لا تأتي، وقد لا يلاحظ أحد ذلك حتى تقع حادثة ولا يجد تنبيهاً عنها.

لذلك اجعل لكل ترقية قائمة صغيرة بعد التشغيل، لا تأخذ أكثر من خمس دقائق: افتح /api/stats وتأكد أن detection_enabled صحيح لكل كاميرا، وأن detection_fps أكبر من صفر في كاميرا فيها حركة، وأن inference_speed رقم حقيقي لا 10 الثابتة، ثم اطلب صورة التصحيح لكاميرا واحدة وتأكد أن الصناديق تظهر، ثم امش أمام كاميرا الباب وتأكد أن التنبيه وصل إلى هاتفك. وقبل الترقية خذ نسخة من مجلد /config كله، لأن فيه الإعداد وقاعدة البيانات معاً كما رأينا، فإذا احتجت الرجوع إلى الإصدار السابق فالقاعدة القديمة معك. وقد شرحنا أهمية تثبيت رقم الإصدار في الصورة وعدم استخدام stable في دليل Frigate.

أخطاء شائعة

• ترك detect.enabled دون كتابة، ثم الظن أن Frigate يكشف لأن الواجهة تعرض البث.
• الكشف بدقة منخفضة جداً على كاميرا بعيدة، ثم الشكوى من أن Frigate لا يرى الأشخاص.
• رسم المنطقة على الجدار أو السقف، بينما يحسب الوجود بالنقطة السفلية من الصندوق.
• كتابة الأقنعة بالصيغة القديمة بعد الترقية، فيبدأ Frigate في الوضع الآمن دون كاميرات.
• رفع المرشحات حتى تختفي كل التنبيهات الكاذبة، ومعها الحقيقية.
• شراء Coral لتركيب جديد اليوم، والتوثيق نفسه لم يعد يوصي به إلا لمن يحتاج أقل استهلاك للكهرباء.
• عدم مراقبة detection_fps وinference_speed بعد كل تشغيل، فيتوقف الكشف دون أن يعرف أحد.

قائمة تحقق لكل كاميرا

حذف التجربة

docker rm -f scv-frigate scv-cam
docker volume rm scv-frigate-media
docker network rm scv-frnet
rm -f config/frigate.db*

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• Frigate لا يمرر الصورة كاملة على النموذج، وإنما مربعات حول الحركة مصغرة إلى 300×300، لذلك دقة الكشف والأقنعة تحدد ما يراه النموذج أصلاً.
• مضاعفة دقة الكشف من 640×360 إلى 1280×720 رفعت الأشخاص المكتشفين في مشهدنا المزدحم من 4 إلى 13، مقابل زيادة في المعالج من قرابة 2.5 إلى 2.8 نواة.
• المرشحات رفعت وسيط الثقة في الأشخاص من 0.73 إلى 0.89 وخفضت العدد إلى 6، والمنطقة المطلوبة حولت كل النشاط إلى اكتشافات لأن أحداً لم يقف فيها بقدميه.
• الكاشف على المعالج احتاج قرابة 55 مللي ثانية لكل كشف، وتخطى Frigate أكثر من 80% من الإطارات، وهذا هو الرقم الذي يقول لك إنك تحتاج مسرعاً.
• توثيق Frigate لم يعد يوصي ب Coral للتركيبات الجديدة، وOpenVINO على معالج Intel حديث أو NPU أو Hailo أو بطاقة NVIDIA خيارات بأزمنة بين 5 و15 مللي ثانية.
• راقب detection_fps وinference_speed بعد كل تشغيل، فقد صادفنا كاشفاً لم يبدأ العمل وواجهة تبدو طبيعية.

وفي المقال القادم من مرحلة الكاميرات بإذن الله نجرب ZoneMinder كاملاً لمكتب صغير، ثم نربط التنبيهات بالمنزل الذكي Home Assistant. وأقرب المقالات إلى هذا الموضوع على الموقع:

دليلFrigate: تسجيل كاميرات المراقبة على سيرفرك مع كشف الأجسامكيف تثبت Frigate على سيرفرك، وتسجل به كاميرات المراقبة محلياً، ويكشف لك الأشخاص والسيارات دون أن يخرج الفيديو من بيتك.دليلأنواع كاميرات المراقبة وكيف تختار بينهاما الفرق بين أنواع كاميرات المراقبة، وما الذي تحتاجه في الكاميرا حتى تسجلها على جهازك، وكم قرصاً تحتاج للتسجيلات.دليلتشغيل نماذج اللغة على جهازك: كم ذاكرة وأي GPU تحتاج؟كيف تحسب الذاكرة التي يحتاجها النموذج، وماذا تتوقع من جهازك الحالي قبل أن تشتري بطاقة رسومية GPU.دليلعتاد الهوم لاب: Mini PC أم NAS أم سيرفر مستعمل؟كيف تختار جهاز الهوم لاب بأرقام الشركة المصنعة وليس بالسعر وحده، وكم يكلفك من الكهرباء في السنة بالتعرفة السعودية.دليلبوابة تفتح تلقائياً بقراءة لوحة السيارة: مشروع عمليكيف تبني بوابة لمجمع سكني أو شركة تقرأ لوحة السيارة وتفتح للمصرح لهم، مع شاشة للحارس وسجل لكل دخول.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ التجارب على Frigate 0.18.2 بكاشف OpenVINO على المعالج، وMediaMTX 1.21.1، وDocker Engine 29.8.0.