IllustraBot : Android
IllustraBot : Android
Voici mes notes prises à la réunion de lancement du 28/01
Surtout n'hésitez pas à corriger mes erreurs et approximations !
Maintenant, c'est à vous de prendre les choses en main et de vous coordonner pour chaque tâche.
Good luck !
Équipe:
Cédric @cebernard
Julien @jjacques
Nicolas (éventuellement) @nicolaslenillon
à faire:
identifier les briques à intégrer
canevas
génération gcode
Ah et au fait, je ne sais pas si je vous ai dit : NOUS N'AVONS QUE 1 MOIS ! ;)
Surtout n'hésitez pas à corriger mes erreurs et approximations !
Maintenant, c'est à vous de prendre les choses en main et de vous coordonner pour chaque tâche.
Good luck !
Équipe:
Cédric @cebernard
Julien @jjacques
Nicolas (éventuellement) @nicolaslenillon
à faire:
identifier les briques à intégrer
canevas
génération gcode
Ah et au fait, je ne sais pas si je vous ai dit : NOUS N'AVONS QUE 1 MOIS ! ;)
Jérôme - FabManager/Vice-Président
Hello,
Vu que l'IHM va rester relativement simple (par exemple, un canevas et une seule couleur de crayon), que pensez-vous de regarder ce que l'on peut faire avec "LiveCode" :
http://www.runrev.com/products/mobile-d ... /overview/
A première vue, c'est un environnement qui correspond tout à fait à ce que l'on veut.
Maintenant, il faut faire un essai : si c'est trop l'usine à gaz, je laisserai tomber ;)
EDIT: Oops ...! LiveCode n'est pas encore Open Source (voir leur page "Help Us" ). Suite au prochain numéro ^^
Vu que l'IHM va rester relativement simple (par exemple, un canevas et une seule couleur de crayon), que pensez-vous de regarder ce que l'on peut faire avec "LiveCode" :
http://www.runrev.com/products/mobile-d ... /overview/
A première vue, c'est un environnement qui correspond tout à fait à ce que l'on veut.
Maintenant, il faut faire un essai : si c'est trop l'usine à gaz, je laisserai tomber ;)
EDIT: Oops ...! LiveCode n'est pas encore Open Source (voir leur page "Help Us" ). Suite au prochain numéro ^^
- davidblaisonneau
- Messages : 36
- Enregistré le : mer. 2 nov. 2016 16:05
A mon avis, 2 approches possibles pour la réception des données :
- idéalement, vous balancez les données sur un port derrière lequel on met un netcat à l'écoute, et il renvoie les données sur le /dev/machintruc correspondant à l'interface avec l'Arduino
- soit vous faites des POST successifs, et le RPi reçoit les données et les passe à un CGI -> peut-être nécessaire si on n'a pas de /dev/machintruc correspondant à l'interface avec l'Arduino, on aura besoin de développer un petit exécutable pour envoyer les données sur le SPI/autre
Agreed ?
- idéalement, vous balancez les données sur un port derrière lequel on met un netcat à l'écoute, et il renvoie les données sur le /dev/machintruc correspondant à l'interface avec l'Arduino
- soit vous faites des POST successifs, et le RPi reçoit les données et les passe à un CGI -> peut-être nécessaire si on n'a pas de /dev/machintruc correspondant à l'interface avec l'Arduino, on aura besoin de développer un petit exécutable pour envoyer les données sur le SPI/autre
Agreed ?
- davidblaisonneau
- Messages : 36
- Enregistré le : mer. 2 nov. 2016 16:05
Pour moi, les programmes d'envoi de GCode attendent au moins un retour chariot avant d'envoyer d'autres requètes:
https://github.com/grbl/grbl/blob/maste ... _stream.py (commentaire: # Wait for grbl response with carriage return) Donc cela implique un flux bidirectionnel pour l'acquittement du GCode, d'où ma proposition de WebSocket.
Donc mon idée, le websocket est juste là pour faciliter le passage par internet, le serveur n'agirai que pour éviter deux sessions en // et transmettre le GCode à un /dev. (la première proposition de @yann)
https://github.com/grbl/grbl/blob/maste ... _stream.py (commentaire: # Wait for grbl response with carriage return) Donc cela implique un flux bidirectionnel pour l'acquittement du GCode, d'où ma proposition de WebSocket.
Donc mon idée, le websocket est juste là pour faciliter le passage par internet, le serveur n'agirai que pour éviter deux sessions en // et transmettre le GCode à un /dev. (la première proposition de @yann)
David, FabManager / Trésorier
Quelques points :
le réseau LTE de labo ici, n'est pas limité en ports ouverts/autorisés, donc on passe ou on veut.
Il faut éviter l'UDP pour avoir la capacité de réémission de TCP. En effet d'après les Bell Labs l'usb du RPi peut perdre des données. C'est un problème pour eux qui voulaient brancher une caméra, mais avec les mécanismes réseau TCP, ça ne devrait pas nous gêner.
Je pensais à une simple socket TCP, mais on peut utiliser du websocket, ça rajoute une couche de buzz ;)
Je suis pas pour la solution POST/cgi, ça rajoute des fork, de la comm inter-process qui n'apporte pas grand chose. Un simple netcat peut-être suffisant (il semble que le driver puisse accepter des read()/write(), à vérifier) ou un serveur perso en C ou python si on doit passer par des ioctl()
Sinon, les acquittements qui semblent nécessaires entre arduino(grbl)/RPi n'ont pas forcément besoin de remonter vers android. Par contre il faut peut-être envisager un retour RPi->android de type "trames de pause" le temps que le feutre se mette à la bonne position quand on pose le doigt.
le réseau LTE de labo ici, n'est pas limité en ports ouverts/autorisés, donc on passe ou on veut.
Il faut éviter l'UDP pour avoir la capacité de réémission de TCP. En effet d'après les Bell Labs l'usb du RPi peut perdre des données. C'est un problème pour eux qui voulaient brancher une caméra, mais avec les mécanismes réseau TCP, ça ne devrait pas nous gêner.
Je pensais à une simple socket TCP, mais on peut utiliser du websocket, ça rajoute une couche de buzz ;)
Je suis pas pour la solution POST/cgi, ça rajoute des fork, de la comm inter-process qui n'apporte pas grand chose. Un simple netcat peut-être suffisant (il semble que le driver puisse accepter des read()/write(), à vérifier) ou un serveur perso en C ou python si on doit passer par des ioctl()
Sinon, les acquittements qui semblent nécessaires entre arduino(grbl)/RPi n'ont pas forcément besoin de remonter vers android. Par contre il faut peut-être envisager un retour RPi->android de type "trames de pause" le temps que le feutre se mette à la bonne position quand on pose le doigt.
Jérôme - FabManager/Vice-Président
Hello,
Je touche un peu aux websocket et j'ai fais une expérience assez concluante de websockets servies par un serveur nodeJS (ce qui évite le cgi).
En deux mots, la websocket servait les coordonnées de la souris d'un conférencier à un ensemble d'étudiants.
Je n'ai pas observé de lag trop important (le déplacement est fluide).
Je touche un peu aux websocket et j'ai fais une expérience assez concluante de websockets servies par un serveur nodeJS (ce qui évite le cgi).
En deux mots, la websocket servait les coordonnées de la souris d'un conférencier à un ensemble d'étudiants.
Je n'ai pas observé de lag trop important (le déplacement est fluide).