These wheel encoders are designed for the Boe-Bot, and installing them is a piece of cake, even on such a customized robot...
The servos are mounted outside of the chassis on my Boe-Bot, so I added some spacers to simulate its thickness. This will ensure the coders are at the distance of the wheels than they are supposed to be.
The only "issue" is the access to the breadboard and the BS2 I/O connectors. It's getting crowded in there and I don't really like that : I might build a 16x3 connector to avoid having a web under the PC104... Another idea...
First, I tried the 5 pointed star path provided by Parallax to test the sensors : they work fine but they need some calibration. Not a real surprise though...
For the calibration, I followed the instructions provided with the encoders. These sensors can be very powerful / complicated, so I try to learn how to use them from the beginning... Tonight, I was able to run the calibration program twice, and the measures seem to be constant enough. Here is an example of calibration result, using the Calibrate_All.exe tool :
Malgré le manque de temps, je n'ai pas pu résister à m'offrir quelques cadeaux de chez Parallax :
Me voici donc heureux propriétaire d'un BS2PX, de 2 Pings))) et de codeurs de roue. Pourquoi cet investissement sur la platine microcontroleur alors que le PC104 présentent pas mal d'avantages : la puissance de calcul est supérieure, la complexe concurrence d'évènements pourrait être centralisée et traitée à l'aide d'un outil spécialisé comme MS-RDS...
Les réponses sont multiples et font appel au bon sens. Ce sont mes bonnes résolutions pour ce projets.
1. La puissance et l'architecture du PC104 ne permettent pas de centraliser toute la gestion du robot. L'expérience montre qu'avec la configuration matérielle actuelle, le PC104 doit être épargné au maximum pour rester performant en traitement d'image. "Toutes" les autres tâches seront donc confiées au BS2. C'était mon plan initial, mais j'ai dévié de cet objectif en explorant diverses pistes. Retour aux sources !
2. Le BS2 est sous-employé, employons-le ! De plus, une promotion intéressante sur le site du fabricant va me permettre de changer pour le plus rapide de la famille Basic Stamp. J'espère que cela permettra d'absorber les nouvelles tâches, mais aussi que cela aidera à améliorer la qualité des échanges avec le PC104. Ce dernier point m'avait semblé influent lors de la programmation Object Avoidance. Le BS2PX offre 126 octets de buffer sur l'instruction de réception série asynchrone SERIN. Intéressant.
3. Les codeurs de roue ouvrent des possibilités intéressantes pour la navigation, en améliorant largement la notion de Dead Reckonning. Mon objectif en commençant ce robot était de fabriquer un "véhicule" pouvant se déplacer de manière autonome dans un environnement hostile et complexe : un appartement... Avec les codeurs, il sera normalement capable de partie à l'aventure, puis de revenir à son point de départ. En tout cas suffisamment proche de son point de départ pour qu'il puisse utiliser d'autres capteurs pour affiner son positionnement (reconnaissance d'image par exemple).
4. Enfin, depuis le démontage des capteur latéraux IR, le robot est un peu démuni pour la détection rapide d'obstacles proches (hors vision). Un Ping))) devant chaque roue combleront de manque !
Plein d'idées et de nouveaux jouets, avec l'envie de travailler sur la fonction "Navigation" du robot.
Un analyseur logique USB qui offre aussi la possibilité d'analyser des protocoles standards (RS232, I²C...). Un vrai couteau suisse pour le développement. Le logiciel qui l'accompagne est complet et j'apprends tranquillement à l'utiliser.
Les 16 entrées disponibles permettront par exemple de surveiller toute l'activité du BS2 en une seule mesure...
As you can see on the following schematics, this new accessory is powered with +5V from the power supply PCB.
Note that it's got 2 inputs, which allows to switch the LEDs on from the BS2 or from the PC104 (printer port).
Each input has a pull down resistor to avoid floating status.
Diodes + Transistor = "OR gate"
This little device is not going to change everything because the available power is limited, but the first vision tests prove that it's an improvement. I re-used the Roborealm routine "object tracking" without moving the robot or changing the poor lighting condition of the room :
Without the additionnal lights, the yellow item is not detected
With the LEDs on, a blob appears and can be processed
What next ?
LEDs orientation still need to be tuned
The second input has to be tested. Roborealm would be able to switch the lights on just when needed, simply through a "Parallel_Port" module.
First project after a couple of months without doing anything on the robot : build additional lighting on the cam.
Light source:
6 ultra bright LED (26000 MCD), approx. 20 mA, 5V.
Switch:
I made a little PCB to manage the power. It's got 2 logical inputs that could be connected to the BS2 and to the PC104 printer port. Both inputs can trigger one 2N2222 transistor, through pull down resistors and diodes. It works correctly but the collector-emitter voltage is only 4.5V to 4.55V. Consequence : to have an efficient light production, the current in the LEDs will be higher than expected. Bad news for autonomy.
Additional lighting : Switch PCB and LEDs PCB
As you can see on the photo, the lighting assembly is not mounted on the cam chassis yet, but a first simple test demonstrated the improvement of vision processing. To be confirmed on the robot.
I am also thinking about completing this device with 2 fixed "headlights", maybe mixing regular and IR LEDs that could improve edge detection in poor lighting conditions.
Après un déménagement, après une saison pendant laquelle on peut jouer dehors, après plusieurs mois sans toucher à mon robot préféré, c'est la rentrée !
Pas mal d'idées de programmations et d'améliorations matérielles. A ce sujet, il y a des soldes intéressantes sur le site de Parallax. Je viens de craquer pour un Basic Stamp 2px dont je prendrai possession dans quelques semaines. Pourquoi ce choix : puissance de calcul, configuration programmable des entrées/sorties. A suivre...
Du coté programmation, je vais "à nouveau" m'intéresser à MSRDS. La programmation séquentielle de RoboRealm a ses limites, par exemple, pour la gestion des concurrences, ou pour la répartition des tâches entre BS2 et PC104.
Je parlais plus haut de déménagement ; je suis maintenant parisien ! Avez-vous connaissance de "clubs" d'apprentis roboticiens dans la capitale ?
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...)
Since the BS2 is not very convenient with fractional calculus, the decimal value sent by the ADC will probably be processed by the PC104. I will still use the BS2 as an interface allowing "on demand voltage monitoring", or when it's useful to know / show the actual voltage value.
I may just test the [adcbits] variable with a simple IF...THEN loop. If it's below a threshold, then it's time to charge the robot. Easy programming, but the voltage will remain unknown from the user. Hey wait ! It's supposed to be an autonomous robot... I guess this method will be my favorite !
_______________
Edit (March, 1st) : I corrected a little mistake in the chart and in the linear interpolation equation...
After a couple of modifications on the new PCB, I mounted it on the robot and started to use the new voltage monitoring function.
Yes, I had to modifiy it :
First, I must admit that a I made a major mistake when designing it... The ADC0831 input line was not at the right polarity. It would have not been a big deal if I had tested the PCB without the ADC on its socket. I should have gone to sleep instead of burning one these integrated circuit... Good thing I ordered a spare one.
Moreover, The potentiometer I chose for the voltage divider bridge (9,6 V to 5,2 V max) was to light, which means the current accross it was to high, which means it got warm pretty fast and it was probably consuming way to much power...
It's always good to remember the basics like ohm's law...
Layout for prototyping board
Everything seems to work properly now. I started to try the embedded voltage monitoring tonight. What I need now is to figure out a conversion law between the actual voltage and the value read through the ADC. I run the code below on the BS2 to collect these values in excel :
' {$STAMP BS2}
' {$PBASIC 2.5}
'mesure tension
'ADC0831
'init
adcbits VAR Word
cs PIN 9
clk PIN 10
dataoutput PIN 11
DEBUG CLS
'main
DO
GOSUB adc_data
GOSUB calc_volts
GOSUB display
LOOP
'subs
adc_data:
HIGH cs
LOW cs
LOW clk
PULSOUT clk,210
SHIFTIN dataoutput,clk,MSBPOST,[adcbits\8]
RETURN
calc_volts:
RETURN
display:
DEBUG HOME
DEBUG "8 bit bin val : ", BIN8 adcbits
DEBUG CR, "dec val : ", DEC3 adcbits
RETURN
After collecting around 10 values, I should be able to write a "standard" piece of code, easily reusable in each new mission / program.
Je viens de démonter la carte d'alimentation du robot. Son unique fonction était de distribuer l'énergie aux différents composants. La nouvelle version est déjà en cours de montage !
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.
Just like your cellphone, my robot needs to monitor the voltage of its battery to avoid overdischarge. This feature is not yet implemented.
It means that I check quite often the battery with my metrix when playing around with the robot.And it means that I've probably overdischarged the Ni-MH a couple of times...
Monitoring the voltage will also allow to use more efficient and lighter batteries like Lipos, that were not affordable when I started this project.
Today, I tried a simple A/D converter, the ADC0831 to monitor the battery using the BS2. Okay, it was the very first test, so it may look a bit messy :
Wires all over, but it worked just fine :
At this time, the output is an 8-bit value, without any reference voltage or calibration. This will need some math and adjustments in the code... This will be done on the future power supply PCB that I am going to make soon.
