Webcam : V1
2009 : la webcam de départ est un modèle bureautique très basique en USB 1.0 avec une résolution de 640×480.
La webcam doit être disposée au milieu du jardin au même niveau que la mangeoire, l'ensemble doit être le plus petit possible pour ne pas trop diminuer le WAF. La webcam étant USB, il faut la brancher à un ordinateur mais les câbles USB sont habituellement limités à 5m, 10-12m en utilisant des répéteurs actifs. La webcam est connectée à Popeye, il se trouve à plus de 30m de câble de la webcam… Il faut donc trouver une solution pour palier à cette longueur importante. J'ai trouvé des prolongateurs USB 1.0 utilisant un câble Ethernet pour transporter le signal USB, ils sont constitués d'un côté d'une prise USB et de l'autre d'une prise Ethernet.
Ils fonctionnent par paire : d'un côté, l'adaptateur femelle se branche sur le périphérique USB et sur le câble Ethernet. De l'autre côté du câble Ethernet, l'adaptateur sort une prise USB mâle à connecter sur l'ordinateur. Le câble Ethernet est utilisé comme support physique de transmission de signal, ce système n'est pas compatible TCP/IP.
Le défi suivant est d'installer la webcam dehors au gré des intempéries. En enlevant sa coque en plastique ainsi que celle du prolongateur, il est possible diminuer fortement leurs encombrement. Je les ai également raccordé directement ensemble en enlevant les prises USB et minimisant la longueur de câble.
J'ai choisi d'installer l'ensemble dans un petit boitier électrique étanche. J'ai découpé une ouverture avec ma dremel puis coller une morceau de plexiglas transparent avec du mastic et fixé la webcam derrière. Une petite ouverture sur le bas du boitier permet de faire passer le câble Ethernet.
Le tout est monté sur un poteau de 2,5m de haut avec une vue directe sur la mangeoire. Le câble passe dans une gaine plastique enterrée dans le jardin et ressortant au niveau du le garage.
Malheureusement, cette webcam n'est pas conçue pour fonctionner à l'extérieur mais en intérieur avec peu de lumière : dehors, lorsqu'il y a un peu de soleil, elle est éblouit et affiche une image toute blanche. Après plusieurs essais, j'ai installé un verre de lunette de soleil devant l'objectif. 
Cela permet désormais d'avoir une image non brulée mais avec une perte de couleur et de netteté.
Logiciel
La webcam est reconnue à l'aide des drivers gspca (intégré depuis la mainline du noyau) comme un périphérique v4l :
[ 33.150000] Linux video capture interface: v2.00 [ 33.400000] gspca: main v2.5.0 registered [ 33.530000] gspca: probing 046d:08a2 [ 35.420000] zc3xx: probe sensor -> 000e [ 35.430000] zc3xx: Find Sensor PAS202B [ 35.440000] gspca: probe ok [ 35.730000] usbcore: registered new interface driver snd-usb-audio [ 35.740000] usbcore: registered new interface driver zc3xx [ 35.740000] zc3xx: registered
J'ai choisi d'utiliser mjpg-streamer pour la capture d'image et la publication en http. Le paquet Debian n'existe pas, il faut donc le compiler à partir des sources.
Récupération des sources :
svn co -r 94 https://mjpg-streamer.svn.sourceforge.net/svnroot/mjpg-streamer/mjpg-streamer
Se positionner dans le dossier :
cd mjpg-streamer
Compilation des sources :
make clean all
Lancement de mjpg_streamer :
LD_LIBRARY_PATH=. ./mjpg_streamer -b -i "input_uvc.so" -o "output_http.so -w ./www"
Puis ouvrir un navigateur sur http://popeye.home:8080 pour constater le bon fonctionnement.
Après quelques ajustements d'orientation de la webcam, voici quelques images capturées :
Le rendu n'est pas extraordinaire, la qualité de la webcam y est pour beaucoup, elle n'est pas adaptée à être dans un environnement aussi lumineux, le verre de lunette de soleil altère également les couleurs.
Stabilisation
01/2010 : après plusieurs jours d'utilisation, de nombreux kernel oops ont fait leur apparition dans les logs du noyau. Le driver USB de la webcam était en cause et une fois planté, un rmmod ne suffisait pas à remettre les choses en ordre, un reboot était obligatoire. Ces erreurs étaient surement liées à une instabilité de la connexion USB du fait de la très grande longueur de câble malgré la présence des prolongateurs. Je n'ai pas trouvé de solution logicielle à mettre en oeuvre pour palier à ce problème.
J'ai alors ressortit d'un de mes tiroirs mon NSLU2 pour l'installer le plus proche possible de la webcam tout en le laissant dans le garage à l'abri des intempéries et proche d'une source de courant. 10 m sépare alors la webcam du slug.
Ce dernier sera alors en charge d'exécuter mjpg-streamer pour rendre accessible la webcam sur mon réseau.
Comme pour le serveur en i386, il n'existait pas de paquet Debian mjpg-streamer compilé pour armel, je l'ai donc compilé avec la même procédure que précédemment. Par contre et pour corser le tout, le NSLU2 n'a pas beaucoup de RAM. Il “suffit” de lui mettre un fichier de swap sur la clé USB, mais cela va provoquer un nombre très important d'écritures et brûler la clé rapidement. Une solution alternative est de mettre en place un fichier swap sur un montage NFS.
Après s'être armé de patience et quelques heures de lutte, il est finalement possible de lancer le programme :
cd /opt/mjpg-streamer && LD_LIBRARY_PATH=/opt/mjpg-streamer ./mjpg_streamer -b -i 'input_uvc.so -fps 10' -o "output_http.so -w ${MJPG_PATH}/www"
Par contre, lors du boot du slug, les modules noyaux de la webcam ne montent pas systématiquement, il faut les charger de la manière suivante avant de lancer mjpg-streamer en ajoutant l'extrait suivant dans /etc/rc.local :
# création du périphérique mknod /dev/video0 c 81 0 # chargement des modules modprobe usbcore modprobe videodev modprobe gspca_zc3xx
Voici les logs du noyau lorsque la webcam est branchée :
[ 15.619846] Linux media interface: v0.10 [ 15.770726] IXP4xx MII Bus: probed [ 15.819800] eth0: MII PHY 1 on NPE-B [ 15.973385] Linux video capture interface: v2.00 [ 16.004020] gspca_main: v2.14.0 registered [ 16.048776] gspca_main: zc3xx-2.14.0 probing 046d:08a2 [ 16.973189] input: zc3xx as /devices/pci0000:00/0000:00:01.0/usb2/2-1/input/input1 [ 17.064290] usbcore: registered new interface driver zc3xx [ 1213.743279] usb 2-1: new full-speed USB device number 3 using ohci_hcd [ 1213.961052] usb 2-1: New USB device found, idVendor=046d, idProduct=08a2 [ 1213.967980] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1213.979954] gspca_main: zc3xx-2.14.0 probing 046d:08a2 [ 1214.741868] input: zc3xx as /devices/pci0000:00/0000:00:01.0/usb2/2-1/input/input2
Puis il faut faire pointer le navigateur sur http://slug.home:8080 et voila !
Après plusieurs semaines de tests, cette configuration fonctionnait très bien et ne plantait plus. 
Détection de mouvement
03/2010 : j'ai installé un logiciel de détection de mouvement motion sur le NSLU2 pour prendre des photoslorsqu'un animal picore. Celles-ci sont stockées sur le NFS de Popeye afin de ne pas “bruler” la clé USB.
Cet outil compare le nombre de pixelx qui changent entre 2 images et utilise un algorithme de “veillissement” des zones pour s'adapter au changement brusque.
Initialement, la détection était trop sensible : plus de 1000 images étaient produites par jour, difficile de faire le tri.
J'ai alors commencé par diminuer le nombre d'image par seconde que la caméra transmet à 2. Puis j'ai configuré plus finement motion pour notamment configurer le filtre d'accentuation / réduction via l'option despeckle pour diminution les parasites.
Ensuite, j'ai configuré un masque se superposant sur les images capturées afin de réduire la zone sur laquelle la détection est appliquée. Cela permet d'exclure des régions comme le mur de la maison sur lequel l'ombre d'un arbre est projetée. Ci dessous, le masque utilisé, uniquement les zones en blanches sont analysées.
Au final, voici les parties essentielles du fichier /etc/motion/motion.conf :
daemon on process_id_file /var/run/motion/motion.pid setup_mode off v4l2_palette 8 input 8 norm 0 frequency 0 rotate 0 width 640 height 480 framerate 2 minimum_frame_time 5 netcam_url http://localhost:8080/?action=stream netcam_http 1.0 netcam_tolerant_check off auto_brightness off brightness 0 contrast 0 saturation 0 hue 0 roundrobin_frames 1 roundrobin_skip 1 switchfilter off threshold 3500 threshold_tune on noise_level 110 noise_tune on despeckle EedDl mask_file /root/mask-2012.pgm smart_mask_speed 8 lightswitch 60 minimum_motion_frames 5 pre_capture 0 post_capture 0 gap 5 max_mpeg_time 0 output_all off output_normal on output_motion off quality 100 ppm off text_right %Y-%m-%d\n%T text_changes on text_event %Y%m%d%H%M%S text_double off target_dir /mnt/media/webcam/ snapshot_filename %Y%m%d-%H%M%S jpeg_filename %m-%d/%Y%m%d-%H.%M.%S
J'ai écrit une IHM très simple en PHP pour parcourir les prises de vues et les afficher.
Alimentation
12/2010 : j'ai cherché une solution pour supprimer l'alimentation du NSLU2 en utilisant celle du serveur mais ils sont éloignés de 15 m. Je n'avais pas envie de tirer un nouveau cable électrique entre les 2 et j'avais entendu parlé du PoE (Power Over Ethernet) : le câble Ethernet est utilisé pour transporter de la donnée (bridée en 100 MBits) ET du courant.
Un câble Ethernet est composé de 4 paires; en 100 Mbits, seul 2 sur les 4 sont utilisées. Ainsi, de nombreuses bidouilles sont alors possibles : PoE, double Ethernet…
Pour mettre en place du PoE, plusieurs solutions existent sur le marché mais elles nécessitent des injecteurs : ce sont des appareils qui font circulé du 48 V continu sur les paires non utilisées. Il faut également un régulateur de tension de l'autre coté du câble pour ajuster la tension aux pré-requis de l'appareil connecté. Ce type de matériel est plutôt honéreux et est majoritairement utilisé en entreprise pour alimenter les postes téléphonique ou caméra IP de surveillance. Une alternative consiste à utiliser des injecteurs passifs plus simple et moins cher pour lesquels l'alimentation de 48V est remplacée par un bloc secteur de son choix.
L'injecteur est composé d'un port Ethernet femelle et d'une prise jack de 2.1 mm femelle. En branchant dessus un bloc secteur de 12 V, l'injecteur relie les fils 7 et 8 du câble Ethernet au pôle positif de cette alimentation et les 4 et 5 à la masse. De l'autre du câble Ethernet, l'extracteur est composé d'une prise Ethernet mâle et d'une prise jack 2.1 mâle. Ce 2e adaptateur sépare les conducteurs relié à l'alimentation vers le connecteur jack et ceux de la donnée vers la prise Ethernet. Ainsi l'appareil en bout de ligne s'utilise comme s'il était branché directement sur le bloc secteur et reçoit la donnée normalement. Néanmoins, il faut faire attention à la chute de tension se produisant sur un cable de grande longueur avec une section aussi petite (voir calcul ci-dessous). De plus, la tension n'étant pas de 48 V, ce système n'est pas compatible avec les appareils utilisant le PoE “standard”.
Calculs de résistance
La première mise en oeuvre de cette technique de POE fut pour mettre le NSLU2 dans le jardin à 15 m du serveur. Il requiert une tension de 5V sous 1A.
La chute de tension en courant continu dans un câble éléctrique se calcule avec les formules suivantes :
- loi d'Ohm : $U= R*I$
- avec U la tension exprimée en Volt (V), R la résistance en Ohm (Ω), I l'intensité en Ampère (A)
- résistance d'un câble : $R=\frac{ρ*L}{S}$
- avec R la résistance du câble, ρ la résistivité en Ω/m, L longueur du câble aller / retour, S section du câble
- la section d'un câble à partir de son diamètre est le calcul d'une aire d'un cercle : $S=π*r^2$
- avec S aire du cercle, r rayon du cercle.
Avec un câble Ethernet de catégorie 5e, nous avons :
- $ρ = 17⋅10^{-9} \,Ω⋅m$ : résistivité du cuivre
- $D = 0.64516\,mm$ : diamètre du câble, AWG22
- $L = 30\,m$ : le NSLU2 est à 15 m du serveur, l'aller retour est donc le double.
La section du câble est de : $$S=π*(\frac{D}{2})^2 \approx0.327\,mm^2$$
La résistance du conducteur est de : $$R=\frac{ρ*L}{S} => \frac{17 * 10^{-9} * 30}{0.327 * 10^{-6}}\approx1.56\,Ω$$
Le NSLU2 est donné pour consommer environ 5 W, soit 1 Ampère avec son alimentation de 5 V. La chute de tension est donc : $1.56*1=1.56\,V$. En l'alimentant directement avec son transformateur à l'extrémité du câble, il ne recevra que $5-1.56=3.44\,V$, il ne fonctionne pas avec si peu de courant. La phase de boot étant la plus gourmande, au final, il ne démarre même pas.
De plus, avec une section aussi petite et un courant aussi important, le cable mettra pas longtemps à fondre… 
Pour pallier à ce problème, il faut mettre une tension plus importante en entrée, le courant sera plus faible et donc il y aura moins de perte. Je me suis branché directement sur le 12 V de l'alimentation de Popeye.
La puissance de 5 W sous 12 V requiert 0.625 A. En reprenant le calcul ci dessus, nous obtenons une chute de tension de : $1.56*0.625\approx0.98\,V$. Donc en bout de câble, nous avons $12-0.98=11.2\,V$. Le 12 V d'une alimentation de PC n'est pas la tension la mieux régulée, cela peut être 12.2 V ou 11.8 V. Le cas le plus défavorable nous donne donc : 10.82 V. Ceci est bien supérieur à la tension nominale du NSLU2.
LM7805
Pour abaisser la tension à 5 V, le composant le plus commun à utiliser est le LM7805 : c'est un régulateur linéaire de tension à tension variable d'entrée. Le schéma de câblage est simple et nécessite que 2 condensateurs.
Le défaut majeur de ce composant est qu'il converti la chute de tension demandée en chaleur et donc il peut beaucoup chauffer.
Le cas le plus défavorable est lorsque l'alimentation du PC sort 12.2V soit une chute de tension à ces bornes de : $12.2-0.98-5 = 6.22 V$. La dissipation en chaleur est $P=U*I$ ce qui donne $6.22*0.625\approx3.9\,W$.
.
Régulateur LM2596
De nombreux autres montages existent, les régulateurs de tension à découpage sont également communs. Plutôt que d'appliquer une résistance variable comme le LM7805, ils hachent le courant avec une fréquence de 150 kHz environ en faisant varier la taille des créneaux haut et bas puis la re-linéarisent afin que la tension moyenne de sortie soit stable. Cela est beaucoup plus efficace que la solution précédente. De nombreux montages tout prêt sont disponibles sur les sites de ventes aux enchères en ligne à un coût dérisoire.
Ainsi, en mettant ce régulateur en bout de câble entre l'adaptateur POE et le NSLU2, je peux alors l'alimenter en 5V.
Le schéma de l'assemblage complet ressemble alors à cela :
Allumage automatique
Un petit défaut du NSLU2 est qu'il faut appuyer sur le bouton power en façade pour l'allumer et il n'est pas possible d'un point de vue logiciel de forcer l'allumage dès qu'il y a du courant. De nombreuses méthodes sont décrites ici ou là pour l'allumer automatiquement dès qu'il y a du courant. J'ai choisi la dernière méthode : relier le 5 V de l'USB au connecteur d'alimentation du slug.
De plus, j'ai ajouté un relais piloté par l'Arduino afin d'allumer et éteindre le NSLU2 en fonction de l'heure de lever 
et de coucher du soleil 
.
La récupération de ces heures est effectuée par un script perl maison qui parse la page de météo France puis qui ajoute des entrées dans at.
Pour allumer le slug, la commande à exécuter est ./pin.pl webcam on et pour l'éteindre ./pin.pl webcam off.
Pour l'enregistrer dans at, il faut lancer :
echo "pin.pl webcam on" | at 2012-07-24T05:36:28
Changement de boitier
02/2011 : les trous dans le boitier étanche contenant la webcam ne sont plus étanches, des petits insectes ce sont glissés à l'intérieur. J'ai changé la boite et améliorer le système de fixation interne afin qu'il soit plus flexible en cas d'évolution.
J'ai également changé la mangeoire qui se faisait vieillissante.
Fin de vie
12/2013 : le NSLU2 se met à planter régulièrement et toujours dans la matinée. En fait, il plante quelques heures après avoir démarré ou après un certains volume de données transférer : ~1 Go. Il ne répond plus au ping et aucune trace n'est laissée dans les logs stockés sur la clé USB.
Après de longues recherches et tests infructueux, je me suis finalement branché sur le port série du slug pour tenter d'y voir un peu plus clair.
Une fois la phase de boot passée et en générant du trafic, des kernel oops s'affichent en pagaille : l'USB se déconnecte régulièrement… Et comme la clé et la carte réseau sont branchés sur le bus USB, les logs ne peuvent plus s'écrire dessus et le réseau ne réponds plus.
Je pense que c'est lié à l'âge du NSLU2, les condensateurs utilisés dans la gestion de l'USB doivent être abimés mais rien n'est visible à l'œil nu. Paix à son âme. 
- realisations/webcamoiseaux/nslu2
- Dernière modification : 2024/04/01 10:00