Asservissement de la caméraLa camera que nous pilotons est une sony EVID30 disposant de plusieurs fonctionnalités pour la contrôler : rotation assurée sur 2 axes PAN et TILT et zoom. Contrôle de la camera (PID / ZOOM)Pour contrôler la camera, nous avons décidé de concevoir un système de contrôle de type PID (Proportionnel-Intégral-Dérivé). Nous avons développé la composante proportionnelle et dérivée du contrôleur permettant de concevoir un système de déplacement de bonne qualité, ensuite, pour le zoom nous avons utilisé les fonctions de commande de zoom déjà implémentées dans l'API ARV. Déplacement de la caméra![]() Le suivi du visage par la caméra est réalisé par l'analyse de la position du barycentre du volume englobant du visage par rapport au centre de l'image. Pour cette analyse nous utilisons un vecteur d'erreur qui mesure cet écart et qui permet de savoir dans quelle direction il faut déplacer la caméra. Cette information va nous permettre de définir la composante proportionnelle de notre contrôleur PID, c'est à dire tout simplement le déplacement de la caméra en fonction de la position du barycentre : on tente de réduire la norme du vecteur erreur en déplaçant la caméra. Pour ce faire, on définit une 'zone neutre' autour du centre de l'image (un rectangle de dimension proportionnelle à l'image), lorsque le barycentre n'est plus dans la zone neutre, on déplace la caméra en fonction des composantes PAN et TILT du vecteur erreur. De même, une fois que le barycentre se situe dans la zone neutre on immobilise la caméra. Notez que dans cette première approche, on ne tient pas compte de la vitesse de déplacement de la caméra (que l'on considerera constante).
Fonction de zoomLa fonctionnalité de zoom de la caméra est assuré par l'analyse de la valeur maximale entre la largeur et la hauteur du volume englobant du visage de l'orateur. Si cette longueur est plus grande qu'une certaine tolerance que nous nous fixons nous dézoomons, nous zoomons dans le cas contraire. Pour coupler cette fonction de zoom avec le déplacement de la caméra il a fallu procéder en plusieurs étapes. Pilote de la caméraLe pilotage de la caméra (rotation, zoom, configuration : toutes les commandes à l'exception de l'acquisition vidéo) se fait par le port série, via le protocole VISCA. Les caméras EVI-D30 possèdent deux sockets, qui leur permettent de stocker et d'exécuter deux commandes simultanément. Cependant, la communication avec la caméra doit obéir à quelques règles. L'envoi d'un ordre donne lieu à deux retours de la part de la caméra : tout d'abord un accusé de réception, qui indique le numéro de la socket dans laquelle la commande sera stockée, puis un message d'accomplissement, envoyé lorsque la commande est exécutée et que la socket redevient libre. Le pilote de la caméra doit prendre garde à ne pas envoyer d'ordre si les deux sockets sont occupées. De plus, lorsqu'un ordre est envoyé à la caméra, aucun ordre supplémentaire ne doit lui être envoyé tant que l'accusé de réception du premier n'est pas revenu, et ce même si les deux sockets étaient libres.
Afin de respecter le protocole VISCA, il est impératif de récupérer tous les accusés de réception et tous les messages d'accomplissement, afin de suivre en permanence l'occupation des sockets de la caméra. Cependant, les temps de réponse de la caméra sont relativement élevés : pour une commande de rotation de la caméra, il faut compter entre 30 et 40 milisecondes pour recevoir l'accusé de réception, et entre 60 et 180 ms pour le message de d'accomplissement. Le pilote de l'API ARV, qui communique de façon synchrone avec la caméra, immobilise pendant une durée similaire le thread d'asservissement. Ces délais ne sont pas acceptables, notre objectif étant de fonctionner en temps réel, soit 40ms par image. Pour résoudre ce problème, il est impératif de modifier le comportement du pilote de la caméra. Celui-ci est déporté dans un thread séparé. Le thread principal, uniquement dédié au suivi du visage sur l'image, poste ses requêtes de déplacement et de zoom au thread pilote, toutes les 40ms environ. Ce dernier écoute les messages en provenance de la caméra, et bloque tant qu'un message n'a pas été reçu intégralement. Il actualise sa représentation interne de l'état des sockets en fonction de ce message. Lorsqu'une socket est libre, il peut envoyer une commande postée par le thread principal, et se remettre en écoute. En phase de suivi du visage, le thread principal n'a besoin d'envoyer que deux types de commandes : zoom et déplacement de la caméra. Les temps de réponse mentionnés plus haut font que le pilote ne peut envoyer autant de commandes que ce qui est réclamé par le thread principal. De plus, on ne doit pas trouver, à un instant donné, deux commandes de déplacement sur les deux sockets de la caméra (idem pour le zoom). Le thread pilote met donc à disposition du thread principal deux boîtes aux lettres distinctes : l'une pour les requêtes de zoom, l'autre pour les requêtes de déplacement. Lorsque la caméra renvoie un message d'accomplissement d'une commande de zoom par exemple, seule une autre commande de zoom peut alors être envoyée. On choisit dans ce cas la commande la plus récemment postée ; les autres commandes sont supprimées de la boîte aux lettres. Les commandes sont donc envoyées à leur rythme à la caméra, sans que cela empêche le suivi du visage d'être effectué en temps réel. Comme on envoie toujours la commande la plus récente d'une boîte au lettres, l'asservissement de la caméra ne souffre pas d'effet de retard.
|