fablab-lannion.org

Si tu n'as pas le matos, si tu poses le code quelque-part, peut-être que @laurent pourrait essayer sur la Uno que je lui ai passé ?

Super ça avance !



@nicolaslenillon c'est le moment de mettre ça à disposition sur github non ? ;)



Quel es ton identifiant que je t'ajoute au dépôt ?



 



 

Salut,



J'arrive avec mes gros sabots dans ce topic avec une question qui me trotte dans la tête...



Comment a ton prévu de gérer les congestions de flux entre le bourrin d'android d'un côté et le moteur qui peine à avancer de l'autre ?



Ce serait pas mal de mettre une mémoire tampon au niveau du Rpi ( ou interface du mm genre) pour absorber le flux android->rpi et le dépiler dans le petit buffer d'interface de l'arduino en fonction par ex d'un état buffer_full transmis par l'arduino.



Un avis ?



 

Plutôt qu'un simple buffer intermédiaire, je pense qu'il faudrait une communication bidirectionnelle complète.

Si l'on prend le cas ou on lève le stylo pour recommencer le dessin plus loin: le temps de déplacement vers les nouvelles coordonnées va être long . On pourrait prévenir l'utilisateur d'attendre le positionnement du stylo par un écran rouge (par exemple). et l'appli andoid ne recommence à dessiner que quand tout est pret. Comme cela on évite d'accumuler du retard (et du buffer) au fur et à mesure du dessin.



En quelque sorte, on déplace le buffer vers le doigt de l'utilisateur :)



 



 



 



 

@jerome: le gestionnaire bidirectionnel, tu le vois où coté arduino ou coté RPi ?



 



@nicolaslenillon:



Merci pour le code, je l'intègre sur GitHub ce soir

Regarde si GRBL supporte le gcode G16, ce code permet de passer en coordonnées polaires (http://www.cnccookbook.com/CCCNCGCodeG1 ... inates.htm). Ce code est à tester mais à mon avis, la carte fera juste de la conversion en cartésien pour piloter 2 moteurs perpendiculaires et je ne suis pas certain que la table de @jerome soit prise en compte.

Si ça ne fonctionne pas, je ne pense pas que la meilleur option soit de gérer ça coté Arduino, il est déjà bien chargé le pauvre :) Ne pourrait t'on pas s'en occuper à la génération du GCode ? avec une option qui permet de sélectionner le type de table ?  l'arduino faisant juste son travaille standard, c'est à dire tourner les moteurs de X pas pour parcourir Y mm

Il n'y a pas d'emblée un buffer, au moins au niveau du Raspberry ? Quand il collecte des données depuis internet, pour les envoyer sur /dev/machintruc , on est en mode fichier, les données sont mises à la queue-leu-leu (ok, "en FIFO", ça fait plus pro !) et lues quand l'Arduino a le temps (ou sous interruption ?)



 



Concernant l'idée de la communication bi-directionnelle, ça me semblerait contre-productif de se casser la tête pour implémenter un mécanisme de blocage de l'appli de dessin, qui reviendra à mettre en évidence un problème de latence, vis-à-vis des usagers de la démo... A choisir, je pense qu'il vaut franchement mieux réfléchir à la façon de mettre en place un buffer, s'il n'y en a pas déjà.



 



 

je viens de pousser le code sous github.



Je me suis permis de copier ton 'Read me.docx' dans un fichier texte, pour faciliter sa lecture en mode console.

Si j'ai bien compris, le protocole SPI fonctionne de toute façon en full-duplex, avec un maître et X esclaves. Sachant que c'est le maître qui fixe la fréquence de l'horloge qui va cadencer les échanges, et que le Pi n'a pas d'horloge interne, je suppose -quelqu'un vérifie ?- que c'est l'Arduino qui va être maître. Partant de là, c'est l'Arduino qui aura l'initiative des échanges : c'est à lui d'envoyer un bit sur MOSI (pour dire à l'esclave d'envoyer quelque-chose), puis en reçoit un sur MISO. Il faudrait vérifier que lorsque le buffer est plein, il n'envoie rien sur MOSI, et il ne devrait rien recevoir sur MISO. -> à vérifier quand même...