http://photocerfvolant.free.fr

de **becotus** le Sam 03 Décembre 2011, 17:47

Suite à la nacelle construite avec brio et présentée par RDD, il y a de quoi s'interroger entre Pololu et Arduino.

Bien qu'il existe d'autres possibilités de microprocesseurs, Arduino et Pololu apparaissent comme les deux offres les plus élaborées et les plus adaptées à l'aérophoto et à des néophytes de mon genre.

Il est intéressant de noter que Pololu a été créé en 2000 par 3 étudiants au MIT ( le très renommé Massachussets Institute of Technology); L'Arduino quant à lui a été créé en 2006 par deux professeurs italiens pour des TP sur les microprocesseurs, et cela dans la ville d'Italie où se trouve Olivetti. Y a-t-il d'un côté le pragmatisme utilitaire américain pour les besoins fondamentaux, et de l'autre la multiplicité et la performance des solutions potentielles prisées par les latins?

Le besoin d'une confrontation technique et des modalités de mise en oeuvre entre les deux systèmes devrait nous en dire plus.

de **becotus** le Sam 03 Décembre 2011, 17:50

A l'heure de faire un choix, et par comparaisons entre les deux, voici ce que j'en retiens pour l'instant:

Modules, fonctionnalités, accessoires:
Difficile de différencier Pololu et Arduino. Pour les deux, trés nombreux modules de base, gammes très ressemblantes, tout autant de modules complémentaires, gestion par port USB, entrées/sorties série pour communiquer, sorties pour faire fonctionner des servos et bien d'autres choses en les configurant, possibilités de radio-commande, Wifi, interfaces graphiques, GPS, etc...Il semblerait que davantage de capteurs soient proposés sur Pololu. Pololu a une vraie gamme de modules basés sur des applications groupées de base, par exemple avec ou sans radio-commande. Il est remarquable que plusieurs fournisseurs proposent des produits validés Arduino, qui est en license libre, avec des modules très semblables, mais dont les différences peuvent mieux satisfaire les préférences propres à chacun. Avec Pololu et avec Arduino, il faut souvent faire des assemblages de modules dès que les besoins en fonctions différentes s'accroissent. Des modules et des capteurs d'Arduino sont utilisés sur Pololu et vice-versa. ... Difficile de choisir.

Concepts
Pololu est très orienté sur la robotique; les modules permettent de gérer directement des servos. Ainsi il y a en sortie la connectique directe des servos. Pololu offre beaucoup de capteurs de toutes sortes et de petits modules pour des fonctions complémentaires (par exemple le déclenchement direct). Pour d'autres composants, des entrées diverses, et tout autant pour d'autres sorties, Arduino présente au premier abord une plus grande diversité. Pololu se construit en ajoutant des fonctions prédéfinies; avec Arduino on prépare ses fonctions dans le module de base. Il y a deux approches pour des résultats assez équivalents.... Il y a là une orientation selon les besoins de chacun.

Le langage de programmation:
Au départ, c'est le même, puisque tous deux sont en C++. Cependant, les logiciels de configuration propres à Pololu et Arduino sont différents. Mon impression au travers des présentations et des tutoriaux des deux systèmes pour des non-initiés est que Pololu est plus facile à aborder pour les fonctions de base, avec en contre-partie un peu plus d'efforts pour aller plus loin, et au contraire, Arduino demande plus d'attention pour démarrer, mais ensuite est aussitôt ouvert à d'autres possibilités. Pour des applications basiques le résultat est sans doute plus accessible avec Pololu; pour des applications plus diversifiées sur le même système, et plus personnalisées, Arduino est sans doute plus approprié. Pour aller plus loin et modifier des scripts en C++, il y a de très bons tutoriaux pour ce langage et il est donc autant possible de pousser son Pololu que son Arduino... Ce choix se fera donc sur les pratiques souhaitées et ne fera en somme que conforter la préférence de concept.

Construction électronique:
Indéniablement, pour les connexions de base, et en particulier s'il n'y a que des servos à gérer, c'est simple et direct sur Pololu. Avec Arduino, il y a des connexions à installer; il n'y a rien de difficile, mais ce sont des taches et des accessoires électroniques à prévoir en plus.... Toujours cette impression d'orientation plug & play pour Pololu et de lego à monter pour Arduino.

Alimentation électrique:
Tous les modules Pololu s'alimentent entre 0 et 12 ou 16 V et fonctionnent en 5V. Les modules Arduino sont alimentés soit de 0 à 12V, ou en 5V et certains en 3V.. ..Il faut donc être vigilant à l'achat.

Les tutoriels
Il y a beaucoup de tutoriels sur Pololu, sur toutes sortes d'applications, mais celles en français sont des applications particulières, comme en mécanique. Arduino bénéficie de quelques très bons tutoriaux en français; Comme Arduino permet plus de diversité, il semblerait que même pour des choses simples, il soit moins facile de trouver des scripts tout fait et éprouvés. heureusement qu'en aérophoto il y a ce forum.... Il y a là actuellement une différence qui peut fortement orienter le choix.

La disponibilité et le prix:
Je n'ai pas perçu de différences de disponibilité entre Pololu et Arduino. A niveau égal dans la gamme les prix sont très voisins....Le choix ne sera pas sur la disponibilité ou le prix mais sur les besoins propres.

Voilà donc mes impressions de futur utilisateur potentiel. Évidemment, ce sont des impressions; d'autres analyses et d'autres commentaires modifieront ces impressions.

de **becotus** le Sam 03 Décembre 2011, 18:13

@ admin
Bon, j'ai écrit dans le titre Polulu au lieu de POLOLU . Peux-tu corriger?

Merci Emmanuel

de **J-C** le Sam 03 Décembre 2011, 21:19

Mouep ! Pour moi ces deux solutions sont à la fois différentes et identiques.
Identiques car elles sont basées sur la programmation d'un microcontrôleur. Toute programmation nécessite un langage et une interprétation. Et c'est là qu'on entre dans les différences. Le Pololu se rapproche plus du Tucit ou de l'Aurico vu qu'il est basé sur un microcontrôleur PIC. Sauf que là, l'interface de programmation simplifiée permet plus de finesse dans les paramètres.
Cependant avec une autre interface de programmation, on pourrait faire quasi autant qu'avec un Arduino.
Et c'est là que j'en arrive à la différence : l'interface de programmation (ou IDE).
Sur l'Arduino, c'est presque du "brut de décoffrage" , en gros, pour faire ce que fait le Pololu, il faut quelques lignes de code (pas compliquées d'ailleurs). L'arduino est basé sur un microcontrôleur Atmel. Aussi, pour le programmer, il faut un langage C/AVR (du C pour microcontrôleur)... Bref. Mais l'interface de programmation de l'Arduino a été faite grâce à Processing. Et là, avec processing on peut faire une interface de programmation de l'Arduino aussi simple (voire plus) et orientée KAP que celle du Pololu. En gros, si je n'avais pas la flemme, je ferai un programme de configuration de mon code MiniKap, sous Processing... mais c'est dur quand on est seul et surtout quand on se satisfait de l'existant (et quand on n'a aucune arrière pensée commerciale).

En résumé, on ne peut pas comparer les solutions techniquement, car c'est du pareil au même, c'est de la robotique.
Par contre, il est vrai que la programmation du Pololu semble plus abordable "sorti de boîte" que celle de l'Arduino. Mais l'Arduino à l'avantage de sa communauté de passionné même s'il demande un peu plus d'investissement (intellectuel ?). Ceci étant, la programmation d'un PIC est aussi plus complexe que celle d'un Atmel, et on peut lui faire faire plein de truc aussi, mais on n'a pas un IDE simplifié comme celui de l'Arduino... Les scripts ne sont que les parties émergées de l'iceberg binaire de ces petites bêtes.

A+
JC

de **Emmanuel** le Sam 03 Décembre 2011, 21:51

becotus a écrit:@ admin
Bon, j'ai écrit dans le titre Polulu au lieu de POLOLU . Peux-tu corriger?

Merci Emmanuel

C'est fait Christian. Mais l'auteur du premier message peut éditer lui-même le titre de son premier post. De même que les posteurs suivants peuvent aussi éditer le titre de leur réponses (par défaut, le titre initial est repris, mais c'est modifiable). C'est juste pour l'info.

de **becotus** le Dim 04 Décembre 2011, 2:28

Bon, exact, mais ce n'est pas si simple puisque l'erreur se propage dans les réponses suivantes, et l'accès au titre du message n'est pas le titre de la série, et je croyais qu'ils étaient liés, mais non.
Désolé, hors sujet mais concerne le fonctionnement de phpBB.

de **rdd** le Dim 04 Décembre 2011, 8:36

Christian je partage à 100% ta synthèse et l'ajout de J-C.

J'insisterais quand même sur le "ready to play" du Pololu, en moins de 10min sur la table on fait marcher deux ou trois servos sans avoir a télécharger trois ou quatre exemples de scripts sur le net. La conception est vraiment faite en ce sens, par exemple, au branchement d'un Maestro, le logiciel Pololu le trouve, s'y connecte, et adapte son interface au µcontroleur détecté : seulement 6 voies, etc... Alors qu'avec un arduino, c'est à l'utilisateur de sélectionner le modèle de µcontroleur branché, et, éventuellement, son port COM s'il y en a plusieurs...

J'arrive donc aux mêmes conclusions (temporaires vu le manque de recul sur Pololu) que vous : plus facile à démarrer mais va peut être moins loin. Dans le cas d'un projet ambitieux il faut peut être mieux miser sur l'arduino.

de **becotus** le Dim 04 Décembre 2011, 15:59

Merci pour ces confirmations.
Mon analyse étant celle d'un néophyte qui découvre sans avoir utilisé encore, je ne puis être aussi prononcé sur l'affirmatif de Pololu en tant que "prêt à fonctionner".
Je me dis justement que pour de l'autokap Pololu est largement suffisant et certainement peu stressant.
Il y a la gestion du déclenchement en Ricoh qui n'est pas directe. En me basant sur le script pour le Canon S90, j'ai écrit celui qui devrait convenir pour les Ricoh sur la prise USB.

Code: Tout sélectionner: # routine Ricoh sur Pololu # mise en route, déclenchement, arrêt # servo n°0 comme input # servo n°5 déterminé comme output # 0V si < 6000 2V si = ou > 6000 # initialisation + demi-enclenchement + enclenchement total + relachement # Arrêt => garder le bouton enfoncé pendant 2s sub remote begin remote_a if ricoh endif repeat sub remote_a 0 get_position 1000 less_than return sub ricoh 10 delay # 0V 10ms ¤ 6000 5 servo # 2V 30ms ¤ 0V 80ms ¤ 30 delay 0 5 servo 80 delay 6000 5 servo # 2V 150ms ¤ 0V 50ms ¤ 150 delay 0 5 servo 50 delay 6000 5 servo # 2V 30ms ¤ 0V 30ms ¤ 5V ¤ 30 ms ¤ 0V 400ms 30 delay 0 5 servo 30 delay 6000 5 servo 30 delay 0 5 servo 600 delay remote_a if fin endif return sub fin 6000 5 servo # 2V 500ms ¤ 0V 50ms ¤ 600 delay 0 5 servo 50 delay 6000 5 servo # 2V 30ms ¤ 0V 30ms ¤ 5V ¤ 30 ms ¤ 0V 400ms 30 delay 0 5 servo 30 delay 6000 5 servo 30 delay 0 5 servo 900 delay return

Comme quoi, ce n'est pas compliqué et plutôt facile quand on sait comment c'est composé. Ensuite il restera à prendre la fonction input sur une autre voie pour lancer cette routine, et à introduire cette routine dans le script général de la configuration des servos comme tu nous l'as montré.

Je continue à réfléchir sur les autres fonctionnalités que j'ai en tête et qui ne sont pas de l'autokap, et à comparer les mérites entre Pololu et Arduino.

PS: 22 décembre: mise à jour du script après essais et validation

de **André** le Dim 04 Décembre 2011, 16:56

Ouhlala !
Ben moi, je comprends de moins en moins de quoi vous êtes en train de parler...
Le Poilu me plaisait bien mais je crois que je vais en rester à une mini nacelle comme celle d'Yvo...

de **rdd** le Dim 04 Décembre 2011, 20:07

Pour ce qui concerne les impulsions, j'ai constaté une grosse différence entre ce que produit le Maestro et ce que produisent l'arduino ou le CAMRemote.

Je m'explique : sur le S95 (et sur le G10, j'ai fait les deux pour confirmer), j'ai mis un script chdk qui m'imprime la valeur de l'impulsion reçue. Par exemple quand chdk reçoit 700ms d'impulsion positive par l'usb, il affiche '70'.

J'ai testé avec ce script pour la mise au point du déclenchement avec le maestro, et les valeurs ne sont pas très régulières. Lorsque j'active la sortie du servo où j'ai mis l'usb chdk, pendant 700ms, j'ai une valeur en 67 et 74 sur le S95 (pareil sur le G10). Alors qu'avec l'arduino (ou le CAMRemote), le script m'affiche des valeurs entre 69 et 71, donc plus fiable.

Je pensais que cela pouvait venir de l'alimentation (2xAA en stepup pour avoir 5V), mais, alimenté par l'usb du PC ça fait pareil.

Cela n'est pas grave en soit car il suffit, côté CHDK de mettre une fourchette plus large dans le script, mais si ton Ricoh attend 120ms à 1% prêt ça ne déclenchera pas tout le temps.

Arf ... mon royaume pour un oscillo qui me permettrait de confirmer tout ça par des mesures :roll:

de **Deltakap** le Lun 05 Décembre 2011, 13:45

Pas sur que ça aide à la compréhension, mais à mon sens il est impossible de comparer ces deux systèmes... sauf si on parle de réponse à une problématique bien précise:
Est-ce que je veux faire une nacelle autokap ? alors oui, je peux le faire avec les deux, mais ça sera beaucoup plus simple avec le pololu puisqu'il est conçu de fait pour contrôler des servos.
Est-ce je veux faire une nacelle radiocommandée avec une micro-télécommande, et qui fasse aussi de l'autokap si besoin ? alors là, le plus sur est de s'orienter directement vers l'arduino puisque le pololu n'est pas prévu pour ça (bon, c'est peut-être plus ou moins adaptable, mais pas sur que ça fonctionne comme on le voudrait)

Pour moi, la différence fondamentale entre les deux systèmes, c'est que l'Arduino doit être entièrement programmé pour savoir faire quelque chose, alors que le pololu est déjà programmé pour faire du controle de servos... et qu'il ne peut pas être reprogrammé pour faire autre chose.
Le pololu est simplement configurable (via le logiciel livré avec et installé sur le PC) mais n'est plus programmable.
A noter que l'Arduino peut être évidemment configurable aussi (via un logiciel à créer soi-même, et c'est loin d'être impossible) mais seulement si on l'a programmé soi-même pour être configurable.

L'arduino permet une liberté totale de fonctionnalités qui ne dépendent que du programme qu'on lui donne à exécuter, le pololu, lui, permet avant tout.... de controler des servos.

Pour faire une comparaison libre et (un peu trop) imagée :mrgreen:

, dans un cas on achète une magnifique clio toute neuve qui moyennant une "configuration" a effectuer soi-même (vérification des niveaux, remettre du carburant, etc...) permettra de façon extrêmement fiable d'aller.... faire les courses au supermarché du coin (mais c'est parfait, c'est ce qu'on attend d'elle

).
Dans l'autre cas on achète un chassis avec 4 roues et un hangar qui comprend tous les moteurs et carrosseries du monde (les programmes pour ceux qui suivent

)... si on a besoin d'un tracteur on choisi un moteur puissant de tracteur et une belle carrosserie de tracteur et on file directement aux champs.... si on a besoin d'une voiture de course, on choisi le moteur de formule 1 et la carrosserie rouge qui va avec. Faudra juste mettre un peu plus les mains dans le cambouis :mrgreen:

mais on aura le véhicule de ses rêves (ou juste de ses besoins)

de **mich2e** le Lun 05 Décembre 2011, 16:00

c'est peut etre un peu mon problème: j'aimerais bien aller faire des courses en tracteur, rouge pourquoi pas !
ou en moto :lol:

plus sérieusement, vu la facilité avec laquelle tu avais réalisé la première nacelle ultra géniale.....tu devrais pouvoir rajouter un gros moteur !

de **Deltakap** le Lun 05 Décembre 2011, 17:08

mich2e a écrit:tu devrais pouvoir rajouter un gros moteur !

La question que je me pose, c'est que reproches-tu au camremote ?

Parce que en principe il a déjà le gros moteur, en tout cas ce qui manquait cruellement à ma bidouille, à savoir le tilt et l'interface de configuration depuis un PC, une portée en principe plus importante et un tas de boutons sur la télécommande. (les 4 de la mini télécommande demandaient à faire des compromis pour ajouter le tilt)

de **mich2e** le Lun 05 Décembre 2011, 21:40

Honnêtement rien, mais rien de rien que je reproche au Camremote ! C'est à ce jour le meilleur système que j'ai utilisé par son rapport qualité prix encombrement modularité. Sauf peut etre son prix qui a chaque fois fait sortir un billet de 80 euros ! rien que pour le module de commande. et presqu'autant pour la radio. (Je ne sais d'ailleurs pas si on peut racheter le récepteur sans racheter la telecommande). et les temps sont durs ;-)

Je l' utilise sur 2 nacelles différentes RICOH / PENTAX et ca marche plutôt bien. Et pour voler à coté de Patrick, régulièrement j'ai meme découvert que chaque nacelle savait reconnaitre SA radio à l'allumage ! c'est assez malin !
Mais j'aime bien l'idée de continuer à améliorer à chaque fois un peu plus: l'idée d'un petit module qui serait compatible - tu te souviens: modulaire - et qui permettrait de préparer une nouvelle nacelle autokap/manuel light, c'est tentant.
nous avons longtemps discuté de ce que l'on attendrait d'un système parfait. l'expérience montre qu'on a toujours envie d'en rajouter un peu. le mieux reste l'ennemi du bien. Mais du coup le vrai truc c'est d'être capable de le paramétrer finement par soi meme et d'y implémenter des fonctions. et comme je ne compte pas me mettre à la programmation, l'interface graphique m'a laissé penser que c'était plus facile.
Pour être concret, je pense par rapport au CamRemote, que quelques détails sont intéressants:
* ta conception avec une bascule automatique en autokap si pas de signal est TRES intéressante, Le cam remote ne passe pas tout seul en autokap. il faut le faire avec la radio.
* en autokap, l'approche de RDD avec un nombre limité de pan sur le tilt vertical est aussi une bonne amélioration. pas utile de faire 8 vues en vertical,
* que pour une nacelle autokap ultra ligth, l'idée d'alimenter par la pile de l'appareil.... mais garder une radio au cas ou ca fait rever !
Et honnêtement, si effectivement il existait un système qui permette avec une interface simple, de programmer d'autres fonctions, j'essaierais aussi de limiter l' alimentation du retour vidéo, de façon à économiser les piles, par exemple aux seuls instants ou on actionne la radio ou on déclenche avec une tempo à mettons 2s,
En cherchant bien je peux encore trouver quelques idées.

Mais si déjà on fait tout cela....

de **Deltakap** le Lun 05 Décembre 2011, 22:28

mich2e a écrit:En cherchant bien je peux encore trouver quelques idées.

N’hésite surtout pas, n'hésitez surtout pas....

L'idée de l'autokap automatique sur une nacelle radiocommandée est la tienne, je n'ai fait que la mettre en pratique (et c'est vrai que c'est pratique, ma nacelle fonctionne comme ça et c'est vraiment un plus énorme par rapport à sa version télécommande RC d'origine).

C'est vrai que tu me parles depuis toujours de cette modularité, pas si facile pourtant à mettre en oeuvre en pratique... mais qui au final pourrait être LA vraie réponse aux attentes les plus diverses.

Parce que, et pour revenir au sujet proposé par Christian, on voit bien qu'il y a à la fois des besoins en terme de fonctionnalités avancées et des interrogations face à la maîtrise (ou non) des outils pour y parvenir. Certains franchiront le cap du passage à la programmation (Christian sans doute, puisqu'il se pose la question

), d'autres ne le feront jamais comme l'avoue sans honte Michel (non pas qu'il n'en n'ait pas la capacité... c'est juste parce que c'est pas son truc et qu'il n'a aucune envie d'essayer :mrgreen:

). Mais bon, comme il a de très bonnes idées (de celles qui sont capables de me motiver)... il est plus que pardonné

de **Deltakap** le Mar 06 Décembre 2011, 7:37

(suite.....)

becotus a écrit:Bien qu'il existe d'autres possibilités de microprocesseurs, Arduino et Pololu apparaissent comme les deux offres les plus élaborées et les plus adaptées à l'aérophoto et à des néophytes de mon genre.

Juste pour chipoter, il est plus juste de parler pour ces modules de microcontroleurs (http://fr.wikipedia.org/wiki/Microcontr%C3%B4leur) que de microprocesseurs (http://fr.wikipedia.org/wiki/Microprocesseur). Ces deux composants ont certes physiquement un air de famille et ont en commun la possibilité d'exécuter les instructions données par un programme, mais leurs principales différences sont le degré d'intégration (plus élevé pour le microcontroleur: il n'a besoin que de très peu de composants externes pour fonctionner avec son environnement) et la vitesse d'exécution des instructions (beaucoup plus importante pour le microprocesseur avec une consommation beaucoup plus élevée).

Dans notre domaine, arduino, camremote, pololu, tucit, aurico et même les cables Gentled utilisent tous un microcontroleur (Atmel AVR, ou PIC de chez Microchip).
A mon sens, camremote, pololu, tucit, aurico et Gentled entrent dans une même catégorie: les microcontroleurs sont préprogrammés pour effectuer une tache bien précise (controle de servos et/ou déclenchement d'apn).
Camremote, pololu, tucit, aurico sont configurables et permettent à l'utilisateur de paramétrer leur mode de fonctionnement.

L'arduino, lui, n'est pas préprogrammé, enfin si un peu (le bootloader, j'y reviendrais).

- Arduino, c'est quoi? et pourquoi a-t-il un tel succès auprès des hobbyistes créateurs de robots, des bidouilleurs et des artistes de tous poils?

Pour faire fonctionner un microcontroleur, il lui faut quelques composants externes et bien sûr avoir la possibilité de le programmer. Il faudra donc à terme le monter sur un circuit imprimé regroupant tous ces composants (et donc concevoir ce circuit imprimé). Puis, il faudra créer sur un ordinateur avec un logiciel dédié le programme qu'exécutera le microcontroleur. Il faudra enfin utiliser un programmateur (souvent cher pour un amateur) pour entrer ce programme dans le microcontroleur. Une fois toutes ces étapes passées, le microcontroleur fonctionnera enfin de façon autonome. C'est jouable... mais c'est très lourd (et ch*ant) à mener à terme dans le cadre d'un loisir.

Arduino est, à l'origine, un concept qui regroupe un format défini de circuit imprimé pour la partie matérielle (ça s’achète tout fait et ça supporte des tas de cartes d’extension qui s’emboîtent comme des legos) et un logiciel libre et gratuit (qui s'appelle aussi arduino

) pour créer le programme qu'exécutera le microcontroleur. Encore plus fort, ce programme pourra être chargé sur le microcontroleur via la prise usb de la carte arduino sans utiliser de programmateur!!!: Un petit bout de programme, le bootloader, est préchargé sur le microcontroleur et surveille le port usb. Dès qu'un programme est envoyé depuis le logiciel de l'ordinateur (le logiciel arduino donc), il est chargé sur le microcontroleur. Dès que c'est fait, le microcontroleur redémarre et exécute le programme qu'on vient de lui charger et peut vivre sa vie de façon autonome.
Arduino simplifie donc énormement la phase de conception d'un système à microcontroleur.... il ne reste plus qu'à brancher une alim, le cable usb et... développer son programme (Ah bah si, faut quand même mouiller un peu sa chemise :mrgreen:

).

Plusieurs formats de cartes arduino existent aujourd'hui, supportant différents type de microcontroleurs plus ou moins puissants (Atmel AVR pour l'instant et sans doute bientôt des PIC Microchip via le logiciel Wiring dont le logiciel Arduino est issu) et différentes tensions d'alimentations... ça complique pas mal le choix de la "bonne" carte pour sa propre application

Mais toutes sont gérées et programmables par le logiciel Arduino.

Ça se passe là: http://www.arduino.cc/ (ou http://www.arduino.cc/fr/)

de **Deltakap** le Mar 06 Décembre 2011, 8:31

(suite again....)

becotus a écrit:Difficile de différencier Pololu et Arduino. Pour les deux (...) possibilités de radio-commande, Wifi, interfaces graphiques, GPS, etc...Il semblerait que davantage de capteurs soient proposés sur Pololu.

tu es certain de ça?
On parle bien du contrôleur de servos décrit par rdd?
J'ai raté un truc? C'est expliqué où?

de **Deltakap** le Mar 06 Décembre 2011, 8:47

(la suite de la suite, désolé :mrgreen:

)

becotus a écrit:Indéniablement, pour les connexions de base, et en particulier s'il n'y a que des servos à gérer, c'est simple et direct sur Pololu. Avec Arduino, il y a des connexions à installer

Pas forcement: il existe une carte "Roboduino" avec les connecteurs de servos:

Source: http://www.geeetech.com/robot-aduino-bo ... -p-76.html

PS: Elle n'est évidemment plus compatible avec les shields d’extension arduino.

Il y a aussi un IO Expansion Shield pour le classique Arduino Duemilanove/Uno (à emboîter dessus)

Il existe également un shield pour l'arduino nano:

Source: http://www.geeetech.com/new-arduino-nan ... p-311.html

C'est cette dernière solution que j'ai adopté avec un arduino nano 5V ATMEGA328. Cette carte d'extension pour le nano permet de brancher directement les servos et dispose d'un support pour un transducer APC220 (emetteur/recepteur 433Mhz)

Bon ok, c'est beaucoup moins compact que le pololu

de **Deltakap** le Mar 06 Décembre 2011, 9:53

(encore moi

....)

becotus a écrit:Pour des applications basiques le résultat est sans doute plus accessible avec Pololu

Pour se faire une idée, voici quelques exemples simples livrés avec le logiciel arduino:

- Pour faire clignoter une LED:

Code: Tout sélectionner: /* Blink Turns on an LED on for one second, then off for one second, repeatedly. This example code is in the public domain. */ void setup() { // initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards: pinMode(13, OUTPUT); } void loop() { digitalWrite(13, HIGH); // set the LED on delay(1000); // wait for a second digitalWrite(13, LOW); // set the LED off delay(1000); // wait for a second }

- Allumer/éteindre une LED en fonction de l'état d'un interrupteur:

Code: Tout sélectionner: /* Button Turns on and off a light emitting diode(LED) connected to digital pin 13, when pressing a pushbutton attached to pin 2. (...) */ // constants won't change. They're used here to // set pin numbers: const int buttonPin = 2; // the number of the pushbutton pin const int ledPin = 13; // the number of the LED pin // variables will change: int buttonState = 0; // variable for reading the pushbutton status void setup() { // initialize the LED pin as an output: pinMode(ledPin, OUTPUT); // initialize the pushbutton pin as an input: pinMode(buttonPin, INPUT); } void loop(){ // read the state of the pushbutton value: buttonState = digitalRead(buttonPin); // check if the pushbutton is pressed. // if it is, the buttonState is HIGH: if (buttonState == HIGH) { // turn LED on: digitalWrite(ledPin, HIGH); } else { // turn LED off: digitalWrite(ledPin, LOW); } }

- Faire varier la position du servo de 0 à 180° puis retour, en boucle:

Code: Tout sélectionner: // Sweep // by BARRAGAN <http://barraganstudio.com> // This example code is in the public domain. #include <Servo.h> Servo myservo; // create servo object to control a servo // a maximum of eight servo objects can be created int pos = 0; // variable to store the servo position void setup() { myservo.attach(9); // attaches the servo on pin 9 to the servo object } void loop() { for(pos = 0; pos < 180; pos += 1) // goes from 0 degrees to 180 degrees { // in steps of 1 degree myservo.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position } for(pos = 180; pos>=1; pos-=1) // goes from 180 degrees to 0 degrees { myservo.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position } }

Dans ce dernier exemple, l'usage d'une librairie (ici Servo) permet de simplifier le travail de codage.

Pour lancer la compilation et l'envoi d'un de ces programmes sur la carte arduino (dans le microcontroleur donc), il suffit de cliquer sur le bouton "upload" du logiciel arduino et d'attendre quelques secondes que le transfert soit effectué... le microcontroleur redémarre tout seul et fait clignoter la LED, ou lit un interrupteur ou fait bouger le servo, ou n'importe quoi d'autre selon les besoins.... c'est tout

de **a906** le Mar 06 Décembre 2011, 10:34

Gilbert, t'es encore resté toute la nuit devant le pc et l'arduino... lalalala, j'te jure :lol:

de **Deltakap** le Mar 06 Décembre 2011, 10:39

a906 a écrit:Gilbert, t'es encore resté toute la nuit devant le pc et l'arduino... lalalala, j'te jure

Nan, mais debout à 5h pour en oublier le moins possible

c'est pas du dévouement ça ? :mrgreen:

de **André** le Mar 06 Décembre 2011, 18:30

Ah ben si : on peut dire ça...
Du coup, je me sens obligé de prendre le temps de lire toute ta prose... mais j'avoue ne pas y comprendre grand chose

Mais pas d'inquiétude : c'est moi, pas tes explications :wink:

de **hansel** le Mar 06 Décembre 2011, 19:06

André a écrit:Mais pas d'inquiétude : c'est moi, pas tes explications

Quand j’étais gamin a l’école la maitresse me disait "tu comprend vite, mais il faut t'expliquer longtemps' :lol:

Avec les Arduinos (comme probablement avec les Pololus) le plus importent c'est de commencer. J'ai débuté en jouant avec les exemples. Après ça l'imagination et le temps disponible sont les limites! Quand ça ne fonctionne pas, on adapte ou on essaye quelque chose d'autre :mrgreen:

de **André** le Mar 06 Décembre 2011, 20:53

hansel a écrit:Quand j’étais gamin a l’école la maitresse me disait "tu comprend vite, mais il faut t'expliquer longtemps'

Tiens on dit ça par chez vous aussi ?
Maintenant, c'est moi la maîtresse ( :wink:

) mais il faut m'expliquer longtemps et c'est pas sûr que je comprenne :oops:

de **becotus** le Mar 06 Décembre 2011, 22:18

@ André,
Si tu veux savoir s'il est possible de se faire sans coup férir une nacelle autokap de base, tu verras sur le sujet de la nacelle Pololu mini Maestro 6 que c'est possible.

Ceci dit, j'ai initié ce sujet de discussion pour comparer ces deux systèmes car il n'est pas évident au départ de faire un choix sur les moyens potentiels par rapport à des besoins et des envies personnels.
A la lecture de ce qui a déjà été exprimé, je me rends compte qu'il y a deux niveaux de comparaison qu'il convient de distinguer. D'une part le système complet avec la gamme associée: Arduino et Pololu, et d'autre part le module Pololu micro Maestro6 vis à vis d'un module comme l'Arduino nano pour confronter deux modules de prix voisins.

Commençons par comparer ces deux modules avec un bref résumé journalistique.
Le module Pololu micro Maestro 6 est un contrôleur de servo. Parfait pour cette tache, simple à mettre en oeuvre autant pour la partie connectique que la partie paramétrage. Il est assez facile de lui adjoindre quelques fonctions et quelques modalités non complexes ce qui le rend tout à fait personnalisable.
Le module Arduino nano est une carte programmable, avec une grande universalité d'applications potentielles. On peut en faire beaucoup de choses, ce qui implique d'ajouter un minimum de connectique, et de se pencher sur un minimum de programmation. Il faut donc faire un peu d'électronique, et un peu de programmation. Un peu d'initiation avec les bons tutoriaux existant et le résultat sera très gratifiant.
Autrement dit, le module Pololu micro Maestro 6 sera plus rapidement mis en oeuvre que l'Arduino nano, mais à terme il offrira poins de possibilités. C'est donc un choix stratégique. Pour un but identique, une nacelle autokap simple, la comparaison se tient.

Cependant, il est peut-être inapproprié de comparer ces deux modules car ils n'ont pas le même but au départ. En fait, l'Arduino nano devrait se comparer à un autre contrôleur programmable, et le Pololu mini maestro à un autre contrôleur de servo.
Finalement, dans la gamme du système Arduino, et des fabricants associés, je n'ai pas trouvé un module similaire au Pololu Maestro.
Inversement, dans la gamme Polulu il existe des micro-contrôleurs tels que le Baby Orangutan B 328 mais malgré tout, avec des différences et sans la grande universalité de l'Arduino.
En fait les deux systèmes ont chacun une large gamme de modules avec des complémentarités, et on peut trouver son bonheur autant dans un système que dans l'autre. Tels que je les vois, le système Pololu ressemble davantage à un assemblage possible de kits fonctionnels complémentaires, et le système Arduino à des éléments multi-applications qui sont définis selon les orientations et les objectifs choisis. L'universalité est dans la gamme permettant l'assemblage de modules fonctionnels chez l'un et dans la créativité et la personnalisation de solutions chez l'autre. En simplifiant à l'extrême, du plat cuisiné pour l'un, un assortiment de produits du marché pour l'autre. Il est d'ailleurs curieux de noter qu'il y a peu de tutoriaux à propos de Polulu. Ce ne sont la plupart du temps que des modes d'emploi pour réchauffer, et de l'autre de multiples recettes de cuisine. Ainsi, pour L'Arduino il y a plusieurs tutoriaux, la plupart très bien faits.

Voila comment je perçois ces deux systèmes sans les avoir encore utilisés, mais au travers des solutions que j'ai pu observer et d'informations que j'ai pu noter.
Tout ce que Gilbert a indiqué est juste. [Diable, il est incollable sur l'Arduino].
Ces deux systèmes sont différents. Tant mieux, il suffit de bien comprendre pourquoi et finalement y trouver son bonheur.

de **André** le Mer 07 Décembre 2011, 7:18

Merci a tous en tous les cas de prendre le temps de nous expliquer tout ça par le détail.
Comme le dit Hans, faudrait peut-être que je me lance pour que tout cela devienne un peu plus concret pour moi :wink:

de **rdd** le Mer 07 Décembre 2011, 9:30

... et maintenant on en sait assez pour monter un Maestro 6 ... contrôlé par un arduino nano ... avec une télécommande de CAMRemote :lol:

Blague à part, tout cela peut sembler complexe et réservé à des initiés ... comme le chdk ... il n'en est rien ! Et même si vous butez sur un point ou un autre, notre petite communauté saura en venir à bout. J'ai fait en deux/trois mois ce qu'il m'aurait pris deux/trois ans sans la lecture des échanges J-C/Deltakap et des idées de Christian ou Gilbert qui éclairent drôlement bien le chemin.

Si cela vous tente, lancez vous car c'est une aventure extra, très stimulante et ... très bien adapté à la météo actuelle :wink:

de **Deltakap** le Mer 07 Décembre 2011, 11:40

becotus a écrit:Cependant, il est peut-être inapproprié de comparer ces deux modules car ils n'ont pas le même but au départ. En fait, l'Arduino nano devrait se comparer à un autre contrôleur programmable, et le Pololu mini maestro à un autre contrôleur de servo.

Il y a effectivement quelque chose qui manque dans le titre de ce post "POLOLU et ARDUINO: comparaisons".
qu'entend-on exactement par pololu ?

Si on parle du Pololu mini maestro testé par rdd, il est plus juste à mon sens de le comparer au camremote (sans radio), au tucit ou à l'aurico. (et du coup, c'est de la balle pour se fabriquer une nacelle autokap avec un fonctionnement très personnalisé sans trop se casser la tête). Après, on peut bien sûr faire la même chose avec un arduino... mais comme déjà mentionné, ça va demander un peu plus d'investissement personnel (intellectuel?)
Le vrai regret c'est que le microcontroleur du mini maestro ne soit pas (re)programmable. Cette carte aurait été une vrai tueuse pour le kap.

Si on veut comparer l'arduino à d'autres "Programmable Controllers" (ce qui est plus logique), on trouve sur le site pololu.com la page http://www.pololu.com/catalog/category/64. On note d'ailleurs que le premier est un..... arduino uno :oops:

suivi de 3 orangutan.
Je n'ai pas trouvé (pas assez cherché peut-être) avec quoi on programme ces orangutan's (et c'est facheux quand même!). Tous les 3 sont basés sur des microcontroleurs Atmel AVR.... ont-ils un bootloader compatible avec le logiciel arduino??? je ne sais pas

L'autre "offre" à comparer à l'arduino est bien le "Parallax BASIC Stamp 2" http://www.pololu.com/catalog/product/1600.
Là, le logiciel de programmation est PBASIC. Je ne connais pas, mais bon, comme arduino il doit suffire de s'y mettre. Par contre, pour entrer le code dans ce basic stamp, c'est un cable RS232 qui est proposé :shock:

(bien, mais ça se branche où?). Bon heureusement, il y a un site parallax.com qui doit expliquer tout ça.

Je pense que dans la gamme "Programmable Controllers", le concept arduino a pour lui la simplicité de mise en oeuvre et une communauté d'utilisateurs très importante (et donc toujours très active), ce qui lui donne une sacré longueur d'avance dans le cadre de cette robotique de loisirs. Après franchir le pas.... ou pas :mrgreen:

that is the bonne question

PS1: malgré mes propos, je n'ai rien à vendre

PS2: Je ne suis pas incollable sur l'arduino, loin de là... je n'ai toujours pas pris le temps de chercher à comprendre le fonctionnement des interruptions sur les atmel AVR (malgré tout un des concepts fondamentaux de ces petites bêtes), chose qui a été très simple à maîtriser sur les PIC de Microchip (mais qui eux ne disposent pas (encore?) de l'environnement matériel et logiciel si bien pensé de l'arduino, comme toujours rien n'est parfait

)

de **becotus** le Mer 07 Décembre 2011, 18:30

Bon, il va bien falloir que je fasse un choix!

Le vrai regret c'est que le microcontroleur du mini maestro ne soit pas (re)programmable.

Gilbert, que veux-tu dire par là?

de **Deltakap** le Mer 07 Décembre 2011, 22:00

becotus a écrit:Gilbert, que veux-tu dire par là?

Oui, c'était mal formulé

Le microcontroleur du mini maestro 6 (visiblement un PIC 18F14K50 de Microchip) est bien évidemment, comme tout microcontroleur, programmable et reprogrammable... sauf que là, une fois soudé sur sa carte mini maestro, il n'est plus possible de modifier son programme: Il faudrait le dessouder pour le placer physiquement sur un programmateur, le reprogrammer puis le ressouder sur son circuit imprimé de mini maestro... mieux vaut oublier cette manip

Il a été programmé pour être un controleur de servos et pouvoir dialoguer avec son logiciel de configuration sur le PC. Il est impossible (raisonnablement) de lui faire faire autre chose.
Si il avait été simplement programmé à l'origine avec un bootloader, il aurait été possible, sans le dessouder, de le programmer et de le reprogrammer à volonté (sans avoir à utiliser physiquement un programmateur de microcontroleur, le bootloader le "remplaçant") et d'en changer totalement les fonctionnalités (à la manière de l'arduino) tout en gardant l'avantage de la compacité de ce mini maestro.

Mais bon, c'est déjà bien ce qu'il fait

de **becotus** le Sam 10 Décembre 2011, 10:31

Merci Gilbert pour tous ces compléments.
Mes projets (actuels) sont:
¤ Un ajout à ma nacelle stéréo: déclenchement Ricoh et retour vidéo de l'un ou l'autre des appareils. Bon, je peux le faire aussi sans microcontrôleur mais j'éviterai ainsi de monter mon CA1 spécial stéréo et ses gros cables et j'aurai plus de possibilités... (le CA1 est le module de déclenchement de Ricoh auquel j'ai ajouté une 2ème usb et une entrée pour le déclenchement à distance, ce qui fait 65g)
¤ Ajouter un pano automatique sur la nacelle radio-commandée. Un appui sur la 5ème voie de la radio-commande, et hop, c'est parti pour un tour.
¤ Des fonctions supplémentaires pour la nacelle perche et déclenchement sans le CA1
¤ Une nacelle autokap simplissime

C'est décidé, je commence par me lancer avec un Pololu micro Maestro 6 channel & usb.
Le plus simple et le plus rapide, suffisant pour tous ces projets, sauf pour la nacelle perche, et en plus, pas cher, et bien peu de compléments à prévoir. Comme je sais que la programmation prend toujours du temps, j'économise de ce côté là. J'avais prévu d'avoir l'ajout stéréo pour la fin de l'année et de lancer l'ajout pano sur commande dans la foulée. ca devrait le faire. Ensuite, on verra. Pour la perche, ce pourrait bien être un Arduino.

de **Deltakap** le Sam 10 Décembre 2011, 10:58

Bonjour Christian,

becotus a écrit:Merci Gilbert pour tous ces compléments.

Je t'en prie

becotus a écrit:¤ Un ajout à ma nacelle stéréo: déclenchement Ricoh et retour vidéo de l'un ou l'autre des appareils. Bon, je peux le faire aussi sans microcontrôleur mais j'éviterai ainsi de monter mon CA1 spécial stéréo et ses gros cables et j'aurai plus de possibilités... (le CA1 est le module de déclenchement de Ricoh auquel j'ai ajouté une 2ème usb et une entrée pour le déclenchement à distance, ce qui fait 65g)

As-tu le schéma de ce CA1? Est-il sur ton site? (j'ai pas cherché :oops:

)

becotus a écrit:¤ Ajouter un pano automatique sur la nacelle radio-commandée. Un appui sur la 5ème voie de la radio-commande, et hop, c'est parti pour un tour.

Là, j'ai un gros doute... commander le maestro avec une voie de radiocommande? A part utiliser un Gentled (chdk par exemple) pour interfacer le récepteur radiocommande et le maestro, je ne vois pas comment tu vas faire. (les signaux sont à priori incompatibles, je ne vois pas comment le maestro pourra lire le train d'impulsions de la radio)

becotus a écrit:¤ Une nacelle autokap simplissime

Là, ok, et c'est sans doute le meilleur choix à faire.

becotus a écrit:Pour la perche, ce pourrait bien être un Arduino.

N'hésite pas à donner des détails sur ce que tu veux comme fonctions sur cette perche (pour savoir si c'est le meilleur choix

)

de **Deltakap** le Sam 10 Décembre 2011, 11:11

Deltakap a écrit:As-tu le schéma de ce CA1? Est-il sur ton site? (j'ai pas cherché )

J'ai rien dit :oops:

Le CA1, c'est la télécommande filaire officielle du Ricoh (avec un deuxième usb pour la stéréo et un interrupteur déporté)
Le Maestro devrait pouvoir le remplacer complètement sans trop de problèmes

de **becotus** le Sam 10 Décembre 2011, 18:38

Avec tous ces soutiens locaux de la région caennaise, le Pololu Maestro n'a plus qu'à bien se comporter.

Un doute sur la 5ème voie? moi aussi.
Il y a la possibilité d'entrées analogiques entre 0 et 5V en déclarant des voies en input et non en sortie servo. Dans le script, la commande get_position lit la valeur entre 0 et 1023 et on l'utilise pour une fonction déterminée. Oui, je sais, une impulsion de seulement 1,75 ms n'est pas une tension continue, pas certain que le Maestro réagisse. Il m'a semblé qu'il y a des solutions toutes simples qui existent.
Je verrai bien, sinon il y a un plan B.
Sur mes nacelles le déclenchement est un interrupteur. Il va déjà me servir pour lancer le déclenchement du Ricoh, donc là, pas de souci. Si je garde cette position un certain temps, le script peut le vérifier (par exemple à deux reprises à 1s et à 2s) et donc déclencher la séquence pano puis revenir en veille.

de **Deltakap** le Sam 10 Décembre 2011, 19:27

becotus a écrit:Un doute sur la 5ème voie? moi aussi.

Branché directement sur le récepteur, le maestro devrait lire aléatoirement des 0 et des 1 (statistiquement + de 0 que de 1, quelle que soit la "position" de la 5ème voie).

Le plan A pourrait être un GentWire USB (canon) avec le fil bleu relié au noir coté voie 5 du récepteur. Apparemment, avec cette modif (http://www.gentles.ltd.uk/gentwire/Manual-usbc.pdf ), la sortie du GentWire change d'état tant qu'on actionne la voie de la radiocommande. Ce signal devrait pouvoir être "mesuré" sans problème par le maestro.
Faudrait juste massacrer la bête coté prise usb pour récupérer les fils noir et rouge et les envoyer vers une entrée du maestro....
J'ai l'impression que le GentWire ricoh fonctionne différemment (http://www.gentles.ltd.uk/gentwire/Manual-usbr.pdf) et ne conviendrait pas pour servir d'interface !?

Pour le plan B, à priori aucun souci

de **alpaph** le Sam 10 Décembre 2011, 19:58

Tiens, une petite histoire de l'Arduino. Le troisième paragraphe à partir de la fin peut donner des idées aux audacieux.

http://www.framablog.org/index.php/post/2011/12/10/arduino-histoire

de **J-C** le Sam 10 Décembre 2011, 20:12

Excellent article.

A+
JC

de **Deltakap** le Dim 18 Décembre 2011, 19:35

Je viens de tomber sur un plugin pour l'IDE arduino (Le programme installé sur l'ordi et qui permet de programmer le microcontroleur de la carte arduino) qui donne la possibilité de programmer visuellement avec des blocs de fonctions.

Je testé vite fait, et c'est plutôt sympa.
Je n'ai pas fait tout le tour et il y a forcement des limitations, mais un autokap ultra simple se programme en deux minutes !!! (bon ok, dans l'éditeur classique aussi... avec un peu d'habitude et/ou un moteur de recherche sous la main)

On ajoute graphiquement des blocs les uns aux autres comme un lego, on clique sur le bouton "générer" et le sketch s'affiche dans la fenêtre d'édition habituelle (ça ne fonctionne que dans ce sens là, pas de l'éditeur de sketch vers l'éditeur de blocs).
Il n'y a plus qu'à faire un upload comme d'habitude et hop...

Ce n'est pas la solution idéale pour faire du sur-mesure, mais ça semble malgré tout assez intéressant pour faire ses premiers pas dans le monde de l'arduino.

Pour info, il est bien sur possible de télécharger l'IDE arduino ainsi que ce plugin, le tout gratuitement, pour se faire une idée.... Bon évidemment, pour tester en vrai, il faudra bien sûr acheter une carte arduino :wink:

L'installation du plugin est expliquée là:
http://www.semageek.com/arduino-present ... ardublock/

ou directement là:
http://blog.ardublock.com/2011/10/25/in ... duino-ide/

Edit: Apparemment, le projet scratch4arduino (http://seaside.citilab.eu/scratch/arduino) doit permettre le même genre de chose (mais là, je n'ai pas regardé

)

de **becotus** le Dim 18 Décembre 2011, 22:23

J'avais déjà repéré cette page avec d'autres d'ailleurs sur ce site au nom enchanteur. Il est certain que c'est excellent pour commencer puisque l'écriture du script se fait automatiquement pour des fonctions simples. C'est moins crispant que de craindre une erreur d'écriture qui plante tout et qui prend du temps à retrouver quand on débute.
Par ailleurs, j'ai remarqué que certains utilisent des Pololu Maestro en liaison avec un Arduino puisque le Maestro est un contrôleur de servo, et il y a des scripts arduino pour cela.
Je devrais commencer dans quelques jours sur Maestro, et je pense en même temps à un projet pour Arduino!

de **Deltakap** le Lun 19 Décembre 2011, 12:04

becotus a écrit:Par ailleurs, j'ai remarqué que certains utilisent des Pololu Maestro en liaison avec un Arduino puisque le Maestro est un contrôleur de servo, et il y a des scripts arduino pour cela.

En partant de cette idée, j'ai trouvé le post suivant: http://forum.pololu.com/viewtopic.php?f=16&t=4377 qui donne une bonne idée du protocole à utiliser pour communiquer avec le maestro sur son port série.
Du coup, une solution élégante pourrait être d'utiliser simplement sur la nacelle un module xBee branché directement sur le maestro (sans arduino), et pour la télécommande au sol un arduino et un xbee. l'arduino pourrait envoyer directement les bons codes au maestro via le xbee. L'inconvénient, c'est que sans arduino là-haut, on ne peut pas renvoyer d'infos depuis la nacelle vers le sol (altimètre ou autres)
(PS: Le xbee serait à préférer dans ce cas à un APC220 pour garder une bonne réactivité des commandes... avec la quasi obligation d'un retour vidéo en 5.8Ghz pour éviter les interférences avec le xbee qui fonctionne lui en 2.4Ghz.)

Bon, c'est une réflexion brute de décoffrage, faudrait développer un peu cette éventuelle possibilité pour voir si il n'y a pas de contre indications. En tout cas, ça permettrait de remplacer totalement l'emetteur/recepteur classique.
Mais si il faut se mettre au développement arduino (pour la télécommande).... autant en mettre un aussi sur la nacelle et se passer du maestro.... faut voir.

Edit: A noter que l'utilisation sur la nacelle d'un arduino couplé à un mastro est une solution matérielle (pas donnée certes) au problème d'incompatibilité des librairies SoftwareSerial et Servo (non résolu avec la version arduino 1.0 :evil:

). Si on a plus de deux servos à piloter et la nécessité d'utiliser SoftwareSerial, l'ajout d'un maestro est à considérer

becotus a écrit:Je devrais commencer dans quelques jours sur Maestro, et je pense en même temps à un projet pour Arduino!

N'hésite pas à nous faire part de ce projet.... toutes les bonnes idées sont bonnes à prendre

Edit: Pour le fun, un exemple d'autokap PAN et TILT avec Ardublock....

Et qui génère un code bien crade :mrgreen:

: (pas testé en vrai mais à priori fonctionnel)

Code: Tout sélectionner: #include <Servo.h> Servo servo_pin_10; int _ABVAR_2_; int _ABVAR_1_TRotationPAN; int _ABVAR_3_i; Servo servo_pin_9; void setup() { servo_pin_10.attach(10); _ABVAR_1_TRotationPAN = 0; pinMode( 13 , OUTPUT); servo_pin_9.attach(9); _ABVAR_3_i = 0; } void loop() { _ABVAR_1_TRotationPAN = 10000 ; servo_pin_9.write( 1520 ); delay( ( _ABVAR_1_TRotationPAN / 8 ) ); servo_pin_9.write( 1500 ); for (_ABVAR_2_=0; _ABVAR_2_< ( 5 ); ++_ABVAR_2_ ) { servo_pin_10.write( _ABVAR_3_i ); _ABVAR_3_i = ( _ABVAR_3_i + 18 ) ; delay( 1000 ); digitalWrite( 13 , HIGH ); delay( 200 ); digitalWrite( 13 , LOW ); } _ABVAR_3_i = 0 ; delay( 3000 ); }