scripting temps réel

Salut à tous.
Je recherche un langage de scripting qui puisse facilement être embarqué dans une applic C++ ou C (comme le Lua), si possible open-source et gratuit, et qui puisse être utilisé dans un contexte temps réel.
Pourquoi? Mon école participe au concours Eurobot, le prof voudrait qu'une des parties du programme dictant les actions du robot puisse être plus flexible, qu'il ne soit pas nécessaire de recompiler systématiquement. Je ne saurais pas encore dire si le temps réel est à 100% nécessaire, mais je me dis que logiquement, c'est le cas typique ou on en utilisera.
Pour résumer il faudrait un langage de scripting sans garbage collector (c'est à ma connaissance la seule caractéristique qui rendre un langage incompatible avec le temps réel).
Merci à ceux qui me répondront.

Tu as Boost.Python et lualib qui te permettent d'intéragir respectivement avec Python et Lua dans du code C++. Je te conseille de regarder leur documentation respective pour te faire un avis.

Sans rire, comme si je ne connaissais pas :D, je le marque même dans mon post.
Merci quand même pour la réponse, mais en lisant jusqu'au bout c'est bien aussi.

Si j'ai bien compris le problème, le besoin de flexibilité vient pour la partie "intelligence" du robot, pas pour la partie "contrôle". J'ai l'impression que quel que soit le langage utilisé, on arrivera assez vite sur les algorithmes mis en oeuvre à des incompatibilités avec un temps réel pur.

Donc, plutôt qu'un langage de script temps réel, je m'orienterai plus vers une architecture qui puisse bien séparer les différents niveaux de contrôle, et n'imposerait pas de contraintes temps réel strictes au niveau le plus haut.

Citation:

---

Envoyé par zais_ethael

Sans rire, comme si je ne connaissais pas :D, je le marque même dans mon post.
Merci quand même pour la réponse, mais en lisant jusqu'au bout c'est bien aussi.

---

Tu ne parles que de Lua dans ton post. Bref.

Quelles sont les possibilités que tu as déjà envisagées ?
Lesquelles as-tu définitivement écarté et pourquoi ?

Bon, en réalité le projet est assez abstrait pour le moment, en gros il y a du code auquel je n'ai pas accès parceque l'équipe de conception n'est pas encore décidée et tout ce que je sais c'est que cette partie pose un problème de flexibilité. Pour le moment, je fais le tour des possibilités avec le peu que je sais, histoire d'avoir un peu de répondant devant le prof.
Alors, qu'ai je pu envisager?
- Une archi qui séparerait cette partie du reste du code, voir un système à plugin. Mouais, pas vraiment révolutionnaire sur le gain de temps à la compilation, c'est quand même plus simple un bête fichier de script à changer tant que les perfs pures ne sont pas un gros problème (je ne pense pas que ce soit le cas).
- Un langage de scripting lambda (le Lua, plus parceque son utilisation semble fort simple qu'autre chose, de toutes façons un langage impératif ou un autre...), c'est la solution facile et il est fort peu sur que son garbage collector et la légère imprécision qu'il est susceptible d'engendrer pose un réel problème.
Néanmoins, je sens qu'en avançant cette idée on pourrait me le reprocher pour le bon motif bien connu dans le profession "les langages à garbage collector sont inutilisables sur un os temps réel" et "les robots faut que ce soit en temps réel". Voila pourquoi je cherche un langage de scripting un peu spécialisé - ou tout du moins qui pourrait servir dans ce but -.
En cherchant sur le net, on ne peut pas dire que je trouve grand chose, à part peut-être le Erlang (langage fonctionnel), réputé pouvant servir dans les applics real time. L'ennui c'est que, bien qu'il soit interprété, il semble être plus une plateforme de développement complète qu'un petit langage généraliste embarquable dans une applic, ce n'est donc pas vraiment ce que je recherche.
Comme je le dis, le langage en question importe peu tant qu'on garde la facilité d'utilisation d'un script, mais il serait appréciable pour éviter tout problème (plus hiérarchique que technique) d'avoir un beau logo "realtime certified" tatoué sur le bidule.

http://squirrel-lang.org/

Je connais le squirrel, il est nottament utilisé dans code::blocks, mais en quoi est-il différent d'un autre langage du même style?

Citation:

---

Squirrel is a high level imperative/OO programming language, designed to be a powerful scripting tool that fits in the size, memory bandwidth, and real-time requirements of applications like games. Although Squirrel offers a wide range of features like:
(blabla)
-automatic memory management (CPU bursts free; mixed approach ref counting/GC)
(bla)

---

ca me parraissait etre ce que tu demandes

c'est tres tres leger (a peu pres aussi leger que lua), efficace, et le mode de liberation de la memoire est sans pic de CPU.

pour info, j'ai un ami qui a bosser pendant un an au Japon sur des aibot, et il les programmait eu Lua. Donc c'est tout a fait possible de le faire avec Lua. Après, pour le problème du garbage collector, ca va surtout poser problème si le hardware du robot est plutot limité.

Et un truc important : si tu veut garder un max de perf, evite de passer par des outils comme Luabind qui te permettent effectivement de gagner du temps de developpement et du type safety, mais qui vont aussi t'ajouter un overhead à l'execution qui n'est pas forcement le bienvenu en temps réel...

Ca me parrait interressant, comme de toutes façons je ne trouve rien de concret comme langage spécialisé je crois que je vais plutot m'engager dans cette voie.

L'allocation dynamique elle-même n'est pas proscrite sur un vrai système temps-réel ?

je ne pense pas qu'il s'agisse de la fusee ariane...

Pour du temps réel, a priori il faut que tout le code ait une limite dans sa durée d'exécution. Et quand tu fais de l'allocation dynamique, tu sais pas combien de temps ça va prendre, non ?

moi j'aime bien le scripting javascript dans Qt

Citation:

---

Envoyé par loufoque

Pour du temps réel, a priori il faut que tout le code ait une limite dans sa durée d'exécution. Et quand tu fais de l'allocation dynamique, tu sais pas combien de temps ça va prendre, non ?

---

Je le sais à peu près autant que quand je fais un tri, un traitement/analyse d'images, un algorithme d'optimisation,...
C'est pourquoi une telle restriction posée en axiome me semble restrictive, à la limite du dogmatisme, et que je préfère partir sur l'idée d'un système à deux vitesses, en limitant le temps réel dur aux aspects gestion de la sécurité et à ce qui est très proche du hard, là où ça a du sens et où c'est faisable. Mais je n'ai pas trop l'expérience du temps réel dur.

Tu peux aussi regarder URBI qui est un langage de script créé pour les robots il gere entre autre le parallelisme en natif et il peut s'interfacer avec à peu près n'importe quel langage!

Citation:

---

Envoyé par JolyLoic

Je le sais à peu près autant que quand je fais un tri, un traitement/analyse d'images, un algorithme d'optimisation,...
C'est pourquoi une telle restriction posée en axiome me semble restrictive, à la limite du dogmatisme, et que je préfère partir sur l'idée d'un système à deux vitesses, en limitant le temps réel dur aux aspects gestion de la sécurité et à ce qui est très proche du hard, là où ça a du sens et où c'est faisable. Mais je n'ai pas trop l'expérience du temps réel dur.

---

L'allocation dynamique n'est pas déterministe c'est pour cela que l'on ne l'utilise pas en temps réel ou tout du moins on évite au maximum. Le seul endroit ou le non determinisme de l'allocation dynamique est acceptable est pendant la phase d'initialisation d'un systeme.



Pour info je suis en spécialisation GISTR (Génie Informatique des Systemes Temps Réel) à l'EPITA.

Le Urbi a l'air très interessant, malheureusement il semblerait que le moteur d'exécution soit propriétaire et que les développeurs ne mettent à disposition que des moteurs pret à l'emploi pour certain robots grand public au lieu d'une biblio.

Citation:

---

Envoyé par zais_ethael

Le Urbi a l'air très interessant, malheureusement il semblerait que le moteur d'exécution soit propriétaire et que les développeurs ne mettent à disposition que des moteurs pret à l'emploi pour certain robots grand public au lieu d'une biblio.

---

Sur ce lien: http://www.gostai.com/download.php en bas de la page tu verras que les clubs et les ecoles peuvent avoir un support gratuit pour developper leur propre moteur urbi pour leur robot. Cela ne te couterai rien ne serait ce que d'envoyer un mail pour avoir un peu plus d'info!

J'avais pas vu. Ok je note ça.

Citation:

---

Envoyé par capitN.flam

L'allocation dynamique n'est pas déterministe

---

Merci, je sais, je n'ai pas dit le contraire. Mon argument était que :
- Un tri, en O(n log n) en moyenne, peut dégénérer en O(n²), c'est à dire être si long qu'on puisse considérer qu'il est comme non déterministe (ou alors, la gestion de la mémoire le devient aussi, il suffit de parcourir toute la mémoire après tout).
- Tous les algos d'analyse d'image que je connais sont non déterministes.
- Les algorithmes d'optimisation sont non déterministes
- ...

Tout ça pour dire que si l'on se prive de l'allocation dynamique pour ça, on se prive d'énormément d'autres choses. Si c'est admissible dans certains cas, ça ne l'est pas dans d'autres. A tel point que certains fonctions d'un logiciel ne pourraient pas être remplies.

Citation:

---

Envoyé par capitN.flam

c'est pour cela que l'on ne l'utilise pas en temps réel ou tout du moins on évite au maximum.

---

Je peux te citer tout un tas de systèmes temps réel où l'allocation dynamique est pourtant largement utilisée, et sans complexes. Par exemple un logiciel de prédiction météorologique (système temps réel, puisque s'il met pour prédire le temps de lendemain plus d'une journée, il ne remplis plus sa fonction) ne s'en prive pas.

Un simulateur de vol, de conduite,... en utilise tant qu'il veut sur certains aspects (simulation des véhicules externes, gestion événementielle du scripting d'une session), avec une parcimonie relative sur d'autres (dynamique du véhicule, stratégie de contrôle de la plate-forme à vérins,..), et peu ou pas sur d'autres (interface avec certaisn capteurs, intégration HIL (hardware in the loop) d'électronique existant dans les vrais véhicules (par exemeple un calculateur ABS).

Citation:

---

Envoyé par capitN.flam

Pour info je suis en spécialisation GISTR (Génie Informatique des Systemes Temps Réel) à l'EPITA.

---

Je n'aime pas trop l'utilisation d'arguments d'autorité, surtout quand elle est relative et que mon but est de démonter le point de vue dominant. Je suis près à entendre de vrais arguments.

il existe beaucoup d'algorithmes sur les images en O(n) (n nombre de pixels, soit m x p) malgré tout, nottament les calculs de squelettes ou la determination des formes, des calculs de distance (sur des images en niveau de gris)

sinon pour etre franc, JolyLoic, en tant qu'exterieur au temps reel ( mois d'etude a peine sur ce sujet, a peine touche du doigt) je suis interesse par savoir ton experience dans ce sujet, ca aide a justifier tes dires. parce que pour moi, quand tu dis

Citation:

---

Par exemple un logiciel de prédiction météorologique (système temps réel, puisque s'il met pour prédire le temps de lendemain plus d'une journée, il ne remplis plus sa fonction) ne s'en prive pas.

---

ca n'a aucune valeur si tu ne dis pas

"j'ai travaillé sur un logiciel de prediction meteorologique ici ou la", la ca ressemble a des paroles en l'air. je ne dis pas que c'est faux, que tu pipeautes ou quoi, mais vu que deux avis divergent et que l'un traine dedans, si tu n'avances pas une experience mais juste des phrases dites en l'air, ca a moins de valeur pour moi.

Citation:

---

Envoyé par JolyLoic

Merci, je sais, je n'ai pas dit le contraire. Mon argument était que :
- Un tri, en O(n log n) en moyenne, peut dégénérer en O(n²), c'est à dire être si long qu'on puisse considérer qu'il est comme non déterministe (ou alors, la gestion de la mémoire le devient aussi, il suffit de parcourir toute la mémoire après tout).
- Tous les algos d'analyse d'image que je connais sont non déterministes.
- Les algorithmes d'optimisation sont non déterministes
- ...

Tout ça pour dire que si l'on se prive de l'allocation dynamique pour ça, on se prive d'énormément d'autres choses. Si c'est admissible dans certains cas, ça ne l'est pas dans d'autres. A tel point que certains fonctions d'un logiciel ne pourraient pas être remplies.



Je peux te citer tout un tas de systèmes temps réel où l'allocation dynamique est pourtant largement utilisée, et sans complexes. Par exemple un logiciel de prédiction météorologique (système temps réel, puisque s'il met pour prédire le temps de lendemain plus d'une journée, il ne remplis plus sa fonction) ne s'en prive pas.

Un simulateur de vol, de conduite,... en utilise tant qu'il veut sur certains aspects (simulation des véhicules externes, gestion événementielle du scripting d'une session), avec une parcimonie relative sur d'autres (dynamique du véhicule, stratégie de contrôle de la plate-forme à vérins,..), et peu ou pas sur d'autres (interface avec certaisn capteurs, intégration HIL (hardware in the loop) d'électronique existant dans les vrais véhicules (par exemeple un calculateur ABS).



Je n'aime pas trop l'utilisation d'arguments d'autorité, surtout quand elle est relative et que mon but est de démonter le point de vue dominant. Je suis près à entendre de vrais arguments.

---

En disant que je suis en GISTR je voulais simplement dire que c'était mon domaine d'activité. Loin de moi l'idée d'être une autorité en la matière.

Pour en revenir au non déterministe, un tri même s'il dégénère en O(n^42) (valeur volontairement abérente) finira et au final on aura les bonnes valeurs aux bons endroits. Dans le cas d'une allocation dynamique efectivement dans le pire des cas on fera un parcours de toute la mémoire mais on peut sortir du malloc (ou new) en n'ayant pas alloué de mémoire, malloc peut retourné NULL et new lève une exception, dans ce cas là que fais tu avec ton système?
Effectivement dans certain cas on utilise l'allocation dynamique mais c'est sur des systèmes qui ne sont pas critique.

Nous n'avons peut être pas la même définition de temps réel. Pour moi c'est un système qui est temps réel (hardware + software), apparement pour toi ce peut n'être q'un logiciel (ton exemple pour la météorologie).
Siu ce n'est qu'un logiciel rien n'empeche de rajouter des ressources pour ton exemple un processeur un peu plus puissant pour que le calcul revienne en dessous de la barre de la journée. Dans le cas d'un système complet on ne peut pas changer le matériel si simplement car il y a souvent des contraintes: place, poids, résistance aux chocs, à la chaleur, ...

Citation:

---

Envoyé par screetch

sinon pour etre franc, JolyLoic, en tant qu'exterieur au temps reel ( mois d'etude a peine sur ce sujet, a peine touche du doigt) je suis interesse par savoir ton experience dans ce sujet, ca aide a justifier tes dires.

---

J'ai travaillé pendant 8/9 ans sur un simulateur de conduite. C'était du temps réel "soft" (un louper de pas de temps n'avait pas de conséquences graves, il fallait juste que ce soit un évènement pas trop courant), sachant qu'on s'appuyait souvent sur du matériel (plate-forme à vérins, volant à retour d'affort...) qui incluait déjà un certain niveau de logiciel (souvent en temps réel plus "hard", lui) et qui prenait déjà en compte ses propres aspects de sécurité.

Pour la météorologie, je n'ai pas d'expérience directe, mais ai discuté avec un gars qui faisait sa thèse là dessus (sur but était comment réintroduire dans l'algo de prédiction les nouvelles observation qui ont pu être faites depuis le début du calcul), et je peux t'assurer que ses problématiques étaient à 100 lieux d'une minimisation des allocations mémoire...

Citation:

---

Envoyé par capitN.flam

Dans le cas d'une allocation dynamique efectivement dans le pire des cas on fera un parcours de toute la mémoire mais on peut sortir du malloc (ou new) en n'ayant pas alloué de mémoire, malloc peut retourné NULL et new lève une exception, dans ce cas là que fais tu avec ton système?

---

Je reporte l'erreur aux couches appropriées du système, qui elles n'ont pas besoin d'allocation mémoire, en leur laissant décider quoi faire. Ca peut aller de faire exploser Ariane à rebooter automatiquement le système à basculer vers une stratégie survivaliste minimale, à...

Ce qui me semble important, plus que l'allocation mémoire, est l'indépendance entre couche de façon à ce qu'une erreur haut niveau ne vienne pas mettre en cause le bas niveau.

Citation:

---

Envoyé par capitN.flam

Effectivement dans certain cas on utilise l'allocation dynamique mais c'est sur des systèmes qui ne sont pas critique.

Nous n'avons peut être pas la même définition de temps réel. Pour moi c'est un système qui est temps réel (hardware + software), apparement pour toi ce peut n'être q'un logiciel (ton exemple pour la météorologie).

---

Justement, je pense que j'ai une vision plus large de ce qu'est un système temps réel. Prenons une voiture, un des systèmes temps réel où la sécurité compte beaucoup les plus utilisés actuellement. Et bien, dans ce système, certains aspects se moquent totalement du déterminisme (la navigation, par exemple, et tout ce qui est habitacle en général (d'ailleurs des langages comme Java y sont de plus en plus présent)), certains aspects y font bien plus attention (les calculateurs ABS ou ESP, les directions assistées électriques...(1)). Et de toute façon, tout est prévu (pour l'instant du moins, mais ça risque(2) de changer, ce n'est par exemple plus le cas dans l'aéronautique) pour qu'en cas de défaillance complète de l'électronique, la mécanique reste suffisamment stable pour assurer la sécurité des personnes.

Citation:

---

Envoyé par capitN.flam

Siu ce n'est qu'un logiciel rien n'empeche de rajouter des ressources pour ton exemple un processeur un peu plus puissant pour que le calcul revienne en dessous de la barre de la journée.

---

En l'occurrence, pour la météo, ce n'est généralement pas possible, le bottleneck étant dans la possibilité de distribuer les algorithmes sur n processeurs (n se comptant en milliers), et je crois aussi dans le débit de communication entre les différents processeurs. S'il suffisait d'acheter un millier d'ordinateurs en plus pour avoir les résultats plus vite, les ingénieurs de météofrance seraient au chômage...

Citation:

---

Envoyé par capitN.flam

Dans le cas d'un système complet on ne peut pas changer le matériel si simplement car il y a souvent des contraintes: place, poids, résistance aux chocs, à la chaleur, ...

---

Et prix...

Mais de toute façon, changer un matériel a un impact sur les performances, pas sur le déterminisme.


(1) D'ailleurs, chose amusante, quand on lit la définition du protocole CAN, utilisé pour communiquer entre les différents éléments d'une voiture, un peu comme de l'USB pour l'informatique, mais vendu comme déterministe et temps réel, on se rend compte qu'en fait il n'est pas déterministe...

(2) Voire c'est en train de changer, je ne bosse plus chez un constructeur automobile, et n'ai donc pas suivi.