J’ai craqué en suivant mon dernier post, je me suis dit que c’était faisable.
Je vous présente donc la V0.1: http://poppy-project.github.io/poppy-ergo-jr/simulator/
Avec @Pierre, on devrait pouvoir rapidement changer les sliders pour des requetes html donc utilisable avec pypot. Ce sera déjà une super version.
Il y a poste de dev web ouvert 
Bien joué !
Le truc ennuyant est que pour chaque créature il faut hardocoder les liens entre les STL. Ca serait intéressant de pouvoir le faire automatiquement depuis le fichier URDF, comme cela est actuellement fait pour V-REP. Pour cela, on peut s’inspirer du code de ros3djs (parseur d’URDF en js) dont le projet est assez similaire à ce qu’on souhaite faire.
C’est quand même pas mal beau gosse, tu as gagné le trophée du meilleur dev javascript de l’équipe.
Yes, complètement !
Pour la génération du robot à partir de l’URDF, une alternative consiste à écrire un bout de code python qui génère le js qui va bien. Cela ne doit pas être si violent (pour peu que les STL utilisés respectent un semblant de convention).
ça rend super bien !
n’hésitez pas je pense à discuter avec Gregoire Passault, il a fait une chose similaire avec Metabot et a rajouté une couche de blockly !
And… it’s done:
@jgrizou @Pierre Génial, bravo à tous les deux !!!
Cela va intéresser @droy 
On se rapproche de la possibilité d’avoir un système Snap!+simulateur entièrement dans le browser, sans rien à installer.
Quels sont les possibilités de moteurs physiques, permettant par exemple de faire des projets autour de la locomotion ou du poussage d’objets ?
C’est en cours avec http://chandlerprall.github.io/Physijs/. Disons fin du mois pour une première version.
Si c’est performant, on va pouvoir lancer des concours de saut en longueur!
En effet si cela fonctionne de superbes projets pédagogiques vont devenir possible, avec des concours de saut (longueur ou d’obstacle) ou de course par exemple que les élèves pourront ensuite tester avec un vrai ergoJr !
Tu parles si ça m’intéresse, c’est génial ! Ça ouvre de sacrés perpectives !
Nouvelle version en ligne: http://poppy-project.github.io/poppy-ergo-jr/simulator/
Pas de vrai changement en apparence, mais refonte profonde du code. Optimisation et modularisation du code en utilisant require.js.
@Pierre: J’ai rajouté dans le menu une option “remote” (avec choix interactif de l’IP et du PORT). Je me suis inspiré de la branche demo-live-threejs mais je n’ai pas testé avec un robot. Si tu as le temps pour tester rapidement ce serait cool. Si tu dois modifer c’est dans js/app/octopus: https://github.com/poppy-project/poppy-ergo-jr/blob/master/simulator/js/app/octopus.js. Voir en bas la fonction pollPos.
J’ai réduis par 2 le nombre de polygones et les ai enregistrés en stl binaire, ce qui permet de gagner 80% du poids des fichiers et de réduire la charge processeur/gpu.
Ca ne fonctionne pas. Dès que je clique sur Enable, l’ensemble du robot sauf la base disparait. Mise à part une typo 128.0.0.1 au lieu de 127.0.0.1 je n’ai rien vu de pas clair. Du coté serveur web je ne reçois pas de requête erronée.
Je n’ai pas poussé le début plus loin, je ne comprends pas grand chose au framework js que tu utilises.
Ok, donc côté serveur tu reçois les bon paquets bien formés?
J’ai voulu utiliser vanilla javascript et pas jquery, j’ai pas cherché bcp non plus car je ne pouvais pas tester, j’ai juste converti le code suivant:
$.get("http://172.16.153.135:8080/motor/m1/register/present_position",
function (data) {
pypot_pos[0] = data.present_position;
});
en:
var httpRequest = new XMLHttpRequest()
httpRequest.onreadystatechange = function (data) {
octopus.guiData["M"+i] = data.present_position;
}
var url = "http://" + octopus.guiData.remoteIP + ":" + octopus.guiData.remotePORT + "/motor/m" + i + "/register/present_position";
httpRequest.open('GET', url)
httpRequest.send()
}
Un problème c’est p-t que je crée 6 new XMLHttpRequest() par tour à 60Hz 
Il faut voir si jquery fait un truc particulier pour ça. Y a-t-il un moyen simple de simuler un robot avec server REST pour faire des requêtes REST? (sans V-REP et en simulant des moteurs qui font des sinus)
Aussi, je ne me sers de jquery nulle part, et je trouve que c’est philosophiquement embêtant de l’utiliser ici d’autant plus que je ne pense pas que ce soit la méthode parfaite sur le long terme. Quand j’aurai le temps je testerai socket.io.
Oui c’est pas limpide au début, mais ça permet d’organiser le code en module en prenant en compte les dépendance et sans poluer tout le workspace. Le index.hmtl à aussi l’avantage d’être simple car c’est require.js qui gère les imports. Si tu veux t’y pencher, je me suis inspiré de GitHub - felixpalmer/amd-three.js: AMD + three.js example application layout pour l’organisation. Mais sinon tout se passe dans https://github.com/poppy-project/poppy-ergo-jr/blob/master/simulator/js/app/octopus.js pour l’option remote pour l’instant.
@Pierre c’était un peu la question que j’avais hier
C’est ce que je t’ai montré hier dans le bureau de Didier sans vraiment d’explication
@jgrizou pour tester il faut que tu mettes à jour pypot et poppy_creatures.
Ensuite, l’idée est de créer une créature en Python comme on le ferait pour se connecter à un robot physique ou à v-rep:
from poppy.creatures import PoppyErgoJr
jr = PoppyErgoJr(simulator='threejs', use_http=True)
# Magie Python pour lancer le server web en background
from threading import Thread
t = Thread(target=jr.http.run)
t.daemon = True
t.start()
Il faut également spécifier que l’on veut lancer un serveur web que Three.js peut venir interroger (je détaille ce choix en rapport avec notre discussion d’hier plus bas).
On peut ensuite envoyer des ordres au moteur comme sur un vrai robot et voir le résultat sur Three.js. Le contrôler sur ces moteurs “imaginaires” affectent simplement la goal_position à la présent_position. Les moteurs se “téléportent” à leur position goal :
jr.m2.goal_position = 42
from pypot.primitive.utils import Sinus
s = Sinus(jr, 50.0, jr.motors, amp=30, freq=.1)
s.start()
@jgrizou, j’ai testé cela fonctionne très bien sur l’ancienne version du dépôt pour Three.js mais pas sur la nouvelle. On peut regarder ça ensemble à l’occasion si tu veux, mais tout seul je risque de perdre trop de temps à essayer de comprendre l’archi du js.
Pour en revenir à la question d’hier, à savoir (si j’ai bien compris) la possibilité de faire communiquer Snap à Three.js. Il existe plusieurs façons d’envisager ça:
En espérant avoir été plus clair
Il faut rajouter un block écrit en JavaScript pour utiliser les websockets, mais on aura probablement besoin de le faire si on veut améliorer le temps de réponse des requêtes.
Le seul interêt que je vois de faire en full JS c’est de pouvoir l’utiliser dans son navigateur en ligne. Si on est hors ligne ça revient au même de cliquer sur un exécutable qui n’a pas besoin des droits admins pour lancer Snap! que de cliquer sur un fichier index.html qui s’ouvre dans son navigateur. En ayant en tête qu’on ne pourra jamais avoir tout en JavaScript (traitement d’image, accès au matériel, …), que ça va multiplier les sources de problèmes, le fait de pouvoir faire bouger le robot en ligne sur son navigateur en vaut-il la peine ? Je n’en suis pas persuadé, et je pense que pour l’effet escompté c’est plus simple de faire tourner des python dans des conteneurs docker pour chaque personne qui veut utiliser le robot en ligne.
Effectivement mais n’importe qui dans le monde pourrait programmer un ergo virtuel en cliquant seulement sur un lien… plutôt pas mal comme impact et pour disséminer le projet. Mais comme tu dis, c’est beaucoup de dev et plein de trucs non-compatibles avec les robots physiques.
Mon avis est que faire du tout JS serait un petit changement de focus du projet car cela risque d’inciter fortement les profs à ne faire que du Snap/ErgoJr en ligne. Il me semble que l’on veut transmettre plus que du simple code sur un ordi avec la dimension robotique, tangible, modifiable, hackable etc… Il faut donc que le robot physique soit présent dès le début de l’initiation et à tout age, idéalement avec un “framework” cohérent du primaire aux écoles d’ingénieur. Je pense donc qu’il vaut mieux concentrer les efforts dans ce sens.
Si j’ai bien compris, tu dis qu’une alternative au tout JS c’est de créer un serveur virtuel pour chaque connection avec un pypot qui tourne et fait le lien entre ErgoJS et Snap?
Tu penses que c’est fesable avec des temps de latence correcte?
Ca dépend de où tu es positionné par rapport à ton serveur, mais si tu as un FAI pas trop mauvais, le principal temps de latence vient du wifi entre ton routeur et ton ordi. Mon idée est de s’inspirer du fonctionnement de tmpnb et de sagemathcloud (explication de l’architecture).