Poursuite automatique sur caméra PTZ

Le contexte

La surveillance côtière consiste à repérer les embarcations qui circulent dans une zone et à les garder à l'œil. Sur les sites équipés, cette veille s'appuie notamment sur des caméras motorisées longue portée, que l'opérateur pilote à la main depuis un poste de supervision. Cependant, cette conduite manuelle mobilise un opérateur par caméra, repose sur une vigilance que la fatigue érode, et ne laisse aucune trace exploitable de ce qui a été observé. Ma mission consiste à déterminer si cette veille peut être confiée à une chaîne de traitement automatique, sur le matériel déjà installé, sans dégrader la qualité d'observation attendue par l'opérateur.

Pourquoi la mer est un cas difficile

La détection sur une scène maritime ne ressemble pas à de la détection sur route ou en intérieur. Le fond n'est jamais deux fois le même, et plusieurs difficultés se cumulent.

• La houle crée des motifs qui bougent en permanence sans jamais constituer un objet
• Une même classe d'embarcation occupe quelques pixels au loin et une bonne partie de l'image à courte distance
• Les conditions de lumière varient fortement : contre-jour, brume, pluie, crépuscule
• Le zoom modifie la perception du mouvement, ce qui interdit un réglage unique de la commande
• La définition de la vidéo reste limitée au regard des distances observées

Les choix techniques

Trois critères ont guidé la sélection de chaque brique, fixés avant toute comparaison : voir des cibles minuscules, tenir le temps réel sur le matériel disponible, et pouvoir être intégré dans un produit. Le troisième s'est révélé le plus discriminant.

• La famille DETR plutôt que les détecteurs à ancres : elle évite le filtrage des doublons, dont un réglage trop sévère fusionne une bouée et une embarcation alignées, et trop permissif laisse passer des redondances
• RF-DETR s'appuie sur un extracteur pré-entraîné sans annotations, ce qui lui demande beaucoup moins d'exemples pour s'adapter à un jeu d'images constitué en quelques semaines
• ByteTrack conserve les détections de faible score pour une seconde tentative d'association : quand une petite embarcation s'éloigne et que son score chute, sa trajectoire survit au lieu d'être coupée
• La licence a pesé autant que la performance. Certaines briques plus efficaces sur le papier obligeraient à publier le code de tout produit les intégrant, ce qui est rédhibitoire pour une preuve de concept destinée à devenir un produit. Toutes celles retenues sont sous licence permissive
• ONVIF pour la commande, parce que c'est un standard : le système fonctionnera avec d'autres caméras que celle installée

Ce que le système fait, et où il s'arrête

Les essais menés en conditions réelles montrent que le système peut faire de la détection multi-cible, poursuit une embarcation de taille normale pendant plusieurs minutes, en temps réel, sans dégrader l'image présentée à l'opérateur. Cependant, il décroche sur les cibles les plus petites et les plus rapides. Le domaine d'emploi est donc connu, ce qui vaut mieux qu'un système dont on ignore à partir de quand il cesse de fonctionner.

Trouver le maillon faible

Le système décroche sur les cibles petites et rapides, mais lequel des trois maillons en est responsable : la détection, le suivi ou la commande ? La question décide de l'endroit où porter l'effort suivant. Pour la trancher, j'ai comparé les enregistrements des poursuites réussies et de celles qui ont échoué, sur deux mesures : le nombre d'images où la cible n'est pas détectée, et l'écart moyen entre la cible et le centre de l'image. Le lien apparaît sur la première, pas sur la seconde. Autrement dit, quand la cible est détectée, la caméra vise juste ; ce sont les instants où elle ne l'est pas qui hachent la poursuite. C'est donc la disponibilité de la détection qui limite le système, et l'effort est passé du réglage du régulateur à l'amélioration du détecteur.

• L'enregistrement des sessions permet de rejouer la même scène avec deux réglages différents. La mer et la lumière n'étant jamais deux fois les mêmes, une comparaison faite en direct ne prouverait rien
• Un banc de réglage intégré à l'application modifie un paramètre sans redémarrer.
• Sans ces deux outils, le constat serait resté une impression

Ce que j'en retire

• Mesurer avant de décider : sans protocole d'essai reproductible, on optimise ce que l'on sait mesurer plutôt que ce qui limite réellement
• La chaîne de vision complète, de la constitution du jeu d'images au déploiement d'un moteur d'inférence optimisé
• Des bases d'automatique acquises sur le terrain, en concevant une boucle qui doit rester stable malgré son retard
• Un critère que je n'avais jamais considéré : la licence, qui peut rendre inutilisable une bibliothèque performante
• Le conditionnement d'une application pour un poste isolé, où rien ne peut être téléchargé à l'installation