Recherche programmeur PC et autres talents!

[romain]

Bonjour à tous,

Les bumpers ne sont pas gérés de manière autonome ? C'est à dire que le bumper si il est activé, se débrouille tout seul pour descendre et renvoyer la balle ?..
Et seulement après, 'tranquillement' envoyer l'info au cpu ?

Si ce n'est pas ça, c'est un peu dommage non ?.

qui dit "activer le bumper tout seul" suppose que le microcontrôleur "sait" qu'un bumper correspond à tel contact.
Il faut donc faire une correspondance entre le N° de contact et l'activation de la bobine N°...
Le système étant générique, on ne peut pas se permettre de le mettre en dur dans le code...
C'est la raison pour laquelle j'ai écrit :

Pour l'instant, aucune partie de code de commande du flipper ne sera déporté dans le microcontrôleur, tout sera géré par le PC; le micro sera simplement esclave du PC.

Si le problème du temps de réponse apparait ce sera une solution, cependant vu sa complexité, il est préférable de s'en passer autant que possible.

Papo06->On verra pour les 2ms mais si le bumper a un peu plus de latence, vu l'inertie de la mécanique, je pense pas que ça joue tant que ça

[damien d.]

Si justement, plus l'électronique est lente, si tu rajoute en plus l'inertie de la mécanique, et tu te retrouve avec un bumper inefficace.

[michel06]

Je relis ce sujet sur lequel j'avais posté iil y a quelques mois mais personne n'avais répondu ou commenté mon mai... Vous vous faites de sacrés noeuds avec les langages de programmation, le temps réel etc...
J'ai une assez grande expérience de l'informatique "embarquée/temps réel" moderne, je suis enseignant/chercheur en informatique et je travaille depuis pas mal d'années dans me monde des systèmes embarqués et de la robotique.

On distingue effectivement le "bas niveau" sur lesquel travaille Romain, qui est essentiel, et là des langages type C/C++ sont la norme, et le "haut niveau", c'est-à dire la "macro-commande". Les cpu aujourd'hui, que ce soint dans le monde mobile (Windows CE/Mobile/linux embarqué à base d'ARM par ex) ou dans le monde classique, sont infiniment plus puissante que ce que l'on trouvait dans nos flips. On sait aujourd'hui contrôler des robots mobiles en C# ou en Java sans aucun problème lié à ce que l'on appelle "le temps réel". On a même plus besoin d'un OS "temps réel" tels que certains Linux temps réel, CE, VxWorks ou Qnx utilisé dans les pinball 2000. Un bête XP suffit pour controller un robot, commander ses moteurs, lire ses capteurs, calculer de nouvelles positions etc... On envoit des ordres et on lit en pseudo parallèle grace à des librairies spécialisées comme la CCR de Microsoft par exemple (Concurrent Runtime) qui facilitent grandement l'écriture de programmes effectuant des tâches en parallèle. Je pourrai rentrer dans les détails si vous le souhaitez.

Les systèmes embarqués dans les véhicules sont majoritairement écrits en Java à l'aide du framework OSGI et là aussi, on a de la lecture et de la commande parallèle.

Les OS dessous ne sont pas "temps réel" mais comme le bas niveau lui l'est, si on perd quelques millisecndes par-ci par-là ce n'est pâs bien grave.

Croyez-moi, le temps réel dans un flipper c'est de la rigolade par rapport aux contraintes de la robotique. Et on peut très facilement envisager de programmer toute la logique de haut niveau (les règles, l'équivalent des scripts vpinmame + code des roms= avec un langage de haut niveau.

Critiquer java, C# etc... à ce niveau-là n'a aucun sens. 95% de Vista a été re-écrit en C# par exemple, ça bouffe certe plus de mémoire mais les performances sont comparables, je peux vous communiquer des articles scientifiques à ce propos. Idem pour Java, son apparente lenteur pour les néophytes est souvent assimilée au temps que met le logiciel à se lancer (il faut charger la JVM, etc... ce qui est long) mais une fois que tout est en mémoire, les perfomances sont le plus souvent comparable à du C/C++.

Quel intérêt à travailler avec ces langages plutot qu'en C/C++ ? Justement, ils sont de plus haut niveau et on développe plus rapidement...

Robosoft développait à 100% en C/C++ sous Linux temps réel. Ils ont lancé une gamme de robots sous CE/XP + le Microsoft Robotic Studio, ils ont redéveloppé tout leur middleware en C# autours de ces outils et en quelques mois tous leurs softs ont été portés sur cette nouvelle architecture. Les perfs sont là et les temps de développement réduits de trois quart. Je ne fais pas l'apologie de Microsoft ici, c'est juste pour dire que de nos jours on peut envisager sans aucun problème de développer une appli "flipper" au-dessus des cartes de romain dans absolument n'importe quel langage, un framework (ensemble de librairies) permettant de faire de la programmation parallèle étant un plus indéniable, il existe de tels frameworks pour Java (OSGI), pour C# (la librairie CCR), etc.
Avec le Robotic Studio on développe des "services" par exemple "service de controle des lampes", "service de controle de la puissance" etc... et ces services sont à la fois des services temps réel et des services web (on peut appeler un URL pour avoir l'interface de test/debug dans son navigateur).

Etc... le PDG de Robosoft m'a acheté mon the Machine Bride of Pinbot et c'est aussi un passionné de flip. Il m'a dit "mais c'est comme un robot !" Ben oui.

[romain]

Bonjour,

concernant le bas niveau nous sommes d'accord que le C/C++ reste le standard et surtout que de telles librairies seraient portables.

Pour le haut niveau, le problème reste entier. Le but principal est de permettre à n'importe qui de coder ses propres règles et de commander SON flipper.
Il faut donc un langage facile d'approche, ayant peu de pièges (ce qui exclu d'emblé le C++) et faisant abstraction de la couche de commande.

Les tables virtuelles actuelles étant codées en VBS, ça me parait un bon compromis entre ce que les créateurs de ces tables savent faire, la facilité de programmation et d'interfaçage.
Maintenant : existe-t-il un IDE pour faciliter une telle programmation ? Cet approche permet-elle un interfaçage facile avec les librairies bas niveau et enfin (mais mes espoirs s'amenuisent) un portage ??

La solution serait-elle alors de créer un "middleware" spécifique, un langage (mais là on a pas fini) qui permettrai de bosser facilement mais à partir de quoi ???

C'est à ça que servait ce sujet à l'origine, et non pas de faire débat sur ce qui est temps réel et ce qui ne l'est pas. Merci de recentrer un peu le sujet

à vos PC

[Papo06]

Je copie colle mon message ici


----------------------------------



je voulais juste rebondir sur le vbscript, dans vp/fp l'objet est caché et déjà là puisque c'est lui même et qu'il appelle de façon magique les fonctions dans le vbscript, mais on obtient à peu près le même résultat en créant un objet à la main avec WScript.CreateObject et les fonctions seront appelées de façon magiques tout comme dans vp/fp en connectant l'objet créé avec un préfixe quelconque via ConnectObject

Le reste ressemblera à peu de choses près à un script vp/fp sauf qu'il faudra nommer l'objet flip, nommer l'objet son, nommer l'objet dot ou afficheur

exemple totalement bidon et faux syntaxiquement mais c'est pour donner une idée:

Dim flipper, display, sound

flipper = WScript.CreateObject("pin2.flipper")
display = WScript.CreateObject("toto.afficheur")
sound = WScript.CreateObject("bidule.gestionson")

' associe le préfixe 'flipperevent' à l'objet flipper pour les évènements
WScript.ConnectObject(flipper,"flipperevent")

Dim score = 0, partieencours = FALSE

' appelé si on appuie sur le bouton start
Function flipperevent_startbutton
display.write("Staring game");
score = 0
partieencours = TRUE
sound.playmp3inloop("tutu.mp3"); ' background sound
End Function

Function flipperevent_switch_down(num)
if num = 52 and partieencours then
flipper.solenoidFire(25,100) 'active solenoide 25 pendant 100ms
score = score+1000
display.write("Bien joué mec ! ton score:"+score);
sound.playsample("bip.wav"); ' bumper sound
end if
End Function

-------------------

après on peut gérer de plusieurs manières les callback sur les évènements, soit avec une fonction par switch pressé+switch réouvert, soit 2 méthodes seulement, en filant le numéro en paramètre idem pour les lampes et solenoides, soit implémenter une méthode solenoidOn(N), solenoidOff(N) et automatiques par exemple solenoidFire(n, durée) pour éviter d'avoir à gérer les timer dans le script

Pascal

[romain]

De mon côté je me suis mis au C++ et ai énormément bossé sur des appli portables windows/linux.

Je suis donc capable de faire la même chose qu'en VB mais en C++ (je ne ferai pas la liste des avantages...).
Que proposez-vous à partir de là ? Qu'est-il possible de faire grâce à une interface graphique ? des choses très limitées par rapport à ce qu'on attends d'une interface haut niveau à mon avis...

Je suis ouvert à vos suggestions (ex : code dans un fichier, traitement du fichier pour la programmation évènementielle; paramétrage par boutons, cases à cocher...; interface avec un moteur de script; etc...)

[Papo06]

Ben justement tu programme ton truc en "ce que tu veux" tant que le module que tu génères est compatible avec le vbs (objet ole en gros) et expose ses méthode et sait gérer les évènements on s'en fout du langage.

Et justement pour débuter un simple script qui crée les object flip, des timer, du son, afficheur c'est pipo et ça revient exactement au même que ce qui est fait dans vp/fp

Pascal

[romain]

salut,

ça j'avais bien saisi, faire des bibliothèques c'est pas bien compliqué du moment qu'on sait le faire (je n'ai jamais créé de bibliothèques) et du moment qu'on sait exactement comment on compte travailler avec derrière (pour fournir les bonnes fonctions d'interface).

De mon côté je suis capable de faire un programme, soit un .exe qui tourne sous n'importe quel windows (sans aucun plugin ni framework), soit les sources compilables sous Linux.
Cette methode permet d'avoir un truc portable et hyper facile d'utilisation pour n'importe qui.
Le scripting c'est bien, je ne connais pas, ce n'est sûrement pas portable, et je voudrai savoir si on peut coder des machines d'état etc pour la gestion du flip ??
Quel est le temps de réponse d'une telle programmation (j'ai entendu parler de 55ms au pire pour du VB).

Je ne demande qu'à découvrir

[michel06]

Le langage de script se compile et peut avoir les mêmes perfs que C/C++
Quel que soit le langage. Il n'existe plus de langage plus rapide qu'un autre. C'est ça l'état de l'art aujourd'hui... un langage n'est jamais plus rapide qu'un autre, ça dépend de son intepréteur, de son compilateur, de l'architecture sur laquelle il tourne, etc... Tu peux faire du java ou du C# aussi rapide que du C archi optimisé (Vista a été récrit à 95% en C# par exemple).
Mais oui, tu as raison, du VBscript interprété (et non compilé) est plus lent qu'un langage compilé, mais ce serait aussi le cas pour du C inteprété (ça existe)...

Je trouve que l'idée de papo06 qui consiste à réutiliser les scripts de FP, est excellente. J'en ai déjà parlé dans un autre post ailleurs...

[Papo06]

Le scripting c'est bien, je ne connais pas, ce n'est sûrement pas portable, et je voudrai savoir si on peut coder des machines d'état etc pour la gestion du flip ??
Quel est le temps de réponse d'une telle programmation (j'ai entendu parler de 55ms au pire pour du VB).

Ben justement ce que j'ai montré plus haut c'est exactement ce qui est fait dans vp/fp ! ils ont simplement utilisé le moteur vbscript dans leur programme, là on fait l'inverse c'est le moteur vbscript qui crée les dll et qui appelle le progs, ça revient strictement au même, les auteurs de vp/fp n'ont pas réécrit l'interpréteur vbscript, ils ont fait la même chose que ce que j'ai montré plus haut, j'ai bien compris que vous vouliez créer vos table dans fp ou vp et réutiliser le script, mais pas besoin d'avoir vp ou fp lourdingue pour ça, il faudra juste faire une moulinette de conversion de script (ça c'est pas dur).

Pascal