Aller au contenu

Messages recommandés

Posté
  Le 19/06/2019 à 17:51, Fabrice Teissier a dit :

J'ai essayé la commande que tu m'as donné et j'ai eu ça comme réponse :

chmod: impossible d'accéder à '/dev/ttyACM0': Aucun fichier ou dossier de ce type

Voir davantage  

Ah !, alors débranche l'arduino, puis rebranche là, et fait la commande "dmesg" pour voir ou elle est installé dans le système.

Un exemple du résultat de la commande "dmesg" quand je branche l'arduino sur le port usb, chez moi elle est sur "ttyACM0", en vérité le chemin complet est /dev/ttyACM0" dans ce cas.

  Révéler le contenu masqué

 

Sinon tu as aussi la commande "lsusb", elle te diras pas ou est relié l'arduino, mais au moins si le système la reconnait.

  Révéler le contenu masqué

 

Yves.

 

Posté

@Alarcon yves la commande dmesg me donne ça concernât l'USB:

 

  Révéler le contenu masqué

 

Et me donne ça pour la commande "lsusb":

 

Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 

Posté (modifié)

Ah c'est sur que FBSD c'est pas la joie ;)

un petit lusb ...ne voit pas ton device ?

Dans ce cas la vbox ne doit pas avoir les bons addons dans ta fenêtre de ta VM les périphériques USB sont ils détectés et activés ?

Modifié par Raphael_OD
Posté

Apparement si, quand je lance la commande, j'ai ça:

nafa@NAFABox:~$ lsusb
Bus 001 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
nafa@NAFABox:~$ 
 

Et dans les settings usb de Vbox j'ai ça :

 

874608229_Capturedcran2019-06-2010_48_08.thumb.png.217d79f84cd16dac69981cbcc32a076a.png

Posté

Te restes a voir si les drivers FTDI en fonction de ta carte arduino ou clone ...sont bien présents le mieux c'est d'installer l'IDE complet pour Linux /arduino

Posté

J'ai enfin trouvé le problème ! Pfff...

 

En fait, cela n'avait rien à voir avec l'USB. J'avais juste fait une bêtise en voulant rendre mon code propre visuellement.

J'avais effacé deux lignes essentielles à la communication série dans la partie "void handleSerial()"

 

memset(str, 0, 20);

Serial.readBytesUntil('\n', str, 20);  

 

C'est pour cette raison que INDI ne pouvait plus communiquer avec le Flip flat.

 

En revanche, je n'arrive pas à régler le souci du "Time out". J'ai essayé la manip proposé par  @Cedric02700 mais cela ne change rien.

En fait le "time out" n'intervient pas à la connexion mais après les commandes d'ouverture et fermeture du capot.

Je pense que cela vient du fait que j'ai trois servos à commander les uns après les autres et que la séquence complète dure 10 secondes, sans doute trop long pour le drivers INDI.

 

707758072_Capturedcran2019-06-2111_50_41.thumb.png.e4ea00e6bc11de99577300b4693f9b25.png

 

J'ai essayé en doublant la vitesse des servos pour accélérer la séquence et là, j'ai un autre message : "Read Overflow"

 

166629739_Capturedcran2019-06-2111_59_16.thumb.png.667d4bf3954798d62509bc406ec69d36.png

 

Mystère...

 

A priori, cela ne gène en rien le bon fonctionnement mais j'aurais bien aimé trouver un truc pour supprimer ces erreurs.

 

En tout cas, merci à tous pour votre aide...

Posté

On avait eu ce problème au début du post

 

 

  Le 21/04/2019 à 01:51, olivier1986 a dit :

@gehelem @supaii @Cedric02700

 

Je viens de résoudre notre problème!! et ça marche du tonnerre! ça m'a travailé toute la journée ^^

Donc en fait je suis resté sur le message de Cédric02700 postulant l'implant d'un delai ... et magie c'était THE reponse!!! un délai dans la fonction void handleserial () juste avant le1er if, et ça a marché! bon biensur je n'ai pas testé cela en 1er et c'est pour cela qu'il est si tard! j'ai choisi après plusieurs essais la valeur de 100ms car:

- en dessous c'était instable avec SGP mais fonctionniel avec INDI

- au dessus on ressent la présence du delay et c'est dommage!!

 

En revanche, puisque pour le coup ce sont deux bonnes nouvelles et pas qu'une, c'est qu'en plus d'un driver indi qui fontionne au poil (essais avec le vrai matos ... un régal!!) et ba ça marche aussi avec SGP tester la aussi en vrai!!

ca devrait en faire plaisir à plus d'un!! héhé!!

 

Bon au dodo car il se fait tard maintenant, et voilà le code!! bonne nuit (bonjour??) tout le monde!!


 

  Révéler le contenu masqué

 

Voir davantage  

 

Posté

@Fabrice Teissier

Bonjour, à tout hasard, quand vous dites avoir essayé de mettre le delay juste avant la commande handleSerial(), avez vous essayé de modifier cette valeur?

j'avais mis 100ms mais on peut surement augmenter cette valeur.

le fait que INDI renvoie une erreur S000 time out c'est quand INDI n'arrive pas à connaitre le statu du flip flat.

en fait, INDI demande tout le temps à connaitre le status du flip flat.

les 100ms que j'avais mise laisser le temps à l'arduino de vérifier les caractères présents sur le port série.

si c'est trop court il n'a pas le temps de le lire et affiche un time out. Si vous mettez 10s à ouvrir ou fermé, cela n'influence pas le statu car normalement INDI doit indiquer que le flip flat est en mouvement, et je pense que c'est valable quelque soit le nombre de servo car il doit afficher " en mouvement" durant la fonction ouverture().

tant que le flipt flat n'est ni en position ouverte ni fermé alors il est en mouvement!! normal!! mais reste à savoir si INDi le voit.

Je vais regarder votre code car sur mon simulateur celui ci ne fonctionne pas 😕

 

Olivier

Posté

Bah... J'ai beau essayer toutes les valeurs de delay entre 50ms à 1s et rien n'y fait. 

Effectivement, il semblerait qu'INDI n'arrive pas à connaitre le statu du flip flat au bon moment.

Mais pour quelle raison ?

Posté

Deux remarques à propos d'indi :

- le handshake

Lorsque le driver Indi initialise la connection (lorsqu'il ouvre le port série), il envoie immédiatement un "handshake"

C'est une question blanche qui ne sert à rien, juste à s'assurer que la connection fonctionne.

ça ne poserait pas de problème si ces satanés arduino ne s'amusaient pas à envoyer un reset lorsque le port série s'ouvre :

le handshake arrive en plein reboot de l'arduino, et ça part aux fraises.

Le délai qui a été ajouté dans le code permet de contourner ça, j'avoue que je ne pige pas très bien pourquoi

J'ai remarqué  le même comportement avec AstroEQ + driver indi EQmod, et Moonlite + driver indi éponyme, c'est exactement la même limonade.

Et c'est aussi pour cette raison que j'utilise autant que possible des arduino à base d'atmega32u4 et suivants avec la communication USB intégrée

 

- le statut "not open/closed"

En toute rigueur, il faut gérer la période pendant laquelle le moteur bouge

Dans la routine qui s'occupe de fermer et ouvir, il faut ajouter ceci au début :

      motorStatus = RUNNING;    
      coverStatus = UNKNOWN;

Et ceci à la fin si c'est dans le sens ouverture :

      motorStatus = STOPPED;    
      coverStatus = OPEN;

Ou dans le sens fermeture :

      motorStatus = STOPPED;    
      coverStatus = CLOSED;

De cette façon, comme effectivement indi demande le statut toutes les secondes (polling), si la requête tombe pendant que le moteur est en mouvement la réponse est correcte

ça me parait important si la durée d'ouverture/fermeture dure un peu, genre qq secondes ou même moins.

Comme ça Indi attends patiemment que le machin atteigne la position voulue avant d'enclencher la suite (prise de vues)

 

 

Posté (modifié)

@gehelem Merci pour ces infos.

 

Concernant le handshake, j'ai résolu le problème avec mon nano en dessoudant un micro-condensateur sur sa carte.

 

J'ai essayé de placer les motorStatus et coverStatus là ou tu me dis de les placer dans mes routines d'ouverture et fermeture mais cela ne change rien. Mais j'ai toujours un time out en fin d'ouverture et de fermeture.

 

Voilà la dernière version du code:

  Révéler le contenu masqué

 

J'ai essayer des les placer dans la routine "void handelSerial()" mais là, je ne peux pas compiler le code. IDE me donne des erreurs. Bizard !

 

442929792_Capturedcran2019-06-2202_32_47.thumb.png.c0cf276e3ce06da6e6d48cc94ba0c08d.png

Modifié par Fabrice Teissier
Posté

@Fabrice Teissier l'erreur stray machin truc c'est parce que tu as fait un copier/coller du bout de code depuis ces pages web, tu as dû te ramasser des caractères spéciaux :

Essaie d'écrire directement sans copier/coller

Posté

@gehelem Encore merci !

 

Effectivement, je n'ai plus d'erreur en écrivant directement les commandes. Mais cela ne change toujours rien.

J'ai toujours ces time out.

 

Ce que je remarque, c'est qu'a aucun moment, les statuts du capot et moteur sont en UNKNOWN ou RUNNING dans la fenêtre de contrôle INDI.

Le moteur est toujours STOPPED et le capot soit OPEN ou CLOSED.

 

Est-ce normal ?

Posté (modifié)

Bonjour, il faut comprendre le fonctionnement d'indi et de la liaison série.

Pour la liaison série, le 100ms est un délais d'attente pour éviter la surcharge et la perte de communication, mais se délais peut très bien descendre en dessous de cette valeurs, dépend de la vitesse d'échange entre les deux appareils, mais ce n'est pas forcement là ton problème.

 

Le plus gros problème, c'est que tu utilise la fonction delay(), or la fonction delay(), bloque l'arduino et la communication série, pendant toute la duré que tu lui indique, et dans cas évidement "Indi" râle car pendant se temps tu ne lui répond pas !

 

Pour éviter la fonction delay() soit tu utilise la fonction millis() qui compte le nombre de milliseconde depuis le début du programme, soit tu utilise la lib MsTimer2 qui permet de créer un timer.

Exemple de 3 codes arduino pour faire clignoter une led toutes les 1 secondes.

 

Code avec la fonction delay(1000), mais qui en fait bloque l'arduino quasiment tous le temps.

  Révéler le contenu masqué

 

Code avec la fonction millis(), là on ne fait aucun blocage.

  Révéler le contenu masqué

 

Code avec la lib MsTimer2, idem aucun blocage

  Révéler le contenu masqué

 

Bref, il faut éviter la fonction delay(), quand on utilise l'arduino avec une communication série, c'est toujours source de problème, après il faut bien lire la doc avec la lib MsTimer2, car elle utilise un timer interne qui peut être utilisé par d'autre lib, à vérifier pour éviter des conflits, évidement la fonction appelée par MsTimer2, doit être une fonction non bloquante et son temps d’exécution inférieur au temps de répétition.

 

Yves.

 

Modifié par Alarcon yves
  • Merci / Quelle qualité! 1
Posté (modifié)

@Alarcon yves heu... Merci pour cette leçon de délais mais je croit que ça commence à dépasser mes compétences en programmation 😱

Mon « problème » effectivement, c’est que j’en ai mis partout et je ne vois pas comment arriver à les remplacer tous avec ce que tu proposes 😳

je croyais l’arduino monotache, c’est à dire que lorsqu’il joue une routine void, il ne fait rien d’autre avant la fin de son exécution et qu’ensuite seulement il revient dans loop pour continuer sa boucle de programme. Donc peu importe les délais dans les routines void. Je veux dire par là que je pensais que les délais dans un void n’affectaient pas les autres void. 

Donc ma question : dois je réécrire tous mes délais de chaque routine avec millis() ou avec la lib. MsTimer2 ? Et dans ce cas, c’est mort. Je ne m’en sens pas capable et du coup, tant pis, il y aura des Time Out.

Ou bien dois je seulement modifier les délais dans la routine void handelSerial()  ? Un peu plus accessible pour moi 😅

Modifié par Fabrice Teissier
Posté

Bonjour, oui l'arduino est monotâche, mais possède un système d'interruption, en clair dans certaine situation quand une interruption est levé, le programme en coure est stoppé et on lance une sous-fonction, quand celle-ci se termine, le programme reprend à l'endroit ou il c'était arrêté, bien sur il ne faut pas que la routine d'interruption dure trois plombes.

Laisse moi une semaine que je regarde de plus prés ton code.

Yves.

 

Posté (modifié)

Voilà la dernière version du code documenté là ou je suis sur de ce qui se passe.

 

  Révéler le contenu masqué

 

Modifié par Fabrice Teissier
Posté

Pourquoi ????

 

J arrive à connecter l arduino uno à SGP mais pas l arduino micro.

Je télécharge le même code dans l un et dans l autre. Ils marchent parfaitement avec l Ide de l arduino et le moniteur série.

J ai essayé également avec le code du github orignal:

Avec le UNO, SGP se connecte et communique

Avec le micro, SGP tourne en rond communique à peine puis annoncé un échec de connexion "time out".

 

Y a un truc particulier à faire ? Une formule

magique ? Une incantation ?

 

Bref si vous avez une idée ?

Posté

 

  Le 25/06/2019 à 08:49, Fabrice Teissier a dit :

@ursus Ça ne viendrait pas du fameux petit délai à mettre devant le 1er « if » de la routine void handelserial ?

Voir le lien proposé par cedric02700 en haut de cette page. 

Voir davantage  

 

Je regarderais. Le micro serait plus rapide que le Uno?

Posté
  Le 25/06/2019 à 08:49, Fabrice Teissier a dit :

@ursus Ça ne viendrait pas du fameux petit délai à mettre devant le 1er « if » de la routine void handelserial ?

Voir le lien proposé par cedric02700 en haut de cette page. 

Voir davantage  

 

Bon, je viens d'essayer plusieurs valeurs de delay avant le if, toujours le mème résultat.

 

Je suis en train d'éplucher cela https://forum.arduino.cc/index.php?topic=396450.0

Je comprends mieux les commandes d'Alnitak et il me semble que le code ne profite pas de la structure des commandes --> cf exemple 5

Rejoignez la conversation !

Vous pouvez répondre maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous pour poster avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.