Interface I2C capteurs ultrasons

[azerupi]

Il faut définir une interface (protocole / API) pour que la Raspberry Pi et l'Arduino, qui communiquent en I2C, puisse se comprendre.

Cahier des charges

• Demander la mesure de tout les capteurs en une fois
• Demander la mesure d'un capteur spécifique
• Si le capteur demandé n'existe pas, renvoyer une séquence d'erreur que la Raspberry peut comprendre
• Demander d'énumérer les capteurs qui existent
• Autres?

Proposition

La Raspberry Pi envoie une instruction sur un byte contentant 2 parties codées sur 4 bits:

• La commande
• L'index du capteur (si applicable)

commandes

0001 xxxx        demander la mesure du capteur `xxxx`
0010 0000        demander la mesure de tous les capteurs
0011 0000        demander d'énumérer tous les capteurs
0100 0000        demander le nombre de capteurs présents

L'Arduino renvoie:

1. Une distance en cm (int 16 bits). On sépare le int en 2 bytes pour l'envoyer par I2C et puis on le reassemble sur la Pi. Si une erreur survient (e.g. le capteur n’existe pas) on renvoie 0.
2. n-fois 2 bytes (une fois par capteur)
3. n-fois 1 byte avec l'indice du capteur. On pourrait coder 2 capteurs par byte, mais alors il faut gérer le cas d'un nombre impaire de capteurs.
4. un byte contenant le nombre n de capteurs présent sur l'Arduino, ceci permet de savoir combien de bytes seront envoyés quand on demande les mesures de tous les capteurs

Ceci n'est qu'une proposition, la discussion est ouverte pour d'autres alternatives.

[charlesvdv]

J'ai quelque pensée en plus à ajouter.

Valables pour toutes les communications I2C:

• Est-ce que la communication est 100% sans erreur ? (Il faudrait essayer d'envoyer des grosses séquences de bytes pour voir si on reçoit bien tout correctement) et donc ajouter un CRC ou un code de parité...

• N'enverrions nous pas la taille du message également dans le premier byte pour faciliter la gestion du module I2C sur la raspberry? (Pour avoir un tronc commun avec toutes les interfaces?)

• La communication sera d'office synchrone ? Aussi nn il faudrait réfléchir à ajouter la commande envoyée dans la requête.

• Nous devrions aussi ajouter une information sur l'erreur de l'arduino vu que la raspberry est la seul à logger les erreurs/warnings.

Valables pour US:

• Lors de l'énumération de toutes les données des capteurs, ne faudrait il pas donner d'abord l'id du capteur pour ensuite mettre la valeur. On ajoute un peu d'overread mais on gagne en resiliance.

• C'est peut-être overkill mais possibiliter de demander certains capteurs genre que ceux avant ou arrière. Je sais pas si il y a un grand intérêt mais c's mieux d'y réfléchir mnt qu'après.

Aussi nn j'aime bien l'idee générale.

[azerupi]

Est-ce que la communication est 100% sans erreur ?

100% je ne sais pas. Mais, si je ne me trompe pas un appareil doit envoyer un bit de bonne réception ACK une fois un message reçu. Jusqu'à présent les seuls problèmes qu'on a eu avec l'I2C c'est des timeouts qui résultent en un exception dans la PI quand il y avait des mauvaises connexions ou que l'Arduino ne renvoyait pas ce qu'il fallait.

N'enverrions nous pas la taille du message également dans le premier byte pour faciliter la gestion du module I2C sur la raspberry?

On pourrait, mais dépendant de ce qu'on doit envoyer ce n'est pas toujours nécessaire. Par exemple, pour les capteurs ultrason on a fini par demander une fois le nombre de capteurs présent à l'allumage et du coup on sait combien de bytes attendre en retour pour chaque requête. Ils faudra réfléchir par rapport aux besoins des autres modules.

La communication sera d'office synchrone ?

Par synchrone tu veux dire que l'ordre est préservé? Alors oui, on écrit byte par byte sur le bus et pour chaque byte l’esclave envoi un bit de bonne réception.

Nous devrions aussi ajouter une information sur l'erreur de l'arduino vu que la raspberry est la seul à logger les erreurs/warnings.

C'est pas une mauvaise idée, dans ce cas il faudra un peu réfléchir à ce qu'on a besoin précisément parce que je pense que le système décrit ci-dessus ne pourra pas le gérer.

Lors de l'énumération de toutes les données des capteurs, ne faudrait il pas donner d'abord l'id du capteur pour ensuite mettre la valeur.

Quand on demande les mesures de tous les capteurs ont les reçoit dans l'ordre, donc envoyer l'ID n'as pas trop d’intérêt dans le setup actuel.

C'est peut-être overkill mais possibiliter de demander certains capteurs genre que ceux avant ou arrière.

Je pense pas que ça vaut la peine de le gérer dans l'arduino, vu que la Pi peut demander les résultats d'un capteur précis il suffit de rajouter une méthode dans le code Python qui demande plusieurs capteurs précis.

[JonathanPetit]

Est-ce que la communication est 100% sans erreur ?

Il faudra faire attention lors du placement de la raspberry et de l'arduino dans la partie mécanique parce que si je me trompe pas l'i2c est fort perturbé par le bruit. Il faudra donc pas que la liaison entre les 2 soit trop longue.

La communication sera d'office synchrone ?

Si je me trompe pas la communication i2c est d'office synchrone, en tout cas d'après ce que j'ai pu lire sur la différente documentation rencontré lorsque l'on a testé l'i2c.

[charlesvdv]

Mais, si je ne me trompe pas un appareil doit envoyer un bit de bonne réception ACK une fois un message reçu.

Le fait qu'on envoie/reçoit un signal ACK ne signifie pas que les bits n'ont pas été modifié par la ligne de transmission. Il signifie juste que le récepteur a reçu qq chose.

Une autre chose à rajouter au protocole serait un simple ping pong pour être sûr que l'arduino est connectée.

Une chose où l'on devrait faire attention serait d'avoir un tronc commun important entre les différents protocoles I2C.

[azerupi]

Une autre chose à rajouter au protocole serait un simple ping pong pour être sûr que l'arduino est connectée.

Si elle n'est pas connectée, la librairie SMBus renvoie une exception, donc pas besoin de faire un ping. Par contre il faudra bien gérer les exceptions pour éviter que notre robot plante parce qu'il y à un mauvais branchement...

Une chose où l'on devrait faire attention serait d'avoir un tronc commun important entre les différents protocoles I2C.

Dans #4 on a déjà commencé à faire exactement ça. En fonction des besoins des autres modules on pourra regrouper d'autres fonctionnalités sous la classe I2C pour éviter de se répéter.