مواضيع استخدام Raspberry pi للتحكم في FPV ومراقبتها في إطار على طول ناقلات H.264 ليست جديدة. لا يتظاهر التطوير بأنه أصلي ، وقد تم قضاء القليل من الوقت عليه (من يوليو في عطلات نهاية الأسبوع ، في بعض الأحيان).
ولكن ربما تكون تجربتي (والمصدر) مفيدة لأي شخص.
نشأت فكرة أنك بحاجة إلى إجراء مراقبة بالفيديو في الشقة بعد أن قال أحد الجيران أن شخصًا ما كان يغوص في قفل الباب.
أول شيء تم جلده هو تثبيت برنامج الحركة الشهير على Raspberry pi zero باستخدام كاميرا v1.3. من حيث المبدأ ، فإنه يحل المشكلة. إذا كنت راضيًا عن الإخطار عبر البريد و fps = 4-5.
لكن هذا لا يبدو مثيرا للاهتمام. في متناول اليد كان هناك منصة بعجلات وحزام من التجارب القديمة و 18650 بطارية من أجهزة الكمبيوتر المحمولة القديمة.
والنتيجة هي مزيج ممتع من المراقبة بالفيديو المحمول وكشف الحركة.
نظرًا لأن لدي VPS مستأجرًا ، لم تكن هناك مشاكل في الوصول من الخارج (الشبكة المنزلية وراء NAT). عمر البطارية حوالي 4 أيام إذا لم تسيء استخدام القيادة والمصابيح الأمامية.
يمكنك القيادة حول الشقة ، والتحكم عن بعد في كل من الكاميرا والمنصة وتركها في وضع الكشف عن الحركة في أي مكان مرغوب فيه.
الأجهزة
يمكن تقسيم جميع الأجهزة إلى قسمين ، لا يعتمد الأول على الجزء الثاني ويمكن استخدامه بشكل منفصل:
وحدة المراقبة بالفيديو
- التوت بي صفر
- USB WiFi Dongle
- كاميرا التوت بي v1.3
- 2x محرك السائر 28BYJ-48 + ULN2003 سائق
تدار منصة متنقلة عبر SPI من التوت
- 4S 16x18650 Li-ion + 4S 30A Li-ion 18650 (BMS) لوحة + شحن DC-DC مع تثبيت التيار والجهد
- محول DC-DC التنحي (15v -> 5v).
- مجلس stm32f103c8t6
- محركات تروس 4x + لوحة L298N
- مصباح LED 12 فولت (مصباح أمامي) + تحكم في IRF3205 (+ smd pnp و npn)
تم تكوين صورة Raspbian في وضع القراءة فقط. في مثل هذا التكوين ، ينجو التوت بسهولة من انقطاع التيار الكهربائي غير المتوقع لأنه لا يستخدم بطاقات SD للتسجيل على الإطلاق.
البرمجيات
يتكون البرنامج من 3 مكونات منفصلة.
تطبيق Android (تم اختباره على LG6 Oreo و Samsung S5 Lollipop القديم)
وضع FPV- عرض دفق الفيديو H.264 من الكاميرا بالدقة ومعدل البت المحدد
- ضوابط الكاميرا والمنصة
- تسجيل الفيديو والصور من الدفق.
وضع خدمة Android- استطلاع المضيف (بتردد محدد)
- تحميل صورة حدث "الحركة" في الإطار حسب الحدث.
مضيف التوت بي على الثعبان (picamera + spidev + RPi.GPIO)
وضع FPV- بث H.264 دفق (مع المعلمات المحددة بواسطة تطبيق Android)
- استقبال أوامر التحكم لمحركات السائر وإدارتها.
- أوامر التحكم في البث عبر SPI (إذا تم تمكين الوضع)
حركة وضع التتبع في الإطار.- كشف الحركة في الإطار (وفقًا للمعايير المحددة بواسطة تطبيق Android)
- استقبال الطلبات "وما إذا كانت هناك حركة في الإطار" وتحميل الصور عند الطلب
- الإرسال إلى المضيف (بغض النظر عن التطبيق) صورة للحركات في الإطار.
أبسط البرامج الثابتة على stm32f103- تلقي أوامر SPI
- تحكم في اتجاه دوران العجلات ومحركات PWM.
- التحكم في المصباح.
تتبع الحركة
اتضح أن التتبع على ناقلات h.264 مزاجي للغاية وعرضة للنتائج الإيجابية الخاطئة. هناك عدد قليل جدًا من تطبيقات الكشف عن الحركة لـ H.264 على الشبكة. حاولت كل منهم.
الخيار الأكثر بدائية هو حساب عدد المتجهات التي يتجاوز طولها قيمة عتبة معينة. وإذا كانت أي موجهات أكبر من العتبة ، فهذه إشارة على وجود حركة في الإطار.
للأسف. هذا الخيار مناسب فقط لتوضيح المبدأ. هناك الكثير من الإيجابيات الزائفة. خاصة على الأسطح ذات اللون والملمس الموحد.
جميع الخيارات الأخرى تعطي نتائج إيجابية خاطئة أكثر من اللازم ، أو ببساطة لا تفي بمعيار الأداء: "يجب معالجتها خلال فترة الإطار".
ونتيجة لذلك ، اخترت خياري. على الرغم من أنه لا يعطي عمليًا نتائج إيجابية خاطئة ، إلا أنه يتطلب الحركة في عدة إطارات متتالية. ولكن هذه الطريقة أفضل من الإنذارات الكاذبة عدة مرات في اليوم بسبب التغيرات في الإضاءة أو بشكل عام بسبب "الحركات" غير المفهومة في الإطار بواسطة "قرار" الكاميرا. موضوع خوارزميات الكشف الموثوقة ل mv H.264 هو بشكل عام موضوع منفصل ومعقد. تتطلب الخوارزميات الكثير من الوقت للتصحيح العملي ولدي قيود صارمة على وقت التشغيل.
مثال لمتجهات الحركة (أوضاع الأداة المساعدة للقطات):
في الأحداث "الحركة في الإطار" ، يتم إنشاء الإخطارات.
من حيث المبدأ ، لأغراضي ، اتضح أنه يمكن ضمانه تمامًا عندما يتحرك شكل بشري (> 15 ٪ من الإطار) لمدة ثانيتين على الأقل. مع هذا الخشونة من الحساسية ، ببساطة لم أر إيجابية كاذبة على الإطلاق.
التحكم في الحركة.
إدارة المنصة "بالجرار". على سبيل المثال تحكم PWM واتجاه دوران الجانب الأيسر والأيمن. عناصر التحكم (الشرائط) تحت إبهام اليدين. اتضح أنه الأكثر طبيعية بالنسبة لي.
التحكم بالكاميرا - شريحتان تلمسان تعطي الأمر لتدوير زاوية معينة (أبعد من مركز الشريط - كلما زادت الزاوية). كان التحكم المستمر للمحركات غير مريح (غير موضوعي مرة أخرى بالنسبة لي).
تأخر FPV
كانت تأخيرات الفيديو صغيرة نسبيًا (أقل من ثانية واحدة).
للتحكم في منصة مزودة بعجلات بسرعة قصوى تبلغ 3-4 كم / ساعة لتأخير PWM بنسبة 100 ٪ في 0.6 ثانية - هذا أمر طبيعي تمامًا ولا يلاحظه أحد تقريبًا.
ومع ذلك ، يبدو لي أنه حتى 0.3 ثانية من التأخير ، على سبيل المثال ، quadrocopter كثير.
أظهرت الاختبارات أن تنفيذ الترجمة في الثعبان يجلب حوالي 50-70 مللي ثانية إلى الفجوة ، مقارنة بإخراج نفس تيار H.264 عبر rapivid. بالنسبة لي ، هذه 70 مللي ثانية ليست مهمة. ولكن إذا كان أي شخص يريد الضغط على الحد الأقصى ، فعليه أن يأخذ ذلك في الاعتبار.
عند العمل من خلال "شبكة WiFi محلية" (الهاتف كنقطة وصول) ، يكون التأخر 350..600 مللي ثانية. ولكن لا يزيد عن 0.6 ثانية ومستقرة في هذا النطاق. على الرغم من أن 50-70 مترًا في المساحات المفتوحة - هذا هو مجرد اللعب. وعلى مسافة أكبر ، لا تعمل WiFi من الهاتف.
من الجدير بالذكر أن هذا في بيئة "ضجيج RF" للغاية للمباني السكنية ، مع العديد من شبكات WiFi في المنطقة.
لقد فوجئت بالنتيجة في تكوين "موجه WiFi -> مزود الزوج الملتوي -> VPS -> MTC 4G على الهاتف" عبر إعادة توجيه منفذ ssh من التوت إلى VPS.
تبين أن التأخر النموذجي أفضل قليلاً من خلال شبكة WiFi المحلية (!)
حتى أثناء التنقل في السيارة أو بالقرب من هايبرماركت لاغ كبير ، يكون 300 مللي ثانية فقط.
ومع ذلك ، في بعض الأحيان (نادرًا جدًا وغير متوقع) ، أصبح التأخر يصل إلى عدة ثوان. Recontext يساعد. ربما ، هذه بعض ميزات 4G / MTS / مقدمي الخدمة في السلسلة ، إلخ.
بعد أن نجح كل شيء ، كانت هناك رغبة في توصيل قناة الصوت في كلا الاتجاهين. من الناحية الفنية ، هذا ممكن ولا حتى صعب للغاية. لكني لا أشعر بالعبث بمكواة اللحام.
إذا لم يكن Rasberry pi "إضافيًا" ، فسيكون من الأسهل بدلاً من ذلك استخدام الهاتف القديم كمضيف للمراقبة بالفيديو وإدارة النظام الأساسي. الميزة الوحيدة للتوت على هاتف قديم هي وزن أقل. وربما أقل استهلاك الطاقة (لم يقارن).
جميع المصادر