API

Robot

Contrôler directement le robot revient à contrôler sa cinématique, et dans notre cas, comme le robot n'est pas holonome, l'angle est la vitesse (avant/arrière).

class Robot {
    void setSpeed(int speed); // (milli)mètre par secondes ?

    // Soit
    void setAngularSpeed(int speed); // (milli)degrés/radians par secondes
    // Soit
    void setAngle(int angle); // millidegrés/radians
};

Trajectory Manager

Le bas niveau peut aussi s'occuper de mouvements plus complexes (aller à un point XY dans le repère de la table par exemple).

class TrajectoryManager {
    void gotoXY(int x, int y);
    void gotoXYA(int x, int y, int a);
    void gotoDistance(int d);
    void gotoAngle(int a);
};

Protocole

Comment on mappe ça ? On met des indexes ? Comme en I2C ?

robot_set_speed 0x00
robot_get_speed 0x01

robot_set_angle 0x02
robot_get_angle 0x03

etc...

Pour le protocole, on fait : addresse | op(read/write) | index | data ?

J'imagine que c'est en rapport avec le travaile de @bcluzel, avec le dépôt eirbot/RobotCom ?

polyedre commented 5 years ago

Je comprend pas la nécessité de mapper ou de mettre des index. Sinon, la structure me convient :)

En effet, @bcluzel a commencé un truc de son coté, faudrait l'adapter :)

bcluzel commented 5 years ago

Hayo tout le monde;

Oui j'ai commencé à coder le "protocole de com" dans le repo eirbot/RobotCom https://github.com/eirbot/RobotCom , j'utilise l'i2c.

Toutes les nucléos sont des slaves i2c et seul la rpi est le maître. On a différents types de "products" qui ont un certain nombre d’instances d'objets qui ont eux meme différentes propriétés.

Par exemple le produit ASSERV_MACHINE (une nucleo) à comme objet principal l'objet ASSERV mais peut en avoir d'autres(ex DIGITAL). L'objet à ensuite des propriétés que l'on peut accéder en R,W ou R/W. L'objet asserv à pour l’instant les propriétés suivantes :

enum ASSERV_PROPERTIES { ASSERV_NONE, ASSERV_POSITION, ASSERV_SPEED, ASSERV_COEFF_P, ASSERV_COEFF_I, ASSERV_COEFF_D }; On pourra en ajouter d'autres facilement en les rajoutant dans l'enum du fichier ObjectDef.h.

Concernant les données j'ai décidé de les représenter comme ceci : 1 comande = 6*HEXAS: |XX|XX|XX| | COMMANDS OBJECT | OBJECT_ID PROPERTY | DATA |

Et l'adresse i2c est calculé automatiquement en fonction du type de produit et de son id comme ceci : ((unsigned char)system_id+1)<<4 | system_type<<1; (Adresse sur 8 bits pour mbed, sur la rasp on lui donne une adresse sur 7 bit donc on redécale tout vers le LSB)

Bref, j'ai fait des tests et cela semble fonctionnel sur nucléo. Je m'attaque donc au code sur rpi. En quel language vous préfériez que je code tout ca ? Python, Cpp?

De plus j'avais une autre question a-t-on besoin de beaucoup de puissance de calcul sur la rasp ? On prend un rasp 1,2,3 ou 4 ? Car sur la 3 l'i2c est plutôt mal géré, la vitesse du bus dépend de la clock du processeur qui varie en fonction de la charge processeur ... C'est pas ouf...

Le dim. 13 oct. 2019 à 13:16, polyedre notifications@github.com a écrit :

Je comprend pas la nécessité de mapper ou de mettre des index. Sinon, la structure me convient :)

En effet, @bcluzel https://github.com/bcluzel a commencé un truc de son coté, faudrait l'adapter :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eirbot/eirbot2020-2A/issues/13?email_source=notifications&email_token=AKZLJR7CPAH5DGAU3QP633TQOL7SDA5CNFSM4JAGPGMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCUBQQ#issuecomment-541409474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKZLJR2VAMI4L64GMZN2HXTQOL7SDANCNFSM4JAGPGMA .

astralien3000 commented 5 years ago

Ah, enfin un peu de temps pour regarder ça aussi !

| COMMANDS OBJECT | OBJECT_ID PROPERTY | DATA |

enum commands {
    READ,
    WRITE,
    DONE,
    NOT_IMPLEMENTED,
    REBOOT,
    DESACTIVATE
};

Déjà, tu sais que les adresses I2C sont dur 7 bits parce que le dernier est pour la commande (READ/WRITE). Ensuite, chaque commande en plus peut être réduite à un read/write :

DONE -> READ REG_DONE
NOT_IMPLEMENTED -> READ REG_IMPLEMENTED
REBOOT -> WRITE REG_REBOOT
DESACTIVATE -> WRITE REG_ENABLE

struct robot_com_frame {
    unsigned char command;
    unsigned char object;
    unsigned char object_id;
    unsigned char property;
    unsigned char data;
};

Tu a 3 niveaux d'adressage : object, object_id, property. Ça fait un adressage équivalent sur 12 bits si j'ai bien compris, mais il y aura beaucoup de "trous" car la plupart des objets n'auront que 10 properties. Pire, la plupart des types d'objets (aka object) n'auront que 2-3 instances (aka object_id). A l'inverse, certains objets pourraient avoir besoin de plus de 16 properties. Pourquoi pas un adressage "plat" sur 8 ou 16 bits ? (bon 8 c'est un peu light).

En quel language vous préfériez que je code tout ca ? Python, Cpp?

J'ai une petite préférence pour le C++, mais choisis celui dans lequel tu te sent le plus à l'aise pour faire cette tâche. On est bien capables de faire du python comme du C++.

De plus j'avais une autre question a-t-on besoin de beaucoup de puissance de calcul sur la rasp ?

Je ferai en sorte que oui, mais je suis pas sûre que ça pousse à choisir une rasp 3/4.

On prend un rasp 1,2,3 ou 4 ? Car sur la 3 l'i2c est plutôt mal géré, la vitesse du bus dépend de la clock du processeur qui varie en fonction de la charge processeur ... C'est pas ouf...

L'avantage est que l'I2C est un bus synchrone, donc on s'en fout, les nucleo sont censées pouvoir gérer aux dernières nouvelles. Ça serait plus gênant avec de l'UART. (ou du CAN, mais la rasp a pas de contrôleur CAN intégré, donc c'est pas un problème).

EDIT :

@polyedre : Il faut bien être capable d'identifier les objets sur le bus de comm, ou même dans le shell (write "robot.speed" 1, c'est déjà du mapping de la string "robot.speed" vers la propriété (C++) speed de la classe robot).

eirbot / eirbot2020-2A

API haut niveau (rasp-MCU) #13

API

Robot

Trajectory Manager

Protocole