Salut, je vais ce coup si me vider un peu le coeur si ont peu dire. J’ai eu quelques projets ces derniers temps et j’arrive à des résultats qui me déçois. Alors je me suis dit qu’il serais intéressant d’avoir un compte rendu de mes expériences.
Premièrement je considère capable de me contenter de peu, et mes compétence en programmation sont pas énorme en dehors du PHP et HTML, alors j’ai eu à utiliser des guides, et faires plusieurs recherches de plusieurs heures, par chance, j’arrive à lire l’anglais (et je cherche que dans cette langue la plupart du temps).
Alors j’ai eux trois projets, un Deskboard et une Dashcam qui c’est transformé en appareil photo et vidéo. Tous basé sur un Raspberry Pi Zero.
Deskboard
Il est mature et fonctionnel, mais ce n’est pas simple. D’abord l’idée est d’avoir un écran de 3.5" avec des informations utiles; météo, heure, date et nombre de courriel. Vu mais compétence en PHP/CSS/HTML, j’ai fais une version basé sur un Raspbian Lite monté en mode Kiosk avec Chrome.
L’idée est simple, afficher la page Web généré depuis le client. Mais au final c’est lourd, pas très rapide. le CSS ayant c’est limites, tout comme Chrome. Le Javascript devenais lourd et bref, sous un Raspberry Pi Zero, ce n’est pas vraiment top. Alors j’ai converti en Python. La j’ai gagné un peu en vitesse de réaction. Mais la lecture audio demande pas mal du processeur, et j’ai été incapable de pouvoir y intégrer mes caméra IP (en MJpeg 15fps) , a peine quelques secondes et un lag s’impose et une lenteur s’installe.
Alors il marche encore, mais le démarrage est long et des fois, pour une raison que j’ignore, j’ai aucun affichage de mon application Python, mais tous semble « OK », même les logs (de mon app) indique aucune erreur. Mais je soupçonne l’écran d’avoir « chaud » et de mal répondre, si ce n’est pas le Raspberry Pi en lui-même. J’ai été en mesure d’y ajouter un thermomètre et de sortie l’audio via le Bluetooth (ce qui est relativement facile). Et ce en CLI, le bureau n’ayant que le GUI de disponible (pas le « bureau » et etc…).
Alors en résultats;
-
Les écrans sur GPIO : Sur papier c’est bien, mais ce n’est pas vraiment un remplacement fiable pour un mode en CLI ou pour démarrer un nouveau projet. D’abord il faut installer le pilote et « ho! » Surprise! Il ne va rien te montrer sauf un écran blanc, durant le démarrage, et ça peut durer jusqu’au « login prompt ». Alors si il y a un bug, pas de réseau etc… tu es un peu dans la « … » .
-
Le Raspberry Pi Zero Sur papier, il semble formidable, en usage, il est d’une lenteur épouvantable, ce qui prend 15s au RPi3 à faire, lui il le fait en 3 fois plus de temps et ce, unique si il est « focusé » sur cette « job ». Le Wifi est d’une lenteur épouvantable, même collé sur le Routeur. Par contre, la consommation est très faible, marche parfaitement sur des batteries de tout type et des « USB Bank » de tout calibre. Il est possible d’y ajouter un TV-Out en 2 petite soudure et une ligne de code dans la config de base, et il est facile d’ajouter et de souder le GPIO Header , si besoin il y a. SOnt format très compact le rend intéressant comme Raspberry « Laboratoire », avant de transposer sur un autre Raspberry. Plusieurs Hats permette de garder el coté compact tout en ajoutant 4 port USB et un port ETH RJ45 par exemple. Et les plastique modulaire pour le protéger sont intéressants, mais relativement peu utile.
-
Mode Kiosk Le RPi 0 est clairement pas fait pour ce mode, même en limitant ces besoins, il est lent et peut réactif. Soit que tu apprend à vivre avec, soi tu trouve un Raspberry Pi plus puissant. SI tu désire l’utiliser pour que des visiteurs ponctuel l’utilise, il vont vite déchanté.
Dashcam et piCAM
La base du Dashcam a servi de tremplin pour le projet de piCam. La base de la Dashcam était d’avoir une caméra auto activé au démarrage et qui enregistre des segment de ~5 minutes. Lumière Infrarouge, caméra 1080 5MPx pour Raspberry Pi sous un Raspbian Lite et une carte mémoire de 64gb.
Premièrement, une Dashcam doit démarrer rapidement, 20 à 45 secondes c’est vraiment trop long. Après, l’infra-rouge des caméra sont difficilement ajustable, ce qui décolorise beaucoup, et n’ont une porté vraiment que de 3 mètres, voir encore moins. ET le contrôle de la stabilisation de l’image n’est pas vraiment conçu pour les vibrations d’un véhicule.
Mais la, j’ai été pourtant vers la solution la plus simple et la plus « Performante »; raspivid.
J’adore cet outil pour la caméra du Rapsberry. C,est le seul moyen que j’ai trouvé pour avoir un « Preview » et enregistrer en même temps. J’ai été en mesure d’ajouter un « timestamp » et de contrôler la qualité, j’ai eu a jouer avec l’inclusions de mode de copie sur USB et de faire des actions sur l’écoute de boutons ajouté sur le GPIO.
Pour la piCAM c’est le même principe, j’ai utilisé que « raspivid » et « raspistill », et j’ai fait quelques modes. Tout d’abord le « Preview » qui fait que te montrer le « Preview », pas d’enregistrement. Après il y a le mode photo; pas sorcier, quitte le mode « preview » et prend la photo, sauvegarde, et réouvre le mode « preview ». Pour le mode « Vidéo » et « Streaming » c’est le même principe mais sauvegarde avec un « preview » ce que la caméra capte. Format brute de .h264. Sinon le mode « streaming » permet d’ouvrir un serveur tcp (option de raspivid) et de s’y connecter. Il s’assurer d’allumer les services réseau, qui sont désactivé au démarrage, pour limiter le temps de chargement et la demande en alimentation. Dernièrement j’ai voulu ajouté l’audio à la vidéo, mais après plusieurs essais, j’abandonne.
Alors en résultats;
-
Vitesse encore absente : Même sans « GUI » proprement dit, la solution de « raspivid » est la plus rapide mais quand même très lente. J’ai vite ignorer le code en Python, qui est trop lourd pour le RPi0 et la vidéo. « Raspivid » lui est direct, mais la moindre demande d’un autre processus et le fichier de sortie en sort avec des frames manquant et des avancement rapide. Même en limitant le FPS et le Bitrate, je n’arrive pas a maintenir une vidéo stable, résultat; des fichier de « 5 minutes » qui dure 3 minutes, ou 7 minutes en lecture.
-
La vision de nuit : Expliquer moi dans quel contexte une caméra de nuit peut être utile si elle ne vois pas plus de 1 mètre fiable ? Dans un contexte très rare ou tu es dans une caverne, sans lampe de poche et que tu veux filmer des fourmis ? Je m’attendais pas à la vision de nuit des militaire, mais d’être en mesure de filmer la voiture stationner devant moi, sans phare et en ville ou de pouvoir filmer le monde autour d’un feu de camp, sans devoir être à coté d’eu exactement.
-
Passage des « modes » : Le temps qui est pris pour fermer (par « pkill ») et d’ouvrir le « raspivid » ou « raspistill » et commencer l’action est très long. Moi je connais mon matériel, mais j’ai laissé l’appareil a un ami, et vu que tout était très long, il a activé deux ou trois modes et un peux « mêler » les activités. Au point que les fichiers image et vidéo était des fois créé avec 0 octets. Alors ce n’est pas 10 secondes, mais que 3 secondes. Alors passer d’un mode, l’arrêter etc… est lent, pas très pratique, c’est pas mal mieux de prendre son cell, ouvrir l’applicatoion et focusser.
-
Le microphone : J’ai pris le SPH0645 de Adafruit. J’ai suivi le guide et malgré un petit accrochage (besoin d’une commande sudo), et bien il faut dire qu’il marche bien mais très très dur a manipuler. L’idée n’est pas d’avoir une qualité sonore de fou, juste de quoi pour que quelqu’un devant la caméra puisse dire un message. Ce microphone est du 32bits floating en 8kHz mono, un setting des plus étranges que j’ai vu. Ce format est incompatible avec plusieurs applications et formats audio, ce qui n’aide pas. c’est que l’audio des formats et des application utilisent du 8bit (low quality) 16bit (mid-range) ou 24bits (high quality), le 32 n’est pas reconnus dans d’autres format et même que FFMpeg ce trompe et lui associe plutot du 16bit (PCM 16 au lieu de PCM 32). Après du 8kHz c’est la qualité … du téléphone de ta grand mère… 8kHz = téléphone, 11kHz = téléphone touchtone, 22kHz = qualité casette, 44kHz = qualité CD et 48kHz = qualité Studio et il y as encore plus haut, mais la c’est du plus que pro, mon PC est configuré en 48kHz vu qui est relié à une console de mixage et sur un cinéma maison, le son est plus « profond ». Bref, 8kHz c’est bien pour la voix, mais pas pour le reste. Mais le problème n’est pas juste ça, il est pratiquement impossible de synchroniser le son avec l’image. Il est possible de « offset » la piste audio ou vidéo dans FFMpeg, ce qui « fix » le problème de la vidéo qui démarre 3 secondes avant que FFmpeg commence le travail, ce qui fait buffer déjà la vidéo, mais ce « boot time » n’est pas statique dans le temps, alors des fois 3 secondes est requis, des fois 4 secondes. Mais si ce ne serais que juste ça… encore là, ont as aucune fluidité dans la vidéo, même à faible dimension. FFMpeg passe les encodeur de 0.6x à 1.2x, et déséquilibre tout, au point qui stop la synchro audio (bref stop le son) incapable de le positionner dans des frames égale. J’ai tenté le « copy », le « mp3 », le « aac », le « flv », le « mp2 », le « mp4 » pour la piste audio comme vidéo et le firchier de sortie, rien à faire, ce n’est pas stable.
-
Le Raspberry Pi 1 VS Zero (sans W, W et WH) : Le Raspberry 1 est mieux que le Raspberry Zero sur le plan vitesse, même si sur papier le Raspberry Pi Zero est plus rapide (CPU). Je ne peux pas dire pourquoi, mais seulement transférer la carte SD de un a l’autre pour comparé, même si tout codé sous le RPi0, c’est le RPi1 qui gagne, mais du a un problème de GPIO et d’espace, je devais prendre que mes RPi0.
Pi Hole (avec un USB+ETH Hat, sans Wifi)
Ce n’est pas mon projet, mais l’un de ceux populaire. Il est conçu pour le Raspberry Pi Zero, mais je me demande qui vraiment l’utilise ?
Pour ceux qui ne connaissent pas, le PiHole est l’idée d’avoir un contrôleur DNS qui filtre les addresses, et bloque les demandes qui sont en lien avec de la publicité, le suivi, l’hamçonnage etc… et d’autoriser les autres. Il veux aussi rendre l’accès plus rapide en gérant sont propre cache. Il est possible aussi d’y ajouter des règles réseau et même de créer tes entrées pour inventer des noms réseau. Bref, c’est un Routeur sur les stéroïde… sur papier.
Dans les faits, c’est un trou noir de déception et de frustration. Oui il fait ce qui a sur le papier, mais les plus observateurs remarqueront plusieurs soucis;
-
La vitesse : Malgré le cache des DNS et des listes blanche, les accès aux sites web sont de 2 à 10 fois plus long comparé à ma configuration habituel « standard ». Aucun gain de ce côté.
-
Les filtres : Malgré mon suivi précis du Pi Hole et de mes visites Web, j’ai été incapable d’accéder à mes sites de Streaming légaux, tel que « Tou.tv » et sur Youtube j’avais que de la publicité, les vidéo refusait de partir. Dès que je désactive le filtrage, et utilise le bon vieux « adblock » de mon Chrome, je pouvais lire mes vidéo sans aucune publicité.
-
P2P et connections maintenus : Steam est devenu fou par moment, perdant la connection souvent etc… serais pas idéal pour un gamer online, ce qui n’est pas mon cas, mais quand même. Les Torrent ont été incapable d’atteindre des vitesses appréciable.
-
Confidentialité : La force du Pi Hole est surement trop fort, car plusieurs sites que j’utilise ne voulais pas marcher en connections utilisateurs; Facebook, Google (certains services), Paypal, radio-canada.ca, tou.tv que pour nommer quelques uns. ET j’avais retiré mon ad-block pour m’assurer que les bugs sont du PiHole et non du navigateur.
Résumé
Le Raspberry Pi Zero est bien si tu veux faire de quoi très simple qui demande peu d’usage sur la carte SD et peu d’usage du réseau. Il doit surement mieux performer dans des projets de gestion « headless » de servo moteur et de relais. Comparativement à un PC, je lui donne la performance d’un Pentium 233Mhz pour être généreux. L’utiliser en mode bureau est un « calvaire ». Mais pour tester des concept, des modules et chapeaux, il va répondre présent, mais tout ceux qui désire un « mini pc », fuiyez cette version.
Pour la caméra, ça marche du tonnerre, sur les Rpi 2, 3 et 4 il doit être parfait, la qualité est superbe et le potentiel des applications est fabuleuse. Le source des applications sont disponibles, certains ont fait des ajustement pour des situations donnés, mais étrangement aucun pour y inclure l’audio. Faire une caméra IP me semble la seul solution vraiment intéressante. Peut être créer deux serveurs (un vidéo, l’autre audio) pour ce type de projet pourrais rendre le tout intéressant.
Ce que j’ai détesté avec les GPIO est leur structure. J’ai eu a utilisé un module RTC, un module de température et un module audio, les 3 utilise pratiquement tous les pins dans les 12 premiers, ce qui rend l’utilisation d’un module impossible à cause de la présence de l’autre. Par exemple, j’ai commandé deux modules RTC, l’un qui prend les pin 1 à 10, l’autre les pin 1,3,5,7 et 9, je perd automatiquement 1x 3.3.v les connection « i2c » les connection « RX et TX » sur le plus gros, et le « 1-wire ». Alors il faut si possible déplacer les pins (ce qui est impossible avec les i2c RX et TX par exemple), soit trouver un « splitter » de GPIO, car en plus avec un écran, les pin 1 à 26 sont inutilisables par les autres, même si dans les fait ce n’est qu’une fraction qui sont utilisé par l’écran. De plus, rendre le « i2c » si limité quand il peut gérer plus d’un module (avec les addresses) est un non-sens de mon avis. De plus, j’ai pas réussi à trouver de « hub à i2c ».
La numérotation des GPIO a de quoi à créer des situations complètement dangereuses; Le numéro des pin n’est pas identique à celui des GPIO, et de plus, les numéro des GPIO ne sont même pas dans l’ordre. Par exemple, les pins 29,31,33,35 et 37 sont défini comme GPIO # 5, 6, 13, 19, 26. Moi qui est de nature un peu dysleptique, j’ai placé quelques cables aux mauvaises places et interchangé parfois des boutons de place. J’ai fini par m’imprimer une feuille rempli de GPIO avec les identifiants et infos, et de faire mes croquis dessus et de me faire des guide de référence pour manipuler tellement qu’ont peut s’y perdre.
Certain diront que je suis peut-être pas fait pour ça; oui peut-être… mais j’aime la logique aussi, et quand je ne la comprend pas, j’ai de la misère à me repérer.
J’ai fais ce « roman » car je crois que certains ce lance dans des projets avec des résultats parfois au dessus de la réalité des Raspberry. Même moi je me fais avoir par le charme de ces petites bêtes, et je vais quand même y passer encore du temps. Mais il est claire que les Raspberry remplaceront pas les objets techno du quotidien et qui reste quand même de parfait outils d’apprentissage et de base pour des projet de domotique et d’interaction avec le mode réel, et que le choix du Raspberry est très important. Le RPi0 reste également un beau « jouet » pour passer un peu de temps et faire des apprentissages.
Merci de m’avoir lu