L
Robots pour l'exploration lunaire par exemple ou les missiles ICBM ou faire clignoter une ledJorus a dit: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)
chlore a dit:...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" ...
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 ???chlore a dit: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 ...
Je te repose la question, ca veut dire quoi pour toi être temps réel ?chlore a dit: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 ...
Ouais à moitié cuit, ca sent pas le brulé hein...chlore a dit: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)
chlore a dit:...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)
Non c'est vrai ? dingue ça ...Jorus a dit:...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..
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")Jorus a dit: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.
Oui très bon livre, je l'avais lu à l'époque ! Mais tu sais il faut vivre avec son temps.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
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")
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
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.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 )
Jorus a dit: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")
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éamptifJorus a dit: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 (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
Ben oui je suis un vieux crouton.Jorus a dit: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 )
Admettons ... puisque tu aimes jouer sur les mots ...Jorus a dit: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.
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...louloute30 a dit: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 pas forcément nécessaire. C'est vrais que l'arduino est un peu limite pour faire de la régulation.louloute30 a dit: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.
Un temps de réponse important ne veut pas dire qu'il doit être le plus court possible.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."
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é.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
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.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
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.(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 )
Oui et encore avec une cmucam tu peux déjà faire pas mal de choses sur ta arduino si je ne m'abuse.romain_cvra a dit:Pour moi, un PC dans un robot eurobot est utile seulement si tu fait de la vision...
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 1MHzEtre 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
[/quote]"...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..."
Pas de problème on est la pour calouloute30 a dit: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.
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é.Jorus a dit:Maintenant le PC dans le robot offre aussi un certain confort d'utilisation je trouve.
L'arduino en est tout a fait capable! As-tu déjà programmer sur microcontroleur?louloute30 a dit:En fait, Arduino ne serait pas capable de faire l'IA ?
C'est le but de la stratégie... indiqué se que doit faire le robot.louloute30 a dit: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 ?
louloute30 a dit: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 ?
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.
celle que je vais insérer dedans, c'est qu'un bout de code exécuté avec des "if" ou "switch"...
Jorus a dit:Quelle est la ref de tes moteurs ?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?