Aller au contenu


Photo
- - - - -

Communication arduino vers micro-ordi en environnement bruité


6 réponses à ce sujet

#1 Sandro

Sandro

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 701 messages
  • Gender:Male

Posté 20 novembre 2020 - 05:37

Bonsoir,

J'ai un petit problème sur le robot du boulot : on a un micro-ordinateur muni d'un GPIO (Jetson Xavier AGX, c'est un peu comme une raspberry pi en beaucoup plus puissant), qui communique en I2C avec un arduino et (sur un autre bus I2C) avec un joystick.

 

Le problème est que les esclaves (arduino et joystick) sont assez loin du maitre (jetson), respectivement 1.5 et 2m. De surcroit, l'environnement est assez bruité (on a de gros moteurs DC dans le robot). Du coup, la communication I2C n'est pas très fiable :

 

1) Pour la communication avec le joystick, j'ai coté jetson des "crash" de l'I2C ("Resource temporarily unavailable"), mais si je redémarre le programme coté Jetson, il redémarre normalement. Je n'ai pas fais de tests plus en détail, pour l'instant j'ai juste fait un workarround qui fait que le temps de redémarrage ne pose pas de problème

 

2) Pour la communication entre la Jetson et l'arduino :

 

2.1) Initialement, aucune communication possible dès qu'on allumait les phares (bruit de 1V sur SDA et SCK) : résolu en rajoutant des condensateurs entre ground et +12V. Impossible de relancer le programme coté Jetson après un crash (crash immédiat).

 

2.2) Parfois l'Arduino tire SDA à 0V et ne relâche pas le bus : ça vient probablement d'un "bruit" dans le signal I2C qui fait qu'il ne respecte plus le standard. La librairie Wire de l'Arduino gérant très mal les erreurs se retrouve bloquée. Impossible de relancer le programme coté Jetson après un crash (crash immédiat). Un reset de l'Arduinopermet ensuite de relancer le programme coté Jetson

En implémentant un double whatchdog logiciel (basé sur timers) sur l'arduino (reset 10s après le boot si pas de signal I2C, reset 250ms après le dernier signal I2C reçu en l'abscence d'un nouveau signal), on arrive a récupérer d'une partie des erreurs, mais pas toujours.

 

2.3 Dans l'état actuel des choses, il arrives encore que la communication crash (plus rarement, peut être en moyenne après 10 minutes) lorsque le robot roule : redémarage coté Jeton toujours impossible("Resource temporarily unavailable"). La Jetson reçoit parfois des valeurs erronées (flip d'un bit (nb : vu que la valeur par défaut est 0, j'ai observé que des flip 0->1)).

Donc la communication n'est toujours pas stable, et il arrive encore que l'Arduino (je pense) bloque le bus et ne le libère pas (malgré le reset via jmp 0). Les valeurs éronnées ne sont pas trop graves en soit (il suffit d'ajouter une checksum).

 

 

 

 

 

Donc est-ce que vous avez une idée comment on peut facilement communiquer la Jetson avec l'Arduino (via I2C ou autrement) avec une distance de 1.5m en environnement plutôt bruité?

Pour le Joystick (lui même en I2C), vous avez une idée?

 

Merci d'avance

Sandro

 

PS : il y aurait bien la possibilité de connecter l'arduino en USB, mais d'après ce que m'a dit un ancien stagière (partit il y a 2 mois), on ne peut pas mettre 2 arduinos de même type sur le même hub USB (et on en a déjà un, et pas d'autre port USB disponible)



#2 R1D1

R1D1

    Modérateur et Membre passionné

  • Modérateur
  • PipPipPipPipPip
  • 1 210 messages
  • Gender:Male
  • Location:Autriche

Posté 20 novembre 2020 - 05:55

Est-ce qu'il n'est pas possible de blinder l'électronique ? De mes souvenirs de cours (houlà c'est loin), ça ressemble typiquement à un problème de CEM (compatibilité électromagnétique). De mémoire, il faut placer des éléments bloquants entre la source du bruit et les cartes/câbles, dans ton cas mettre les moteurs dans une boîte hermétique aux champs magnétiques/électromagnétiques.

 

Logiciellement, je ne suis pas sûr de ce qu'il est possible de faire, mais si tu blindes ; ça devrait bien réduire tes problèmes.


R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#3 Sandro

Sandro

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 701 messages
  • Gender:Male

Posté 20 novembre 2020 - 06:24

Bonsoir,

le problème c'est que c'est de longs câbles qu'il faudrait blinder. Et si on blinde des cables sur de grandes longueurs, on se retrouve avec une grosse capacité sur le bus, ce qui pose aussi des problèmes.

 

Après, je n'exclus pas une solution hardware (par exemple utilisation d'un autre protocole ou d'un convertisseur). J'ai d'ailleurs commandé deux circuits "d'extension I2C" pour tester, mais il y a j'espère mieux comme solution



#4 jpbbricole

jpbbricole

    Nouveau membre

  • Membres
  • 11 messages
  • Gender:Male
  • Location:CH1804 Corsier-Sur-Vevey
  • Interests:Informatique, électronique, Arduino, CNC (petite) ...

Posté 20 novembre 2020 - 08:22

Bonsoir Sandro

 

Est-ce-que un i2C bus extender comme le P82B715TD, ne rendrait pas le bus i2C plus "solide"?

 

Cordialement

jpbbricole

 


L'expérience est la seule chose qu'il ne faut acheter que d'occasion!


#5 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 931 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 21 novembre 2020 - 12:33

Bonsoir,

J'ai un petit problème sur le robot du boulot : on a un micro-ordinateur muni d'un GPIO (Jetson Xavier AGX, c'est un peu comme une raspberry pi en beaucoup plus puissant), qui communique en I2C avec un arduino et (sur un autre bus I2C) avec un joystick.

 

Le problème est que les esclaves (arduino et joystick) sont assez loin du maitre (jetson), respectivement 1.5 et 2m. De surcroit, l'environnement est assez bruité (on a de gros moteurs DC dans le robot). Du coup, la communication I2C n'est pas très fiable :

 

1) Pour la communication avec le joystick, j'ai coté jetson des "crash" de l'I2C ("Resource temporarily unavailable"), mais si je redémarre le programme coté Jetson, il redémarre normalement. Je n'ai pas fais de tests plus en détail, pour l'instant j'ai juste fait un workarround qui fait que le temps de redémarrage ne pose pas de problème

 

2) Pour la communication entre la Jetson et l'arduino :

 

2.1) Initialement, aucune communication possible dès qu'on allumait les phares (bruit de 1V sur SDA et SCK) : résolu en rajoutant des condensateurs entre ground et +12V. Impossible de relancer le programme coté Jetson après un crash (crash immédiat).

 

2.2) Parfois l'Arduino tire SDA à 0V et ne relâche pas le bus : ça vient probablement d'un "bruit" dans le signal I2C qui fait qu'il ne respecte plus le standard. La librairie Wire de l'Arduino gérant très mal les erreurs se retrouve bloquée. Impossible de relancer le programme coté Jetson après un crash (crash immédiat). Un reset de l'Arduinopermet ensuite de relancer le programme coté Jetson

En implémentant un double whatchdog logiciel (basé sur timers) sur l'arduino (reset 10s après le boot si pas de signal I2C, reset 250ms après le dernier signal I2C reçu en l'abscence d'un nouveau signal), on arrive a récupérer d'une partie des erreurs, mais pas toujours.

 

2.3 Dans l'état actuel des choses, il arrives encore que la communication crash (plus rarement, peut être en moyenne après 10 minutes) lorsque le robot roule : redémarage coté Jeton toujours impossible("Resource temporarily unavailable"). La Jetson reçoit parfois des valeurs erronées (flip d'un bit (nb : vu que la valeur par défaut est 0, j'ai observé que des flip 0->1)).

Donc la communication n'est toujours pas stable, et il arrive encore que l'Arduino (je pense) bloque le bus et ne le libère pas (malgré le reset via jmp 0). Les valeurs éronnées ne sont pas trop graves en soit (il suffit d'ajouter une checksum).

 

 

 

 

 

Donc est-ce que vous avez une idée comment on peut facilement communiquer la Jetson avec l'Arduino (via I2C ou autrement) avec une distance de 1.5m en environnement plutôt bruité?

Pour le Joystick (lui même en I2C), vous avez une idée?

 

Merci d'avance

Sandro

 

PS : il y aurait bien la possibilité de connecter l'arduino en USB, mais d'après ce que m'a dit un ancien stagière (partit il y a 2 mois), on ne peut pas mettre 2 arduinos de même type sur le même hub USB (et on en a déjà un, et pas d'autre port USB disponible)

 

 

Il est possible de mettre deux arduino sur un même hub usb ( pourquoi est ce que çe ne serait pas possible ?  ) par contre il y a une petite subtilité à mettre en oeuvre, l'ordinateur dois savoir qui est qui avant d'envoyer des info à chaque redémarrage ( car les port des arduino peuvent s'inverser, et il ne sera pas possible de savoir qui est qui juste en extrayant des info de la carte car se sont les même carte arduino ( d'où la remarque sur le "meme type " ) Mais il y a une astuce simple : tu implémentes la même commande sur le deux carte " Who are you ? "  et chacune devra répondre un ID différent. Une fois que tu aura reçu l'id tu sauras quel port est connecté à quel ID de carte jusqu'au prochain redémarrage ou branchement débranchement ...  

Ensuite en environnement bruité tu peux utiliser un bus RS485 ou du bus can ... 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 


#6 Sandro

Sandro

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 701 messages
  • Gender:Male

Posté 21 novembre 2020 - 12:18

@jpbbricole : c'est exactement ça que j'ai commandé pour l'instant (plus un autre plus complexe : https://www.digikey....1873-ND/935134)

 

@Mike :

- si effectivement le seul problème en branchant les 2 arduinos sur le même hub est qu'il y a un risque de permutation de leurs numéros de ports, alors ça reste en effet tout à fait gérable (même si c'est un peu pénible). Je penses que je vais regarder de ce coté (ça permet d'avoir un circuit bien plus simple que de rajouter des bus extenders aux deux extrémités).

- pour un bus RS485 ou can, j'y ai pensé, mais comment faire le pont? (ça doit pouvoir se faire en ajoutant des modules ad-hoc)



#7 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 931 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 21 novembre 2020 - 04:16

@Mike :

- pour un bus RS485 ou can, j'y ai pensé, mais comment faire le pont? (ça doit pouvoir se faire en ajoutant des modules ad-hoc)

 

En effet il suffit de rajouter les modules adhoc ... 
En général pour du RS485 ça se branche sur un UART pour du can en général tu as des modules SPI .  
Bref ça reste dans la même idée que l'I2C bus extendeur pour du long range ... 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 




Répondre à ce sujet



  


2 utilisateur(s) li(sen)t ce sujet

1 members, 1 guests, 0 anonymous users