42 réponses à ce sujet

[Microrupteurman]

Tu ne mets pas un condensateur ?

Le LM317 nécessite jusque une résistance ajustable et une résistance de plus .

[transistance]

Foufou c'est peu dire

Tu ne commandes pas tes moteurs en pwm mais en tout ou rien si je me trompes pas, d'où ce comportement. Si tu veux commander en tout ou rien il faudrait des moto-réducteurs plus démultipliés parceque là il va finir par se faire mal le petit Gus :s

[F6FCO]

@Microrupteurman, non pas de capa; elle sert à filtrer et c'est du surplus ici vu qu'on a une alim parfaitement stabilisée en sortie d'accus et juste pour alimenter deux moteurs ce serait une solution "riche" autant s'en passer et économiser la confection d'un PCB.

@Transistance, oui en tout ou rien. Le PWM de l'arduino est bloquant, on ne peut rien faire à coté et je dois sonder l'environnement. J'ai fais un PWM maison non bloquant qui n'utilise que 10µs sur les 100 habituellement utilisées, reste 90µs pour faire le reste mais çà ne suffit pas, le robot avançait par accoups (dans la V1 je ne tourne pour l'instant que sur un seul arduino). Alors j'utilise du tout ou rien pour la balade ce qui me permet de sonder en même temps, et je fais du PWM pour les manoeuvres de dégagement.

[Mike118]

 

@Transistance, oui en tout ou rien. Le PWM de l'arduino est bloquant, on ne peut rien faire à coté et je dois sonder l'environnement. 

 

Comment ça le pwm est bloquant ? Si tu utilise les fonction " analogWrite" sur les pattes "PWM" de ta arduino, tu vas utiliser les timers associé et ton pwm ne sera pas "Bloquant" ... Tu peux sans problème sonder l'environement en " parallèle" . 

Bonne journée !

[F6FCO]

Oui mais ce n'est pas pratique du tout, déjà analogwrite prend beaucoup de temps machine, et il faut indroduire des delay pour régler la largeur des créneaux, et les délay sont bloquants. Tu peux bien sur jouer avec la durée des delay et celle des trucs à faire à coté mais il faut tout re-régler dés que tu fais une modif du code et ce n'est pas le top.

J'ai préféré coder directement les ports avec noucle et condition, ce qui est beaucoup plus rapide et non bloquant. C'est mieux mais çà ne me laisse toujours pas assez de temps pour le reste. C'est pour çà que dans la version avec un seul arduino je me ballade à pleine vitesse.

#define PWMAvantDroit    PORTD&=~(1<<moteurDB);iw++; if (iw>=maxPwm){iw=0;} if(iw<pwm){PORTD|=(1<<moteurDA);} else {PORTD&=~(1<<moteurDA);}

[ashira]

Bizarre ton histoire, tu as des sources ? La fonction analogWrite ne m'a jamais occasionné des ralentissents.

[F6FCO]

Oups... ne fais pas attention à mes propos plus haut, je viens de me rendre compte que j'ai dis des bétises.

Cà vient du fait que je n'ai jamais utilisé la fonction analogwrite pour faire du pwm mais que je l'ai toujours codé avec des digitalwrite et des délay, les rares fois ou je devais en faire les bonnes pins étant déjà occupées, donc bien forçé de se débrouiller autrement.

Et la façon dont je le faisais était bien sur bloquante à cause des delay.

Je lisais analogwrite en pensant digitalwrite.

 

Ce qui fait que j'ai pris l'habitude d'utiliser mon #define tout fait et bien pratique une fois pour toutes et je ne me prends plus la tête avec le choix des pins.

[Sparda]

Je reviens sur un ancien post (faudrait que je me connecte plus souvent ^^')
 

 

La marche arrière après détection d'obstacle dure trop longtemps, à réduire à 500ms.

Tu peux utiliser ton capteur US pour en déduire la distance entre ton robot et l'objet et après faire un conditionnement en distance plutôt qu'en durée qui est super aléatoire car dépendant du sol et du type d'obstacle.
J'utilise pas de capteur US mais il me semble qu'ils ont une réponse linéaire en fonction de la distance? Si oui, c'est encore plus simple que pour les capteur IR où tu as besoin de faire un étalonnage et de calculer un modèle approximatif.

[Mike118]

Oups... ne fais pas attention à mes propos plus haut, je viens de me rendre compte que j'ai dis des bétises.

Cà vient du fait que je n'ai jamais utilisé la fonction analogwrite pour faire du pwm mais que je l'ai toujours codé avec des digitalwrite et des délay, les rares fois ou je devais en faire les bonnes pins étant déjà occupées, donc bien forçé de se débrouiller autrement.

Et la façon dont je le faisais était bien sur bloquante à cause des delay.

Je lisais analogwrite en pensant digitalwrite.

 

Ce qui fait que j'ai pris l'habitude d'utiliser mon #define tout fait et bien pratique une fois pour toutes et je ne me prends plus la tête avec le choix des pins.

Je pense qu'il est plus sage d'utiliser un couteau pour couper sa viande plutôt qu'une cuillère surtout si on a un couteau à disposition  
Si tu veux un coup de main pour retravailler l'organisation des pins n'hésite pas à demander mais quand tu fais un projet bien faire cette étape est vraiment importante  

 

Ensuite si tu ne veux vraiment pas utiliser l' "architecture ardware"  disponible pour faire du pwm interne à ton atmel tu peux à minima utiliser l'architecture ardware des timer pour faire un pwm sur n'importe quel pin en "vrai pseudo parrallèle" de ta loop principale ... 
 

Tu peux utiliser le timer 1 ( attention à l'usage des autre timer (surtout le zéro ) si tu utilise les fonctions millis ou autre ... ) 

Honnêtement c'est bien de savoir se débrouiller " à la main " pour faire du pwm ou autre ( perso c'est par là aussi que j'ai commencé ) mais utiliser les outils dispo ça t'ouvre un beau panel de possibilité  

Enjoy ! 

[F6FCO]

La programmation des timers c'est prévu pour l'étape suivante

Je suis passé de l'IDE arduino à AtmelStudio pour évoluer et m'affranchir de la programmation arduino pour pouvoir travailler au maximum en C standard. Pas toujours simple suivant les librairies utilisées. Ce n'est pas mon métier et je découvre çà petit à petit, étapes par étapes. Je maîtrise maintenant à peu prés le travail avec les champs de bits, l'attribution et la manipulation des pins directement sur les registres,

C'est le but de ce petit robot, me poser des problèmes que j'essaie de résoudre, et il y arrive d'ailleurs très bien.

Si je peux éviter d'utiliser une fonction arduino en la codant en C je n'hésite pas, c'est le but recherché.

Vu que je ne suis pas un familier de la langue du chat qui expire pour tout ce qui est recherches et doc, mes études sont assez laborieuses et avancent tranquillement.

Pour çà aussi que certaines fois il m'arrive de dire des c.....ies.

[Mike118]

Si ton but est de travailler en C sans la surcouche arduino rien de mieux que d'étudier les librairie qui font cette surcouche ^^. Pour tout ce qui est " Timer " je te suggère de regarder la librairie Timer One par exemple. Bonne continuation !

PS : Du coup tu es aller jusqu'à faire Atmel Studio puis AVR ICSP et uploader le programme en passant par un programmateur Atmel ? Ou tu utilise une autre méthode ?

[F6FCO]

Le départ de cette aventure c'est que je me suis lassé de debugger avec le serial.print et que je voudrais avoir plus de moyens de débogages, mettre des pooints d'arrets et pouvoir aller voir l'état de mes registres en live. Pour l'instant j'utilise AtmelStudio et un plugin intégré pour travailler sur arduino, c'est juste un petit pont pour appréhender la chose car le plugin ne me donne pas accès ni au débuggage avancés. Donc c'est une plus belle IDE que l'arduino mais rien de plus dans l'état.

Là j'utilise des "arduino" fabrication maison avec  chargement par un petit module FTDI, pour simplifier le PCB je n'avais pas prévu les pins miso, mosi, etc.

Une chose à la fois si je ne veux pas me noyer, dés que ce robot fonctionnera à peu près bien je graverai d'autres plaques atmegas328 avec le chargement par USBASP, pouvoir m'affranchir de l'arduino et avoir enfin accès au graal.

 

Je viens de commander çà: http://www.ebay.fr/itm/171076679974?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT, je ne sais pas encore trop comment on s'en sert vraiment et je suis en recherche de doc pas trop cabalistique.

Je suppose qu'il doit y avoir des fonctions dans AtmelStudio dédiées au JTAG.

[transistance]

Si ça peut apporter un peu d'eau à ton moulin, pour mes projets basés sur ATmega328 je programme en C avec winavr, j'utilise un arduino uno (et le sketch arduino isp) en guise de programmateur ICSP. J'avais fait un petit "aide-mémoire" sur mon site qui pourra peut être t'aider.

[Mike118]

Je ne connais pas le produit que tu as indiqué et je suis curieux de voir ce que tu vas en faire  
Perso en ce moment je travail avec des " arduini pro mini " en gros c'est un atméga 328 avec un régulateur un quartz  une led un bouon reset et quelque condensateurs et résitences. Je les ais pour quelque dollars et ça me coute moins cher au final que de me faire mes propres cartes ce que je faisais avant ...  Du coup pour tout ce qui est dév j'utilise ça ... ( je fais encore des cartes de temps en temps pour les besoins spécifique mais de moins en moins ... c'est de moins en moins rentable ... ) et ça se programme via un convertisseur ftdi ... lui aussi pour quelques dollars ... 
Je pense pas que ces cartes soient bien différente de ce que tu dois vouloir faire par toi même  

Après je comprends très bien l'envie de faire par soi même vu que c'est comme ça que j'ai commencé ^^ Le truc c'est que vu que je ne fais plus ça uniquement par plaisir ( vu que c'est aussi mon job ^^ ) mon état d'esprit à un peu changé de ce côté et la rentabilité temps/ argent rentre un peu plus en ligne de mire maintenant ...   

Sinon par contre niveau debbugage je l'utilisais uniquement avec les pic via le pickit3 ... Je l'ai pas encore fait avec les atmels, au final je ne me suis même pas encore posé la question ... J'ai plus facilement le réflexe de sortir l'oscillo voir l'analyseur logique car en utilisant le débuggueur du pickit 3 ça impactait directement sur l'horloge d'exécution  de mes programmes ... Et du coup ça ne me facilite pas forcément le debug en fonction des problèmes ...

Il y a pas si longtemps j'avais lu que microchip et atmel travaillaient à faire en sorte que le pic kit et un programateur atmel soient tout deux compatible avec les produits du concurrent ^^ Je sais pas où ils en sont mais il faudrait que je retrouve les sources

[F6FCO]

Ben voilà une converstation qui devient super intéressante.

 

@Transistance, merci beaucoup pour ton lien, je viens de regarder rapidement, çà a l'air bien rempli et je pense que je vais trouver des réponses à pas mal de questions. Je vais prendre le temps de lire çà posément.

 

@Mike118, C'est la même chose pour moi, mes cartes ont le stric minimum, 1 quartz, deux capas, poussoir, 3 leds pour faire joli et voir si çà upload bien et 5 pins pour le chargement FTDI. ces cartes arduino je les ai faites quand un UNO coutait encore dans les 20€ chez le chinois, j'en avais gravées un petit stock à l'époque et je tourne encore avec. C'est sur que çà ne vaut plus le coup de les faire aujourd'hui, sinon pour le fun. Aujourd'hui, acheter un nano vaut le prix d'un chip 328 nu. J'ai le fichier Gcode tout prêt et rôdé, un stock d'atmega328 et çà prend juste 10mn de gravure sur la CNC.

Comme ce n'est pas mon métier, juste un loisir  la rentabilité je m'en fous un peu .

Voilà, le convertisseur FTDI, c'est celui que j'utilise.

 

Tu m'apprends une bonne nouvelle pour le Pickit3 car j'en ai un dans mon tiroir. J'avais acheté çà au prix fort à l'époque car j'avais décidé de me mettre à la prog des PIC (avec les cours de BigOnOff). Le temps de le recevoir j'avais découvert l'existence de l'arduino et j'ai pris un virage à 90°. Le pickit n'a jamais servi, il est beau comme tout et çà me fait un peu mal au cœur de le voir prendre la poussière.

Sans vouloir dire de bêtises (dans l'état de mes connaissances) je pense que le  JTAG ICE que j'ai commandé doit être comme le Pickit3, un truc pour débugger directement sur carte. D'aprés ce que j'en ai vu et ce que je crois en avoir compris, on tire des sondes dans le circuit un peu à la manière d'un analyseur logique. Je peux me tromper, j'en dirais plus après.

 

Par contre cette ligne me laisse perplexe:

Works with AVR Studio 4.12/4.14/4.16/4.17/4.18...!!!!. pls download the sofware yourself

J'utilise la version AmelStudio 6.2. On verra bien.

[F6FCO]

Çà fait quelques jours que je planche sur un souci. Quand je fais un avant toutes d'une roue ou des deux roues, le servomoteur qui gère le module ultrason vient systématiquement se mettre en position zéro. Pourtant rien à voir l'attribution des pins, à l'arret le servo obéit correctement à tous les ordres, quand le robot commence à avancer il se met en position zéro et ne veut plus rien savoir.

Je continue à chercher.

[Mike118]

Hum ...

 

Juste pour être sur que le problème ne vient pas de l'alimentation, post le schémas d'alimentation de l'ensemble : Qu'est ce qui alimente ton servo, qu'est ce qui alimente tes moteurs, qu'est ce qui alimente ton micro contrôleur.  

 

Par contre si tu as un oscillo, regarde la broche qui fourni le pwm à ton servo moteurs...

Mon intuition me dis que ta gestion des PWM dans ton code rend la période de tes pwm non stable... 
Je suppose que tu sais bien qu'un servo se commande avec un PWM particulier dont la periode est de 20 ms environ, mais si tu t"ecarte trop de cette valeur ça marche plus... D'où l'utilité d'utiliser des timers  

 

Bonne continuation

[F6FCO]

Bonsoir Mike118,

 

Je connais le fonctionnement d'un servo, J'en ai déjà utilisés dans pas mal d'applications dont celle-ci http://www.robot-maker.com/forum/topic/7198-doigt-robotise-pour-trafiquer-en-code-morse/

Pour cela que j'étais sur de lui.

 

Tu as mis le doigt dessus, c'était bien un pbm d'alim.

J'alimente maintenant le servo par le 5v des arduinos et çà fonctionne de nouveau proprement (sur banc, je ferais les essais en roulant demain).

Je ne comprends pas trop pourquoi çà ne veut pas avec l'alim des moteurs et je n'aime pas ne pas comprendre.

Image(s) jointe(s)

• 

[Mike118]

Bon content d'avoir quand même pointé dans la bonne direction  

Même si je pensais d'avantage à un problème de période de pwm qu'à un problème d'alimentation ^^

 

Maintenant pour comprendre pourquoi ça marche pas il faut que tu observes ce qui se passe sur ta ligne d'alimentation.

Mesurer le courant consommé ( avec un ampermètre par exemple ou bien un petit capteur de courant a quelques euro + ta carte arduino ^^ ) et regarder la tension sur un oscillo par exemple ( éviter via un multimettre car le but est de regarder si la tension est stable et qu'elle ne présente pas de micro-coupure ), vérifier si le régulateur chauffe   ...

 

NB :  je viens de relire un de tes commentaires :

 

@Microrupteurman, non pas de capa; elle sert à filtrer et c'est du surplus ici vu qu'on a une alim parfaitement stabilisée en sortie d'accus et juste pour alimenter deux moteurs ce serait une solution "riche" autant s'en passer et économiser la confection d'un PCB.

 

 

Et si tu essayais d'ajouter les condensateurs recommandé dans la datasheet ?  

 

 

Il y a des servo qui ne supporte pas du tout les alim "instable" alors que des micro-coupures très brèves peuvent ne pas déranger tes moteurs cc qui sont en rotation continu...

 

à bientôt !

[F6FCO]

"Et si tu essayais d'ajouter les condensateurs recommandé dans la datasheet ? :P"

 

Bon d'accord alors , si vous vous y mettez à plusieurs...

 

Vérifié le 7805 qui fournit du 6v, il ne chauffe pas et il est monté sur radiateur. Je vais descendre tout le fatras au labo pour lui mettre un petit coup d'oscillo. Pas simple, car tout le bazar est installé sur le PC du salon ou j'ai accès à internet et en plus je n'ai pas installé AtmelStudio en bas.