Lors de la réalisation d'un robot autonome, les choix de priorité de comportement sont critiques. En mettant en oeuvre plusieurs capteurs, il y a des chances pour que les données recueillies soient d'ordres différents ou même contradictoires. Donc, mieux vaut limiter le nombre de capteurs.
Ensuite, je pense qu'il sera facile de réutiliser cette routine pour l'intégrer à des missions plus complexes, sans augmenter le nombre de communications entre le PC104 et le BS2, qui s'avèrent très chronophages.
Et puis soyons logiques : nous utilisons nos yeux pour nous frayer un passage dans notre environnement. Peu d'humains utilisent un télé-mètre à ultra-sons pour s'orienter afin de franchir une porte...
Je me suis largement inspiré du tutoriel du site www.roborealm.com, méthode "floor finder" qui permet de filtrer la texture du sol (d'ailleurs, j'aimerais aussi pouvoir en faire autant dans mon appartement... voir les vidéos précédentes...).
Ce programme est simple : il ne gère pas les coins. Concrètement, si le robot se retrouve dans un coin, il va détecter tour à tour les murs gauche et droite, sans prendre de décision de faire demi-tour. Il est coincé...
Difficultés rencontrées : j'ai fait l'erreur de vouloir améliorer la fluidité de la routine en gagnant du temps sur la communication série.
J'ai d'abord augmenté le débit de transmission jusqu'à des valeurs de 38400 bauds. C'est trop ! Au delà de 4800 bauds, la fréquence de réception des valeurs par le BS2 s'effondre, probablement à cause d'erreurs trop nombreuses sur l'octet de synchro "S". La doc du BS2 disait donc vrai...
Après plusieurs essais infructeux, j'ai donc retenu le débit de 2400 bauds, le meilleur compromis entre stabilité et performance. A cette vitesse, transférer un octet et son bit d'arrêt dure 3,75 ms : une valeur non négligeable dans les boucles de calcul du BS2 !
Ensuite j'ai réduit la quantité de données transmises de RoboRealm vers le BS2 :
Ce programme est simple : il ne gère pas les coins. Concrètement, si le robot se retrouve dans un coin, il va détecter tour à tour les murs gauche et droite, sans prendre de décision de faire demi-tour. Il est coincé...
Difficultés rencontrées : j'ai fait l'erreur de vouloir améliorer la fluidité de la routine en gagnant du temps sur la communication série.
J'ai d'abord augmenté le débit de transmission jusqu'à des valeurs de 38400 bauds. C'est trop ! Au delà de 4800 bauds, la fréquence de réception des valeurs par le BS2 s'effondre, probablement à cause d'erreurs trop nombreuses sur l'octet de synchro "S". La doc du BS2 disait donc vrai...
Après plusieurs essais infructeux, j'ai donc retenu le débit de 2400 bauds, le meilleur compromis entre stabilité et performance. A cette vitesse, transférer un octet et son bit d'arrêt dure 3,75 ms : une valeur non négligeable dans les boucles de calcul du BS2 !
Ensuite j'ai réduit la quantité de données transmises de RoboRealm vers le BS2 :
- séquence initiale = "S" [pulsation_moteur_gauche] [pulsation_moteur_droit]
- séquence réduite = "S" [comportement]
L'analyse du comportement étant réalisée par le BS2 avec une structure SELECT...CASE. L'envoi de l'octet "S" reste nécessaire pour assurer la synchronisation. Sans cet octet, le BS2 ne verrait qu'une suite ininterrompue de bits, rendant leur regroupement en octets impossible.
Les gains sont à peine visibles...
La puissance de calcul du PC104 étant limitée, c'est plutôt en travaillant sur le programme RoboRealm que les performances de la routine ont pu être améliorées :
- désactivation des 2 modules "math", inutiles sauf pour les aspects pédagogique ou debug
- désactivation du module "variables display", inutile sauf pour le debug
Il reste cependant à affiner le traitement d'image :
- optimisation des paramètres du "floor finder" pour filtrer les textures
- optimisation des bornes mini/maxi du point cible en fonction de la taille du robot
- anticiper la largeur d'une "issue", et rechercher une éventuelle trajectoire plus dégagée
Ça fonctionne, et ça semble répétable :
On peut distinguer que le mouvement est saccadé, le son est aussi révélateur. Ces irrégularités peuvent être dues à des erreurs de transmission entre le PC104 et le BS2, ou simplement à des lenteurs de Roborealm pour traiter le flux vidéo.
- séquence réduite = "S" [comportement]
L'analyse du comportement étant réalisée par le BS2 avec une structure SELECT...CASE. L'envoi de l'octet "S" reste nécessaire pour assurer la synchronisation. Sans cet octet, le BS2 ne verrait qu'une suite ininterrompue de bits, rendant leur regroupement en octets impossible.
Les gains sont à peine visibles...
La puissance de calcul du PC104 étant limitée, c'est plutôt en travaillant sur le programme RoboRealm que les performances de la routine ont pu être améliorées :
- désactivation des 2 modules "math", inutiles sauf pour les aspects pédagogique ou debug
- désactivation du module "variables display", inutile sauf pour le debug
Il reste cependant à affiner le traitement d'image :
- optimisation des paramètres du "floor finder" pour filtrer les textures
- optimisation des bornes mini/maxi du point cible en fonction de la taille du robot
- anticiper la largeur d'une "issue", et rechercher une éventuelle trajectoire plus dégagée
Le "parcours", simple pour ces premiers essais
Ça fonctionne, et ça semble répétable :
On peut distinguer que le mouvement est saccadé, le son est aussi révélateur. Ces irrégularités peuvent être dues à des erreurs de transmission entre le PC104 et le BS2, ou simplement à des lenteurs de Roborealm pour traiter le flux vidéo.
