olivthill

Juste pour infos, des aéromodélistes, Patrick Cesarato, Jean-Luc Delort et Olivier Segouin, ont créé deux bancs de test qui ont permis de mesurer les caractéristiques de plus d'une centaine de servomoteurs répertoriés dans la base de données Servomances .

Cf. http://www.teaser.fr/~osegouin/aeromode/servos.phtml  et http://www.aeroglide.net/2013/02/servormances-mise-a-jour-fevrier-2013/

 

Edit : Par exemple, pour le MG995, ils ont créé la fiche suivante, où ils indiquent avoir trouvé un couple max de 6.690 à 5V et 8.280 à 6V.

Il faut un système qui permet de poser le crayon à la veritcale sur la feuille, et faire en sorte qu'il écrive sur la feuille et qui pourra aussi le lever. En gros un système d'ascenseur.

C'est très facile avec un "servomoteur" de modélisme. Ca ne marche pas comme un ascenseur mais comme une jambe qui se lève et qui s'abaisse du nombre de degrés que l'on désire. Voir, par exemple : http://www.euromodel-online.eu/radiocommandes-accessoires/peripheriques/servos.html?dir=asc&order=price . Et ça se pilote très bien avec une Arduino, voir par exemple https://itp.nyu.edu/...comp/Labs/Servo .

A mon humble avis, la partie la plus difficile à faire est celle qui bouge le stylo sur la feuille avec beaucoup de précision.

La communication Bluetooth marche comme une liaison série ordinaire.
Donc, pour la programmation du côté de la Bluno, il faut utiliser les fonctions Serial.quelquechose, voir http://arduino.cc/en/Serial/Available#.UwJOImJ5MYE , dont les trois principales sont Serial.available(), Serial.read(), et Serial.write().

Du côté du Smartphone, si c'est un android, je recommande l'application gratuite Blueterm, faite par un informaticien espagnol, qui permet de se connecter et d'envoyer les caractères que l'on veut via le bluetooth. Comme le code source est fourni, on peut s'en inspirer pour écrire soi-même son application en Java avec Eclipse.

Pour ce qui concerne la caméra, je ne suis pas sûr que cette Bluno (ou une Arduino Uno et un module bluetooth) soit assez puissante pour retransmettre les images à distance en direct. Il faudra peut-être stocker les images dans une carte mémoire (il y a des extensions Arduino pour les cartes SD).

Dans le programme, je ne sais pas pourquoi vous utilisez la valeur 666. Les personnes superstitieuses pensent que c'est un mauvais chiffre. Et c'est en le voyant que je me suis dit que ce programme était peut-être une blague, alors je n'ai pas cherché à répondre.

Sinon, en regardant rapidement, je vois qu'il manque :

#include <Servo.h>

Il y aurait eu un message à la compilation à ce sujet, je pense.
Lancer la compilation permet de détecter beaucoup d'erreurs sans prendre aucun risque. Donc, vous auriez pu le faire.

Je ne vois rien dans le programme qui pourrait faire "tout casser lol".

Quand on n'est pas sûr de soi, le mieux est de procéder petit à petit.
Par exemple, au départ, on fait un programme assez petit. On le teste. Puis on rajoute quelques lignes. On reteste. Etc.
Ou bien on peut avoir un programme assez long au début dans lequel on met des zones en commentaires pour tester petit à petit.

Jusqu'à présent, je n'ai jamais vu de servomoteur qui aurait "cassé" suite à un programme mal écrit. Quand le servomoteur reçoit l'ordre de bouger, soit la valeur est dans ses limites et il bouge, soit la valeur est hors des limites, et il ne fait rien.
Par contre, j'ai grillé un servo en me trompant dans les branchements. Un des fils a reçu trop de voltage. Donc, il faut bien vérifier son montage.

pourquoi n'y a t-il pas de fil qui va vers le "moins" de la pile du dessus ?

En fait, il y a une petite barre métallique à droite, qui relie le "moins" de la pile du haut avec le "plus" de la pile du bas. La barre n'est pas dessinée parce que ce n'est pas un fil, et parce que presque tout le monde sait que cette liaison existe dans ce genre de boitier pour piles.
Si on veut, on peut ne pas avoir de boitier et fixer les piles avec du ruban adhésif ou d'autres choses. Dans ce cas, il faudra ajouter la liaison entre le "moins" de la pile du haut et le "plus" de la pile du bas grâce à un fil électrique ou à un petit morceau de cuivre.

Une question subsidiaire serait de savoir si on peut brancher ailleurs le fil noir qui va vers l'interrupteur en bas.
La réponse est oui. Au lieu de le brancher sur le "plus" de la pile du bas, on pourrait le brancher sur le "moins" de la pile du haut, mais pas sur le "moins" de la pile du bas, ni sur le "plus" de la pile du haut.

comment le robot fait pour rouler sans roues ? Ce sont les moteurs qui le font directement avancer sans intermédiaire ?

Oui, quand un moteur est en marche, alors son axe tourne. Et comme l'axe est penché, son mouvement fait avancer le robot.
Si on veut, on peut mettre une petite roue au bout de l'axe. Ca pourra le faire avancer plus vite et le faire moins glisser.

Tout d'abord, je vais vous démoraliser en vous disant qu'on ne peut pas mettre d'interruption sur la pin 13 d'une Arduino Uno ou d'une Nano.

Ensuite, voici quelques explications.
Mais je crains que vous ne les connaissiez déjà puisque vous dites que vous avez déjà testé une interruption sur un bouton avec la arduino.

Les interruptions sont gérées par le microprocesseur. Atmel les a prévues (Intel aussi, et Motorola, etc.).
Un programme qui tourne ne peut être interrompu par rien, sauf par l'extinction du courant et par une interruption.
Un reset déclenche une interruption. L'appui d'une touche d'un clavier d'un ordinateur déclenche une interruption.
Ces événements physiques font changer le voltage de certaines broches du microprocesseur.
Quand cela arrive, le microprocesseur va interrompre le programme en cours, et va faire un saut à une adresse en mémoire interne. Ces adresses sont habituellement dans le bas de la mémoire à des emplacements fixes, qui dépendent de la broche qui est sollicitée. Par exemple, on va dire à l'adresse 10h pour la pin 2, et 14h pour la pin 3 (je ne sais pas si ce sont les adresses réellement utilisées par Atmel, mais c'est pour donner une idée). Entre deux adresses, il y a habituellement 4 octets. C'est peu pour un programme d'interruption. Alors, il s'y trouve généralement uniquement une instruction pour sauter ailleurs, dans la mémoire vive générale où va se trouver le programme d'interruption, qui a été placé auparavant par le programmeur avec la commande attachInterrupt() ou son équivalent dans d'autres langages.
Ensuite le microprocesseur va parcourir le programme de l'interruption, jusqu'à la fin, ou jusqu'à ce qu'il soit interrompu par une autre interruption dans le cas où l'on se trouve dans une partie de code qui n'est pas protégée contre les interruptions (cas par défaut mais qu'on peut changer avec noInterrupts()).
Puis, le microprocesseur retrouve le programme d'avant l'interruption, et continue son déroulement.
C'est tout.

Sur une Arduino Uno, il n'existe que deux connecteurs auxquels on peut attacher une interruption : le 2 et le 3. Sur une Nano, c'est pareil. Le 13 ne peut pas déclencher une interruption.
J'ai oublié de préciser que je parle là des interruption dites "externes". Ce sont celles qui s'utilisent le plus couramment et le plus facilement.

Mais il existe aussi trois interruptions dites "internes". Pour celles-là on n'utilise pas attachInterrupt(), et elles ne sont pas déclenchées par des événements sur des pins de la Arduino. Elles sont déclenchées par des timers internes.

Un timer est une horloge. La Arduino Uno a trois timers. Il est possible d'associer un tick à une interruption interne. Il faudra créer une fonction qui s'appelle précisément ISR(TIMER...vect), avec plusieurs possibilités pour remplacer les points de suspension. Il faudra coder avec des instructions un peu inhabituelles comme cli() et sei().
Voir les explications http://letsmakerobots.com/node/28278 et http://blog.oscarliang.net/arduino-timer-and-interrupt-tutorial/
Je ne sais pas si les timers vous seront utiles. Si vous les essayez, sachez que la librairie servo utilise déjà l'un des trois timers.

j'ai bien compris ton explication

Ok. Content de l'apprendre. Mais est-ce qu'une action correctrice a été entreprise pour résoudre le problème ?

Si oui quel est le résultat maintenant ?

Si non, alors j'ai trouvé la solution entre-temps.
Il faudrait remplacer la ligne :

#include "WProgram.h"

par

#include "Arduino.h"

C'est parce que ça a changé depuis l'époque des anciennes Arduinos.

pour la deuxième librairie tu sais d’où elle peut venir ?

Quelle deuxième librairie ?

Le premier message d'erreur est important :

"In file included from ChuckServoTest.cpp:3: /WiiChuck.h:33:23: error: WProgram.h: No such file or directory"

Le fichier WProgram.h est manquant.
Ce n'est pas un programme standard. Je ne l'ai pas dans mon environnement Arduino. Je ne ne vois pas sur la page http://www.pobot.org/Controle-avec-un-Wii-Nunchuck.html . Je ne sais pas d'où il vient et ce qu'il doit contenir. En tous cas, il faut soit ajouter ce fichier au bon endroit, soit supprimer la ligne d'include de ce fichier.

Ensuite, les messages d'erreur concernant "byte" sont un peu étonnant, car ce type de donnée devrait exister. Ces messages sont peut-être causés par le problème précédent.

On peut avoir un grand modèle d'Arduino (mega 2560) avec son bouclier d'entrées/sorties : http://www.miniinthebox.com/fr/mega-2560-atmega2560-capteur-de-bouclier-carte-d-extension-v1-0-dupont-ligne-et-jeu-de-cables-usb_p381498.html

Personnellement, j'aime bien les Pololu Maestro qui sont très compactes. Il y a un modèle pour 24 servos http://www.pololu.com/catalog/product/1356 , distribué aussi par Robotshop et par Lextronic.

Il y a aussi le contrôleur de servomoteurs SSC-32 Lynxmotion, http://www.robotshop.com/eu/productinfo.aspx?pc=RB-Lyn-100&lang=fr-CA

Superbes vidéos !

Le déplacement de ce robot à quatre pattes est très original.
C'est un beau projet.

Bravo, et bon courage.

Désolé, mais ça ne va pas. Relisez-moi.

Il faut absolument croiser les fils RX et TX, et donc brancher RXD sur TX->1, et TXD sur RX->0 (physiquement les fils ne sont pas croisés car les constructeurs de la carte bluetooth et de la Arduino, n'ont pas mis les connecteurs dans le même ordre, mais en tous cas, la connection doit se faire comme j'ai indiqué et pas autrement, sinon ça ne peut pas marcher).
En effet, il est logique que la transmission de l'un soit connectée à la réception de l'autre, et inversement.

Bonjour tout le monde,

Je m'appelle Olivier Thill. Je suis informaticien. J'habite dans le Val de Marne.

L'année dernière, j'ai décidé de me lancer dans la robotique.

Mon premier prototype a été réalisé à partir d'une règle pliable en bois :

Il s'appelle RobotLeMetre. Je souhaitais qu'il puisse courrir très vite, mais il a déjà du mal à tenir debout tout seul.
Ce type de bois est très rigide. Il se fend dès qu'on essaye de le percer. Son emploi n'est pas pratique.

Mon second prototype a été réalisé à partir de cornières en aluminium :

Il s'appelle OliRobot. Le préfixe ressemble au début de mon prénom et au début du mot aluminium. C'est un prototype. Il n'a pas tous les moteurs et tous perfectionnements que je voudrais avoir au final. Mais il se tient debout. Il bouge la tête, les bras, les hanches, les jambes. Il marche, au sens de fonctionner et au sens de se déplacer avec ses jambes.

Une petite vidéo :

Voili.

...bracelet contre l’électricité statique...

La question été posée récemment à la société Sparkfun. La réponse, en abrégé, est que ça pourrait être utile dans un cadre industriel de haut niveau, mais qu'on s'en passe habituellement dans les autres cas. Voir les commentaires sur la page https://www.sparkfun.com/news/1097 .