La reprise !

Après un nouveau déménagement, il est plus que temps de se remettre à bricoler... Les wheel encoders ne sont toujours pas au point, et ces capteurs apporteront beaucoup au robot. Au boulot !

Reprise en douceur avec une base de routine d'initialisation. Une base seulement, car je projette d'étoffer ce programme pour contrôler l'état initial du robot, toutes missions confondues : énergie, capteurs, actionneurs, constantes... Un programme standard qui trouvera facilement sa place dans un des slots du BS2PX qui patiente toujours dans son emballage.
Fonctions de la fameuse routine : contrôle de la tension, puis alignement des roues sur les codeurs (détection d'un front descendant). Simple, mais cela devrait permettre de démarrer les programmes de wheel odometry dans des bonnes conditions de mesure.

Après cette pause estivale, j'ai à nouveau remarqué que le neutre des 2 servos de roues a bougé. A cause des batteries, leur potar de réglage n'est pas accessible sur mon Boe-Bot. Pas sans démontage partiel en tout cas... Et pourquoi pas un neutre logiciel ? ça coûte seulement 2 constantes...

Wheel odometry : hundreds of tests

I started this robot session by "re-centering" the servos : no rotation for pulses duration = 750. A very basic and mandatory tuning. I ran the calibration routine "calibrate_all.bs2", and this time, I could take advantage of the sun light that is supposed to give better results because of the photoresistor. Let's assume that the term "sun light" is appropriate for this cloudy sunday afternoon in Paris...
Today's value of SDIRINC = $719C
This is similar to the previous calibrations : $70F9, $7211, $71AC...

Okay... Then I spent a good amount of time running test programs, slightly adjusting the calibration values and tuning the "wheel_odometry.bs2" program.
Each run is recorded using the wheel encoders, and these coordinates are imported into Excel to compare the record to the real path :

I managed to find some acceptable SDIRINC values, but they seem to be "dedicated" to a type of motion :
- $6A40 for continuous motion (rotation using the 2 servos at a different speed)
- $7000 for "discrete" motion (rotation using one servo stopped and one servo at full speed)...

Obviously, the wheel encoders require some extra work before this endless project can move to the next step !

Wheel odometry for beginners

This is the third and last step of the wheel encoders training provided by Parallax. We are going to learn how to record the robot path : it's called Wheel Odometry.

After the usual program modifications to fit my robot specs, the "wheel_odometry.bs2" is loaded into the BS2.

I tried to run the program with the default calibration values. The Boe-Bot follows a clover shape while each encoder pulse is recorded and stored to EEPROM. Then I used Excel to plot the path because the coordinates were not properly centered when using the Parallax "botplot.exe". At first, the result seems to be good, just like the manufacturer example !

Actually, the robot was not following this path... Need calibration data ?

The program accuracy relies on 2 constants that are specific to each robot :
- SDIRINC : this value is given by the "calibrate_all.bs2" program that I used after mounting the sensors.
- SPOSINC : this constant depends partly of the distance between the wheels. This distance is normally about 10 cm, but on my robot, the wheel servos are mounted outside of the chassis and there is a camber angle due to the bot weight. The constant had to be recalculated :

After a couple of tests, I came to the conclusion that my calibration constant SDIRINC is false. I kept setting this value lower and lower to get a plotting that looked like the actual robot path. The initial value was $7211 (dec 29201)...

What I want now is to improve accuracy. To do so, I'll try another calibration with day light (because this part of the calibration process uses a photoresistor...).
If I can't have better results with the "math" method, I will have to work with dichotomy in order to approximate this value. I must admit that I did not get exactly what constant produces what effect on the measure... Maybe understanding this could be a good start.

Well, I am closing this post with more questions than answers...

Wheel encoders, part 2

Bonne Année !

Last post was about wheel encoders calibration. Following the Parallax instructions, I got 64 bytes of data and 3 constants which are specific to my robot.

Today, I tried the provided "proactive" navigation. The "Wheel_Motion.bs2" demo program has been modified to meet the configuration of my Boe-Bot :

- Calibration data bytes and constants

- Pin assignment

This routine works quite well ! The program starts with a 1 meter square motion, each side being achieved with speed ramping, a angular correction. The robot finishes its path with a constant error : a 3 cm gap and always in the same direction. This value could probably be improved with a better calibration. I could change the rubber bands on the wheels or execute the calibration procedure on the floor (instead of the desk) to get the same friction...

Please note that to get this constant level of accuracy, the start position has to be constant either, and the wheels have to be at the same angle relatively to their sensor.

Then I ran the complete demo sequence : square, octagon, 2 spins. The final position and azimuth are still constant. Of course, errors keep adding at each path, like always on a robot.

By reusing this program I will be able to have the robot to come back to its mission starting location. Example of behavior : leave the base to find a labeled obstacle, push it down, come back to base". To do that, it will have to monitor/record its path during the beginning of the mission.

This should the next step in this encoders training...

Suivi d'objet - Object Tracking

When I started to improve my Boe-Bot with vision, my inital goal was to make it follow a color object. I managed to do some successful tests but it's time to finish to program this behavior.


To simplify image processing, the tracked object will be a bright color, easy to spot in my apartment environment. This yellow commercial item will be just fine :

Image processing steps, applied on this screenshot :

First, the "Mean Filter" reduces the noise, especially when the tracked object is far from the robot.

A "RGB filter" is used to remove all the pixels that are not orange.

The "Center Of Gravity" module provides 3 useful variables : X and Y coordinates of the orange blob COG, and the size of the blob.

The 3 available variables are processed :

• COG_X is used to calculate robot heading (upper-left corner)
• COG_Y is used to tilt the camera to keep the object into the field of vision (upper-right corner)
• COG_BOX_SIZE is used to determine if the robot needs to move forward or backward, in order to stay at a constant distance from the object (center)

Finally, a VB script sets 3 variables corresponding to the pulses to be sent to each servo through the serial port (lower line of values on the screeshot)

The BS2 waits for these 3 values and sends them to the servos.

Conclusion :

• Exactly like for the obstacle avoidance behavior, the lighting is essential to provide high quality images to Roborealm. I'm thinking about adding an embedded lighting device such as LEDs mounted on the cam chassis. Probably a future improvement !
• The robot reacts quickly when the tracked object moves, it's a good start.
• A lot of parameter need to be ajusted to prevent the cam tilt jitter, to mitigate the risk of image processing error (noise, background color filter...)

Vision et navigation - Obstacle avoidance

Avant la création de ce blog, j'avais créé des programmes de navigation simple basés sur le ping ou sur les capteurs infra-rouge (absents sur la configuration actuelle). Cette fois, j'ai utilisé la caméra pour déterminer la direction la plus dégagée. Dans quel but ?

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 :

- 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

Le comportement a été amélioré en abaissant la caméra

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.

Reconnaître une cible - Target recognition

J'ai voulu ajouter la vision à la routine de recherche et d'approche d'une cible. Le nouvel objectif du robot est donc de renverser toutes les quilles qu'il rencontre jusqu'à ce qu'il trouve celle qui comporte ce superbe symbole graphique distinctif :

Comment ça marche ?

La caméra est active en permanence. Le flux vidéo est traité par le PC embarqué, dit "PC104", à l'aide de RoboRealm qui est configuré avec les modules suivants :

Image brute : la cible et son symbole graphique. A noter, la lumière blafarde de mon bureau, avec par exemple une belle ombre au pied de la quille... Il faut en tenir lors du traitement !

Vitesse d'acquisition avant traitement : 20 FPS

Module Flood Fill 255, qui regroupe les pixels par couleurs similaires, et moyenne les teintes.

Recherche d'arête Canny 0-255

Les arêtes sont élargies avec le module Dilate pour assurer la clôture des contours

Le module Fill remplit les espaces fermés présents sur l'image : ça ressemble à l'original

Le module Shape_Match renvoit la confiance de reconnaissance des 2 "tâches" présentes sur l'image. La meilleure valeur est aussi stockée dans la variable "SHAPE_CONFIDENCE"

Pour chaque image traitée, la valeur absolue de "SHAPE_CONFIDENCE" est envoyée au Basic Stamp par le port série, précédée du caractère "A".

En sortie, ce traitement d'image est largement assez performant pour la mission : en moyenne 4 FPS.

A noter : les déformations du support du symbole et l'effet de perspective ont pu être négligés. Profitons, ce n'est pas toujours le cas...

Fin de la partie Vision.

Le début de la mission est identique à celles précédemment décrites. Après l'approche d'une cible, le micro-contrôleur lit ce qui arrive sur son entrée 1, utilisée pour les communications série avec le PC104. Dès qu'un "A" est reçu, le Basic Stamp est averti que l'octet suivant devra être stocké dans une variable "confiance".

• Si confiance < 50, la quille est renversée et la procédure est reprise du début.
• Si confiance > 50, la cible est identifiée, c'est la fin de la mission !

Target recognition : the closest target is knocked over unless it includes a known symbol

The closest target, update

In my previous post, the robot was first looking for the closest target around using the Ping))) sensor, then it aimed this target, drove toward it and stopped at about 2 inches.

Now, what if the target moves ? At this time, my goal is not to deal with moving targets, but programming a robot means dealing with error accumulation. If this accumulation leads the robot to lose its target, the path has to be adjusted.

To do so, the traveled distance is monitored by counting the pulses sent to the servos. On my Boe-Bot, the ratio is around 2 mm/pulse at slowspeed or 0.48 pulses/mm. Comparing the "pulses distance" and the "ping distance" allows to check if the target has been missed and if the whole process has to be started over.

Code sample :

'approche la cible
DO
PULSOUT 12,730
PULSOUT 13,770
GOSUB getdistance
pulsecount=pulsecount+1
IF pulsecount>(minidist*48/10) THEN 'translate the mini distance given by the ping into pulses before comparing it
  FREQOUT 4,100,3000
  GOTO main
ENDIF
PAUSE 15
LOOP UNTIL distance<=10 'approche à 10 cm
END

L'obstacle le plus proche - The closest target

En utilisant seulement le capteur à ultra-sons, j'ai programmé le robot pour rechercher l'obstacle le plus proche et s'en approcher.
Seul le Basic Stamp pilote le robot.

1. Pivoter sur place en mesurant la distance sur environ 190 azimuts. En effet, il faut envoyer environ 190 pulsations aux servos pour réaliser un tour sur place à vitesse modérée.
2. Mémoriser la distance minimale
3. Poursuivre la rotation jusqu'à retrouver la distance mini mesurée
4. Approcher la cible jusqu'à une distance de 5 cm

Cela fonctionne mais :
- la nature du sol modifie la réaction du robot, sa vitesse de rotation, ainsi que les mesures US
- la mesure US diverge d'environ ±15°, un même point d'une cible peut donc être mesuré plusieurs fois. Une cible cylindrique renvoie donc plusieurs fois la même distance minimale au cours de la rotation du robot. La conséquence est une difficulté à s'aligner sur le centre de la cible. Pour l'instant, j'ai simplement ajouter une correction fixe de l'azimut avant d'approcher la cible. C'est très empirique et pas fiable à 100%. Un sujet à creuser...

Cette routine servira de base à d'autres comportements plus complexes.