Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).
Il y a des solutions ou un gros μP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple μP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc... C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un μP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Il y a des solutions ou un gros μP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple μP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc... C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un μP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
"La première sécurité est la liberté"