Mon Premier robot... Premiers (8ème de) pas...

[louloute30]

Re: Mon Premier robot...

Jorus, tu as bien résumé ma situation;
Je débute, et je vais avancer à petits pas; Alors pourquoi arduino, pour commencer, rien de plus facile j'imagine en lisant ttes les solutions qu'elle peut réaliser.

Comme je n'ai jamais vu une arduino de près, ni même utilisé, Je pensais que j'aurai pu m'en servir pour créer "la stratégie/gestion des galets (ou boules...) à l'intérieur du robot/Information des capteurs" et garder qq connections pour informer un PIC sur les déplacements à effectuer:

Les infos envoyés au PIC seraient:
Tu te trouves au point A; Vas à C en passant par B.
Ainsi, une trajectoire curviligne est annoncée, et tant qu'aucun obstacle n'est détecté par arduino, le PIC joue le rôle du déplacement (accélération - Vmax - décélération), en interprétant au passage les données des encodeurs)
Arrivé à C, le PIC renvoi à arduino la position exacte du robot (qq fois qu'il soit à qq mm de la position souhaitée)

Peut être que je suis complètement à coté...

 

[erolhc]

Re: Mon Premier robot...

Mais comment peut-on généraliser de la sorte et sans argumenter ?
Merci de m'éclairer sur l'inutilité d'un OS embarqué multitâches préemptif en robotique. Donne moi des exemples concrets.
(Qui peut au passage devenir temps-réel : cf Xenomai)

Robots pour l'exploration lunaire par exemple ou les missiles ICBM ou faire clignoter une led : pas besoin de ce type d'OS (inutile voire préjudiciable (ICBM qui doit changer de direction alors que l'OS est en train de tenter de capter désespérément les réseaux wifi environnant ou de faire un contôle anti virus ) et il y plein de d'exemples ou c'est inutile voire pr"préjudiciable : il suffit de se rendre dans une usine et là tu verra que les taches critiques sont effectuées par des microcontroleurs/processeurs avec des programmes qui marchent en temps réél.
Dis moi comment traiter une interruption en temps réel avec un pc sous linux/winsows/osX ...
xénomai : oui et si ma tante en avait on l’appellerait mon oncle : Donc oui il existe des linux temps réel tout comme des OSX temps réel ou des windows temps réel ...mais pas ceux ceux que l'on appelle communément linux, osX, windows ...

Ca ne m'a pas empêché de dire que même un X86 avec un des ses OS boulet et d'une carte I/O enfumerait une carte arduino (bien sur si pas besoin pas besoin de traitement RT)

...C'est vrai si tu lui mets des boulets tels que les OS linux, windows, MacOS, ... et une carte arduino par RS232C/USB/parallèle
Sinon avec une carte PCI multi E/S même avec les OS cités t'enfume la plus rapide des cartes arduino mais ce serait une solution un peu "riche" ...

Donc je maintiens toujours que ... ce sont des OS boulets .. en général ( ) mais qui peuvent peut être convenir voire surement pour le projet de louloute (et je n'ai pas prétendu le contraire)
Et pour voir si ce sont bien des OS boulet : tu programmes l’allumage d'une led dès qu'un contact est fermé sur une entrée
1- avec ton logiciel favori sous ton Os "boulet" favori
2 - en assembleur (voire même en C ou langage évolué) et sous DOS
et compare lequel allume la led le plus rapidement
Ou encore plus simplement puisque l'on est sur un site qui parle de CNC : comparer les performances d'un mach3/breakout board avec un logiciel/matériel dédié (même "simple" de type Galaad/carte à PIC)

 

[Jorus]

Re: Mon Premier robot...

Louloute,

Tu as bien raison de vouloir tester à fond ta arduino. C'est un bon produit qui te donnera plein de possibilités. J'essaye juste de te mettre en garde sur ses limitations. Par expérience on a souvent beaucoup de déception à un mois de la coupe quand on se rend compte que l'on a mal dimensionné son architecture et que l'on a pas le temps d'aborder une carte plus puissante. Donc méfiance. Il est parfois plus prudent de prendre un produit un peu plus puissant, que l'on utilisera pas à 20 % de ses capacités plutôt que d'être frustré à la fin alors que l'on a la bonne solution.

Chlore,

Robots pour l'exploration lunaire par exemple ou les missiles ICBM ou faire clignoter une led : pas besoin de ce type d'OS (inutile voire préjudiciable (ICBM qui doit changer de direction alors que l'OS est en train de tenter de capter désespérément les réseaux wifi environnant ou de faire un contôle anti virus ) et il y plein de d'exemples ou c'est inutile voire pr"préjudiciable : il suffit de se rendre dans une usine et là tu verra que les taches critiques sont effectuées par des microcontroleurs/processeurs avec des programmes qui marchent en temps réél.
Dis moi comment traiter une interruption en temps réel avec un pc sous linux/winsows/osX ...

Ta question ne veut rien dire car pour parler de temps réel il faut en définir le contexte. En gros çà veut dire quoi pour toi être temps réel ???
Mais je pense que ce que tu cherches c'est comment sont gérer les interruptions matérielles. Je te laisse regarder : http://lmgtfy.com/?q=interruption+materielle
Je te rappelle aussi que chaque fois que tu appuies sur une touche de ton clavier ou que tu utilises ton port série, tu utilises des interruptions...
J'ajoute également pour ceux que ca intéresse, que ca peut aussi être l'occasion de voir comment fonctionne EMC2 et comment il s'interface avec le matériel.
[edith][/color]Je te laisse appeler la NASA pour leur expliquer qu'il faut pas mettre des OS boulets sur les robots d'exploration : http://www.techdrivein.com/2010/06/top-10-linux-powered-robots-from-around.html [/piaf][/color]

xénomai : oui et si ma tante en avait on l’appellerait mon oncle : Donc oui il existe des linux temps réel tout comme des OSX temps réel ou des windows temps réel ...mais pas ceux ceux que l'on appelle communément linux, osX, windows ...

Je te repose la question, ca veut dire quoi pour toi être temps réel ? Je veux que mon OS lance absolument une tache de traitement de données quelconques entre minuit et 1h du mat, mon Linux le fait très bien. Il est donc temps réel par rapport à mon besoin.

Ca ne m'a pas empêché de dire que même un X86 avec un des ses OS boulet et d'une carte I/O enfumerait une carte arduino (bien sur si pas besoin pas besoin de traitement RT)

...C'est vrai si tu lui mets des boulets tels que les OS linux, windows, MacOS, ... et une carte arduino par RS232C/USB/parallèle
Sinon avec une carte PCI multi E/S même avec les OS cités t'enfume la plus rapide des cartes arduino mais ce serait une solution un peu "riche" ...

Donc je maintiens toujours que ... ce sont des OS boulets .. en général ( ) mais qui peuvent peut être convenir voire surement pour le projet de louloute (et je n'ai pas prétendu le contraire)

Ouais à moitié cuit, ca sent pas le brulé hein...

Bon allez j'arrete là, c'est le topic de louloute quand même
Jorus

 

[louloute30]

Re: Mon Premier robot...

Sachez que vous ne me dérangez pas du tout... (Vous pouvez continuer votre bataille ici )...

Bon, ok, j'ai pu voir un peux les modèles que tu présentais sur ce topic, j'ai aussi pu voir qu'il était plus cher que les PC (270$);
C'est sur, je vais voir d'ici 2 ou 3 mois mes "capacités" que ce soit en mécanique, voir électronique, mais l'investissement d'un tel produit est je pense un peu déraisonnable à mon échelle.
En revanche, si besoin est, je passerai à un microp ARM 32bit 72Mh; Ce sera sans doute mieux que l'arduino que je vais avoir, mais je verrais ça vers décembre je pense.

Pour le moment, j'imagine comme vous, j'attends de voir le règlement pour voir s'il est préférable de placer les moteurs horizontalement ou verticalement. Et j'espère bientôt recevoir le peu de matos que j'ai commandé, mais ça peine à venir... Je me souviendrais du délai de réception chez DFROBOT... La semaine prochaine je vais aller me chercher de quoi fabriquer la table: 2 grandes plaques, qq barres d'acier (cadre + support) => Ca, je suis sur que je vais y arriver .

J'ai 1 imprimante laser et 2 scanner foutu en rab, ca me fera un peu de mécanique (miniature) pour démarrer. Hélas, j'ai lu qu'on ne pouvais pas prendre les lasers dans les graveurs ainsi que dans les pointers, dommage, j'en avais un de chaque aussi en rab => C'était super pour repérer l'ennemi; en même tps, je comprends que c'était dangereux pour le public...

Une autre petite question, le fil que l'on tire au départ, c'est un fil bien déterminé qui actionnerai un levier?, ou juste une fiche par ex mini-jack que l'on retire d'une jack opposé châssis ? J'ai pu voir que les robots peuvent l'avoir sur la face de leur souhait ainsi que le dessus?

 

[erolhc]

Re: Mon Premier robot...

...Ta question ne veut rien dire car pour parler de temps réel il faut en définir le contexte. En gros çà veut dire quoi pour toi être temps réel ???
Mais je pense que ce que tu cherches c'est comment sont gérer les interruptions matérielles. Je te laisse regarder : http://lmgtfy.com/?q=interruption+materielle
Je te rappelle aussi que chaque fois que tu appuies sur une touche de ton clavier ou que tu utilises ton port série, tu utilises des interruptions..

Non c'est vrai ? dingue ça ...
Pas besoin d'un lien pour savoir comment sont traitées les interruptions matérielles d'un microprocesseur ( je le sais depuis 1985). Par contre je peux te passer ma "bible Pc" (1ere edition 1992 editeur Micro applications ou bien la dernière édition en ma possession 2002) tu saurais comment fonctionne un Pc au niveau matériel : plus rapide que google

Je te repose la question, ca veut dire quoi pour toi être temps réel ? Je veux que mon OS lance absolument une tache de traitement de données quelconques entre minuit et 1h du mat, mon Linux le fait très bien. Il est donc temps réel par rapport à mon besoin.

Ah ? et si tu programme ton linux (ou autre) à 00:00:00,00 tu es sur qu'il va (débuter) traiter ce que tu lui demandé à cette heure précise (ici au 1/100 de s près et je ne parle même pas de la µs que l'horloge RTC d'un PC doit être bien en peine de donner)? c'est à dire qu'il va interrompre toute les autres taches en cours pour exécuter ce que tu lui à dis de faire ? c'est ça traiter une interruption en temps réel (pas "quand j'aurais fini ce que je suis entrain de faire alors attend un poil mon grand")
Donc je t'invite à suivre ton lien pour le fonctionnement et surtout l'utilité d'une interruption sur un µP

Quand tu fais un programme qui doit gérer le temps réel tu sais combien de temps(et cela en µs) met chaque portion (et même chaque instruction) du programme à l'exécution mais pour ça on programme en assembleur

Tu as cité Xenomai comme système temps réel et maintenant tu me parles de linux (version "classique") qui est temps réel : euh c'est bien de faire des recherches sur google mais faut encore comprendre les résultats (ah oui pardon linux est "temps réel" pour toi .. à l'heure près )

 

[louloute30]

Re: Mon Premier robot...

Je n'aurai pas imaginer que la pauvre animation allait succiter autant de remu ménage...
Même les autres pays (pas sur, mais le commentaire sur youtube laisse songeur...) s'y mettent.
Je la laisse encore 2 ou 3 jours, histoire de faire mariner, puis je la retirerai...

Je sens que c'était pas vraiment une bonne idée: Je vais déjà me faire mal voir à peine arriver
Enfin, si ça peut donner un peu d'avance à la France

Y a vraiment des gens qui scrute internet à chaque seconde et vont même jusqu'à cliquer les seuls mots de "table" et "2012"...
Par contre, je n'ai tjrs pas compris pourquoi cliquer "table eurobot 2012" affiche aussi l'animation sur youtube Ce n'était pas voulu !!!!

 

[erolhc]

Re: Mon Premier robot...

Voila ce que c'est : tu a donné un titre trop précis
Manque plus que la réalité soit conforme à ce que tu as dessiné : tu vas te retrouver entre deux 2 gendarmes pour cause d'espionnage

 

[Jorus]

Re: Mon Premier robot...

Pas besoin d'un lien pour savoir comment sont traitées les interruptions matérielles d'un microprocesseur ( je le sais depuis 1985). Par contre je peux te passer ma "bible Pc" (1ere edition 1992 editeur Micro applications ou bien la dernière édition en ma possession 2002) tu saurais comment fonctionne un Pc au niveau matériel : plus rapide que google

Oui très bon livre, je l'avais lu à l'époque ! Mais tu sais il faut vivre avec son temps. J'ai la plus grande base de connaissances à porter de clic donc autant en profiter hein. Et puis avec internet je peux échanger, apprendre des autres, c'est génial, tu devrais essayer.

Ah ? et si tu programme ton linux (ou autre) à 00:00:00,00 tu es sur qu'il va (débuter) traiter ce que tu lui demandé à cette heure précise (ici au 1/100 de s près et je ne parle même pas de la µs que l'horloge RTC d'un PC doit être bien en peine de donner)? c'est à dire qu'il va interrompre toute les autres taches en cours pour exécuter ce que tu lui à dis de faire ? c'est ça traiter une interruption en temps réel (pas "quand j'aurais fini ce que je suis entrain de faire alors attend un poil mon grand")

T'as pas lu ce que j'ai écris. Je veux qu'il lance ma tache entre minuit et 1h. Si il a donc un temps de latence de 15 minutes, ben c'est parfait, il va le lancer à 0h15. Nafout qu'il me lance l'action à 0:00:00,00 puisque je prends en compte un temps de latence d'une heure. Je suis donc temps réel par rapport à mon besoin. J'aurais très bien prendre des minutes au lieu de prendre des heures, peu importe.

Quand tu fais un programme qui doit gérer le temps réel tu sais combien de temps(et cela en µs) met chaque portion (et même chaque instruction) du programme à l'exécution mais pour ça on programme en assembleur

Effectivement, tu es resté bloqué à 1985. C'est bien l'assembleur, tout le monde devrait y passer. Mais c'est pas systématique hein. Aujourd'hui on l'utilise pour des besoins et des optimisations bien précis. On va plutôt parler de tâches, de priorités, de temps de latences et d'ordonnanceur... On peut maitriser le temps d'une tâche de facon plus élaborée qu'une simple addition de temps de cycle d'horloge.

Tu as cité Xenomai comme système temps réel et maintenant tu me parles de linux (version "classique") qui est temps réel : euh c'est bien de faire des recherches sur google mais faut encore comprendre les résultats (ah oui pardon linux est "temps réel" pour toi .. à l'heure près )

Oui tu as raison, et ca appuie ce que j'essaye de t'expliquer, dire qu'un système est temps réel est un abus de langage. Car on est temps réel par rapport à un cahier des charges définissant les limites du système.

Bon c'est à partir de là qu'on va tourner en rond alors en ce qui me concerne je vais chlore le sujet (désolé ), je te laisse le dernier mot !

Bonne soirée,
Jorus

 

[erolhc]

Re: Mon Premier robot...

Ah ? et si tu programme ton linux (ou autre) à 00:00:00,00 tu es sur qu'il va (débuter) traiter ce que tu lui demandé à cette heure précise (ici au 1/100 de s près et je ne parle même pas de la µs que l'horloge RTC d'un PC doit être bien en peine de donner)? c'est à dire qu'il va interrompre toute les autres taches en cours pour exécuter ce que tu lui à dis de faire ? c'est ça traiter une interruption en temps réel (pas "quand j'aurais fini ce que je suis entrain de faire alors attend un poil mon grand")

T'as pas lu ce que j'ai écris. Je veux qu'il lance ma tache entre minuit et 1h. Si il a donc un temps de latence de 15 minutes, ben c'est parfait, il va le lancer à 0h15. Nafout qu'il me lance l'action à 0:00:00,00 puisque je prends en compte un temps de latence d'une heure. Je suis donc temps réel par rapport à mon besoin. J'aurais très bien prendre des minutes au lieu de prendre des heures, peu importe.

Ah bon c'est moi qui sait pas lire ? moi je te parle de démarrer la tache à une heure bien précise au 1/100 de seconde près sur un OS classique, Il me semble bien que c'est ce qui est marqué et que tu as quoté non ? Donc j’attends que tu me dise comment tu peux avoir la certitude que cela sera bien fait avec un OS préamptif

Quand tu fais un programme qui doit gérer le temps réel (et à mon pour beaucoup de gens) tu sais combien de temps(et cela en µs) met chaque portion (et même chaque instruction) du programme à l'exécution mais pour ça on programme en assembleur

Effectivement, tu es resté bloqué à 1985. C'est bien l'assembleur, tout le monde devrait y passer. Mais c'est pas systématique hein. Aujourd'hui on l'utilise pour des besoins et des optimisations bien précis. On va plutôt parler de tâches, de priorités, de temps de latences et d'ordonnanceur... On peut maitriser le temps d'une tâche de facon plus élaborée qu'une simple addition de temps de cycle d'horloge.

Ben oui je suis un vieux crouton. mais au moins moi je suis pas obligé de prendre un moteur de formule 1 pour avancer à 80 km/h parce que je ne sais pas passer la seconde avec un moteur de clio (analogie entre quelqu'un qui fait exécuter une tâche avec Z80 à 4MHz et un autre qui a besoin d'un X86 à 200GHz pour faire la même tâche dans le même temps)
Jamais dit que l'assembleur était systématique (et ça fait bien longtemps que je n'y ais pas touché et la dernière fois c'était pour une routine ou la gestion du temps était critique au sein d'un programme en C)
C'est sur qu'avec des temps d'exécution d'à peu près de 15 min entre la demande et l'exécution réelle y'a pas besoin de se casser le tronc et que tu peux même programmer en basic interprété.
Gérer de façon plus élaborée .. bof .. plus pratique je n'en disconviens pas et faut l'espérer, mieux maitrisée je demande à voir, autant au mieux
Et ton bel ordonnanceur il va gérer la répartition de temps µP entre différentes taches (système multitâches) mais j'aimerais bien connaitre sa base temporelle sur ton système préféré pour savoir comment il va mieux se débrouiller qu'une simple addition de temps de cycles µP pour gérer au mieux le temps (un indice : au mieux sa base temporelle c'est le temps .... de cycle donc pas mieux que cet ancêtre d'assembleur car plus bas c'est impossible mais je suis sur que c'est au moins 1000 fois plus ... donc la gestion fine du temps ah ah ah)

Tu as cité Xenomai comme système temps réel et maintenant tu me parles de linux (version "classique") qui est temps réel : euh c'est bien de faire des recherches sur google mais faut encore comprendre les résultats (ah oui pardon linux est "temps réel" pour toi .. à l'heure près )

Oui tu as raison, et ca appuie ce que j'essaye de t'expliquer, dire qu'un système est temps réel est un abus de langage. Car on est temps réel par rapport à un cahier des charges définissant les limites du système.

Admettons ... puisque tu aimes jouer sur les mots ...
alors pourquoi il y a des système dit "temps réel" et des systèmes dit préamptif puisque c'est pareil ? C'est pas moi qui les ais inventés et encore moins les termes (tant en anglais qu'en français) (en plus il y a même des cinglés qui développé des OS "temps réel" pour AVR AMTEL (comme le µP de l'arduino) faut vraiment avoir que ça à foutre tu ne trouves pas alors l'IDE d'arduino est bien suffisante et fait la même chose )
Mais comme tu ne semble pas l'avoir compris pour moi "temps réel" (et à mon avis pour beaucoup de gens) c'est l’exécution quand moi je l'ai décidé à un temps précis (précision de l'intervalle de temps le plus court matériellement possible) et pas entre telle heure et telle heure au gré du système
Et donc pour ne pas perdre le fil initial .. tu me diras comment tu fais pour traiter une interruption en temps réel ( ) ou bien dans les 10 µ secondes où le µprocesseur la reçoit avec ton OS préamptif : c'est ça le cahier des charges mais bon comme cela fait plusieurs fois que je te le demande j'ai peur que tu me répondes pas ou encore à coté pourtant j'ai bien envie de savoir mais tu veux pas me répondre
Et donc jusqu'à preuve du contraire je pense toujours que les OS préamptifs sont donc bien des boulets (=frein des fois que tu n'aurais pas compris ce que cela veut dire) pour un système performant comparé à d'autres solutions

Edit : petite définition du TR par l'IEEE : "Un système temps réel est un système dont le temps de réponse est aussi important que la qualité de
fonctionnement."
EDit 2 : ton petit robot lunaire équipé de linux : linux il fait quoi ? il gère directement l’électronique (par exemple pour le faire rouler) ou il a juste un rôle de supervision et dialogue avec des µcontroleurs qui se chargent des taches critiques ? J'ai pas trouvé l'info

 

[romain_cvra]

Re: Mon Premier robot...

Une autre petite question, le fil que l'on tire au départ, c'est un fil bien déterminé qui actionnerai un levier?, ou juste une fiche par ex mini-jack que l'on retire d'une jack opposé châssis ? J'ai pu voir que les robots peuvent l'avoir sur la face de leur souhait ainsi que le dessus?

C'est comme tu veux ! Mais le fils doit rester dans ta main! Les jack c'est pas top... C'est un peu dure à l’arrachement et surtout si tu ne tire pas bien droit ça peut décaler le robot...
On utilise un jumpeur de carte éléc depuis 5 ou 6 ans, c'est top on a jamais eu de problème!

En revanche, si besoin est, je passerai à un microp ARM 32bit 72Mh; Ce sera sans doute mieux que l'arduino que je vais avoir, mais je verrais ça vers décembre je pense.

C'est pas forcément nécessaire. C'est vrais que l'arduino est un peu limite pour faire de la régulation.
Mais avec un Atmel ou un PIC plus puissant tu peux le faire sans problème! On commandait 3 axes plus tout la gestion de trajectoire avec un seul Atmel.
Et par exemple, Microb Technology commandait 4 axes plus tout la gestion des trajectoire et la stratégie avec un ATmega2560.
C'est des solutions pas trop chère qui donne de très bon résultat.

Pour moi, un PC dans un robot eurobot est utile seulement si tu fait de la vision...

A+

 

[louloute30]

Re: Mon Premier robot...

Ok, merci de ces précisions romain.
J'avais dis "fiches jack" histoire de bien me faire comprendre, mais ayant fait bp de sono, je n'aurai jamais pris ça au vu et au su de la difficulté de retirer la fiche parfois (qui aurait naturellement pu décaler le robot).

J'avais pensé à qq ch de plus simple comme les connectiques de transfo (220V/ 4-6V)

Mais je n'avais pas encore lu un post sur PS qui indique qu'il est préférable d'inclure dans les mesures du robot TOUTES les parties, même celle amovible pour l'homologation (C'est dans le topic qui parle aussi de cette fameuse balise de 8x8x2 qui peut s'inclure dans un cube de 8x8x8, mais que l'arbitre avait du mal a apprécier...)

Alors ton jumper de carte élec, pas mal du tout: Petit, et facile à tirer. (MERCI )

Au passage, je pense avoir lu bp, et appris beaucoup sur ce fameux asservissement polaire ! Je n'aurai pas vraiment vu les choses ainsi si je l'aurais fait sans regarder;
Aussi, mon arduino que j'ai commandé a un ATMEGA2560 microcontrôleur...

J'ai pu voir aussi dans une vidéo que dans le robot de cette année de coffeemachine (D'ailleurs super bien original) la plupart de la gestion intérieur des paliers auraient pu ne pas être géré par un microcontroleur, mais remplacé par une série de TTL... qui simplifierait la tache alors du microp ? Bonne idée, ou mieux vaut que tout passe tjrs par le microp principal ?

Désolé pour les questions posées, mais j'ai tellement d'années à rattraper, et je sais que si je teste toutes les solutions cela pourraient me prendre bp bp de tps sur le reste, et au final ne jamais aboutir pr mai 2012 à un truc correct.

 

[Jorus]

Re: Mon Premier robot...

Edit : petite définition du TR par l'IEEE : "Un système temps réel est un système dont le temps de réponse est aussi important que la qualité de
fonctionnement."

Un temps de réponse important ne veut pas dire qu'il doit être le plus court possible.

EDit 2 : ton petit robot lunaire équipé de linux : linux il fait quoi ? il gère directement l’électronique (par exemple pour le faire rouler) ou il a juste un rôle de supervision et dialogue avec des µcontroleurs qui se chargent des taches critiques ? J'ai pas trouvé l'info

L'important est qu'il réponde au besoin. Qui t'a dit que ta carte embarquée devaient forcément être seule ? Elle doit se reposer sur des composants qui répondent précisément au besoin posé.

Je reprends un exemple concret. Je veux compter les 30 impulsions par mm évoquées par romain_cvra. A une vitesse de 1 m/s ca nous fait 30000 impulsions par seconde soit 1 impulsion toutes les environ 33 µs.
Je crois que le temps de latence d'interruption est (dans le pire cas et c'est toujours celui qu'il faut considérer) est de l'ordre de 500 µs sur un système Linux classique sur une architecture x86 (genre Athlon ~ 1Ghz). Ca reste à vérifier, je te dis ca de mémoire. Donc si je veux compter mes impulsions de codeurs, on n'oublie direct de le faire sur ma carte mère embarquée : Mon système ne pourra jamais prendre en compte toutes les interruptions. Il me faut un compteur externe que j'interroge quand je veux/peux et je traite mes données à un intervalle favorable à mon système.

Par contre, admettons que je fasse un robot différent, que je me moque un peu de la précision au mm de ses déplacements car je veux juste une mesure approximative de sa vitesse. Je vais prendre un codeur à 2 impulsions par 10mm, soit 20 impulsions par seconde pour une vitesse de 0.1m/s. J'aurai donc une interruption toutes les 50 ms. Là je peux compter avec mon système Linux sans problèmes. Je peux même utiliser le module qui va bien pour ca : http://lxr.free-electrons.com/source/Documentation/input/rotary-encoder.txt
Dans ce cas je traite mes données en temps réel.

Différence entre un OS dit "temps réel" et un OS préemptif classique :
Le classique va parfois mettre 10 µs pour gérer ton interruption tandis qu'il va parfois mettre 500 µs. Ca dépend de la charge du système, de ce qui doit être interrompu (appel système, programme utilisateur, etc...).
Dans un OS dit "temps réel" tu vas toujours assurer un temps de latence presque constant. Ton système doit répondre à des contraintes temporelles strictes. On parle de déterminisme.

Etre temps réel ne veut donc pas dire que ton système doit être capable de répondre le plus rapidement possible mais plutôt qu'il doit répondre dans les limites temporelles imposées.

Donc ta définition du temps réel n'est pas la bonne, je cite :

Mais comme tu ne semble pas l'avoir compris pour moi "temps réel" (et à mon avis pour beaucoup de gens) c'est l’exécution quand moi je l'ai décidé à un temps précis (précision de l'intervalle de temps le plus court matériellement possible) et pas entre telle heure et telle heure au gré du système

Je comprends tout à fait ce que tu essayes d'expliquer mais il s'agit plus d'une notion de rapidité de traitement que de temps réel.

Utiliser Linux n'est donc pas gênant tant qu'il est bien utilisé. Ca ne veut pas dire non plus que ce soit la solution la mieux dimensionnée, loin de là, mais elle n'est en rien un boulet (ou un frein ).
Que ton OS Linux (ou autre, tu m'excuseras, je parle souvent de Linux par expérience) fasse de la supervision, de la vision ou de la triangulation ou de l'IA, tant qu'il apporte un plus en perf, en confort ou en fiabilité, il a sa place en robotique. Personnellement je suis convaincu que c'est le cas. Si tu ne l'es pas ce n'est absolument pas grave ! Mais respecte au moins les personnes et leur travail même si il ne te sont d'aucune utilité :

(en plus il y a même des cinglés qui développé des OS "temps réel" pour AVR AMTEL (comme le µP de l'arduino) faut vraiment avoir que ça à foutre tu ne trouves pas alors l'IDE d'arduino est bien suffisante et fait la même chose )

Personnellement, j'ai vu qu'il y avait des OS multitaches préemptif développés sur AVR et je trouverais intéressant d'en étudier le fonctionnement.

Pour moi, un PC dans un robot eurobot est utile seulement si tu fait de la vision...

Oui et encore avec une cmucam tu peux déjà faire pas mal de choses sur ta arduino si je ne m'abuse.
Par contre si tu veux faire de l'IA, genre quelques dev en prolog ou de la vision plus poussée, tu n'y couperas effectivement pas.
Maintenant le PC dans le robot offre aussi un certain confort d'utilisation je trouve.

Louloute, beaucoup d'équipes utilisent aussi des fins de courses : ta tirette appuyée dessus le maintient en position fermée, dès que tu tires il revient en position ouverte et ton robot sait qu'il peut démarrer.

Mais ca reste le même principe que la solution de Romain.

A+
Jorus

 

[erolhc]

Re: Mon Premier robot...

Bonjour

Voilà maintenant on est à peu près d'accord. Le temps réél c'est de traiter l'information (le switch est fermé) au moment où elle vient et d'y réagir au moment ou tu as décidé (j'allume la LED). Pas forcement une question de vitesse comme tu dis mais juste que c'est toi qui décides pas le système qui choisi le temps opportun.

Etre temps réel ne veut donc pas dire que ton système doit être capable de répondre le plus rapidement possible mais plutôt qu'il doit répondre dans les limites temporelles imposées.
Donc ta définition du temps réel n'est pas la bonne, je cite :

Mais comme tu ne semble pas l'avoir compris pour moi "temps réel" (et à mon avis pour beaucoup de gens) c'est l’exécution quand moi je l'ai décidé à un temps précis (précision de l'intervalle de temps le plus court matériellement possible) et pas entre telle heure et telle heure au gré du système

Je n'ai pas parlé de vitesse mais de temps donné/précis. Et ce temps ne peut pas être donné avec une précision inférieure à ce que le matériel peut faire : ex dire "allume la LED dans 1s et 25 ns" si la fréquence d'horloge du système est de 1MHz

"...Je crois que le temps de latence d'interruption est (dans le pire cas et c'est toujours celui qu'il faut considérer) est de l'ordre de 500 µs sur un système Linux classique sur une architecture x86 (genre Athlon ~ 1Ghz). Ca reste à vérifier, je te dis ca de mémoire. Donc si je veux compter mes impulsions de codeurs, on n'oublie direct de le faire sur ma carte mère embarquée : Mon système ne pourra jamais prendre en compte toutes les interruptions. Il me faut un compteur externe que j'interroge quand je veux/peux et je traite mes données à un intervalle favorable à mon système..."

[/quote]

Ben oui moi c'est ce que j’appelle un OS boulet (tout au moins pour l’application que tu cite : tu as une super bécane de course mais ton frein est serré). Le matériel peut faire mais l'OS bride (voire peut foutre la mer.e puisque tu ne peux jamais être sur du résultat si tu as des impératifs de traitements)

Donc un OS dit "évolué" n'est à mettre que dans des cas précis où par exemple tu a besoin d'une interface utilisateur
Dans le cas du robot de louloute il n'y a pas besoin de ce type d'OS mais peut être qu'il y a besoin de puissance de calcul, etc ...
Ben tu prends une carte X86 tu y mets à la limite un OS simplissime (genre DOS) et tu te sers de cette X86 comme une carte Arduino : tu développes ton programme sur une autre bécane tu compiles et t'injectes dans ta carte X86.
Même dans le cas de Romain avec la vision tu n'a même pas besoin d'OS évolué sauf peut être au stade du développement car tu as besoin de savoir ce que "voit" le robot pour la partie développement du programme d'analyse de la vision

 

[romain_cvra]

Re: Mon Premier robot...

Désolé pour les questions posées, mais j'ai tellement d'années à rattraper, et je sais que si je teste toutes les solutions cela pourraient me prendre bp bp de tps sur le reste, et au final ne jamais aboutir pr mai 2012 à un truc correct.

Pas de problème on est la pour ca

Maintenant le PC dans le robot offre aussi un certain confort d'utilisation je trouve.

C'est claire! En plus de la vision, on fait aussi tourné la stratégie sur notre pc. C'est un peu plus simple a débuggé.
Mais pour un premier robot, un PC c'est inutile! Mieux vaut ce concentré sur la base.

 

[louloute30]

Re: Mon Premier robot...

La stratégie via le PC. OK, mais il y a un détail que je ne comprends plus trop: En fait, Arduino ne serait pas capable de faire l'IA ?

En fait dans mon cas, voilà comment je vois la chose (Si on prend en exemple le règlement de 2011):

Rôle de l'arduino:
1) Asservissement (Je vais tenter le coup, on verra si elle suivra) + déplacements (direction, accélération...)
2) Gestion des réceptions de données concernant les capteurs (Je pense mettre 6 capteurs ultra-sons pour détecter les proximités et peut être 4 IR (On verra bien pr l'IR))
3) Envoi des données aux TTL (cité ci-dessous)

Gestion interne des paliers/galets/boules, ascenseurs, stocks...:
1) TTL+détecteurs binaires pour les déplacements des pions/galets/boules à l'intérieur du robot
2) Interaction avec arduino pour une éventuelle dépose sur un support de la table ou mise en marche de la construction externe au robot...(4 connectiques avec arduino max; normalement avec 2 ça devrait marcher aussi entre dans le robot/sort du robot)

Rôle de l'ordi: (même si je ne l'utiliserai pas cette année, quoi que suivant mon avancement, j'aimerai savoir un peu):
1) Récolte les données de arduino
2) Interprète ces données
3) Indique à Arduino à quel endroit le robot doit se diriger ?
Le pc serait capable de rentrer en interaction avec arduino via le port USB, ou faut-il utiliser un autre port ?

Je serais dans le vrai ou complètement à coté ?

 

[romain_cvra]

Re: Mon Premier robot...

En fait, Arduino ne serait pas capable de faire l'IA ?

L'arduino en est tout a fait capable! As-tu déjà programmer sur microcontroleur?
Car dans le cas ou tu serais trop limité avec le logiciel Arduino. tu peux très bien utilisé seulement le hardwear (la carte) et reprogrammer l'ATMEGA2560 comme tu veux.
Je reste convaincu que pour fair une robot simple, un PC n'est pas nécessaire!!!

J'ai pas comprit ton histoire de TTL tu veux communiqué avec quoi? Une autre carte électronique?
Comme tu aimerais faire un robot simple peut être qu'une seule carte suffit pour tout gérer.

3) Indique à Arduino à quel endroit le robot doit se diriger ?
Le pc serait capable de rentrer en interaction avec arduino via le port USB, ou faut-il utiliser un autre port ?

C'est le but de la stratégie... indiqué se que doit faire le robot.
Oui tu peux faire communiqué PC et arduino via l'USB.

 

[louloute30]

Re: Mon Premier robot...

Ok, merci de ces précisions.
Non, je n'ai jamais programmé sur microprocesseur
Je pensais utiliser pr le moment le logiciel d'arduino, les codes de prog sont très basiques;
De là à reprogrammer le microprocesseur, ça devrait me faire perdre une bonne semaine (voir 2) le tps de bien percuter les sources qu'on peut trouver ici et là (J'ai déjà MPLAB et de mémoire, c'est soit en assembleur ou en C, donc, ça devrait aller); Bon, s'il le faut, je réviserai... Au début de ce topic, j'avais pour envie de me procurer cette carte: http://www.myavr.fr/7-mymultiprog-lpt.html
de quoi programmer des PIC et autres, mais j'ai vite lever le pied lorsque j'ai vu les tarifs des arduinos totalement abordable !

Je reviens sur les TTL:

En fait, oui, souhaitant dégager au maximum arduino des taches basiques comme déplacer dans le robot un pion d'un endroit à un autre, ou encore gérer une éventuelle construction interne, je pensais utiliser des portes logiques...

Biensûr, cela m'oblige à faire une autre carte, mais ça ne me dérange pas du tout. C'était surtout dans les cas suivant:
- Arduino ne serait pas presque inutilement surcharger de travail si une pièce devrait passer par 3 actionneurs avant d'être à sa place définitive.
- A chaque action interne (déplacement au sein du robot), un capteur (tout type: détection couleur, détection taille, détection pr cette année des rois et reines) pourrait permettre d'assurer une certaine sécurité du déplacement: On peut voir que cette année, plusieurs robot ont pu porter de travers une reine ou un pion, et au moment de le déposer, boom, c'est la cata... d'où une utilisation de qq capteurs sans passer par Arduino me paraissait être une bonne idée.

Bref, la carte des TTL gérerait la chaîne complète entre le tps ou le pion entre dans le robot, jusqu'à ce qu'il ressort.
^^ En fait c'est une solution qui n’appellera pas un gramme de prog (non pas que la prog me fasse peur, mais si je peux gagner du tps et éviter un second microp qui ne serait jamais utilisé à 100% de ses capacités), et leur simplicité d'utilisation (des TTL) devrait alors dire 1=> C'est ok , 0 => pas content

Dans cette mesure, je me dirige très vite vers, "Arduino n'aura plus que les déplacements, et pourquoi pas l'IA". Mon inquiétude repose plus sur les capacités de traitement des infos concernant l'asservissement, j'ai le sentiment qu'il faille une grosse puissance du microprocesseur pour gérer les moteurs et encodeurs... Peut être que je me trompe...

 

[Jorus]

Re: Mon Premier robot...

La stratégie via le PC. OK, mais il y a un détail que je ne comprends plus trop: En fait, Arduino ne serait pas capable de faire l'IA ?

Attention à ce que tu entends par IA.
Dans ton cas, tu vas d'abord produire un "automate", c'est sans doute ca ce que tu appelles l'IA.

Ce que j'appelle IA est un sujet beaucoup plus vaste que j'aurai du mal à résumer ici.

Mais soit rassuré, ta arduino comblera tes attentes et tu pourras coder le comportement de ton robot sur cette carte comme Romain l'a déjà précisé.
Vérifie juste que ta arduino a suffisamment d'entrée-sortie pour faire ce que tu veux.

 

[louloute30]

Re: Mon Premier robot...

Merci Jorus (L'arduino doit avoir dans les 50 E/S, de quoi me débrouiller je pense.)

Je n'entends pas par IA: tourner-droit, tourner-gauche, rotation, dirige-toi-la-bas... ce doit seulement être des principes d'automatisme (comme manger/boire/dormir);

Mais plutôt (Quel travail dois-je faire pour gagner plus sans trop en faire...):
-Recherche des nouveaux déplacements à parcourir pour ne pas rentrer en collision avec l'autre, en tenant compte de la position des pions sur la table, et ceux déjà déposés précédemment par le robot, et en procédant par ordre d'importance: Construire et déposer une tour avant de s'occuper de traiter les simples pions sur la table;
-Suivre plus ou moins la trajectoire de l'autre robot (et la mémoriser) pour être sur qu'il n'a pas été (ou supposé été) déplacer une tour que j'aurai pu placer avant sinon, aller vérifier après qu'il soit parti (valable pour les robots fous qui fonce partout).
-Dans le cas de "robot intelligent en face", Imaginer plus ou moins ce que l'autre robot a effectuer comme déplacement, en vu d'interpréter où il a pu déposer des pions remportant des points et prendre les tours au passage à proximité du robot.

^^ Vous l'aurez compris, toujours en se basant des règlements années 2011. Et puis c'est sur, en 90sec, ça ne laisse pas non plus un tps fou pour faire des folies.

 

[romain_cvra]

Re: Mon Premier robot...

A mon avis, une deuxième carte Arduino mais cette fois la standard, conviendrait mieux que ta carte à base de porte logique.
Car il y a toujours un truc à amélioré et reprogrammer, a droite a gauche, et par exemple tu dois des fois ajouter un petit délais, etc...
Et tu peux communiqué assez facilement en série entre les cartes. Mais si tu peux tout mettre sur une seule carte c'est nettement plus simple!

Dans un premier temps, concentre toi sur les déplacement! Et on en reparle après!

 

[louloute30]

Re: Mon Premier robot...

Comme je me rends ce soir au magasin, j'aimerai savoir en quoi est fait la table ? MDF? agglo ? (afin d'essayer d'avoir les mêmes rendements d’adhérence)
Et d'après vous, sera-t-elle encore de 2.1*3 mètres cette année ?

 

[Jorus]

Re: Mon Premier robot...

Attends samedi pour le savoir.

La conception de la table n'est pas le plus urgent dans ton cas de toutes facons.

 

[ybou30]

Re: Mon Premier robot...

Salut à tous,

Tout à fait d'accord avec les attentes de Louloute30 en matière d'IA.

Je ne suis pas du tout au fait de ce qui se fait en matière de robots: ni en prog, ni en architecture.
Par contre, un peu plus en IA (Avec comme support prog PROLOG).
Comme béotien , j'imagine assez facilement que là où çà peut apporter, çà n'est pas forcément en temps réel et en embarqué, mais tout simplement pour faire un choix optimal des algorithmes à implémenter dans l'automate.

Je le vois un peu comme de la méta programmation.

C'est cette partie qui est la plus délicate.
Elle permettrait de gérer la récursivité et le traitement/gestion de listes sur des actions élémentaires (bibliothèque d'actions associées à un contexte), à partir d'informations nouvelles et / ou accumulées (prémisses).
il me semble qu'il s'agit là de quelque chose à creuser, mais çà nécessite du temps, ce serait plus un projet à long terme.

Cdlt
Yanik

 

[louloute30]

Re: Mon Premier robot...

En fait, il ne faut pas se leurrer, une intelligence artificielle, enfin, celle que je vais insérer dedans, c'est qu'un bout de code exécuté avec des "if" ou "switch"... Hélas, on ne va pas concevoir des robots près à "apprendre par eux même", là c'est une tout autre méthode de travail. Mais sans doute très passionnante également. Le tout, c'est de fabriquer une "IA" qui tourne parfaitement en 90s, c'est sans doute ce qui rend plus difficile la prog.

J'ai reçu des nouvelles de DFRobot, l'ensemble est alors envoyé:
1 écran LCD 2 lignes + 6 boutons: idéal pour faire un menu de démarrage + afficher la position réelle du robot, ou débogage divers (Je pense que ça va me faire gagner du tps sur les erreurs...)
J'ai aussi pris un controlleur moteur de 2A (avec un L298 inclus) J'ai lu bp de post où les robots utilisaient un L298. C'est une bonne chose pensez vous, ou mieux vaut prendre une autre type de controlleur? (Mes moteurs actuels, peut-être un peu gros (15cm de long avec réducteurs inclus) sont des 1.2A; mais ils sont puissants).
Ensuite, j'ai pris aussi un petit servo moteur, histoire de voir ce qu'ils valent (2,8 kg) (En moyenne, vous utilisez des plus puissants ? moins puissant ?), et si j'en suis content, j'en prendrai une 10ène à ma prochaine commande
Mes 4 petites Roulettes à billes en métal, et la carte arduino.
Vu que le colis part demain, de hong-kong, avec un tarif de 7€ pour les frais de transport, je pense qu'il faudra attendre une bonne semaine avant d'arriver au pas de ma porte...

Bref, plus d'un mois entre l'envoi de l'argent et la réception des pièces, mieux vaut prévoir son coup lorsqu'on commande chez DFRobot ! Sinon, prix très correct, reste à voir maintenant la "qualité"...

 

[ybou30]

Re: Mon Premier robot...

Salut à tous, Salut Louloute,

Hélas, on ne va pas concevoir des robots prêts à "apprendre par eux même", là c'est une tout autre méthode de travail.

on est bien d'accord, c'est pas le but

celle que je vais insérer dedans, c'est qu'un bout de code exécuté avec des "if" ou "switch"...

C'est plutôt là qu'une IA de méta programmation interviendrait, pour générer algos et code optimisés:
Produire une prog de bas niveau à partir d'une IA.
L'IA n'interviendrait ensuite plus sur le temps réel, ce qui resterait possible bien entendu dans d'autres types de projets.

Ceci reste, bien entendu un apparté dans un sujet aussi passionnant que le tien .
Cdlt,
Yanik

 

[lapoutre]

Re: Mon Premier robot...

Pour les moteurs le plus simple c'est des LMD18200 (3A, 50V)

 

[Jorus]

Re: Mon Premier robot...

D'accord avec lapoutre !
N'hésite pas à mettre un radiateur sur ton LMD18200 si tu prévois que ca chauffe trop.

Quelle est la ref de tes moteurs ?

 

[louloute30]

Re: Mon Premier robot...

Quelle est la ref de tes moteurs ?

Hum, j'ai un peu honte de le dire, mais c'est un Mabuchi (Grosse marque ).
Ben oui je sais, pas terrible, mais j'ai trouvé qu'il était super puissant, et avec le réducteur, qu'il tournait à "bonne allure".

Pourriez-vous m'expliquer pour quelles raisons, il existe des moteurs à 200€ et d'autre à 25€ ? Niveau puissance dvpé, on peut trouver la même à des prix très différents. J'ai pu voir que certain utilisait des maxon... (Bien, pas bien?)

Sinon, je vais faire une V1 avec ces moteurs, histoire de voir (Comme je sais pertinemment que ma V1 ne sera pas efficace pour le projet, je sortirai une V2 après avoir tout bien saisi, et avec ce coup ci les "bons compromis").
Ma V1 servira toujours comme "robot ennemi", et comme robot testeur de nouveautés.

Ok, donc, LMD18200. Je note (Je mets en gras pour m'y retrouver).

 

[Jorus]

Re: Mon Premier robot...

Je ne suis pas expert dans le domaine, d'autres comme Romain seront surement de meilleur conseil sur le sujet.

Je dirais que c'est d'abord une histoire de rendement.
Mais pour te donner un exemple, au début, on avait des moteurs comodrills.
En dessous d'un PWM de 40%, le moteur ne décollait pas...
Maintenant avec nos Pittman à 2% ca tourne...
On a quand même plus de marge de manoeuvre. ^^

Tout le monde te dira que Maxon et Faulhaber c'est le top. En ce moment je regarde les moteurs Crouzet, si quelqu'un a un retour sur leur moteur je suis preneur.

[edit][/color]Un excellent lien pour dimensionner ses moteurs : http://ancrobot.free.fr/Old_version/fichtech/soft/soft_dimmot/index.htm [/edit][/color]

 

[lapoutre]

Re: Mon Premier robot...

Côté moteur le plus économique c est eBay ...
Tu cherches pendant 2 semaines ce genre de moteur chez faulhaber ou maxon ou crouzet:
20 watts réducteur de rapport 20
Pour info j ai un réducteur de 43 sur mes moteurs propulsions et je fait kan même du 0.5 m/s