تصميم وتنفيذ إطار عمل لاكتشاف المشاة المعتمد على مصفوفة البوابات القابلة للبرمجة ميدانيا لتطبيقات القيادة الذاتية

Summary

توضح هذه المقالة البحثية تنفيذ خوارزمية اكتشاف المشاة في الوقت الحقيقي على أجهزة مصفوفة البوابات القابلة للبرمجة ميدانيا، وذلك بشكل أساسي لتطبيقات القيادة الذاتية. تجمع الخوارزمية بين مخطط التدرجات الموجهة (HoG) ومصنف آلة متجه الدعم (SVM)، وتظهر النتائج كفاءة من حيث السرعة واستهلاك الطاقة واستخدام الموارد.

Abstract

تقدم القيادة الذاتية طريقة واعدة لمواجهة العدد المتزايد من الوفيات الناتجة عن حوادث المرور. تتضمن المركبة الذاتية القيادة العديد من الميزات، لكن القدرة على اكتشاف المشاة أمر بالغ الأهمية وتحدي وذات صلة بمواقف زمنية حقيقية مثل المراقبة، وتتبع الأشخاص، والمراقبة. التعرف بدقة على المشاة صعب لأنهم قد يظهرون بأشكال ووضعيات ووضعيات مختلفة. يمكنهم ارتداء أنواع مختلفة من الملابس وأحيانا يكون مخفيا جزئيا أو يندمج مع الأشياء القريبة. تركز هذه الورقة على الكشف في الوقت الحقيقي عن المشاة للسيارات ذاتية القيادة باستخدام منصة أجهزة شهيرة: مصفوفة البوابات القابلة للبرمجة الميدانية (FPGA)، Ultra 96 v2. تطبق الدراسة طريقة لاكتشاف المشاة تعتمد على مخطط مدرج التدرجات الموجهة (HOG) مع مصنف آلة متجهة دعم (SVM) للتعرف على الأفراد في لوحة FPGA، مستفيدة من أدوات التوليف عالي المستوى (HLS). تم اختبار فعالية النظام على كل من الصور الثابتة والفيديو الحي. تظهر النتائج أن لوحات FPGA المتقدمة مثل Ultra 96 v2 تحسن بشكل كبير مؤشرات الأداء. يعمل النظام بتردد ساعة 150 ميجاهرتز مع استهلاك أقل من نصف الموارد المتاحة واستهلاك حوالي 2.5 واط من الطاقة. كما يبلغ النظام عن دقة اكتشاف المشاة التي تقترب من 95٪ ومقاييس فعالة أخرى لتقييم الكشف، مثل الدقة (78.6٪)، الاستدعاء (88.3٪)، ودرجة F1 (83.1٪). باختصار، يمكن للنظام المطور اكتشاف المشاة في الوقت الحقيقي ولديه القدرة على تحسين بيئة نقل ذكية وآمنة بشكل كبير.

Introduction

التنمية الحضرية وظهور المدن الذكية هما مواضيع تهم على مستوى العالم. تعمل جميع الدول على تطوير مدنها بحيث يمكن بناؤها بطريقة آمنة ومريحة للسكان^الذين يعيشون فيها^. لكن في الوضع الحالي، لوحظ أنه مع زيادة عدد السكان وزيادة الازدحام على الطرق، يرتفع معدل الوفيات الناتجة عن حوادث الطرق الناتجة عن إهمال القيادة وضعف الرؤية بشكل مقلق. حل واعد لهذه القضايا هو ظهور المركبات الذاتية القيادة حول العالم، والتي أطلقت ابتكارا 1,2,3,4، ويبذل الباحثون جهودا لتطوير مركبات ذاتية القيادة بالكامل تمكن الركاب من الاسترخاء دون أي قلق. تنبع الحاجة إلى تطوير المركبات الذاتية القيادة من حقيقة أن حتى السائقين ذوي الخبرة قد يواجهون ضغوطا أو معضلات أو إرهاق أو صعوبة في استشعار بيئتهم بسبب سوء الأحوال الجوية، وكل هذه المشاكل تؤدي إلى حوادث الطرق. تم تصميم المركبة ذاتية القيادة لتجنب الحوادث أثناء السفر، وتحسين استخدام موارد المحرك، والامتثال لقوانين المرور، مما سيعزز بلا شك وسائل النقل ^2,4. المركبة الذاتية القيادة مجهزة بميزات وحساسات ووظائف متعددة تسمح لها بالإحساس بمحيطها بدقة عالية، وتجنب أي حوادث أو تصادمات، ولهذا أصبحت الآن حلا واعدا لجعل النقل آمنا^ومحميا 1,2,3,4.

من بين جميع الميزات المدمجة في المركبات ذاتية القيادة، من أهم الميزات هو اكتشاف المشاة. يمكن لنظام كشف المشاة القوي أن يساعد بشكل كبير في تقليل وفيات حوادث الطرق 5,6,7,8، حيث أن غالبية ضحايا هذه الحوادث هم من المشاة. يتضمن اكتشاف المشاة تحديد الأفراد على الطريق وتجنب أي تصادم معهم. هذه الميزة ليست مفيدة فقط للسيارات ذاتية القيادة، بل أيضا لمجالات تطبيقية أخرى مثل مراقبة الحشود، وتحديد هوية الأشخاص، وتتبع ^9,10,11. الجانب الرئيسي في عملية الكشف هذه هو سرعة ودقة الكشف. من الضروري اكتشاف المشاة بدقة وسرعة حتى يكون وقت الاستجابة في أدنى حد أدنى. هناك تحد هائل يفرضه اكتشاف المشاة. يمكن أن يكون المشاة على الطريق بأي ملابس أو مظهر أو وضعية، وقد يكونون غير مرئيين بسبب سوء الأحوال الجوية أو الانسداد^{10، 11، 12، 13، 14}. علاوة على ذلك، من الممكن جدا أن المشاة لا يلتزمون بالقواعد بأنفسهم، ولا يمكن التحكم في طبيعة الإنسان، لذا فإن أفضل نهج ممكن هو تزويد المركبة بالذكاء للتعامل مع أي تصرف خاطئ وتجنب وقوع وفاة. يمكن فهم التدفق الكامل للعمل في هذا البحث والدافع وراء تنفيذ اكتشاف المشاة على الأجهزة بسهولة من الشكل 1 أدناه، الذي يشرح الحاجة إلى اكتشاف المشاة، ومجالات تطبيقه المختلفة، والتحديات المتضمنة، وتطبيقه على FPGA للاستفادة من الفوائد المقدمة.

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

لتحديد المشاة على الطريق، توجد العديد من الخوارزميات. يمكن تقسيم هذه المهمة بشكل أساسي إلى مهمتين فرعيتين رئيسيتين: الخطوة الأولى تستخرج الميزات من صورة إدخال، مع الاحتفاظ فقط بالميزات المهمة التي تنقل المعلومات ذات الصلة، مع تجاهل الميزات الزائدة. للتعرف الفعال على البشر أو المشاة في الصورة، من الضروري أن تشير هذه الخصائص إلى وجود شخصية بشرية داخل المشهد^13،14. بعد هذا الاستخراج، يجب إرسال الميزات إلى مصنف يمكنه تحديد ما إذا كانت الميزات المحددة تتوافق مع الإنسان. لذلك، تتطلب الخوارزمية مرحلة استخراج ووصف الميزات، تليها خطوة تصنيف لتحديد وجود المشاة في مشهد الإدخال. هناك خوارزميات متنوعة متاحة لهذا الغرض. ومع ذلك، فإن الطريقة الأكثر قبولا لاكتشاف المشاة حتى الآن لا تزال الجمع بين مخطط التدرجات الموجهة (HoG) مع مصنف آلة المتجه الداعمة (SVM) ^12,13,14,15. هناك العديد من الأمثلة على التطورات البرمجية، لكن الهدف في النهاية هو نقل التنفيذ إلى منصة عتادية متوافقة، والتي يمكن دمجها بعد ذلك في نظام التطبيق للاستخدام في الوقت الحقيقي. لذلك، التركيز الحالي ينصب على تحقيق الأجهزة. لذا يمكن القول إنه من الضروري تطوير تطبيق مادي مناسب لأنظمة كشف المشاة، حيث يمكن نشر كاميرات مزودة بأجهزة مناسبة على المركبات وتحديد المشاة على الطريق. عند النظر في الأجهزة المناسبة لهذه التطبيقات، فإن أحد الخيارات الأكثر استخداما هو مصفوفة البوابات القابلة للبرمجة الميدانية (FPGA) بسبب مزاياها العديدة، بما في ذلك تقليل وقت التصميم، وقابلية التوسع، وسهولة التعديلات، وإعادة التكوين، واستهلاك أقل للطاقة^{والطاقة} 15,16,17,18,19,20,21^,22.

لقد تطورت لوحات FPGA باستمرار وتستخدم الآن على نطاق واسع لتطبيقات رؤية الحاسوب المعقدة والمتقدمة التي تتراوح من معالجة الصور الأساسية إلى اكتشاف الأجسام، والواقع المعزز، والتعلم العميق 20,21,22. حاليا، تقدم العديد من لوحات FPGA عالية الأداء قدرات معمارية استثنائية لاستيعاب المعالجة المكثفة المطلوبة لهذه التطبيقات المعقدة. إذا تم تنفيذ الميزات المتقدمة للمركبات ذاتية القيادة، مثل اكتشاف المشاة، على هذه المنصات العتادية، يمكن أن تكون هذه المنصات مفيدة جدا لتطوير النماذج الأولية السريعة لتحليل الأداء، وبعد التحسين، يمكن نقل الخوارزمية المنفذة إلى دوائر متكاملة فعلية لدمجها في النظام.

لأكثر من عقد من الزمن، كانت هناك منشورات مهمة تعتمد على تطبيق اكتشاف المشاة باستخدام طريقة HoG وSVM على منصات FPGA المختلفة. يلخص الجدول 1 المقالات في هذا المجال خلال الفترة من 2015 إلى 2025^{15، 16، 17، 18، 19، 20، 21، 22، 23، 24}، مع التركيز على العوامل الرئيسية مثل دقة الصورة، معدل الإنتاجية، أو عدد الإطارات في الثانية (FPS)، نوع المصنف، والنقاط البارزة الرئيسية أو المساهمات التي قدمها ورق.

المرجع	منصة FPGA	دقة الصورة	المصنف	أبرز النقاط / المساهمات
15	زيلينكس زينك	640×480	آدابوست	تنفيذ FPGA في الوقت الحقيقي؛ كفاءة الموارد؛ يستخدم الثنائية للتحسين؛ دقة اكتشاف جيدة.
16	مجلس DE1-SOC الخاص بتيراسيك	640×480	SVM	مستخرج HOG عالي الأداء؛ يدمج SVM؛ الكشف بمقياس واحد؛ خط أنابيب منخفض التأخير.
17	ألتيرا DE2-115	640×480	آدابوست	يقيم الأداء من وجهات نظر متعددة؛ تنفيذ FPGA ل HOG+AdaBoost؛ الكشف المباشر عن المشاة.
18	إنتل ستراتيكس V	640×480	SVM	كشف المشاة متعدد المقاييس؛ خط أنابيب HOG+SVM الصديق ل FPGA؛ تبرز المقايضات بين الدقة وكفاءة الأجهزة.
19	زينك ألتراسكيلي+ MPSoC	3840×2160	SVM	معالجة UHD في الوقت الحقيقي؛ HOG+SVM في خط الأنابيب المستمر؛ تنفيذ SoC FPGA؛ تحسين النقاط الثابتة؛ هندسة معمارية قابلة للتوسع.
20	غير محدد	غير محدد	SVM	يحقق دقة اكتشاف >95٪؛ تنفيذ FPGA في الوقت الحقيقي؛ يستغل التوازي؛ تصميم دقيق لتقنية HOG+SVM FPGA لاكتشاف المشاة.
21	Zync 7000 FPGA	1920×1080	SVM	بنية تدفق عالي الإنتاجية ل HOG+SVM؛ يدعم دقة HD؛ خط أنابيب فعال لتسريع FPGA.
22	ألترا96 (النسخة الأولى)	240×320	SVM	تنفيذ FPGA باستخدام HLS؛ يكتشف إشارات المرور الحمراء؛ يحسب الاحتمالات في 891 منطقة؛ يتراوح زمن الاستجابة بين 153,838 إلى 19 دورة.
23	زيلينكس زينكيو-7000 FPGA	640 × 480	HOG + SVM	تم تنفيذ اكتشاف المشاة باستخدام HOG-SVM على FPGA، محققا أداء في الوقت الحقيقي مع استهلاك طاقة أقل مقارنة بمعالجة المعالج. تم إثبات خط أنابيب استخراج الميزات المحسن المناسب لتطبيقات الرؤية المدمجة.
24	Xilinx Virtex-6 FPGA	640 × 480	كاشف الأجسام ذات النقطة الثابتة (ميزات شبيهة بهار)	اقتراح تسريع FPGA عالي الإنتاجية لاكتشاف الأجسام باستخدام حساب النقاط الثابتة، مما يقلل التكلفة الحسابية مع الحفاظ على الدقة. أظهرت تسارعا بنسبة 15× مقارنة بتطبيقات المعالج مع استخدام موارد الأجهزة بكفاءة.

الجدول 1: مراجعة الأدبيات للأبحاث المبنية على اكتشاف المشاة في FPGA (2015–2025).

يلخص الجدول 1 أن هناك أدبيات واسعة في مجال اكتشاف المشاة، وتطبيق الأجهزة هو المجال الذي يهم الباحثون. ومن الواضح أيضا وجود تقنيات متقدمة للتعلم العميق وتعلم الآلة، مثل الكواشف القائمة على شبكات العصبية الالفافية (CNNs) مثل YOLO، وهياكل المحولات، وغيرها، لمهمة اكتشاف المشاة. بل إنها تتفوق حتى على خوارزمية HoG التقليدية من حيث الدقة، ولكن عند النظر في تنفيذ الأجهزة، فإن الخوارزميات المتقدمة تؤدي إلى استهلاك هائل للموارد^23,24 بسبب تعقيدات الخوارزمية التي قد تؤثر أيضا على معايير أداء أخرى، كما لوحظ أنه بسبب التعقيدات الإضافية تكون السرعة أفضل قليلا في حالة خوارزمية HoG التقليدية^{24. 25}. كما لوحظ أن التقنيات المتقدمة تستهلك طاقة أكبر عند تنفيذها على الأجهزة^24,26. لذا، فإن هدف العمل المنفذ في هذه الورقة هو إجراء اكتشاف المشاة باستخدام إطار HoG التقليدي وSVM على أجهزة FPGA وتحقيق مقايضة دقة وسرعة وقوة ملائمة للتضمين في الوقت الحقيقي. من الجدول 1 يتضح تماما أنه عند تحليل الأعمال القائمة على HoG وSVM، يلاحظ وجود منشورات محدودة استخدمت لوحة تطوير FPGA²⁷ المعتمدة على Zynq UltraScale+ MPSoC (نظام متعدد المعالجات على الشريحة) التي تم تقديمها مؤخرا لاستكشاف قدرات هذه اللوحات، حيث تطورت هذه اللوحات من وجهة نظر البنية، وتقدم إمكانيات كبيرة من حيث تنفيذ تطبيقات رؤية الحاسوب في الوقت الحقيقي عالية الجودة. هناك منشورات محدودة أنجزت نظام كشف المشاة بالكامل في الوقت الحقيقي على لوحات FPGA. ومع ذلك، ركزوا على التنفيذ الفعال أو تحسين المهام الوسيطة. علاوة على ذلك، تعتمد معظم هذه التطبيقات على تنفيذ النظام بأكمله على لوحة FPGA من خلال استخدام لغات وصف الأجهزة. قلة فقط استفادوا من أدوات التوليف عالي المستوى (HLS) لتسريع دورة التصميم. توضح هذه الورقة تصميم وتنفيذ الكشف اللحظي للمشاة على لوحة FPGA مخصصة لتطبيق القيادة الذاتية. تستخدم الورقة إطار عمل HoG وSVM لغرض اكتشاف المشاة على الصور الثابتة أو الفيديو أو إدخال الكاميرا الحقيقية. الأجهزة المستخدمة هي لوحة FPGA متطورة وصدرت حديثا، وهي Ultra96 v2، وهي بنية FPGA متقدمة تشكل منصة قوية لرؤية الحاسوب، ومعالجة الصور، وتعلم الآلة، والحوسبة الحافية، ^{وغيرها.} Ultra96 v2 هو لوحة تطوير تتميز بمعالج AMD Xilinx Zynq UltraScale+ MPSoC²⁷ المعتمد على Arm. تشمل هذه اللوحة قسم نظام المعالجة (PS)، الذي يتكون من أنوية معالج مبنية على ARM تدير الجوانب البرمجية للمشروع، وقسم المنطق القابل للبرمجة (PL) الذي يسمح بتسريع الأجهزة القابل للتخصيص 20,21,22. معا، تعزز هذه المكونات وظائف النظام الهجين، حيث يدير جزء PS التحكم والتفاعل مع العناصر الخارجية، بينما يتعامل جزء PL مع منطق المعالجة الفعلي.

Protocol

يتم توضيح إجراء التنفيذ المستخدم في هذا البحث، المعتمد على اكتشاف المشاة باستخدام HoG + SVM على لوحة FPGA، مستفيدا من فوائد التوليف عالي المستوى، في الشكل 2 أدناه.

الشكل 2: إجراءات التصميم لتنفيذ اكتشاف المشاة على لوحة FPGA. المرحلة 1: خوارزمية اكتشاف المشاة باستخدام HoG+SVM على أداة HLS وتوليد كتلة IP. المرحلة الثانية: خوارزمية اكتشاف المشاة باستخدام HoG+SVM لتنفيذ FPGA الفعلي وتوليد ملف البت. المرحلة 3: برمجة اللوحة باستخدام ملف البت المولد. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

1. اكتشاف المشاة باستخدام HoG وSVM على أداة HLS

1. قم بتحميل بيئة التطوير المتكاملة (IDE) في بايثون حسب خصائص النظام التي يتم عليها عملية التنزيل.
   ملاحظة: في هذا العمل، تم استخدام نسخة بايثون 3.10.
2. تنفيذ سكريبت بايثون لتشغيل نموذج تدريب باستخدام خوارزمية HoG ومصنف SVM. ابدأ السكربت بتحميل العينات الموجبة والسالبة من مجموعة البيانات.
   ملاحظة: استخدم مجموعة بيانات INRIA^{رقم 11}.
3. استخرج ميزات HoG لنافذة بحجم 64 × 128.
4. قسم بيانات التدريب والاختبار من مجموعة بيانات INRIA بنسبة 80/20 مع خلط عشوائي لإعادة الإنتاج.
   ملاحظة: يتم خلط مجموعة البيانات عشوائيا باستخدام دالة بايثون قبل تقسيم البيانات. لضمان قابلية التكرار بحيث يتم نفس التقسيم في كل مرة يتم فيها تثبيت قيمة البذور في الكود.
5. تدريب باستخدام تصنيف متجه دعم C (SVC) SVM باستخدام نواة خطية.
6. استخرج متجهات الوزن والانحياز.
7. احفظ أوزان SVM والانحياز بصيغة Q8.8 الثابتة لتنفيذ FPGA.
   ملاحظة: يتم التحويل عن طريق تحجيم كل قيمة فاصلة عائمة تتولد أصالة بمقدار 256 (2⁸) وتحويل النتيجة إلى عدد صحيح.
8. اختبر النموذج المدرب من خلال سكريبت بايثون آخر وضبط معامل التنظيم C، حتى يتم حساب الدقة لتزيد عن 95٪.
   ملاحظة: تم الحصول على معامل تنظيم محسن: C = 0.05.
9. افتح أداة HLS وأنشأ مشروعا جديدا مع اختيار رقم الجزء ك xczu3eg-sbva484-1-e.
10. اكتب رمز اكتشاف المشاة على أداة التوليف عالية المستوى باستخدام لغات عالية المستوى مثل C++.
11. في الكود، اكتب ثلاثة سكريبتات C++ مختلفة: واحد لواصف ميزات HoG ومصنف SVM، وآخر لمنصة الاختبار لتوفير مدخلات لصور الاختبار وحفظ صور الإخراج، والثالث لملف رأس يعلن عن المعلمات المستخدمة في الكود.
12. في كود حساب ميزات HoG، قم بتغيير حجم الصورة إلى 640 × 480 وتطبيق بنية نافذة منزلقة بحجم نافذة 64 × 128. لكل نافذة، احسب مقدار التدرج والاتجاه لكل كتلة متداخلة بحجم 8 × 8.
    ملاحظة: من المهم مسح الصورة بالكامل من خلال مفهوم النافذة المنزلقة حتى يتم تغطية كل منطقة في الصورة وتحديد المشاة بكل الحجم الممكن.
13. في الجزء الآخر من نفس الكود لوصف ميزة HoG، مرر التدرجات المحسوبة إلى مصنف SVM. اكتب الكود لمطابقة الميزات مع أوزان المصنف وقارن مع العتبة لتصنيف الميزة المكتشفة كميزة إنسان أو لا.
14. انقر على تشغيل محاكاة C في أداة HLS لمحاكاة الكود بمساعدة منصة اختبار للتحقق من صحة وظائف الكود.
15. قدم صورا مختلفة للكود وتحقق من صور المخرج مع المشاة المكتشفين.
16. انقر على تشغيل C Synthesis لتركيب الكود لتعيين الكود إلى لغات الأجهزة بواسطة الأداة وتوليد تقارير التوقيت والاستخدام.
    ملاحظة: تقوم الأداة بفتح تقارير توليف HLS تلقائيا. يعرض هذا التقرير تقدير تردد الساعة المطلوب لتنفيذ المهمة المشفرة على منصة FPGA المختارة، كما يوفر تقديرا للموارد المستخدمة. هذه القيم المبلغ عنها هي تقديرات فقط، ويتم حساب المعاملات الفعلية فقط بعد التنفيذ على لوحة FPGA.
17. انقر على تصدير RTL لتصدير كتلة الملكية الفكرية (IP) لخوارزمية HoG لاكتشاف المشاة.
    ملاحظة: يجب استخدام هذا العنوان في المراحل اللاحقة من التنفيذ.

2. برمجة لوحة FPGA

1. افتح أداة برمجة FPGA وأنشئ مشروعا جديدا. اختر رقم الجزء ك xczu3eg-sbva484-1-e وأنشئ تصميم كتلة جديدة.
   ملاحظة: تم إنشاء هذا المخطط الكتل لإثبات التكامل بين الجزء من PS وPL في لوحة FPGA. بروتوكول الاتصال المستخدم هو بروتوكول واجهة التوسيع المتقدمة (AXI).
2. ابحث عن كتالوج IP في الأداة وبمجرد العثور عليه افتحه.
3. إنشاء مستودع مستخدم بإضافة مسار عنوان IP RTL المصدر في الخطوة 1.17.
4. في نافذة تصميم الكتل الجديدة ، انقر بزر الفأرة الأيمن واختر إضافة عنوان IP. جميع عناوين IP ستكون مرئية، بما في ذلك تلك التي توفرها الأداة بالإضافة إلى المستودعات التي أضافها المستخدم.
5. أضف كتلة Zync Ultrascale PS من المستودع.
   ملاحظة: تعكس هذه الكتلة جزء PS من النظام، المسؤول عن توليد الساعات المطلوبة، كما تحتوي على منافذ الرئيسية وتابعة للاتصال بعنوان IP HoG المستورد عبر كتلة الربط AXI، والتي تعمل على أساسيات بروتوكول AXI.
6. أضف 8 عناوين IP ل HoG لأن النظام سيعالج 8 نوافذ في نفس الوقت للاستفادة من ميزة التوازي الذي توفره لوحة FPGA.
7. أضف كتلة إعادة ضبط نظام المعالج ، وهي أيضا تتحكم في الساعة وإعادة ضبط كل كتلة في الرسم التخطيطي.
8. أضف كتلين axi_smart connect لتوصيل عناوين HoG مع كتلة Zync PS. يظهر مخطط الكتل بالكامل مع الوصلات الكاملة في الشكل 3.
   ملاحظة: كما هو موضح في الشكل 3، تم عرض جميع الكتل التي يجب إضافتها إلى التصميم بوضوح. يتم التقاط الشكل 3 من الأداة ويظهر المنافذ الداخلية لكل كتلة بالإضافة إلى الترابط بين منافذ الكتل المختلفة. هذه الكتلة هي التصميم الرئيسي لأنها مسؤولة عن إنشاء الواجهة بين PS وجزء PL من لوحة FPGA.
9. بعد إكمال التوصيلات كما هو موضح في الشكل 3، انقر على التحقق من التصميم.
   ملاحظة: التحقق من الصحة يتحقق أساسا من الاتصالات المفقودة أو المقطعة، مما قد يؤدي إلى مشاكل في مراحل لاحقة.
10. انقر على التوليف ثم تنفيذ التصميم في ال tool بعد نجاح التحقق من مخطط الكتل.
    ملاحظة: يقوم Synthesis برسم مخطط الكتل المصمم ويعطيه على لوحة FPGA. ستبلغ هذه الخطوة عن أي مخالفات قد تشير إلى أن التصميم لا يمكن تنفيذه على الأجهزة.
11. ستقوم الأداة أيضا بتوليد تقارير تتعلق بالتوقيت، واستخدام الموارد، واستهلاك الطاقة. افحص التقارير بعناية للتحقق من أي مخالفات توقيت وتحليل أداء النظام المصمم.
12. انقر على إنشاء ملف تدفق البتات الذي سيولد ملف .bit المطلوب لبرمجة لوحة FPGA.

الشكل 3: مخطط كتلة لاكتشاف المشاة باستخدام عنوان IP مستورد HoG + SVM. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

3. التنفيذ النهائي على لوحة FPGA

1. احصل على لوحة FPGA وأدخل بطاقة SD مع ملف الصورة المناسب في الفتحة على اللوحة.
2. وصل اللوحة بالكمبيوتر أيضا.
3. قم بتشغيل لوحة FPGA في وضع بطاقة SD لتفعيل برمجة بايثون عليها^21,22.
4. يمكنك الوصول إلى منصة Jupyter على اللوحة بعد توصيلها بالواي فاي.
5. وصل كاميرا ويب باللوحة.
6. اكتب كود بايثون لاستيراد ملف البت المنشأ وأداء مهمة الوصول إلى صور الكاميرا.
7. في الكود، اكتب السكربت بحيث تكتب الصورة في ذاكرة لوحة FPGA عبر جزء PS وتمرر إلى جزء PL للمعالجة.
   ملاحظة: جزء PL من اللوحة الذي يتوافق مع عناوين HoG IP يصل إلى بكسلات الصورة عبر مواقع الذاكرة هذه ويعالجها ويوفر الدرجات كمخرجات.
8. اكتب الكود المناسب بنفس سكريبت بايثون لقراءة الصور المعالجة وعرضها على شاشة الكمبيوتر.
   ملاحظة: هذا يكمل التصميم بالكامل وأصبح النظام جاهزا للنشر في التطبيقات الواقعية. جميع الرموز المستخدمة في هذه الدراسة تم رفعها كملفات ترميز تكميلية (الملف التكميلي 1 [Script_1_train_test.py]، الملف التكميلي 2 [Script_2_HLS_hog.cpp]، الملف التكميلي 3 [Script_3_HLS_test_bench.cpp]، الملف التكميلي 4 [Script_4_HLS_consts.h]، الملف التكميلي 5 [Script_5_jupyter_code.txt]).

Results

تنفيذ اكتشاف المشاة على نظام HLS
يوضح الشكل 4 نتائج المحاكاة على أداة HLS لاكتشاف المشاة باستخدام HoG + SVM. يتم إدخال صورة إدخال مع مشاة كمدخل اختبار للرمز، ويتم عرض المخرج مع المشاة المكتشفين. هناك قسمان في الصورة. الكشف الأول يحتوي على العديد من الصناديق المحيطة بنفس المشاة مرارا وتكرارا، وفي الصورة الثانية، تزال الصناديق المتداخلة ويتم قمعها، لتبقى فقط صناديق الكشف الرئيسية.

الشكل 4: نتيجة المحاكاة من أداة HLS. (أ، ب) صورتان مختلفتان للإدخال والصور الناتجة مع المشاة المكتشفين. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

توفر أداة HLS أيضا تقارير توليف للتوقيت واستخدام الموارد. يبرز ملخص التوقيت الفترة الزمنية المطلوبة للتصميم ويوفر أقصى وأقل قيم زمن استجابة من حيث عدد الدورات. هذه المعلومات مفيدة لتقدير مقدار الوقت الذي يتطلبه التصميم لتنفيذ وتردد الساعة عند الانتقال إلى التطبيق الفعلي للأجهزة. يوضح الجدول 2 أدناه تقرير التوقيت بعد توليف HLS، والذي يوضح بوضوح أن فترة الساعة المستهدفة كانت 6 نانوثانية وأن التصميم استغرق 5.25 نانوثانية، وهو أقل من الهدف، وبالتالي يمكن أن تكون الفترة الزمنية 6 نانوثانية أو أكثر ولكن ليست أقل من 5 نانوثانية.

ملخص التوقيت
الساعة	الهدف	تقديرات
	6.00 نانوثانية	5.250 نانوثانية ثانية
ملخص الاستخدام
	إجمالي / متوفر	نسبة الاستخدام
BRAM18K	22 / 432	5%
DSP48E	13 / 360	3%
FF	5611/ 141120	3%
LUT	9904/ 70560	14%
أورام	0	0

الجدول 2: تقرير تقديري لتوقيت واستخدام الموارد من أداة HLS لاكتشاف المشاة باستخدام HoG-SVM.

يوضح الجدول 2 أيضا تقرير الاستخدام. يظهر نسبة استخدام موارد FPGA المهمة على متن السفينة حسب اللوحة المستهدفة المختارة. بالنسبة لهذا التصميم الخاص باكتشاف المشاة، يظهر تقرير الاستخدام أن التصميم يستهلك 14٪ من جداول البحث (LUTs)، و3٪ من فليب فلوب (FFs)، و3٪ من معالجة الإشارات الرقمية (DSP)، و5٪ من ذاكرة الوصول العشوائي الكتل (BRAM). هذه التقديرات ليست تقارير الاستخدام الدقيقة، لكن التقارير الفعلية قريبة من هذه التقديرات. هذه فقط التقديرات التي يمكن حسابها بواسطة أدوات HLS. عادة ما يكون التطبيق الفعلي مختلفا جدا عن هذه التقديرات.

التنفيذ الفعلي ناتج عن برمجة الأجهزة
بعد أن يتم تعيين الكود إلى عنوان IP، والذي يتم استيراده في أداة برمجة FPGA، وتنفيذ التصميم على جهاز FPGA الفعلي، يتم أيضا توليد عدة تقارير. الأول هو ملخص التوقيت، الذي يوضح ما إذا كان تردد الساعة المقدم للتصميم كافيا أم لا. إذا تم استيفاء جميع قيود التوقيت ولم تكن هناك مخالفات، يمكن للتصميم المضي قدما. يوضح الجدول 3 أدناه ملخص التوقيت الذي تم إنشاؤه بواسطة الأداة. كما هو موضح في الجدول، يشير ملخص التوقيت إلى أسوأ تراخي سلبي، وهو 4.073 نانوثانية. وبما أن هذه القيمة إيجابية، فهذا يشير إلى أن هذا الوقت الكبير لا يزال متاحا. تشير القيم السلبية إلى أن FPGA يستغرق وقتا أطول لإتمام المهمة، وأن الساعة تعمل بسرعة. وبما أنه في هذه الحالة لا توجد قيم سالبة، فهذا يعني أن قيود التوقيت قد تحققت.

ملخص توقيت التصميم
الإعداد	انتظر	عرض النبضة
أسوأ سلبي Slack 4.073 نانوثانية	أسوأ تثبيت للترخي 0.010 نانوثانية	أسوأ عرض نبضي Slack 3.500 نانوثانية

الجدول 3: ملخص التوقيت الفعلي لاكتشاف المشاة على لوحة FPGA.

أيضا، تعرض الأداة تقارير استخدام الموارد، وهي الاستخدام الفعلي للموارد على متن السفينة حسب لوحة FPGA المختارة. في هذه الحالة، اللوحة المختارة هي لوحة تطوير FPGA²⁷ المعتمدة على Zynq UltraScale+ MPSoC (نظام متعدد المعالجات على الشريحة). يوضح الجدول 4 أدناه استخدام الموارد، والشكل 5 يوضح التمثيل المخططي لاستخدام الموارد.

يشير ملخص الاستخدام إلى الاستهلاك الفعلي للموارد على متن السفينة نظرا لوجود 8 أنظمة HoG IPS مستخدمة بالتوازي، وكانت التقديرات المبلغ عنها من توليف HLS لنظام HoG IP واحد. ولكن حتى بعد هذا الاستخدام المكثف، فإن استخدام الموارد لكل مورد أقل من 50٪. يوضح الجدول 4 بوضوح الاستخدام بالنسبة للموارد المختلفة ونسبة استخدامها، والتي تظهر بشكل مصور في الشكل 5.

المصدر	الاستخدام	متوفر	نسبة الاستخدام
LUT	40536	70560	57.45%
لوترام	7304	28800	25.36%
FF	33342	141120	23.63%
برام	68	216	31.48%
DSP	128	360	35.56%
BUFG	2	196	1.02%

الجدول 4: تقرير الاستخدام الفعلي لاكتشاف المشاة على لوحة FPGA.

الشكل 5: استخدام الموارد لاكتشاف المشاة على لوحة FPGA بعد التنفيذ الفعلي. ابحث عن الجداول (LUT): 57٪، LUTRAM: 25٪، Flip Flops (FF): 24٪، ذاكرة بلوك RAM (BRAM): 31٪، معالجات الإشارة الرقمية (DSP): 36٪، المخازن: 1٪. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

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

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

يتم إجراء تحليل آخر لفهم ميزة استخدام 8 عناوين HoG بدلا من عنوان IP واحد أو أكثر من 8 في مخطط الكتلة المنشأ، كما هو موضح في الشكل 3. تم حساب مقاييس الأداء المتعلقة بالأجهزة لكل من عنوان IP واحد ل HoG و8 عناوين HoG بالتوازي. يوضح الجدول 5 أدناه المقارنة.

مقياس الأداء	1 IP	8 حقوق IP
التوقيت (ns)	5.312	~5.25
التردد (ميغاهرتز)	188	150
القوة (W)	1.9	2.43
LUTs	4998	40536
FF / السجلات	4,031	33,342
DSP	16	128
برام	8.5	68
ألعاب التصويب من منظور الشخص الأول	~10–11	83

الجدول 5: مقارنة مقاييس الأداء باستخدام عناوين IP فردية مقابل متعددة من HoG.

يوضح الجدول 5 بوضوح أنه عند النظر في الموارد مثل LUTs وFFs وDSPs وBRAM، فإن مع IP واحد من HoG و8 عناوين HoG IP، يكون التكبير خطيا مع زيادة تقارب 8 أضعاف في الموارد المستخدمة. وهذا متوقع بوضوح، حيث أن المزيد من حقوق الملكية الفكرية سيؤدي إلى استهلاك المزيد من الموارد. أيضا، إذا تم رصد التردد، فإن التردد الأقصى ينخفض قليلا بنسبة 20٪ من 188 ميجاهرتز إلى 150 ميجاهرتز. وهذا متوقع أيضا لأن المزيد من الكتل يؤدي إلى المزيد من الوصلات وبالتالي مسارات أطول، مما يؤدي إلى زيادة المسارات الحرجة. لكن العوامل المفيدة مثل الإطارات في الثانية (FPS) تتحسن من 10 إلى 83، مما يظهر تحجيما غير خطي في حالة FPS بسبب مفهوم التوازي المقدم بسبب 8 عناوين HoG. كما أن القدرة تتراوح من 1.9 واط إلى 2.4 واط، مما يشير إلى تحسين كفاءة الطاقة عبر التبطين. لذا، يشير هذا التحليل بوضوح إلى أن إدخال 8 عناوين HoG مفيد للتصميم، وأن التوسع فوق 8 قد يؤدي إلى الإفراط في استهلاك الموارد؛ لذا، لا يعتبر عدد الكتل التي تتجاوز 8 مفضلا.

نتائج اكتشاف المشاة بعد تنفيذ FPGA
وأخيرا، يتم دمج النظام بالكامل على لوحة FPGA، ويتم توليد ملف تدفق البت، والذي يتم برمجته بعد ذلك على اللوحة عبر بطاقة SD المجهزة بقدرة برمجة بايثون. بمجرد إقلاع اللوحة باستخدام بطاقة SD، يمكن الوصول إلى واجهة jupyter ويمكن كتابة كود بايثون وتشغيله على المنصة. يتم تشغيل واختبار كود بايثون لاكتشاف المشاة على صور إدخال مختلفة. تظهر نتيجة بعض الصور في الشكل 7 أدناه. تستخدم هذه الصور من مجموعة بيانات INRIA بالإضافة إلى صور عشوائية للمشاة تم الحصول عليها من مصادر مفتوحة المصدر^{عبر الإنترنت 26,27}.

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

كما يختبر النظام على التقاط الإطارات في الوقت الحقيقي عبر كاميرا ويب واكتشاف المشاة في الإطار، كما يتم اختبار النظام على مدخلات الفيديو المسجلة مسبقا للمشاة. تظهر نتائج ذلك في الشكل 8 والشكل 9. يعرض الشكل 8 مجموعة من الإطارات النموذجية التي التقطتها كاميرا الويب ونتائج اكتشاف المشاة في كل إطار، بينما يوضح الشكل 9 نتائج اكتشاف المشاة المنفذة على فيديو إدخال مقدم للنظام.

الشكل 8: نتائج اكتشاف المشاة على الإطار الذي تلتقطه الكاميرا في الوقت الحقيقي عبر لوحة FPGA. التقاط الفيديو في الوقت الحقيقي عبر كاميرا ويب 720 P وإظهار الكشف اللحظي للمشاة. الصور الضبابية ناتجة عن التقاط لقطات من الفيديو المباشر المستمر. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

الشكل 9: نتائج اكتشاف المشاة على الفيديوهات المقدمة كمدخل للوحة FPGA. تم أخذ الفيديوهات من روابط مفتوحة المصدر. يرجى الضغط هنا لعرض نسخة أكبر من هذا الشكل.

تقدير مقاييس الأداء
لحساب الكفاءة وتحليل أداء التصميم المطبق أعلاه، من الضروري حساب مقاييس الأداء المفيدة لتقييم الأداء. تعتمد مقاييس الأداء لاكتشاف كفاءة خوارزمية الكشف أساسا على قيم الإيجابيات الحقيقية (TP)، والسلبيات الحقيقية (TN)، والإيجابيات الكاذبة (FP)، والسلبية الكاذبة (FN). من هذه القيم، يمكن حساب مقاييس الأداء مثل الدقة، الاسترجاع، درجة F1، الإيجابيات الكاذبة لكل صورة، والدقة وفقا للمعادلات الموضحة أدناه. لوحظ أن معظم الأوراق البحثية تنقل أدائها في الكشف من خلال معامل الدقة. لكن لوحظ أن حساب الدقة الذي يتضمن استخدام TN يمكن أن يكون معاملا مضللا، حيث لا يمكن حساب قيمة TN بشكل صحيح بالمعنى الحقيقي، لأنها تتضمن إيجاد عدد جميع نوافذ الكشف في صورة لا يوجد بها مشاة فعليا، كما أن الخوارزمية المطبقة تبلغ أيضا عن عدم وجود كشف. عادة ما يكون هذا العدد كبيرا جدا، حيث أن إجمالي نوافذ الكشف في الصورة كبير، والمناطق الخلفية في كل صورة عادة ما تتوافق مع مناطق لا يوجد بها مشاة. من خلال النظر عن كثب إلى صيغة الدقة المعروضة في المعادلات [1] – [5]، يمكن إدراك أنه بما أن قيمة TN ستكون مرتفعة جدا مقارنة ب TP+FP+FN، فإن معامل الدقة عادة ما يكون له قيمة عالية. لتقييم الأداء بشكل حقيقي، من الأفضل الإبلاغ عن مقاييس مثل الدقة، والاستدعاء، ودرجة الفورمولا 1 التي لا تعتمد على TN وبالتالي فهي أكثر دقة.

[1]

[2]

[3]

[4]

[5]

لإيجاد قيم TP وTN وFN لهذه الورقة، تم تكرار التجربة على الصور الثابتة على عدد هائل من الصور. من نتائج كل صورة، تم حساب قيمة الإيجابيات الحقيقية، وهي عدد المشاة الذين تم اكتشافهم بشكل صحيح، والإيجابيات الكاذبة، وعدد المشاة الذين تم اكتشافهم بشكل خاطئ، والسلبية الكاذبة، وهي المشاة الفعليين الذين لم يتم اكتشافهم. تم الإبلاغ عن القيم التالية بعد إجراء التجارب وموضحة في الجدول 6 أدناه.

مقياس الأداء	القيمة
TP	143
FP	39
FN	19
بريسيسون	0.786 (78.6%)
الاستدعاء	0.883 (88.3%)
نتيجة الفورمولا 1	0.831 (83.1%)
FPPI	0.867

الجدول 6: مقاييس الأداء لخوارزمية اكتشاف المشاة المبنية على FPGA المنفذة.

لذا يصف الجدول 6 أعلاه دقة خوارزمية كشف المشاة من خلال مقاييس الأداء المختلفة، والدقة، والاستدعاء، ودرجة F1، وFPPI، عندما يتم تنفيذ الخوارزمية على منصة الأجهزة.

مقارنة الأداء مع تطبيقات HoG القائمة على FPGA الحالية
وأخيرا، يمكن مقارنة العمل المنفذ مع الأدبيات السابقة لتوضيح أي مساهمات مهمة لهذا البحث. هذا المقارنة موضح في الجدول 7^{15، 16، 17، 21، 24}أدناه. المقالات التي تجرى من خلالها المقارنة كلها تعتمد على تطبيقات اكتشاف المشاة المطبقة على منصات FPGA، والخوارزميات المستخدمة لهذه الاكتشافات هي نفسها للجميع، وهو HoG مع مصنف، وهو إما مصنف Adaboost أو SVM. حجم الصورة أيضا نفسه لكل واحد (640 × 480). يتم إجراء المقارنة بناء على معايير مثل تردد الساعة التي تؤثر على السرعة، والإطارات في الثانية، واستهلاك الطاقة، واستهلاك الموارد من حيث LUTs، وDSPs، والذاكرة، والقطع، والسجلات. لتحفيز مقارنة عادلة، فإن الأوراق البحثية التي تم النظر فيها للمقارنة لها دقة صور متشابهة، ولتطبيع مقارنة الموارد، يتم تطبيع كل استخدام للموارد عن طريق قسمة عدد الموارد المستهلكة على إجمالي الموارد المتاحة وفقا للوحة FPGA المستخدمة.

المرجع	حجم الصورة	مجلس FPGA	تردد الساعة	الإطارات في الثانية (FPS)	القوة	البكسلات /الساعة	LUTs (٪)	DSP48s (٪)	ذاكرة BRAMs / بتات الذاكرة (٪)	السجلات/القواعد (FF) (٪)
15	640×480	زيلينكس زينك	82.2 ميجاهرتز	40	-	1	40	2	0	-
24	640×480	فيرتكس 6	150 ميجاهرتز	10	19 W		39	53	22	-
16	640×480	إعصار V	162 ميجاهرتز	526	9 W	0.99	21	86	100	21
17	640×480	ألتيرا DE2-115	50 ميجاهرتز	129	3.6 وايت	-	73	-	72	60
21	640×480	Zync 7000	100 ميجاهرتز	240	1.6 وايت	-	13	3	1	10
هذا العمل	640 × 480	ألترا 96 v2	150 ميجاهرتز	83	2.435W	0.0632	57	35	31	24

الجدول 7: مقارنة المعلمات والأداء لتنفيذ اكتشاف المشاة على FPGA

كما هو موضح في الجدول 7 أعلاه، يمكن ملاحظة أنه عند مقارنة التنفيذ في هذا البحث مع الأعمال السابقة، تظهر المقارنات تحسنا كبيرا من حيث السرعة. لوحة FPGA قادرة على العمل بتردد ساعة 150 ميجاهرتز، مما يعني أن الفترة الزمنية لإتمام المهمة بأكملها أقل من 6 نانوثان. على الرغم من أن بعض الأعمال السابقة أبلغت عن معدل إطارات أعلى بكثير، إلا أنه من خلال الفحص الدقيق يمكن تحليل أن هذه الميزة تأتي على حساب استهلاك طاقة أعلى وكذلك الاستخدام شبه الكامل لبعض الموارد. إذا أخذنا استهلاك الطاقة في الاعتبار مقارنة بهذا العمل، فإن الطاقة المبلغ عنها أيضا أقل من الجانب المطلوب، وتشير استخدامات الموارد إلى أن استهلاك كل مورد أكبر قليلا من بعض التنفيذات، لكنه يساوي أو أقل من 50٪ (57٪ LUTs، 35٪ DSPs، و31٪ BRAM)، مما يدل على مساحة كبيرة لتنفيذ المزيد من المهام في هذا التصميم. بشكل عام، يمكن القول إن العمل المنفذ في هذه الورقة يحقق موازنة متوازنة بين الأداء والطاقة واستخدام الموارد. بالإضافة إلى ذلك، أظهر العمل المعروض توازيا قابلا للتوسع عبر عدة كتل IP دون التأثير بشكل كبير على معايير الأداء.

الملف التكميلي 1: Script_1_train_test.py.يرجى الضغط هنا لتحميل هذا الملف.

الملف الإضافي 2: Script_2_HLS_hog.cpp. يرجى الضغط هنا لتحميل هذا الملف.

الملف التكميلي 3: Script_3_HLS_test_bench.cpp. يرجى الضغط هنا لتحميل هذا الملف.

الملف التكميلي 4: Script_4_HLS_consts.h.يرجى الضغط هنا لتحميل هذا الملف.

الملف التكميلي 5: Script_5_jupyter_code.txt.يرجى الضغط هنا لتحميل هذا الملف.

Discussion

تنفذ هذه الدراسة بشكل فعال نظام كشف المشاة في الوقت الحقيقي باستخدام خوارزمية HoG + SVM على أجهزة FPGA متقدمة تعتمد على لوحة تطوير Zynq UltraScale+ MPSoC^{رقم 24}. تشير النتائج إلى أن خوارزمية HoG التقليدية للكشف البشري¹¹ تحقق دقة تقارب 95٪ وتستخدم فقط نصف موارد FPGA المدمجة (LUTs، FFs، BRAM، DSPs)، مما يترك قدرة هائلة على تضمين معالجة أكبر بكثير لأداء بعض المهام المختلفة. عند تحليل نهج التنفيذ بالكامل، يلاحظ وجود خطوات حرجة متداخلة. إحدى الخطوات الرئيسية هي تدريب نموذج SVM 18,19,24 بمجموعة بيانات مناسبة لاكتشاف المشاة الفعال بحيث يتم استخراج الأوزان واستخدامها في برمجة FPGA. سيشير رمز التدريب إلى دقة الأداء، ويجب ضبط عتبة الكشف بعناية من خلال معامل التنظيم لتحقيق دقة تقارب 95٪. المعايير المختارة في التدريب هي أوصاف HoG المخصصة بحجم نافذة 64 × 128، حجم كتلة 16 × 16، حجم خلية 8 × 8، وعدد صناديق يتم اختياره ب 9. حاليا، تم إجراء التدريب على مجموعة بيانات INRIA^{رقم 11} مع 2416 صورة إيجابية و1218 صورة سلبية. تشمل الزيادة تدوير الصور لتوفير النسخة المعكوسة الأفقية. سيتم معالجة إدراجات رئيسية أخرى، مثل تقييم النموذج في ظروف ضعف الرؤية أو اختلافات في المقاييس، في أعمال مستقبلية لضمان قابلية التكرار والمتانة. يجب أن تتضمن مجموعة البيانات التي تم النظر فيها للتدريب صورا للمشاة في أوضاع مختلفة، ويجب أن تتضمن أيضا صورا لا تحتوي على أي مشاة^18,19.

الخطوة الحاسمة الأخرى هي إنشاء مخطط الكتل للنظام بأكمله بحيث يمكن لجزء PS من لوحة FPGA التواصل مع جزء PL. في هذه الخطوة، يجب التأكد من أن كل كتلة مميزة بالمنافذ الصحيحة وأنها متصلة بشكل صحيح مع الكتل الأخرى. توفر الأداة أيضا توجيها تلقائيا مع اقتراحات لمساعدة المصمم. خطوة حاسمة جدا هي تعيين العناوين بعد إكمال مخطط الكتلة. يجب تعيين عناوين IP المستوردة ل HoG حسب عمقها، ويجب ألا تكون هذه العناوين متطابقة لأي عنوانين IP. هذه العناوين مطلوبة في كود بايثون على بطاقة SD لمساعدة جزء PS في لوحة FPGA على فهم موقع العنوان في PL الذي يجب عليه الوصول إليه لقراءة وكتابة البيانات. لذا فإن الخطوة التحدي هي تطوير الواجهة على منصة بايثون التي تسمح للمستخدم بتغذية الصور الداخلة/الفيديوهات/تغذية الكاميرا الحية إلى FPGA، وعرض صورة الإخراج مع المشاة المكتشفين بعد استلام الصور المعالجة من FPGA. يحتاج كود بايثون إلى كتابة مع رسائل تصحيح مختلفة حتى يتمكن المصمم من عرض النتائج الوسيطة، وفي حال حدوث أعطال، يمكن تشخيص وتصحيح الأخطاء. تم قضاء وقت هائل في هذا البحث لإنشاء واجهة مناسبة بين ال PS وجزء PL. تمكن سكريبت بايثون لهذه الواجهة من الوصول إلى بيانات عناوين HoG بعد عدة تكرارات، وكان تضمين عدة عبارات لعرض النتائج الوسيطة مفيدا جدا في استكشاف الأخطاء وتصحيحها.

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

على الرغم من وجود قيود كما هو موضح أعلاه، إلا أن البحث يساهم بشكل كبير حيث يمكن تكييف النظام المطور بسلاسة لاكتشاف المشاة في الصور الثابتة، أو البث الحي، أو مدخلات الفيديو. تتطلب هذه الطرق الثلاث تعديلات طفيفة فقط على كود بايثون على منصة Jupyter، مما يثبت قدرة النظام على التكيف السريع مع سيناريوهات مختلفة. تشير النتائج إلى أن التنفيذ على بنى FPGA المتقدمة يحقق نتائج مشجعة، حيث أن معايير الأداء محسنة للغاية، مما ينتج عنه قيم جيدة ومقبولة. تردد الساعة المحقق مشابه للأدبيات^{السابقة 14، 15، 16، 20، 23}، مما يشير إلى أن السرعة لم تتأثر، بينما يشير استهلاك الطاقة الأدنى إلى عدم وجود مشاكل في التدفئة. بالإضافة إلى ذلك، يظهر استخدام الموارد أن جميع الموارد تستخدم بأقل من 50٪، مما يشير إلى إمكانات كبيرة لمزيد من التحسينات التصميمية.

يمكن استخدام النظام المطور في أي تطبيق يتطلب مهمة اكتشاف البشر، ويمكن تكييفه لتطبيقات الوقت الحقيقي. كما قد تركز الجهود المستقبلية على إزالة القيود المذكورة من خلال تطوير النظام بالكامل إما على الجزء الإضافي من خلال جعل منطق FPGA يقرأ صور الإدخال ويعرض صور الإخراج المعالجة بنفسه، حيث لا تزال الموارد المتوفرة على متن السفينة ما يقرب من 50٪. وأيضا إذا كان من المقرر استخدام دمج PS وPL، فيمكن تطوير الواجهات من خلال أدوات تطوير البرمجيات (SDK). يمكن أن تشمل الامتدادات الأخرى تحديد المشاة في ظروف جوية أقسى بكثير أو خلال انخفاض الرؤية، أو تحديد المشاة المحجوبين المختبئين خلف أشياء أخرى، مما يتطلب تعديلات على الخوارزمية. التعديل الوحيد المطلوب في هذه الحالات هو استبدال الأوزان المدربة على SVM بعد التدريب المناسب وفقا للتحدي المختار، وبقية النظام لا تتطلب أي تعديلات أخرى. لذا فإن النظام المطبق مناسب جدا للتكيف مع سيناريوهات تحدية أخرى بسهولة. رؤية مستقبلية أخرى قد تكون التركيز على دمج ميزات إضافية في النظام لإنشاء مركبة ذاتية القيادة بالكامل باستخدام لوحة FPGA المتقدمة.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
بايثون	بايثون	الإصدار 3.10
لوحة FPGA ألترا 96 V2	Xilinx	تم تقديمه في 2018	منصة تنفيذ الأجهزة المستخدمة لتنفيذ خوارزمية اكتشاف المشاة
فيفادو	AMD	2019.2	أداة برمجة FPGA المستخدمة لبرمجة لوحة FPGA Ultra 96 v2 باستخدام خوارزمية اكتشاف المشاة
فيفادو HLS	AMD	2019.2	أداة التوليف عالية المستوى المستخدمة في برمجة رمز اكتشاف المشاة على مستوى عال في الورقة لتصدير الملكية الفكرية (IP)