320 réponses à ce sujet

[R1D1]

...

Ensuite pour les fonctions de la cartes d'alim:

Voilà ce que je propose :

Prise pour batterie couplée à un bouton qui permet de tout couper.
Série de prises 5V 3A pour alimanter la pi + différents truc. ( deuxième pi, ou pont en H ... )
Un prise permettant de relier la batterie en passant par un relais et qui peut être couper via un second interrupteur sans éteindre la Pi. ( prise sur laquelle on peut brancher nos moteurs et autres.)
un voyant qui est orange si on a Allumer l'inter général mais coupé l'interrupteur lié au relais, vert quand les deux interrupteurs sont bons et rouge si on a plus de 5V au niveau des prise 5V 3A ( tout va mal si on est dans ce cas là )

Mon expérience pratique en électronique étant ce qu'elle est, je vais plutôt raisonner au niveau fonctionnalité. Je pense qu'il faut les choses suivantes :
- Arrêt d'urgence qui coupe l'alimentation de puissance (moteur, servos) SANS couper l'alim de la Pi (éteindre de force un ordi, ce n'est jamais une bonne idée).
- Interrupteur d'alimentation qui coupe le lien batteries / reste du système.
- Un ensemble de ports supplémentaires 5V 3A, comme tu dis, configurables par jumpers (off de base, possibilité d'abaisser à 3.3V). Ou plutôt, un ensemble de ports avec les caractéristiques précitées. Brancher la RaspBerry ou une autre carte devient transparent.
- Un voyant qui indique l'état des interrupteurs (vert : tout est ON, orange : alim générale ON, moteurs OFF). Le cas survoltage que tu décris doit à mon avis être géré directement par la carte en coupant l'alimentation de ces prises (et en faisant effectivment clignoter une led rouge par exemple).
- Monitoring du passage de l'état "en charge sur le secteur" à l'état "en utilisation autonome" ou "en utilisation à partir du secteur" (pour pouvoir travailler juste sur les capteurs sans déplacmeent du robot et économiser la batterie.
- Récupération par la RaspBerry du niveau de batterie.

Cette liste de fonctions n'est pas forcément réalisable dans le budget que l'on s'impose, mais je pense que ça permettra de couvrir la majorité des besoins. J'ai repris tes propositions en essayant de les reformuler, et j'ai l'impression qu'on est relativement d'accord.

Je pense en général que ça serait pas mal d'interagir de manière plus directe pour discuter tous ensemble. que pensez-vous de la création d'un petit canal IRC où l'on pourrait de temps en temps faire un point, poser des questions, etc ?

[Melmet]

Bon je suis OK avec ce que vous avez dit... MAIS :

Quand est il de l'alim 3.3V? Un jour faut alimenter les cartes en 3.3v et plus en 5V et aujourd’hui c'est le contraire. Faut ce mettre d'accord la.
J'ai mis des PDF avec des alim séparer sur chaque cartes en 3.3V avec liaisons en I2C et je ne sais toujours pas si ca vous va.(ou alors j'ai oublier de les mettre je sais plus lol)
Mon idée de dépars reste basic, mais peut servir.
Mon composant pour avoir un +3.3V 1A et le LF33CV dispo chez farnel.
Donc ma question est : que pensez vous du LF33CV?

Si ce composant vous satisfait, je pense qu'il faut l'incorporer sur la carte d'alim général pour économiser de la place sur les autres.

Pour ce qui est de l'assemblage des carte faut regarder celles qui produisent plus de chaleur et bien les ventiler ou les séparer des autres.

bon je vais aller vérifier si j'ai mis les pdf de mes nouvelles cartes et faire un schéma fonctionnel , sur ce bonne soirée />/>

[Mike118]

Bon je suis OK avec ce que vous avez dit... MAIS :

Quand est il de l'alim 3.3V? Un jour faut alimenter les cartes en 3.3v et plus en 5V et aujourd’hui c'est le contraire. Faut ce mettre d'accord la.
J'ai mis des PDF avec des alim séparer sur chaque cartes en 3.3V avec liaisons en I2C et je ne sais toujours pas si ca vous va.(ou alors j'ai oublier de les mettre je sais plus lol)
Mon idée de dépars reste basic, mais peut servir.
Mon composant pour avoir un +3.3V 1A et le LF33CV dispo chez farnel.
Donc ma question est : que pensez vous du LF33CV?

Si ce composant vous satisfait, je pense qu'il faut l'incorporer sur la carte d'alim général pour économiser de la place sur les autres.

Pour ce qui est de l'assemblage des carte faut regarder celles qui produisent plus de chaleur et bien les ventiler ou les séparer des autres.

bon je vais aller vérifier si j'ai mis les pdf de mes nouvelles cartes et faire un schéma fonctionnel , sur ce bonne soirée />/>/>

Je suis d'accord sur le fait de rajouter une sortie 3.3V sur la carte d'alim, pas de problèmes par contre la question quelle capacité max en mA ? 1000 perso ça me va.
Par contre le LF33CV à voir, j'ai peut être une référence en CMS qui ferait mieux serait moins cher et prendrait moins de place...

Ensuite ce 3.3V doit être dispo tout le temps ou on doit pouvoir le couper ? Si il se coupe, il se coupe en même temps que la partie passant par le relais ?

Pour en revenir aux fonctions de la carte :

• Prendre en entrée une tension comprise entre 6V et 50V;
• Convertir la tension d'entré sur une sortie 5V 3A? ( qui permet d'alimenter la raspberry et autre, ce 5V sera présent dès la mise sous tensions de la carte )
• être mis sous tension par un bouton
• mettre à disposition une sortie de même tension que la batterie , protégé avec fusible, coupable par un bouton d'arret d'urgence, 10A ?
• Un voyant bicolore vert rouge indiquant : tout est sous tension : vert; 5V activé mais bouton d'urgence activé : orange; problème : rouge;

ce qui reprend en gros :
- Arrêt d'urgence qui coupe l'alimentation de puissance (moteur, servos) SANS couper l'alim de la Pi (éteindre de force un ordi, ce n'est jamais une bonne idée).
- Interrupteur d'alimentation qui coupe le lien batteries / reste du système.
- Un voyant qui indique l'état des interrupteurs (vert : tout est ON, orange : alim générale ON, moteurs OFF). Le cas survoltage que tu décris doit à mon avis être géré directement par la carte en coupant l'alimentation de ces prises (et en faisant effectivment clignoter une led rouge ) => par contre je suis pour le rouge mais sans clignotement.


En revanche ces point là :

- Monitoring du passage de l'état "en charge sur le secteur" à l'état "en utilisation autonome" ou "en utilisation à partir du secteur" (pour pouvoir travailler juste sur les capteurs sans déplacmeent du robot et économiser la batterie.

là j'ai pas prévu sur la carte un module de charge... par contre plus tard je pense faire une carte faite pour des batteries comprises entre 3.7V et 7v avec un charueur intégré...
Idem j'ai rien mis pour qu'on puisse travailler sur le secteur... à voir avec tout le monde si c'est vraiment utile, et si oui je vais me pencher dessus.

- Récupération par la RaspBerry du niveau de batterie.

ça ça peut s'ajouter par contre il faut deux trois détails en plus.

Choses que je peux proposer : on fait en sorte d'avoir un point qui permet d'afficher le niveau de la batterie de manière proportionnelle en continu( type pont diviseur avec haute résistance )

Soit on fait en sorte que la prise de mesure soit disponible que sur commande de manière à ne pas consommer tout le temps contrairement à la solution précédente mais du coup ça prend un GPIO ...

Par contre si on veut que la raspberry pi le lise il faudrait ajouter sur une autre carte les convertisseurs analogique numérique extérieurement à la carte d'alim.

Sinon on peu aussi ajouter le convertisseur sur cette carte et imposer qu'une des port analogique et dédié à la surveillance du niveau de la batterie.

Sinon on peut aussi ajouter un afficheur de type bar graphe indiquant le niveau de charge ... ( et le communiquer ou non en même temps à la pi ) que cela soit en continu ou bien sur demande. ( rien que sur cette dernière phrase il y a plus de 5 possibilités évoquées x) )

Après on peut discuter de l'utilité par rapport au coût... la première solution étant la plus économique ...

Donc si vous vous mettez d'accord sur un des choix moi je veux bien travailler dessus aussi.

Bref mettons nous d'accord sur les fonctions ensuite la carte se fait bien !

[Melmet]

Bon, ok.
Si tu peut m'assurer que l'ont a pas besoin du 3.3V autant sans passer, non ?

Si tu as d'autre composant pour le 3.3V je suis preneur.

pour la reste je suis d'accord avec toi, mais faut pas oublier que le robot doit être a bas coûts et modulable en fonction des besoins.
Je pense qu'il vaut mieux partir sur un début simple et après faire des cartes un peut plus complexe et plus chers dans le même objectif de la modularité ou l'ont peut changer de cartes sans tout démonter.

bon surveille la dropbox j'ai mis des trucs dedans.

[Mike118]

Bon, ok.
Si tu peut m'assurer que l'ont a pas besoin du 3.3V autant sans passer, non ?

Si tu as d'autre composant pour le 3.3V je suis preneur. />

pour la reste je suis d'accord avec toi, mais faut pas oublier que le robot doit être a bas coûts et modulable en fonction des besoins.
Je pense qu'il vaut mieux partir sur un début simple et après faire des cartes un peut plus complexe et plus chers dans le même objectif de la modularité ou l'ont peut changer de cartes sans tout démonter.

bon surveille la dropbox j'ai mis des trucs dedans.

Le composant que j'avais en tête était le LT1764 ... par contre il coûte un peu trop cher après réflexion... et puis mis a par le fait qu'il peut faire passer 3A il est pas nécessairement beaucoup plus intéressant ...

EN tout cas je ne garantis pas qu'on a pas besoin de régulateur 3.3V ... Mais je dis juste que la communication I2C entre pic en 5V et rpi en 3.3V ça marche ...

Ensuite il est clair qu'il va falloir faire attention au budget ... Combien maxi pour la carte d'alim ? Indiquez moi un prix. De mon côté je vais faire un " devis " pour la carte d'alim avec les fonction que j'ai donné et donner la liste des composants. On va voir si on tranche dans le lard ou si on peu ajouter des fonctions.

à bientôt !

[jpoilux]

Après de nombreux tests et de longues heures passées à travailler sur une carte additionnel pour le rpi, il s'avère qu'un level shifter est nécessaire pour la communication en i2c entre les composants et le raspberry.
Le niveau des signaux étant de 5v pour par exemple un MCP23017 et de 3,3v pour le rpi, de nombreuses données ne transitent pas correctement. Cela entraine des erreurs de communications.
Ce phénomène est variable en fonction de la charge du processeur, car il génère pas mal de parasites.

[Mike118]

Après de nombreux tests et de longues heures passées à travailler sur une carte additionnel pour le rpi, il s'avère qu'un level shifter est nécessaire pour la communication en i2c entre les composants et le raspberry.
Le niveau des signaux étant de 5v pour par exemple un MCP23017 et de 3,3v pour le rpi, de nombreuses données ne transitent pas correctement. Cela entraine des erreurs de communications.
Ce phénomène est variable en fonction de la charge du processeur, car il génère pas mal de parasites.

Salut, j'utilise le mcp23017 et je n'ai pas observé ce problème peux tu donner plus de détails sur les conditions que tu avais pour l'observer? Car perso le nivo 3.3V de la pi est toujour bien interprété comme un 1 logique au niveau du mcp quand ce dernier est alimenté à 5V ... J'ai fais les test avec le 5V provenant de la pi mais je ferais le test avec un 5V prevenant d'une autre source si besoin!

à bientôt !

[Melmet]

Salut, permet moi de poser une question ou deux:
-qu'appelle tu un level shifter?
-Cela pourrait-il endommager la R-pi?
-Peut t'on interfacer cela avec un circuit genre 74HC244?

Désoler de poser peut être des questions aussi bête, mais faut que je me foute a la sauce!!!


@mike: t'en es ou dans tes recherches?

[jpoilux]

Un level shifter, ca ressemble à ça:
http://fr.hobbytronics.co.uk/raspberry-pi/logic-level-i2c
Et fonctionne comme ceci:
http://husstechlabs.com/support/tutorials/bi-directional-level-shifter/

Ça permet d'adapter/convertir le niveau des signaux, 3,3v coté i2c rpi, et 5v coté i2c mcp.
Sur la plupart des projets n'utilisant qu'un seul module i2c, il est vrai que c'est pas forcément nécessaire.
Pas vraiment de risque pour le rpi si l'i2c et à 5v.
Lors des essais sur une platine de test, je n'avais pas non plus de problème.

Cependant, pour ma carte final, j'ai plusieurs modules en i2c:
- 1 mcp 23017 en i2c, 16 inputs/outputs
- 1 convertisseur analogique vers numerique (ADC) en i2c, 10 inputs (-1 qui est dédié au niveau de la batterie)
- 1 générateur de pwm pour servo moteur en i2c, 12 outputs
- 1 connecteur additionnel pour un lcd (en i2c aussi)
- 1 ampli audio

La carte est alimenté par une PSU stepdown qui injecte également le 5V/1A par le gpio pour alimenter le rpi.
Ma carte est en stackable juste au dessus du rpi, dont le processeur génère pas mal de parasite.

Du coup, avec tout ces modules en fonctionnement (4 en i2c), le flux de donnée par l'i2c, les parasites moteurs lorsque le robot se déplace...
Ba, sans le level shifter, l'i2c n'est pas stable et fait des erreurs de communication.
Car 5v mélangé à la CEM (contrainte electro magnétique)... le rpi avec sont 3,3v ne voit plus tout et se retrouve comme ébloui par moment.

Voici ma fameuse carte avec level shifter:

Voila pour mon retour d'expérience.

[ilels]

Bonjour,

je suis interessé moi aussi! Ou en est votre collaboration ?

Pour ma part, je ne pourrai pas aider coté meca, je pourrai eventuellement donner des avis coté electronique, par contre coté prog, pas de problème, c'est mon metier.

Je suis passionné de robotique

Comment vous rejoindre ?

A++

[Melmet]

Bonjour,

je suis interessé moi aussi! Ou en est votre collaboration ?

Pour ma part, je ne pourrai pas aider coté meca, je pourrai eventuellement donner des avis coté electronique, par contre coté prog, pas de problème, c'est mon metier.

Je suis passionné de robotique

Comment vous rejoindre ?

A++

Welcome, ça va peut être avancer! Merci de ta participation.

[Mike118]

Bonjour,

je suis interessé moi aussi! Ou en est votre collaboration ?

Pour ma part, je ne pourrai pas aider coté meca, je pourrai eventuellement donner des avis coté electronique, par contre coté prog, pas de problème, c'est mon metier.

Je suis passionné de robotique

Comment vous rejoindre ?

A++

Salut,

En fait pour le moment la seule chose qu'on a vraiment c'est un dossier drop box, si tu me donne en mp ton adresse mail je t'envois l'invitation pour accéder à la drop box et aux fichiers qu'elle contient.

Welcome, ça va peut être avancer! Merci de ta participation.

Salut, je suis toujours le forum moi aussi et j'ai toujours envie de mener à bien ce projet =) par contre il est vrai que j'ai pas mal de boulot ces temps ci ! =/ En tout cas même si j'ai du boulot je suis toujours là toujours motivé !

En tout cas perso ce que j'ai pour le moment c'est une carte d'alim proto qui se met sur la pi... mais qui est trop cher à mon gout en terme de composant pour notre projet... De plus la carte que j'ai faite se met au dessus de la pi et je me disais qu'il serait peut être plus judicieux de la mettre en dessous de la pi et du coup en profiter pour utiliser que les connecteurs qui sont censés se mettre sous la pi en faisant la carte stackable. Je voulais savoir ce que vous en pensiez.

Ensuite je cherche un système pour l'odométrie du robot. Si on fait un robot qui est pour de l'intérieur je me vois bien utiliser des souris d'ordinateur. Qu'en pensez vous ? Pourriez vous trouver des souris d'ordinateur assez petite ? Moi je pense pouvoir développer un truc utilisable pour les souris ... à voir... D'ailleurs on fait un robot de quelle taille? Qui ressemble à quoi ? Côté info on peut essayer de programmer des truc sympas niveau synthèse vocale ou analyse d'image, tout est envisageable !

En fait je pourrais avancer d'avantage tout seul ( malgré le boulot que j'ai) si je le voulais mais le but du projet est selon moi de vraiment faire quelque chose de collectif... Genre quelqu'un qui donne des dimensions, un autre qui fait une modélisation, un autre qui choisis les moteurs qui vont bien et ainsi de suite ... Perso je veux bien m'assigner plus d'une tâche comme décrite au dessus mais ça ne m'intéresse pas de le faire tout seul car c'est pas le but initiale...

En tout cas ce projet est ouvert à tout le monde !

[Mike118]

Bon moi je fais un retour d'expérience sur l'usage des souris optique pour l'odométrie ...
Pour l'instant c'est pas glorieux du tout... En gros j'ai acheté des petites souris à 2euros30 sur ebay, je met les deux souris sur la pi et j'utilise un petit programme en C++ qui me repère la position en X et en Y des deux pointeurs. Le but étant de fixer les souris sous le robot et ainsi d'en déduire la position et l'orientation du robot.

Récupérer les coordonnées des deux souris n'est pas un problème ... Il y a juste à gérer le moment où la souris sort de l'écran... ( en gros j'incrémente ou décrémente une variable sortie et je remet le pointeur au milieu) cependant les souris optiques ne sont tout simplement pas précise ... Je m'explique : J'initialise la position de mes poiteurs à (0,0) je déplace les souris et les remet exactement à la même place ( via des marques ) et la position final n'est jamais ( 0,0 ) ... sur des déplacement de quelques centimètre ( environ 10 ) j'ai des écart de parfois + 1cm et d'autre fois -1cm ...

Je crois que le soucis est d'origine au niveau du capteur des souris ... En y réfléchissant tout ceci parrait logique ... car une souris n'est pas faite pour mesurer une position mais plutôt un déplacement, sa précision n'est pas très importante car en fait on regarde le pointeur et on déplace notre souris pour que le pointeur aille au bonne endroit... et c'est pas la souris qu'on déplace à un endroit précis pour que le pointeur se retrouve toujours à un endroit donné...

Du coup si quelqu'un a des avis ou suggestion je suis prenneur ! De mon côté si cela ne donne rien je vais me retourner vers de l'odométrie plus classique... ( tant qu'à faire je vais voir pour utiliser les roulettes des souris que j'ai acheté ! x) )

[Leon]

Mike, est-ce que tu as essayé de "régler" la souris? Tous les OS, et toutes les souris ont un mode de fonctionnement par défaut qui amplifie les mouvements rapides par rapport aux mouvement lents. C'est fait pour aider l'ergonomie, et ça nous fait chier.
Il faut trouver dans ton OS les réglages de souris, et régler le facteur d'amplification à "pas d'amplification".

Leon.

[Mike118]

Je ne savais pas cela ! Merci du conseil je vais essayer de voir de ce côté là si je peux trouver quelque chose... (Mon Os c'est raspbian sur la Pi )
bonne journée à toi et à bientôt =) .

[Mike118]

Mike, est-ce que tu as essayé de "régler" la souris? Tous les OS, et toutes les souris ont un mode de fonctionnement par défaut qui amplifie les mouvements rapides par rapport aux mouvement lents. C'est fait pour aider l'ergonomie, et ça nous fait chier.
Il faut trouver dans ton OS les réglages de souris, et régler le facteur d'amplification à "pas d'amplification".

Leon.

Bon j'ai cherché de ce côté. Je nais rien trouvé du côté des OS autre que le réglage de la sensibilité qui n'a pas améliorer la chose. Cependant en faisant quelque recherches approfondies, j'ai trouvé que le composant des capteurs de souris optique actuels contiennent à la fois la partie capteur optique et la partie traitement, qui justement par défaut amplifie les mouvements rapides par rapport aux mouvement lents...
Par contre sur les souris optique plus ancienne cela se faisait en deux composants séparé !

Du coup je suis partie à la recherche de souris optique antique et je suis tombé sur une souris avec les deux composants séparés. Maintenant je fais mes tests en me branchant sur le premier composant, avant traitement de l'info.

Les tests semble déjà un peu plus concluant : pour l'instant sur 20 cm de déplacement j'ai une erreur de 2 mm ... Du coup je continue de ce côté ...

[Wmickael]

Bonsoir, je vois que tu essayes de faire de l'odométrie avec un capteur optique de souris, mais est ce que cela n'imposera pas une certaine distance (très faible) entre le capteur et le sol? Vu comme ça, ça semble être un inconvénient important

Bon je n'ai pas encore lu tout ce que vous avez mis, mais peut être qu'un accéléromètre pourrait être une bonne solution (après il faut voir pour la précision, je n'ai pas eu l'occasion de tester)

Sinon wii pour l'odométrie classique, ce qui n'est pas terrible c'est le glissement sans roulement (pour ca que t'as du laisser tomber)

[Mike118]

Oui le fait d'utiliser un capteur optique comporte deux inconvénients :

• Le fait de devoir être placé précisément entre 0.5 et 2mm au dessus du sol,
• Le fait que la surface sur laquelle le robot se déplace doit être adaptée

Pour moi la deuxième contrainte étant de loin la pire ...

Cependant en contre partie la techno semble pouvoir faire bénéficier de deux avantages :

• Si les deux première contraintes sont respectées, plus de problème de glissement!
• Pas de direction privilégié => possibilité pour les robots omnidirectionnels...

Après reste à voir la précision de l'ensemble ...

[transistance]

Je vais peut être dire une grosse bêtise et je devrais sans doute m'en abstenir mais je tente quand même :

Alors j'ai aucune véritable connaissance en optique mais il y aurait pas moyen d'augmenter la distance sol <> capteur en couplant celui-ci avec un système optique (une simple loupe) ?

En tout cas si il y a des chances que ça marche ça vaut certainement le coup d'essayer (même si on ne gagnait "que" 5mm).

[Wmickael]

Honnêtement je pense que c'est difficile d'augmenter la distance sol-capteur à cause des perturbations extérieures (lumière ambiante notamment) mais bon c'est de l'optique aussi, donc il doit y avoir des questions d'angles, donc finalement si l'emetteur et le récepteur sont dans le "même composant" ca va être galère

Après faut voir comment ça fonctionne (ce que j'ai dit ne sont que des hypothèses qui me semblent cohérentes)

Sinon, pourquoi ne pas envisager l'utilisation d'un accéléromètre?