994 réponses à ce sujet

[R1D1]

Bon en fait Arobasseb m'a devancé

Pour être clair sur ce que je disais : le choix d'un langage ou l'autre dépend de la facilité d'implémentation d'une fonctionnalité. Si python offre une lib de communication super simple, ça peut valoir le coup de réflechir à l'utliser.
Mais dans ton cas, si tu veux rester avec C++, et surtout pour une fonctionnalité aussi basique que la communication série, pas besoin de python. Je passerai personnellement par l'USB, ce lien (https://www.monocili...sing-usb-and-c/) semble contenir toute l'info nécessaire.
Après, je ne suis pas très au point sur les protocoles de communication, donc c'est ce qui me semble le plus simple. La solution est facile à mettre en place: il faut juste un câble USB. À toi ensuite de définir quelles infos doivent transiter. Il est probablement judicieux de faire des calculs de base sur l'arduino pour simplifier le code côté raspberry (e.g. aggréger toutes les mesures de capteurs à un temps t donné et tout renvoyer à une fréquence paramétrable vers le Pi, faire les boucles d'asserv les plus basique sur l'arduino directement).
J'ai pas le temps de tester en pratique avant ce week-end je pense, mais je peux essayer ce lien (comm USB) d'ici dimanche.

[Oliver17]

Cool, le truc qui me chipotte sur le lien, c'est que le gars si j'ai bien compris alimente sont arduino nano via l'usb, ne serait il pas préférable d'alimenter mon arduino uno à part et utiliser l'usb pour la communication, du moins ça doit être possible, non ?? (question de noob) car la pi ne va pas pouvoir alimenter comme il faut l'arduino ?

 

Ok, donc maintenant à voir si j'ai bien compris...

 

"aggréger toutes les mesures de capteurs à un temps t donné et tout renvoyer à une fréquence paramétrable vers le Pi"

 

Donc là le but est de renvoyant toutes les infos de l'arduino en même temps à un certains temps t donné, c'est bien ça hein , ne peut on pas envoyer les infos en continue...

 

"faire les boucles d'asserv les plus basique sur l'arduino directement"

 

Là on parle bien genre, des capteurs de distances, l'arduino calcul tous ça et renvoi les infos à la pi qui lui par la suite fera des calculs plus poussé ??

 

Merci

[arobasseb]

Je pense qu'il faut voir l'arduino comme l'esclave qui s’occupe des taches d'entrées/sorties. Par exemple la raspberry pi (RPI)  demande les valeurs des capteurs à l'arduino, ensuite la RPI calcul les mouvements de cinématique inverse qui permette de réagir par rapport à la lecture des capteurs et ensuite la RPI envoie les commandes des actionneur à l'arduino qui elle de sont coté s'arrangera pour les respecter.

Du coup la RPI ne gère pas de PWM, convertion analogique/numerique ou autre, il fait juste du calcul et de la communication série ou l'interfaces  avec des périphériques complexes (camera, gamepad, ...) + la gestion réseau.

[Ulysse]

Un exemple de ce qui se fait : une unité centrale reliée à des périphériques (capteurs et actionneurs ). Chacun son rôle.

 

[arobasseb]

Un exemple de ce qui se fait : une unité centrale reliée à des périphériques (capteurs et actionneurs ). Chacun son rôle.

 

Architecture_03.png

 

Bon, bah avec un tel schéma on ne peut plus rivaliser :respect: 

[Amhnemus]

@Olivier17 si je raconte pas de connerie si tu branche ton Arduino en USB ton branchement pour alimenter ton Arduino avec les bornes VIN ne te sers à rien. L'arduino prendra d'abord le courant par l'USB

[Oliver17]

@ Arobasseb : Effectivement je le vois un peu de ta façon, après, est ce la bonne ?!

 

@ Ulysse : Bizzare ça me rappel un certains robot qui galope sur les plages

Le boitier gris, c'est ce qui dispatche ton courant et informations ??

 

@ Amhnemus : Hum, je ne sais plus ou j'ai lu ça, mais si des capteurs demande trop de jus, on risque pas de faire griller le bousin ?

Bon en même temps, mes capteurs ne devraient pas trop consommer si je ne dis pas de bêtises.

[gerardosamara]

@Oliver17 ,

 

Il  y a une librairie python "serial"  au niveau du RPI pour dialoguer en USB avec l'arduino

[arobasseb]

@Oliver17 ,

 

Il  y a une librairie python "serial"  au niveau du RPI pour dialoguer en USB avec l'arduino

 

Chut @gerardosamara tu as dit le mot qui fache @Olivier17  

[Oliver17]

       

 

LOL

[Oliver17]

Coucou les Maker's, alors avant de connecter l'Aduino à la Pi, j'ai d'abord voulu me refaire copain avec l'Arduino en testant l'écran OLED 128x64, le hic, mon écran ne fonctionne qu'avec la version 128x32 de la librairie Adafruit.

Pourtant c'est bien un 128x64, d'après le vendeur.

 

Avez vous une idée sur le problème ??

 

Merci

[arobasseb]

Quel est le problème exactement ? Le code ne compile pas, tu ne peux écrire que sur la moitié de l'écran ? Et quelle est la référence de l'écran ?

[Path]

Oui, il faut modifier le .h de la lib. Cest un define qui prend en compte ta résolution.

[Oliver17]

Alors dans l'ordre :

 

- le code compile (en testant l'exemple) qu'avec le mode 128x32 lorsque j'essaye avec l'exemple 128x64 ça me dit :

 

exit status 1

#error ("Height incorrect, please fix Adafruit_SSD1306.h!");

 

- Je suis branché sur le 3.3v, Grd, et SDA, SCL, donc pour l'instant ça ne fume pas c'est que c'est bon ^^ mais j'ai vu un gars avec une carte Nano qui se branche sur l'analogique en A4 et A5, je n'ose pas essayer.

 

PS : le fils de mon imprimante vient de péter d'un coup, bizarre, bref on s'en fout mais ça surprend

 

EDIT : ok Path, je vais essayer de trouver ça, c'est pas gagné

 

Ah, je ne peux pas ouvrir le .h , hum

Modifié par Oliver17, 18 octobre 2017 - 04:26 .

[Oliver17]

Hum, c'est une blague ? je fais la modification du .h, je remet tous ça dans le dossier librairies, je relance le programme, je l'envoi à la carte et j'ai ça :

 

Le croquis utilise 17822 octets (55%) de l'espace de stockage de programmes. Le maximum est de 32256 octets.
Les variables globales utilisent 1539 octets (75%) de mémoire dynamique, ce qui laisse 509 octets pour les variables locales. Le maximum est de 2048 octets.
La mémoire disponible faible, des problèmes de stabilité pourraient survenir.

[arobasseb]

Instinctivement je dirais que d'avoir modifier la constante de 32 à 64 il doit allouer plus de taille à certaines variables. Tu avais quelles valeurs avant en 32 ?

[Oliver17]

Alors là je ne sais pas, voilà ce que j'ai fais :

 

#define SSD1306_I2C_ADDRESS   0x3D  // 011110+SA0+RW - 0x3C or 0x3D    <----------ICI j'ai changé l'adresse comme indiqué.
// Address for 128x32 is 0x3C
// Address for 128x64 is 0x3D (default) or 0x3C (if SA0 is grounded)   

/*=========================================================================
    SSD1306 Displays
    -----------------------------------------------------------------------
    The driver is used in multiple displays (128x64, 128x32, etc.).
    Select the appropriate display below to create an appropriately
    sized framebuffer, etc.

    SSD1306_128_64  128x64 pixel display

    SSD1306_128_32  128x32 pixel display

    SSD1306_96_16

    -----------------------------------------------------------------------*/
#define SSD1306_128_64        // <----------ICI j'ai dé-commenté comme indiqué.
//   #define SSD1306_128_32
//   #define SSD1306_96_16
/*=========================================================================*/

[Oliver17]

Bon ben j'utilise une autre librairie pour tester : u8glib

 

https://bintray.com/.../u8glib/Arduino

 

J'aurais aimé utiliser celle d'adafruit qui a l'air plus complète mais ça ne fonctionne pas, par contre, à ce rythme la, la mémoire de la UNO va être vite bouffé dis donc.

Et il y a juste un écran avec deux pauvres lignes écrites.

 

Le croquis utilise 9938 octets (30%) de l'espace de stockage de programmes. Le maximum est de 32256 octets.
Les variables globales utilisent 274 octets (13%) de mémoire dynamique, ce qui laisse 1774 octets pour les variables locales. Le maximum est de 2048 octets.

 

Alors j'imagine si je dois brancher le drivers maestro, l'écran, et autres capteurs la carte va fumer.

 

[arobasseb]

Tu vas afficher quoi? Un simple écran 2*12 caractères ne suffirait pas? Sinon si tu manques de place il faudra que tu supprimes de la librairie tout ce que tu n'utilises pas.

[Oliver17]

Je pense surtout afficher des messages d'erreurs, puis d'autres trucs selon les capteurs, comme la position si besoin de la central inertielle, ou l'heure par exemple et plus...