EnglishEN

الرؤية الحاسوبية · سلامة الحشود · 2026

Stadium

نموذج أولي لمراقبة الحشود والبوابات

يعدّ الأشخاص عند بوابات الملعب من الفيديو، وينبّه للازدحام، ويقترح أين يُنقل الموظفون.

الدور
مطوّر منفرد
الحالة
نموذج أولي عامل
السنة
2026
الكود
github.com/Abdulel3h/Stadium
تصوّر توضيحيرسم توضيحي للفكرة — وليس لقطة شاشة من المنتج.

في سطور

  1. 01المشكلة

    الازدحام عند المداخل يصير خطرًا قبل أن يحصيه أحد، وموظف البوابة لا يرى إلا طابوره.

  2. 02ما بُني

    YOLO يرصد الأشخاص في كل إطار، ومحرك قرار يحدد حالة البوابات الأربع، ولوحة حيّة تتحدث كل ثانيتين.

  3. 03دوري

    بنيته وحدي: الرصد، ومحرك القرار، والواجهة البرمجية، ولوحة المتابعة.

  4. 04النتيجة

    نموذج عامل بكود منشور. لم يُعاير في ملعب حقيقي، ولا أدّعي دقة عدّ.

كيف يعمل

  1. 01المدخل

    كاميرا أو فيديو

  2. 02المعالجة

    رصد الأشخاص عبر YOLO

  3. 03الذكاء

    قواعد حالة البوابات

  4. 04المخرج

    لوحة حيّة وتنبيهات

قرارات شكّلته

  • رؤية حاسوبية لا أجهزة جديدة

    رؤية حاسوبية على بث الكاميرات العادية بدل حساسات جديدة — أقل تكلفة في التجربة، وتعمل مع الكاميرات الموجودة أصلًا.

  • اقتراح إجراء لا مجرد إنذار

    لا يكتفي محرك القرار بتمييز البوابة المزدحمة، بل يقترح أين يُنقل الموظفون، فتكون المخرجات قابلة للتنفيذ مباشرة.

بصراحة

ما لا أدّعيه

لا يُدّعى تشغيل في ملعب فعلي ولا أرقام لدقة العدّ.

حدوده الآن

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

لو استمر

  • جعل مناطق البوابات قابلة للضبط لكل كاميرا
  • قياس دقة العدّ على لقطات موسومة
  • إضافة اختبارات للعتبات ولواجهة الحالة

التقنيات

Python · Ultralytics YOLO · OpenCV · Flask · NumPy · JavaScript

السجل الكاملالسياق والقيود والملاحظات الهندسية كما هي.

السياق

مشروع فردي بناه عبدالإله من البداية إلى النهاية.

المشكلة

يتحول الازدحام عند المداخل إلى خطر على السلامة قبل أن يحصيه أحد. يرى موظفو البوابة طابورهم فقط لا الصورة الكاملة، فيتأخر القرار المهم: نقل الموظفين أو تحويل القادمين.

ما بُني

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

النتيجة

نموذج أولي عامل بُني منفردًا: رصد وتوزيع على المناطق، وأربع حالات، وسجل تنبيهات، واقتراحات للموظفين، وواجهة برمجية للحالة، ولوحة متابعة حيّة. لم تتم معايرته في ملعب حقيقي، ولا تُدّعى أي نسبة لدقة العدّ.

القيود

  • استخدام كاميرات قائمة بدل حساسات جديدة
  • مخرجات يستطيع المشغّل التصرف بناءً عليها فورًا
  • يعمل محليًا على ملفات فيديو أو كاميرا ويب

المسؤوليات

  • بنى النظام كاملًا في مشروع فردي
  • نفّذ رصد الأشخاص عبر YOLO وتوزيعهم على المناطق
  • صمّم محرك القرار لحالة البوابات والتنبيهات واقتراحات الموظفين
  • بنى واجهة Flask للحالة ولوحة المتابعة الحيّة

ملاحظات هندسية

  • يرصد Ultralytics YOLO الأشخاص إطارًا بإطار
  • يُنسب مركز كل رصد إلى إحدى مناطق البوابات الأربع
  • يحدد محرك القرار الحالة ويسجل تنبيهات الازدحام والفيض ويقدّر وقت الوصول
  • تعرض Flask الحالة الحالية عبر نقطة الحالة (api/status)
  • تستعلم لوحة HTML عن الواجهة كل ثانيتين