Beau boulot que tu as fait là, ça te fait une bonne station de perçage / fraisage.
par curiosité quand tu dis que tu veux faire des pièces en série, c'est pour un robot quelconque ou rien à voir ?

Vous avez raison, je me suis montré trop impatient. Au temps pour moi.


J'avais pensé la même chose au début, mais ça donne quelque chose de curieux quand je trace ma droite :

Si :
0kg -> 0.1s
2kg -> 0s
1kg -> 0.05s ? Bah, non, sinon ça voudrait dire que plus le servo porte une charge, plus il est puissant. Ce qui n'est pas logique.

Et si on considère que à 2kg, on a un temps tellement long qu'il paraît nul, du genre 9999s, ça voudrait dire que à mis parcours, soit 1kg, on serait dans les 5000s...

Salut VBRK,

Si tu considères que ton servo chargé à 2kg effectue 60° en 0s, cela veux dire que ton servo fait un déplacement intantané ! Pas trop possible ça. Au contraire si tu dit que ton servo moteur chargé à 2kg met un temps infini à faire un déplacement de 60°, c'est pas faux mais c'est pas pour autant que ton servo mettra l'infini / 2 (désolé pour les matheux qui seront choqués par cette expression) pour effectué 60° chargé d'1kg. Le souci c'est que ce point à 2kg qui est en théorie un point d'équilibre, n'est pas sur la caractéristique qu'on peut approximer linéairement. Ce qu'il te faudrait faire (facile à dire mais pas evident) c'est charger ton servo avec un poids d'environ 1.5kg (pour pas etre trop pres de la non linéarité) et de mesurer le temps mis pour faire 60°. à partir de là tu pourra extrapoler pour estimer les temps pour les poids qui t'interressent. Faut dire aussi que trouver cette info sur un servo moteur c'est pas comode... avec un "vrai" moteur (ou motoreducteur) tu pourrai avoir les caractéristiques puissance, couple, vitesse et déterminer facilement ce que tu veux.

J'ai déjà commandé sur le site pro de radiospare, le seul qui existait à l'époque et sur lequel il y avait effectivement une valeur minimum de commande pour les particuliers, moi, il me sembles que c'étais plutôt dans les 60€ mais je me trompes peut être.

Ça fait quelques années que je n'ai plus rien commandé chez eux vu qu'ils ne livrais plus que les professionnels, je n'étais pas au courant de ce nouveaux site, il l'on ouvert récemment ?

Et bien je suis comme toi,et effectivement "à l'époque" il y avait un minimum de commande de 50 euros. C'est ensuite passé à 150 euros pendant une période. Je n'ai plus trop commandé ensuite donc je ne sais pas si ça à ouvert récemment ou non.

Oups je crois que ta raison je me suis précipiter pour répondre désoler

d'après ce qu'ils disent c'est programmer avec Borland Codebuilder 6.0 croyez vous que c'est plus adéquate pour des applications électroniques que delphi ? parce que mon but d'apprendre un langage c'est de l'utiliser pour la robotique.

Pour ça je ne sais pas du tout, par contre j'imagine que tu doit pouvoir accéder au port parallèle avec delphi aussi, et donc pouvoir récupérer des informations comme tes trames IR (en gros faire la meme chose que ce que tu voulais faire avec le port série mais avec le port parallèle).

ah bon ? il faut payer pour quoi ? j'ai réussi à télécharger l'installateur du petit logiciel (DigiTrace) c'est que c'est bon j'imagine. (Il parle de donation si on aime son programme mais rien de spécifique à payer)

Voilà le lien vers le setup : http://www.xs4all.nl/~jwasys/old/setup_digitrace.exe

Pas grave, je voulais surtout m'assurer qu'il y a vraiment rien pour avoir une temporisation précise a l'échelle du microseconde

maintenant j'ai la réponse merci!

Une autre idée qui m'est venue à l'esprit, étant donné qu'on fait bien des oscilloscope avec des cartes son, je me suis dit il y a bien quelqu'un qui a pensé à faire un analyseur logique avec un port parallèle de PC ^^
Je sais pas si c'est assez rapide pour ce que tu veux faire (la gars annonce 1million de sample / s mais ça peut varir en fonction du matériel), et si tu n'est pas trop allergique à l'anglais tu pourra peut etre trouver ton bonheur dans le coin : http://www.xs4all.nl/~jwasys/old/diy2.html

et à tout hasard tu as regardé du coté des logiciels "oscilloscope" qui peuvent récupérer les signaux qui arrivent sur la carte son du pc ? En branchant le récepteur IR tu pourrait peut être obtenir ce que tu veux ?

Merci j'aurais appris que le PID virtuel existe
Je constate que je ne te serais d'aucun secours pour tes erreurs aléatoires de lecture :/
Bizarre quand même que ces erreurs n'existent pas lorsque tu utilise un programme de test en boucle, ça veut dire que ces erreurs n'existent que lors de leur lecture réelle et donc que le système de lecture entraine la venue de ces erreurs.
Le circuit de lecture n'est-il pas sensible à quelques parasites ? est-il bien cablé de la meilleure façon ? voilà j'essaie d'orienter un peu les recherches

C'est toujours bien d'avoir un point de vue différent, ça permet souvent de progresser ^^
J'avais fait des tests de cette carte CPLD quand le CPLD était cadencé à 24mhz et meme avec les moteurs qui tournaient pendant le prog de test en boucle j'avais pas d'erreur non plus. Depuis j'ai passé le CPLD à 50Mhz pour pouvoir augmenter la vitesse de transmission des données (et pour qu'il puisse suivre la cadence de l'arduino@16Mhz) mais c'est peut être ça qui le perturbe. Il faut dire aussi qu'un CPLD c'est hyper sensible par nature, alors le 3.3V et du 50Mhz sa doit pas plaider en ma faveur... Je vais essayer de faire des tests sur la lecture des codeurs directement plutot que sur le registre que j'ai à coté. Si je désactive ma remise à zéro automatique des compteurs, sans faire bouger les codeurs, je peux réaliser pleins de lectures de la meme valeur et voir si il y a des fausses lectures.
Pour ce qui est du cablage, peut être pas de la meileure façon qui soit mais tout mes fils sont torsadés pour réduire les parasites, mon alim est filtrée et chaque carte a des condensateurs de découplage. Les fils sont les plus courts possibles. La liaison avec l'arduino se fait avec un cable de 10 cm de long composé de 3 fils torsadés, sa devrait marcher nickel.

Je vais essayer de faire quelques tests de plus, mais si il y en a qui passent par là et qui ont des idées je prends toujours ^^(pas que pour le problème des erreurs de lecture, mais aussi pour l'oscillation sur la voie droite)

Bienvenue Dark Flint

je crois qu'on a trouvé le frère caché de Bet@M@x ^^ (d'ailleurs détail qui ne trompe pas : Electron n'a pas répondu en premier, ET Bet@M@x a répondu en premier alors que le nouvel inscrit n'est pas une fille... hm hm)
Pauvre Electron je sais pas comment il va faire..

Quelque chose me dit que ça va mal finir cette histoire...

Hé moi aussi je suis fan d'Inounx

Hé hé je ne savais pas que j'avais un fan ^^

Ps : désolé obrelux pour le pourrissage de sujet...

En gros au lieu de dire je fait un PID pour le moteur gauche, et un PID pour le moteur droit, je viens asservir deux moteurs virtuels, un moteur qui fait avancer le robot dans l'axe de son orientation, et un autre moteur qui fait tourner le robot. C'est un asservissement polaire, ou en theta- alpha, avec theta distance et alpha angle. Comme ces deux moteurs sont des moteurs virtuels il y a un petit calcul permettant de redispatcher la commande d'un moteur virtuel sur les deux moteurs réels. Chaque moteur indépendamment n'est pas asservi mais ce sont ces moteurs virtuels qui le sont. C'est beaucoup plus intuitif à commander que chaque roue, mais ça a l'inconvénient d'être un peu moins précis. Pour palier à ce problème, ce qu'on voit pas mal sur les robots de coupe, ce sont 4 encodeurs, 2 par moteurs donc, 1 fixé sur l'arbre moteur qui sert à réaliser un PID sur ce moteur et un en roue libre qui touche le sol aligné avec l'axe moteur pour mesurer l'avancement "réel" et c'est avec ces codeurs là que l'asservissement polaire est réalisé. Cela permet d'avoir de la précision sur le controle des moteurs tout en les contrôlant en distance et angle. J'espère que j'ai pu t'éclairer un peu

OK
Sinon je viens de voir le datasheet et ils disent qu'il peut aussi s'alimenter en 5 V alors n'hésite pas

Datasheet

c'est que tu m'as fait douter pendant un instant ^^ . Comme c'est pas moi qui ait réalisé cette carte j'ai pas fait gaffe mais je viens de regarder : le cpld est un XC95144XL (arf) et bien sur devine quoi ? XL sa veux dire tout plein truc performants... dont le 3.3V.
Les entrées sorties sont 5V compliant mais on ne peut l'alimenter qu'en 4v max.
La datasheet c'est par ici

Salut Inounx, je ne connais pas bien le matériel que vous utilisez, mais je sais une chose sûre c'est qu'il vaut mieux alimenter en 5V la TTL qu'en 3,3V pour être certain de ne pas avoir d'erreurs
Ils ont été étudiés pour le 5V

Si tu as des broches non utilisées sur ton TTL elles seront au niveau Haut par défaut (technologie TTL) donc je te dis ça au cas où

Essaie aussi de cabler un condo de 22 nF au plus prés du circuit TTL entre le +VCC et la masse, car de fortes fluctuations peuvent se produire là lors des changements d'états du circuit TTL surtout si tu utilise 3,3V en VCC.

Salut Electron,

je me suis peu être mal exprimé, mais le CPLD que j'utilise (Xylinx XC95144) est uniquement en 3.3V. Je suis donc obligé de l'alimenter au maximum avec 3.3V et comme tout le reste de l'électronique de commande est en 5V pour la liaison avec l'atmel de l'arduino je suis obligé de mixer les 2. Coté condo toutes les cartes électroniques que j'utilise ont des condensateurs de découplage donc pas de souci de ce coté là.

merci, tu m'aide bien

Avec plaisir

je leur ait juste trouvé deux défauts (pour l'instant ) :

1)Ils sont à cours de pickit3

2) Ils ne vendent apparemment pas de pic

Voilou !

Regarde chez les autres revendeurs, tu trouvera forcément ce qu'il te faut ^^

J'ai regardé tes réalisations, sa me rapelle moi quand j'étais plus jeune. C'est bien continue comme ça t'es sur la bonne voie ^

Pour les 150 euros minimum c'est de mémoire c'était comme ça il y a quelques années, je te recommande vérifier (cela ne m'étonnerais pas qu'ils aient complètement arrété de livrer les particuliers). Et bien sur il faut que le minimum soit dépassé par commande, pas au total de toutes tes commandes.

Non ce n'est pas moins cher : comme ils ont pour principal but de vendre à des entreprises, tout les prix sont Hors Taxe.

------- EDIT ------
Autant pour moi, il existe un site radiospares pour les particuliers sans minimum de commande apparement :

COMMANDES ET PRIX
Les commandes peuvent nous être passées exclusivement par Internet sur le site www.rs-particuliers.com.
Les prix en vigueur sont ceux figurant sur notre site www.rs-particuliers.com. Ils sont stipulés en Euros toutes taxes comprises mais hors frais de traitement et livraison. RS Components SAS se réserve le droit de les modifier à tout moment mais s’engage à appliquer les prix en vigueur qui vous auront été indiqués sur le site au moment de la validation de votre commande.

Les frais de traitement et de livraison s’élèvent à :
10 € TTC pour une commande inférieure à 100 € TTC,
5 € TTC pour une commande comprise entre 100 et 150 € TTC,
0 € pour une commande supérieure à 150 € TTC.

et c'est par là : http://www.rs-particuliers.com/

Salut shyhack,

perso j'ai une colone proxxon et comme toi j'ai le même problème. Quand je descend la perceuse elle se décale légèrement vers la manette. ça doit être un problème sur ce genre de petites colonnes qui ne sont pas de grande qualité. (Ce genre d'outil coute cher en général) Après moi comme je m'en sers exclusivement pour percer des circuits imprimés je fait pas des trous profonds et sa me pose pas trop de problème mais c'est vrai que c'est pas génial...

Un gars qui a eu le meme problème sur la proxxon :
http://www.rcgroups.com/forums/showthread.php?t=608804

Enfin juste pour dire que ce n'est pas que dremel...

Salut obrelux,

1) Le pont en H est une structure électronique composée la plupart du temps de 4 transistors (et 4 diodes de roue libre). Cela permet de controler un dipole en inversant ou non la tension à ses bornes. Ce dipole est la plupart du temps un moteur en robotique même si on peut controler tout est n'importe quoi avec un pont en H.
pour plus d'infos : http://fr.wikipedia.org/wiki/Pont_en_H
et si tu veux encore plus de détails je te laisse chercher un peu sur le net, c'est quelque chose de très classique en électronique. (Il existe notamment des composants intégrés qui réalisent cette fonction sans avoir à tout faire soit même).

2) Pour transformer une tension alternative en continue tu as plusieurs solutions : la plus simple et la plus "historique" est d'utiliser un pont de diode (pont de graetz) qui va redresser ta tension puis de filtrer le tout avec un ou deux condensateurs. Une autre solution plus couteuse mais plus efficace en rendement est d'utiliser un hacheur. Le principe est de découper la tension très rapidement, puis de filtrer pour qu'en sortie la tension soit au niveau voulu (meme si c'est simplifié, on coupe la tension les 3/4 du temps pour avoir 1/4 de la tension en sortie par exemple). Même chose le net regorge d'infos sur ces choses là google est ton ami.

3) Gotronic, Sélectronic, Electronique diffusion, Lextronic, (conrad comme tu as dit mais il sont pas terrible sauf pour quelques trucs particuliers), radiospare (plutot réservé professionnels mini de commande de 150 euros il me semble si t'es particulier) et farnell (pour pro aussi mais livrent au particuliers si commande > 30 euros) . Hors de la france tu as sparkfun, roboshop (canada) et je ne sais plus quoi d'autre. J'en oublie surement il en existe tellement...

Salut à tous,

maintenant que j'ai un peu plus de temps pour travailler sur le robot, j'ai pu finir avec un ami la carte à CPLD qui sert à décoder et à compter les informations des codeurs optiques. J'ai mis en place un asservissement tout simple en théta-alpha (asservissement polaire). étant donné que c'est la première fois que je me lance dans la pratique pour un asservissement (en dehors des cours mais c'est là qu'on s'aperçoit que quand on fait marcher une manip toute faite et en étant guidé cela n'a rien à voir avec le faire "en vrai") je me heurte fatalement à des petit problèmes. J'ai donc quelques petites questions pour ceux qui passerons dans le coin :

- Dans le principe mon asservissement fonctionne (plus ou moins il faut régler les coefs) mais assez régulièrement (et je ne sais pas pourquoi) je fait des lectures fausse de valeurs. Du coup quand j'ai une consigne de 30tick / dT par exemple de temps en temps je me retrouve avec une valeur -1500 ou 400. Comme vous pouvez vous en douter sa donne des à-coups sur la commande et sa fausse complètement le positionnement. Est ce que certains d'entre vous ont déjà été confrontés à ce problème là ? je pensais filtrer les mesures mais après c'est génant dans le fait où je suis limité en dynamique du système, même si dans l'absolu mon robot n'a pas besoin d'être très dynamique. Je me demandais si cela venait pas des moteurs qui perturbent la lecture à certain moments, parce que dans le doute j'ai incriminé la carte à CPLD. Comme il y a un registre qui me permet de commander des pattes en sortie du CPLD j'ai fait un programme qui réalise en boucle des cycles de lecture écriture avec des valeurs différentes. Et résultat du test : aucune erreur sur des millions de lectures / écritures. Je me suis aussi aperçu qu'il y avait moins d'erreurs de lecture quand je faisait une première lecture bidon puis les "vraies" lectures ensuite. (Il faut encore que je fasse d'autres tests de lecture sur le CPLD dans des conditions différentes, je crois que c'est trop sensibles ces bestioles là)
J'utilise pour l'instant un quartz 50mhz pour toute la partie synchrone du CPLD mais je pense diminuer un peu pour limiter les problème (vers 20/30Mhz). Autre chose que j'ai failli oublier mon CPLD est alimenté en 3.3V (5V compliant sur les entrées) et je me demandais si ça pouvais jouer sur les erreurs de lecture par le uC (même si en théorie le seuil logique est à 2V équelques il me semble pour du 5V)

- Par la liaison série de l'arduino je renvoie les valeurs de mes codeurs et les valeurs des commandes générées par les PID. J'affiche ensuite tout ça avec matlab. C'est là qu'on se rend compte que la moteur gauche est très bien positionné par rapport à sa consigne (sans tenir compte des erreurs de lecture) alors que le moteur droit oscille autour de sa consigne. Comme l'asservissement est effectué sur les deux moteurs à la fois et non sur chaque moteur séparément je me demandais si c'était vraiment normal. Je joint deux captures d'écran Matlab : la première montre un essais de consigne de 90°/s sur 3s, la deuxième montre la même chose mais avec une lecture bidon effectuée avant les vraies lectures.
Légende : pour les odomètres courbe bleue = valeur lue, rouge = consigne.
Pour les les commandes courbe rouge = commande brute calculée par les PID, en bleu la même commande seuillée entre 255 et -255 (255 pas de PWM avec avant ou arrière).
Le delta de temps est de 1/61s (calcul des PID à 61Hz). Les unités des courbes de odomètres sont en ticks sur l'axe Y et en secondes sur l'axe X. Pour les courbes des commandes sur Y il n'y a pas d'unité ce sont des "pas de PWM" et sur X toujours le temps en secondes.

Salut Léon,

super boulot que tu fait là, et tu en avances à un bon rythme à ce que je vois (j'ai toujours quelques problèmes à rester motivé face à certain problèmes qui me bloquaient dans mes projets, je respecte d'autant plus ceux qui arrivent à fournir un travail constant à leur projet).

Pour le poids de la bête je dit respect : faut le faire pour tout faire tenir dedans, et plus en ce souciant des problèmes de centre de gravité...

J'ai vu que tu utilisais Matlab pour afficher tes données et faire des tests. J'utilise aussi Matlab, ça fait gagner pas mal de temps pour faire du débug, mais je me demandais comment tu fait pour transmettre tes données à Matlab en temps réel ? il y a des boites à outils pour ça peut être ? Comme je suis en train de travailler sur l'asservissement de mon robot en ce moment ça pourrait m'être très pratique

en tout cas bonne continuation pour ton projet

Salut denis, (Bienvenue sur le forum au fait)

j'ai acheté une Roboard il y a quelques temps déjà donc je peux te fournir quelques informations complémentaires si besoin.
J'ai essayé d'y installer une debian (4 ou 5 je ne me rappelle plus), il y a des docs qui existent et sa ce fait très bien (on crée une clé usb bootable et on installe à partir de ça une debian classique light avec un noyau spécial pour ce processeur là), le seul souci est que c'est assez lent à booter. Environ 50s ou qq chose dans le genre.
Par contre le fabriquant de la Roboard fourni un petit linux minimal (XLinux) qui permet de faire beaucoup de choses (bien qu'un peu limité au niveau drivers) qui boote en 14s a peu près, ce qui est déjà largement mieux.

Comme toi j'ai eu besoin d'une carte graphique pour faire du débug, ça tombe bien il en proposent une au format mini-pci avec la roboard, et ya rien à dire c'est vraiment pratique (Tu peux aussi utiliser un port RS232 pour faire rediriger la sortie console si tu n'as pas d'interface graphique). Après je me suis monté une carte wifi à la place pour avoir plus de possibilités.

Coté consommation c'est bien ce qu'ils annoncent sur le site, dans les 2-3W. ça varie bien sur en fonction de l'utilisation du processeur et des pariphériques comme les cartes wifi ou les pariphériques USB un peu gourmands en énergie.

Si tu trouves d'autres équivalents, je suis intéressé, ne serait-ce que pour être informé de ce qui ce fait.

a+

Salut Urbi,

bienvenue à toi

Je suis en ce moment stagiaire chez Gostai, donc si tu as besoin d'aide sur l'Urbi, je devrais pouvoir t'aider.

Je crois qu'il ne te reste plus qu'à repartir de zéro... D'un coté tu aurais eu plus de problèmes à récupérer des circuits existants.

Salut,

je dirais que c'est ça que tu cherches : Strap flexibles
Ils existent en Fem / Fem, Male/ Fem et Male / Male.

Salut,

Regarde par ici, un site qui recense les différentes parties de Cybot avec leur schémas : Cybot
Il y a une partie Sonar I/O qui correspond à la carte qui gère l'Ultrason. il ne te reste plus qu'à lire et à comprendre ^^

Le PC est en fait complètement indispensable pour 80% de mes montages électroniques. Je programme des micro-contrôleurs depuis le PC, je dialogue avec mes montages par liaison série, etc... Pour l'OS, tant pis pour toi si tu es anti-windows!

Il y a 2 avantages énormes à utiliser des instruments sur PC:
1) le tarif: vu que ces équipements ne comportent ni écran, ni clavier, ni molette, et vu qu'ils sont beaucoup plus compacts, forcément, ils sont beaucoup moins chers.
2) l'ergonomie: analyser 16 signaux, ça nécessite un gros écran, surtout si tu veux interpréter des trucs (analyseur de protocole). Un analyseur logique autonome avec un gros écran, ça coute une fortune! Mon analyseur a un écran de 1280x1024 sans y avoir mis le prix!

Personnellement, je pense que le PC est l'instrument central de développement sur micro-controleurs.

Leon.

Je n'ai jamais prétendu être anti-windows mais c'est vrai que je travaille sous mac OS X notamment pour programmer l'arduino avec AVR-GCC entre autres et je travaille sous linux pour tout ce qui est programmation. J'utilise windows pour les programmes particuliers tels que matlab, quartus, solidworks ... et les jeux. Pour en revenir au sujet de base je citais la seule compatibilité windows plutôt dans le sens où c'est dommage de ne pas pouvoir utiliser le même environnement que l'on utilise pour développer habituellement (par environnement j'entends machine, os et logiciels). Peut être que je m'achèterais une de ces petites bestioles un jour, je suis d'accord avec toi que c'est très avantageux niveau tarif.