Video en direct

Bonjour à tous,

J’ai un projet de raspberry (pi zero 2W ou autre) pour transmettre données gps et 2 flux de vidéos en direct via un module AR1021X qui a une portée suffisante. J’aimerais utiliser 2 caméras FPV (caméra couleur et caméra thermique), les vidéos seront affichées sur interface mobile.

J’ai besoin d’aide, je sais pas si les composants sont bon choisis ou il me faut d’autres composants…
Merci d’avance🙏

Ce que je peux te dire, c’est qu’une seul caméra peut être connecté en USB vu que les caméra utilise 100% de la bande USB 2.0 pour le signal. Alors il te faudra la caméra thermique en USB et le second sera via le port caméra dédié pour les PiCamera.

Pour le GPS, tu peux ajouter un module facilement via le GPIO ou USB. La demande USB est minime et ne devrais pas interagir avec la caméra.

Il te faudra une bonne carte SD’ un RPi 0 v2 est comme un RPi 3, mais en vraiment plus compact. Tout dépendant de la résolution et des logiciel, tu devrais être en mesure de réaliser ton projet.

Pour la capture des caméra, je te conseil « motion », qui peut en gérer plusieurs en service et faire le stream direct par port. Un interface Web minimal permet la configuration et les ajustements a distance.

Motion Eye OS serais pas contre trop gros pour tes besoins, mes tests ne sont pas intéressant pour le mode production, car il crée un lag parfois immense et semble lourd sur le OS.

Bonjour,

Merci beaucoup pour votre aide, donc on peux dire qu’on peut pas utiliser de caméras FPV,
alors vous pouvez m’en dire plus sur le module AR1021X que j’aimerais utiliser, ce module dispose deux interfaces USB2. 0 et UART, je pensais de l’utiliser pour étendre la portée mais quelle interface sera idéal pour le connecter au RSPI pour transmettre ces données ?

Merci pour vos conseils

Le AR1021X est un module WIfi de longue porté. Il ce connecte via le GPIO (selon la photo), mais indique qu’il utilise le USB. Je ne touche pas à ce genre de module, alors je ne peux parler qu’en me basant sur la specs et mes humble connaissances. Perso, si je n’ai pas de guide ou de confirmation qui est compatible pour les RPi, je songerais à une version en USB. Si c’est le cas, l’ajout d’un hub alimenté aiderais grandement.

Mais ce composant ne sera surement pas le problème, surtout si tu met la main sur un guide pour l’utiliser avec un RPi.

Le problème sera les caméras. Ce que j’imagine est une config pour une piCamera via le port dédié (CSI), et l’infrarouge/thermique, via un port USB.

Depuis L’arrivé du USB 2, toutes les caméras du marché sont conçu de manière non optimisé pour l’utilisation du USB. Au lieu par exemple de compressé le signal pour limiter l’usage de la bande USB, il le laisse non compressé, laissant le pilote faire ce travail. Ceci fait que les caméra sont peux coûteuse, mais affreusement gourmande en bande USB. Mettre une caméra sur un port USB 3 ne change rien à ce fait, vu que ce port tombera en compatibilité USB 2, avec les mêmes limitations. Cependant, il est possible d’ajouter sur le port USB d’autres appareil vu que la limite de charge est de 1.2A et que la majorité des autres appareil en USB (bref, tout sauf les caméra et signal vidéo) exige peut d’alimentation et de bande passante. Les caméras USB 2 ont besoin du CPU pour être performant.

Sur RPi 1, 2, 3, les 4 ports USB sont offert par un HUB et ne sont pas dédié. Sur le RPi0 v1.x et v2 n’ont qu’un seul port USB pour ~500mA, avec un peak possible à ~1A (selon mes tests avec RPi v1.x).

Je met la caméra normal sur le CSI vu que je doute tu soit en mesure de trouver une caméra IR/Thermique pour ce type de connecteur (CSI).

Sur papier, le RPi 0 v2 peut remplir ce que tu demande, mais j’irais vers le RPi 3 B+ ou 4/1GB pour le faire. Surtout si tu utilise plus d’un port USB. L’accès CSI est standard sur ces modèles et offre un meilleur rendement de partage de l’alimentation que les RPi 0 v2. Deplus, le RPi 4 offre plus de puissance pour le CPU, ce qui va aider a réduire le LAG du au traitement des caméras, et en plus, le boot sur un média plus rapide que les cartes SD sont possible.

Pour le Wifi, cherche a savoir si tu peux améliorer simplement celui du RPi par l’ajout par exemple d’antenne externe, via une soudure sur la carte ou le transfert d’antenne vers des pins du GPIO.

Mais selon des réponses sur des forum, changer les antenne d’un RPi viole les certifications et peut mener à des amendes si il cause des interférence en dehors de la réglementation. Le best est l’ajout via USB d’un Wifi plus puissant. OU si tu as le coeur, via le GPIO comme avec la pièce que tu propose.

Bonjour,

Merci infiniment pour votre réponse🙏,

On dirait que mon projet semble un peu compliqué, en réalité mon projet est un drone équipé de quelques capteurs (caméra couleur, thermique, gps, GY91, capteur de Gaz), j’ai fini le développement du drone, maintenant je suis en train de réfléchir sur quelle carte de développement que je vais utiliser pour seulement transmettre ces données via wifi à une interface python que j’ai conçue. Je suis tombé sur esp32,Arduino bcq de documentation dit ces cartes arrivent pas à supporter toutes ces données, c’est là que je vois le raspberry pi, Je sais si c’est un bon choix de choisir le Raspberry dans ce projet ou il me faut autre type de carte plus simple, sachant que les caméras sont pas de hautes résolutions 5Mp pour le couleur FPV/SPI/UART/USB, caméra thermique basse résolution SPI/I2C/UART… La transmission via wifi

Merci d’avance

L’autre problème sera aussi l’alimentation, seul les deux caméra prendra dans les 1A, le RPi Zero c’est 250~750mA, un RPi3 ou 4 c’est 1~1.5A, les autre capteurs c’est dans les 100~500mA.Alors un bloc de 5A serais requis. Alors les batteries devront être bien choisi, pour leur poids et leur capacité. Tout dépend aussi de l’autonomie requise.

Pour le débit de donnée, sur le papier le RPi sera mieux, mais si tu optimise un code pour les fonction requise seulement, tu peux arriver a avoir besoin de moins.

Après faut voir aussi le flux de donnée, ce qui est requis et savoir si un noeud sera causé par le Wifi.

Si le temps réel n’est pas requis, il serait peut-être plus facile de collecter et enregistrer pour après extraire les données pour les consulter, tu éviterais alors tout le côté réseau et Wifi.

Merci beaucoup,

Dans mon projet, la transmission en directe est nécessaire, je vais essayer avec le pi 0, avec ce module connecté via interface UART, il prendra en mesure de transmettre ces données ou c’est mieux par USB ?
Dans le manuel, il est compatible avec RPi

Perso je prendrais via UART ou tout autre chose via le GPIO, car par USB, je me dit que tu as une interface qui est géré par le OS, dont une étape en plus, bref, tu est plus direct avec ton matériel avec UART qu’avec USB.

Pour donner une chance au RPi0 de bien rouler, il faut retirer déjà tout ce qui est inutile au projet. Par la suite, utiliser le moins de libraire et autres chose demandant du CPU pour permettre à tout les senseurs, cams, etc… de marcher au mieux de leur potentiel.

L’intégration des élément au projet doivent être vérifier étape par étape, pour déceler la ou ça peut avoir des problèmes. Et tu n’auras qu’a débugger ce dernier ajout que l’ensemble du projet. Et tu pourras voir avec le temps ce que le projet exige réellement en puissance et en alimentation.

Vu que le temps réel est ton point le plus important, il faudra établir ton lien Wifi en premier. Après tu y va avec les caméras, senseurs, etc… Si tu songe à utiliser un Wifi ajouté au RPi, pense a désactiver le support Bluetooth et Wifi interne du chipset, tu gagneras un peu de puissance. Tu peux également désactiver l’affichage, et/ou de lui forcer une basse résolution, ainsi que réduire la demande de la mémoire dédié au GPU.

Si possible, le OS j’opterais pour un plus ancien, genre Debian buster ou bulleyes. Car étant un peu plus vieux, les guides sont plus facilement trouvables. Leur exigence matériel plus faible, et par conséquent, moins lourd comme système « de fond ». Je n’ai pas l’intention moi même de changer les OS de mes RPi pour le bookworm, je n’ai pas de RPi 4 et 5. J’aime mieux la philosophie Raspberry avant l’arrivé du RPi 4. Sauf les zéro, que j’aime, mais qui sont peux performant (v1.x).

Plusieurs vont recommander DietPi, qui semble en effet plus légé sur papier, mais dans mes tests, j’ai rencontré tellement de problèmes pour mettre en route des choses pourtant simple, et que je ne pouvais pas simplement copier mes lignes d’install de Raspbian à DietPi, que j’ai abandonné sont usage assez vite.

Après faut faire un test sur la durée, car les performances peuvent ce dégrader avec le temps.

J’ai par exemple monté un projet de « dashcam »; Raspbian Buster Lite, RPi zero v1.3, RPi Camera. Rien de compliqué, ffmpeg pour capturer la vidéo via l’exécution de raspvid pour avoir l’image en sortie analogique sur un écran de tableau de bord, 320x240.

La coupe des fichiers était au 2 minutes, j’ai testé le 3 et 5 minutes, mais j’avais plus de problème que je vais exposer ici. La vidéo dans les premiers moments était relativement fluide, et de bonne qualité, mais en exécution plus long, la durée des fichiers, la qualité et le fps ont été grandement affecté, jusqu’à des manque de plusieurs minutes.

L’usage d’une caméra demande beaucoup au CPU et au système, le RPi zero v1.x peut faire marcher une caméra et en faire le stream (j’ai deux caméra de sécurité basé sur ça) mais faut aucune affichage, aucune autre process que « motion » en exécution, un usage minimal de la carte SD. Dès que je passe par exemple « sudo apt update », j’ai un lag vidéo ou même une perte de lien vidéo. La résolution est de 720x480 mjpeg 30fps (~15kb/s de stream).

Vu que c’est pour un drone, je passe vite sur le fait qu’il faut un reboot à la semaine idéalement.

Tk j’arrête la, ça te donne une idée qu’il faut penser à pas mal de truc, et de que le projet est réalisable, mais prendra du temps. Ce n’est pas comme un PC ou qu’ont fait qu’ajouter des appareils USB, code quelques lignes et tout est en ligne. Mais bien aller comme un « R&D » pour créer un produit depuis zéro.

Encore merci de ta part, ça va m’aider à prendre le relais tout ça,