IllustraBot : Android

Discussions générales pour tous les usagers du Lieu
Avatar du membre
jerome
Administrateur du site
Messages : 123
Enregistré le : mar. 1 nov. 2016 20:54

IllustraBot : Android

Message par jerome »

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 ! ;)



 
Jérôme - FabManager/Vice-Président

Avatar du membre
jjacques
Messages : 27
Enregistré le : sam. 5 nov. 2016 15:32

Message par jjacques »

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 ^^

Avatar du membre
yann
Messages : 44
Enregistré le : sam. 5 nov. 2016 14:54

Message par yann »

Du coup vous généreriez le Gcode et enverriez des rafales de Gcode au Rpi. On peut tabler sur une écoute du port 80 côté RPi ?

Avatar du membre
davidblaisonneau
Messages : 36
Enregistré le : mer. 2 nov. 2016 16:05

Message par davidblaisonneau »

Si on fait sur le port 80, le mieux serai de faire du WebSocket, plus approprié à ce genre d'usage.
David, FabManager / Trésorier

Avatar du membre
yann
Messages : 44
Enregistré le : sam. 5 nov. 2016 14:54

Message par yann »

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 ?



 

Avatar du membre
jjacques
Messages : 27
Enregistré le : sam. 5 nov. 2016 15:32

Message par jjacques »

WebSocket a besoin d'un mode connecté TCP.



 



Ne pourrait-on pas traiter les trames directement au niveau UDP plutôt ?



 



Netcat est suffisant pour récupérer le contenu des datagrammes (le flux Gcode) et le traffic ne s'effectuerai que dans un sens (quasiment), non ?!

Avatar du membre
yann
Messages : 44
Enregistré le : sam. 5 nov. 2016 14:54

Message par yann »

On n'a pas plus de risques de perdre des morceaux en chemin, avec de l'UDP ?

Avatar du membre
davidblaisonneau
Messages : 36
Enregistré le : mer. 2 nov. 2016 16:05

Message par davidblaisonneau »

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)
David, FabManager / Trésorier

Avatar du membre
jerome
Administrateur du site
Messages : 123
Enregistré le : mar. 1 nov. 2016 20:54

Message par jerome »

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.



 
Jérôme - FabManager/Vice-Président

vbarreaud
Messages : 0
Enregistré le : sam. 5 nov. 2016 15:21

Message par vbarreaud »

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).

Répondre