Interface I2C gestion moteur

[charlesvdv]

Ce qu'on a besoin comme action:

• tourner à gauche de X degrés
• tourner à droite de X degrés
• avancer de X cm
• reculer de X cm
• arreter les moteurs
• contrôle vitesse
• demander le déplacement déjà effectuer
• demander si action finie ou pas
• demander si l'action est stoppée
• redémarrer l'action stoppée

On a pas de précision de plus d'un cm donc ca sert à rien d'envoyer des données en dizaines de mm ou memes en minimètres. On aura donc besoin de 8bits pour avoir 256cm max (résonnable sachant que le plateau fait 1m*2m).

On peut donc faire un peu comme #5 mais la commande sera sur 8bits.

L'info sur le déplacement déjà effectué devra retourner 2 bytes. Un pour la roue gauche et un pour la roue droite.

@azerupi d'autres idées ?

[azerupi]

On a pas de précision de plus d'un cm

Même les odomètres?

Sinon au niveau des actions, ça me semble bien. Il y à juste une chose très importante qui manque, c'est la régulation de la vitesse :wink:

Soit on permet d'envoyer la vitesse comme paramètre pour chaque commande qui occasionne un déplacement, soit on rajoute une commande qui permet de changer la vitesse pour les commandes qui vont suivre.

Je dirais que les actions listés ci-dessus sont le stricte minimum à supporter, mais si on est chaud il y à moyen d'en ajouter des plus complexes qui permettraient d'avoir plus de mobilité et un déplacement plus fluide et donc plus rapide. On pourrait penser à:

• Tourner en avançant, au lieu d'avancer, s’arrêter pour tourner, avancer, s'arrêter à nouveau pour tourner, ... ça pourrait être plus efficace de pouvoir suivre une trajectoire courbe sans s’arrêter. Pour ça on devrait ralentir une roue par rapport à l'autre et bien réguler les vitesses.
• Tourner autour d'une roue, au lieu de tourner autour du centre, on pourrait vouloir tourner autour d'une des roues. Donc au lieu d'avoir les deux roues qui tournent dans un sens opposé, on aurait une roue à l'arrêt et une roue en mouvement.

Dernière chose, mais peut-être que je m'avance un peu trop, il faudra faire attention aux "accélération instantanées". Les moteurs sont vraiment costaud, si on passe de 0 à 100% en un coup on risque de faire basculer le robot. Je pense qu'il faudra faire en sorte que l'accélération se fasse progressivement.

[charlesvdv]

Même les odomètres?

D'après M. Marchand, une précision de 1cm est déjà très bien malheureusement parce qu'on doit compter aussi sur la précision des moteurs, etc

Soit on permet d'envoyer la vitesse comme paramètre pour chaque commande qui occasionne un déplacement, soit on rajoute une commande qui permet de changer la vitesse pour les commandes qui vont suivre.

Je pense pas que ce soit utile vu que l'on a toujours comme but d'aller le plus rapidement possible. Par contre une commande spéciale pour passer la bascule pourrait etre intéressante.

Dernière chose, mais peut-être que je m'avance un peu trop, il faudra faire attention aux "accélération instantanées". Les moteurs sont vraiment costaud, si on passe de 0 à 100% en un coup on risque de faire basculer le robot. Je pense qu'il faudra faire en sorte que l'accélération se fasse progressivement.

C'est le but de l'arduino avec la régulation PID que l'on doit incorporer.

Je dirais que les actions listés ci-dessus sont le stricte minimum à supporter, mais si on est chaud il y à moyen d'en ajouter des plus complexes qui permettraient d'avoir plus de mobilité et un déplacement plus fluide et donc plus rapide.

D'après M. Marchand, aucune équipe de l'ECAM n'a jamais implémenté ca. Ca risque d'etre fort compliqué sachant que l'on a besoin du rayon de courbure de la trajectoire. Cette curbure pourrait etre non constante, etc... A voir mais pour moi il y a bcp plus important.

[azerupi]

Oui, clairement il y à plus important. Je ne voulait pas dire qu'il fallait l'implémenter, mais plutôt qu'on pouvait structurer le code de façon à pouvoir l'ajouter plus tard, au cas ou. Même si on ne le fait pas cette année, on pourrait reprendre le code l'année prochaine et l'étendre par exemple. Autant pas s'imposer des limites quand elle ne sont pas nécessaires :)

Je pense pas que ce soit utile vu que l'on a toujours comme but d'aller le plus rapidement possible. Par contre une commande spéciale pour passer la bascule pourrait etre intéressante.

Je suis pas tout à fait d'accord, en approchant des "destinations cibles" on voudra probablement ralentir pour être plus précis. On en aura également besoin pour la bascule et peut-être si jamais on tombe sur un obstacle imprévu (e.g. le robot adverse). Autant l'ajouter, je ne pense pas que ça ajoute beaucoup de complexité.