Démontage

Bon, la lecture des docs c’est bien, mais ce n’est pas suffisant, et nous sommes restés sur notre faim.

Désolé mon gars, mais tu vas devoir passer sur le billard pour que nous puissions en savoir plus sur ton cas.

AVERTISSEMENT : les personnes sensibles sont invitées à ne pas poursuivre la lecture de cet article au-delà de ce paragraphe, certaines des photos incluses à des fins de documentation pouvant les choquer.

C’est parti

L’assemblage est plutôt bien fait et le démontage se révèle assez simple, hormis pour le déclipsage des deux moitiés de l’armure du torse. C’est toujours pareil dans ce cas-là, il faut arriver à trouver où sont les languettes et comment elles s’accrochent.

On arrive assez rapidement à cet état des lieux :

(on vous avait prévenu, faut pas pleurer maintenant)

OK, je sais, ça peut paraître dur car ça ressemble un peu à un crash aérien ou à la fin du film Terminator 1, mais rassurez vous, il n’a pas souffert. Nous vérifions à ce titre qu’il est toujours vivant en reconnectant temporairement le circuit principal à la batterie et aux autres cartes électroniques. Il nous refait la même séquence initiale... et ne s’apparie toujours pas à la télécommande. Décidément, ces deux-là ont décidé de divorcer visiblement 🙁

D’un autre côté c’est peut-être la télécommande qui a un problème, impossible de le savoir pour le moment. De toute manière cela n’a pas d’importance, car le but de cette opération n’est pas de dépecer notre ami pour le moment, mais seulement de mieux savoir ce qu’il contient et de comprendre comment il fonctionne.

Gros plan sur le circuit principal

Le voici de manière plus nette que dans le document de la FCC (ouais, mes photos sont de meilleure qualité 😄. On y distingue de gauche à droite :

• l’alimentation, probablement à découpage si on en juge par la présence de la grosse self noire et de sa copine plus petite à ses 2 heures, ainsi que par celle des deux grosses capa vertes à sa gauche
• le driver de puissance des moteurs de la base roulante, dans le coin inférieur gauche et en partie masqué par une des capas de l’alimentation
• le micro-contrôleur au centre, noyé dans une goutte de résine et accompagné de son quartz (petit cylindre allongé brillant immédiatement sur sa gauche)
• l’interrupteur d’alimentation
• le module radio en bout de platine

Le cylindre noir devant le micro-contrôleur est un interrupteur à bille, indiquant au robot s’il est debout, couché sur le dos ou couché sur le ventre. Cette combinaison de détection est rendue possible par le fait qu’il a un jumeau sur l’autre face du circuit, et que l’un comme l’autre ne sont pas parallèles au plan de la platine. Ca ne se voit pas très bien sur la photo [1], mais le fait que les pattes ont des longueurs différentes en donne une petite indication.

Ce dispositif m’a d’ailleurs fait craindre le pire lors des premiers tests de fonctionnement après démontage, car à l’issue de la séquence initiale, le haut parleur diffusait un mot ou un expression incompréhensible [2]  😢 . J’ai fini par déduire que ce "message" signale que le robot n’est pas dans la bonne position, car tel que le circuit principal était alors disposé (cf les photos) cela correspondait à une position couchée (sur le dos ou sur le ventre). En tenant la carte verticalement, le message n’est plus émis. Ouf, pas cassé  😎 !!! Le fait d’avoir 2 capteurs disposés comme ils le sont est assez astucieux pour déterminer facilement la position du robot par combinaison des états de chacun d’entre eux (2 capteurs pouvant prendre 2 valeurs chacun = 4 combinaisons possible).

Les deux fils jaunes qui partent vers le bas sont la liaison vers le haut parleur situé au niveau des hanches du robot.

Le câble gris sur sa droite est celui du 3ème micro, situé dans la poitrine du robot.

L’autre face est un peu moins peuplée et on y retrouve le détecteur de position jumeau. Son intérêt est néanmoins d’avoir une sérigraphie documentant les signaux présents sur les pads à la frontière du module radio. Ceci va nous être très utile pour observer les signaux qui transitent.

On peut également y reconnaître le connecteur des moteurs de la base roulante dans le coin supérieur gauche.

La radio

On peut voir grâce à la sérigraphie au niveau des pads qu’il ne s’agit pas d’un module radio série, mais SPI (présence des signaux MOSI et MISO entre autres). Voilà qui ne va pas nous simplifier la vie et exclut le scénario du remplacement temporaire de la liaison radio par une liaison filaire directe pour tester l’état des protagonistes.

Il n’est même pas certain qu’on puisse utiliser des modules NRF (il y en a qui fonctionnent en SPI) pour ce genre de test, car il y a peu de chances que le protocole utilisé au niveau SPI soit le même, sauf si par chance inouïe le module intégré était lui aussi de type NRF. On verra ça plus tard.

Les épaules

Remontons un peu vers les épaules maintenant.

Le circuit imprimé qui nous fait face est sous la base du cou et contient le contrôleur des moteurs du cou et de la tête (cf paragraphe "Et la tête"), ainsi que les départs vers ceux des bras (connecteurs blancs en bas à droite et en bas à gauche) et celui de l’inclinaison de la tête (connecteur blanc en haut à droite). Le moteur de rotation de la tête est lui directement soudé sur la carte électronique.

On remarque que la sérigraphie des soudures le long du bord inférieur des fils allant vers le circuit principal comporte les repères SDA et SCL. Cela signifie que la liaison entre ces deux éléments est un bus I2C.

Compte tenu du nombre de fils partant vers chaque bras, et sachant que ceux-ci comportent chacun deux moteurs asservis, cette liaison I2C est étendue à l’ensemble des actionneurs du robot (il aurait fallu 5 fils par moteur sinon [3]. Nous sommes donc en présence d’une architecture distribuée, le contrôle des moteurs étant fait au plus proche et étant supervisé à l’aide d’un bus numérique véhiculant des commandes et des retours d’états. Pas à dire, il ne s’agit pas d’un jouet bas de gamme, mais d’un produit conçu de manière élaborée.

On peut voir près du connecteur de gauche un chip (tête en bas) portant la référence 51F116. Il s’agit d’un micro-contrôleur de type 8052 équipé d’ADCs (utilisés ici pour la lecture des potentiomètres de position) et d’une interface I2C (entre autres). A titre de documentation, en voici la datasheet fournie par son constructeur :

Voilà qui nous rend la tâche de retrofit encore plus difficile, car en l’absence du code source du programme qui y est embarqué, impossible de connaître le protocole de communication utilisé ici. La seule solution serait d’observer avec un analyseur logique les trames qui circulent sur le bus I2C, mais il faudrait pour cela que nous soyons en mesure de communiquer avec le robot pour lui faire réaliser des actions précises.

Les bras

Pour en savoir un peu plus sur le contenu des bras, il n’y a pas d’autre solution que de les démonter aussi :

Ca n’a pas été bien difficile, tout l’assemblage étant fait avec des vis facilement accessibles.

On peut voir que la racine de chaque bras comporte un circuit imprimé (dont on entrevoyait la tranche sur la photo des épaules).

On y retrouve un 51F116, servant de contrôleur secondaire. Une liaison à 5 fils (et non 6) partant vers le moteur du coude (connecteur sur l’autre face du circuit), ce contrôleur gère les deux moteurs du bras.

C’est d’ailleurs confirmé par la présence de 2 chips à 6 pattes (dans les quarts supérieur gauche et inférieur gauche) qui sont quasiment à coup sûr des ponts en H de faible puissance.

La platine contrôleur de l’autre bras permet de mieux distinguer les sérigraphies du câble de liaison avec le circuit situé dans les épaules :

Elles nous confirment que nous sommes en présence d’un bus I2C qui s’étend dans tout le robot.

Quant à l’articulation du coude, elle est équipée d’un simple moteur passif et de son potentiomètre de lecture de position, gérés tous deux par le contrôleur situé à la racine du bras.

Et la tête...

... alouette 😄

Je ne l’ai pas démontée, car le moteur utilisé pour l’inclinaison de la tête est passif comme ceux des coudes. Ce qui permet d’arriver à cette conclusion est que le câble qui y part depuis la carte installée dans les épaules ne comporte que 5 fils, comme les liaisons entre l’épaule et le coude.

Etant donné que les carters blancs sont assemblés par clipsage, j’ai jugé préférable de ne pas chercher à les démonter au risque de les abîmer.

L’autre élément contenu dans la tête est le ruban de LEDs qui anime les yeux, et qui est relié à une carte électronique propriétaire, qu’on voit sur les photos en page 6 du document de la FCC. La liaison entre cette carte et la carte principale est constituée d’une nappe à 5 fils, qui pourrait être un bus I2C :

• 1 pour la masse
• 1 pour l’alimentation de la logique (qui semble être en 3V3 partout, si on considère les sérigraphies présentent sur plusieurs caters),
• 1 pour l’alimentation des LEDs elles-mêmes (sans doute en 5V)
• 2 pour les signaux du bus.

Cette carte gère également les micros et est elle aussi basée sur un micro-contrôleur (sous la goutte de résine noire) programmé ad-hoc.

On discerne vaguement l’inscription SDA le long du bord droit de la vue côté composants, ce qui identifie une liaison I2C à ce niveau également. Cela confirme l’hypothèse formulée précédemment. Ce n’est pas surprenant car totalement cohérent avec l’architecture système du robot.

Sur cette même vue, il n’est pas impossible que le gros CI en haut à gauche soit le driver pour les LEDs du ruban, dont le connecteur de la nappe du PCB souple (visible sur les photos en page 2) est situé au milieu du bord inférieur de la carte.

Conclusion

Compte tenu de la miniaturisation des divers sous-ensembles actionneurs, il serait souhaitable de pouvoir les réutiliser tels quels. Ils semblent en effet toujours fonctionnels car lorsque le robot est mis sous tension, les divers moteurs sont brièvement activés et les LEDs de la tête sont animées en continu.

Si la panne est de son côté, le non-fonctionnement du robot peut venir soit de sa partie radio soit du contrôleur général. Dans les deux cas, il est en théorie possible d’y substituer quelque chose de fait maison, mais cela suppose qu’on soit capable de faire du retro-engineering sur les protocoles de communication utilisés sur les liaisons I2C vers et entre les divers sous-ensembles.

Cela est techniquement faisable à l’aide d’un analyseur logique, mais encore faut-il être en mesure de provoquer l’émission de trames, et donc de faire communiquer le robot avec sa télécommande (ou avec autre chose).

La situation serait beaucoup plus simple avec un robot fonctionnel [4], mais ici c’est un peu le problème de la poule et de l’oeuf...

Ne manquez pas nos prochains épisodes... des fois qu’on y réussisse 😉