Aller au contenu


Photo
* * * * - 4 note(s)

Un robot collectif, le robot des robot-makers


  • Veuillez vous connecter pour répondre
320 réponses à ce sujet

Sondage : Un robot collectif, le robot des robot-makers (51 membre(s) ont voté)

Qu'en pensez vous?

  1. Cela ne m'intéresse pas et je ne participerais pas ! (2 vote(s) [3.92%] - Voir)

    Pourcentage des votes : 3.92%

  2. Cela m'intéresse mais je ne participerais pas ! (20 vote(s) [39.22%] - Voir)

    Pourcentage des votes : 39.22%

  3. Cela m'intéresse et je suis prêt à participer ! (29 vote(s) [56.86%] - Voir)

    Pourcentage des votes : 56.86%

Vote Les invités ne peuvent pas voter

#101 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 19 avril 2013 - 12:09

Par contre si c'est pour des batterie 2 cellules et plus, acheter un chargeur externe devient plus rentable !

Plus rentable, je ne pense pas. Plus secure, sûrement (si tu te foire dans ton chargeur, ta batterie peut exploser...)

Ensuite, quand ont dit qu'il faut pouvoir recharger une Lipo via un connecteur, faudrait déjà connaitre le mode de recharge de la batterie Lipo. Car je suppose que pour des batteries comme celles ci, il faut une type de chargement particulier?


En gros, pour une cellule :
Deux contraintes : Ta cellule ne peux pas descendre en dessous de 3V (3.1V pour avoir une marge de sécurité) et ne peux pas être chargé au dessus de 4.2V
Si ces contraintes ne sont pas respectés, la batterie est morte.
Donc une 2S, c'est deux cellules en série, donc 6V à la décharge et 8.4V en charge complète.

Une caractéristique importante à noter (pour la charge d'une LiPo), c'est le nombre d'ampère heure.
Une batterie de 1200mAh pourra être chargé avec un courant max de 1.2A (on peux faire moins pour plus de sécurité).
Donc une LiPo sera chargé au mieux en 1h !

La charge à proprement parlé se déroule en 2 phases :
- Une phase de charge à courant constant si la tension de la cellule est inférieure à 4.2V
- Une phase de charge à tension constante si la tension de la cellule vaut 4.2V

Donc on charge d'abord avec un courant constant. La tension monte progressivement jusque 4.2V
Une fois à 4.2V, on reste bloqué à cette tension. Le courant de charge décroit alors progressivement.
Lorsque la batterie à une tension de 4.2V et un courant proche de 0, la cellule est chargée.

Pour une cellule, pas de soucis.
Pour charger une batterie à plusieurs cellules, il faut respecter ces règles pour chacune des cellules.
Si on veut tout charger en même temps, il faut alors répartir la charge sur les différentes cellules en fonction du niveau de charge de chacune des cellules (qui ne se chargent pas forcement à la même vitesse).
Il y a deux façon de faire, mais selon moi la plus économique, c'est d'appliquer une tension au bornes de la batterie globale et d'avoir un circuit sur chaque cellule qui sert à transférer la puissance d'une cellule à l'autre en fonction du niveau de charge de la cellule.

Un truc de ce genre là : http://electrofly.free.fr/articles.php?lng=fr&pg=61
Mais il y a peut-être moyen de trouver un moyen de virer la zener programmable...

La seconde solution, c'est de paralléliser les chargeurs 1S, mais c'est plus coûteux et plus complexe car on doit réaliser une alim à masse flottante (la masse de chaque alim serait la borne moins d'une cellule)


Voila en gros comment ça marche.
Il faut faire aussi attention à la décharge. Si on utilise une LiPo, il faut s'assurer que la carte d'alim possède une petite sécurité qui vérifie qu'AUCUNE des cellules passe sous la barre des 3V.


Voilà quelques liens pour ceux qui veulent creuser un peu plus :

Réalisation d'un chargeur avec la méthode 2 (pas vraiment réalisable dans notre cas) : http://home.nordnet.fr/~fthobois/accus_lipos.htm
Réalisation d'un chargeur 1S (à analyser) : http://www.shdesigns.org/lionchg.html
Exemple de chargeur 3S avec la première méthode : on a bien un seul circuit de charge, plus un petit circuit par cellule pour répartir la charge entre les cellules : http://www.coolcircuit.com/project/lipo_charger/charger_circuit.jpg ; http://www.coolcircuit.com/project/lipo_charger/lipo_charger.html
Petit tuto sur les LiPo : http://brushlessmania.forumpro.fr/t3664-tuto-quel-accus-lipo-choisir

Voilà. Il ne reste plus qu'a trouvé un moyen de virer la zener programmable ^^
J'ai réfléchit à la méthode du µC qui pilote la charge, mais ce n'est pas assez précis (plus on augmente le nombre de cellule, moins ça devient précis)

Mon site internet : http://ferdinandpiette.com/


#102 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 977 messages
  • Gender:Male
  • Location:Anglet

Posté 19 avril 2013 - 11:27

Je dis que si on dépasse une cellule c'est plus rentable car je proposais d'utiliser un port USB et donc 5V pour recharger le robot... 2 cellules en série dépassent les 5V... Donc si en plus de faire un chargeur plus compliquer il faut augmenter la tension on perd vite en rentabilité ...En plus deprendre plus de place et de peser plus lourd ça coûte plus cher... surtout qu'on trouve des chargeur 2S 3S peu cher ...je t'avais donné un lien la dernière fois ... Donc si on utilise des batterie de plus d'une cellule il me semble plus judicieux d'avoir un chargeur externe...
Après on peut utiliser plusieurs batterie 1 cellules ... les mettre en série pour avoir un voltage plus important et les "détacher" pour pouvoir les recharger indépendamment...

Avantage : c'est générique!

je m'explique : La version standard peut avoir une seule batterie (voir deux). Mais rien n'empêche de rajouter des "bloc" batterie pour les mettre en série ou en parralèle voir les deux ( avec plus de batterie ) incluant le chargeur par usb. reste à les deconnecter les unes des autre avant de les charger.
Un rack pourrait être prévu facilement à cet effet avec des interrupteurs ... Et c'est pas la taille du chargeur usb qui va nous tuer... en gros la prise mini usb c'est plus de la moitié de la taille du chargeur ...

Avec le strict minimum si on fait 30 chargeur je peux les faire à environ 2,5 euros pièces ...voir moins si on en prend encore plus... alors qu'en faire un seul me coûterais bien plus de 10 euros pièces ...

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 ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#103 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 20 avril 2013 - 07:02

Hello!
Je reviens sur le but précis de ce robot, à mon sens. Je comprends les approches "ingé", mais je ne suis pas d'accord avec ces visions.
l'idée ne serait pas à mon sens de faire un robot capable de faire ceci, cela, et trucmuche, mais au contraire une "base robotique", comme dit par d'autres, à
savoir un robot de base, emportant les fonctions vitales, à savoir une alimentation pour le Raspberry pi, un moyen de se déplacer, des systèmes de commandes
pour les moteurs, de quoi lire des capteurs, et des entrées-sorties programmables disponibles, protégées, et accessibles.

Les spécifications plus précises concerneraient la puissance motrice, les dimensions, et un système de châssis qui permette l'extensibilité du robot.

Pourquoi? parceque si on décide de faire un robot capable de faire un certain nombre de tâches précises, alors ça sera juste un autre robot. Ici pour moi l'idée, ce
serait d'avoir une espece de "framework", un peu comme Arduino peut l'être, ou on a une base capable de faire plein de trucs, mais qui en elle même ne fait pas forcément grand chose.

A partir de là on pourrait proposer une configuration type assez simple, genre "robot éviteur d'obstacle", ou "robot suiveur de lignes", histoire que quelqu'un qui achete le KIT se retrouve avec un robot qui fait déjà quelquechose. Un peu comme le programme blink par défaut des arduinos.

Mais l'idée ne serait pas d'avoir une liste de fonctionnalités prévues au départ, mais une base capable de se déplacer, lire des capteurs, et utiliser des E-S programmables, et ce de façon autonome.

A partir de là, l'intérêt, c'est que si on a réussi a standardiser un système de châssis, de modules, etc, on pourra prendre cette base a 100€ qui fait deux trois trucs de base, mais les fait bien, et proposer à l'utilisateur d'ajouter tel ou tel capteur, un bras robotique de tel modèle, bref des modules, un peu au sens des "shields arduino", mais pas forcément aussi "plug and play", qui permettent à chacun de partir d'un robot générique pour arriver à un robot qui fait un truc bien précis. Par exemple, en ajoutant une webcam, faire de la navigation vidéo, reconnaissance de terrain, etc.

En ajoutant une tourelle "lance bidules", transformer le robot en un robot de combat qui embête les gens en leur balançant des bidules dans les cheveux, etc...

Et si c'est bien conçu, le tout serait combinable, de sorte que tant qu'on ajoute pas plus de X kg de modules, pour une consommation maximale de Y mA, avec des contraintes spatiales à définir, eh bien on puisse ajouter autant de modules qu'on veut.


Pourquoi cette approche? parceque ainsi, avec une bonne base, on pourrait tous partir de ça, débutants comme confirmés, et chacun pourrait tenter des expériences/idées à son niveau, mais en outre, de par la standardisation, les trouvailles de chacun seraient facilement exploitables par les autres. Et comme on aurait standardisé, il serait possible à plusieurs membres travaillant sur une base commune d'envisager un projet super ambitieux, chacun développant une partie avec son robot, et on combinerait le tout à la fin...

Par exemple transformer le robot de base en un robot qui gère sa charge automatiquement, se balade dans un environnement qu'il cartographie, et en utilisant des capteurs vidéo, serait capable de faire de la reconnaissance d'objets avec openCV pour reconnaître certains objets, avant de les saisir avec son(ses) bras articulé(s) pour les ranger à une place de référence...

Sur ça on pourrait avoir quelqu'un sur la reco avec openCV, quelqu'un sur la manipulation , quelqu'un sur la cartographie de la zone, et tous travaillant sur une base commune...

Et dans tout ça, celui qui est juste intéressé par un bras robotique pour un robot simple, qu'il télécommanderait, pourrait prendre les bidules développés pour la manipulation pour l'adapter à son projet...

Enfin c'est comme ça que je le vois moi.
Générique, extensible, abordable, modulaire et standardisé.

Et au passage, si on s'est bien débrouillés sur la standardisation, rien n’empêche d'envisager des versions différentes du châssis, par exemple une version plus grosse, plus puissante, ou une version "marcheur", mais compatible avec les modules...

"I have a dream. In my dream, every user, advanced or beginner, would be able to build a robot complying his needs using our base." :P

Mon site principal : http://www.nagashur.com/ (format blog, un wiki y est aussi)

Mon profil sur hackaday.io : https://hackaday.io/sky99 (hackerspace en anglais, j'y ai plein de projets)

Mon Github : https://github.com/sarinkhan/


#104 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 20 avril 2013 - 09:46

Je ne sais pas si tu réagis par rapport aux posts sur le forum ou au fichier pdf que j'ai mis sur dropbox, mais dans le deuxième, ce que j'ai mis me semble cadrer avec ce que tu dis. Par approche d'ingénieur, j'entends que l'on prenne le temps de réfléchir à ce qu'on veut, et de le concevoir, avant de se lancer dans des réflexions sur les modules en eux-mêmes. L'évolutivité que l'on veut donner implique pour moi la conception sous forme de modules. Mais si on reste à ce niveau là, comment savoir les modules que l'on veut mettre au point ? Pourquoi réfléchir à une tourelle ultrasonique plutôt qu'une ceinture photosensible, les coûts étant sensiblement les mêmes ?
Pour moi, il est nécessaire de se fixer, comme tu le dis, les fonctions vitales / de base, pour que notre robot à 100 € soit capable de faire quelque chose (navigation par exemple), une certaine liberté étant donnée par les capacités logicielles de la RPi. La conception modulaire autorisera à quelqu'un prêt à mettre un peu plus que 100 €, ou ayant réussi à mieux optimiser ses 100 € de bugdet que nous à rajouter des capteurs / effecteurs sur le robot, ce qui étendra d'autant le champ d'exploration logiciel. Mais il est nécessaire de passer par cette étape de conception et de brainstorming avant de se lancer dans la conception de chaque module, ce qui n'a à mon avis pas eu lieu (ou alors je suis passé à côté), et risque en nous laissant réfléchir au niveau du module, de nous faire arriver à un certain nombre de modules pas forcément intéressants en termes de robotique. Autant je suis un partisan des approches qui jouent sur l'émergence de comportement complexe à partir de comportements simples, autant ça ne me semble pas applicable à des modules hardware.

Bref, il faut fixer clairement notre objectif pour le robot, histoire que nous partions tous sur la même idée. Pour moi, la question de Melmet "Que doit pouvoir faire le robot?" est symptomatique du manque de vision commune de ce projet, et s'il n'y a pas au moins ça entre les gens qui veulent y participer, ça ne peut pas marcher.
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#105 Gyro49

Gyro49

    Habitué

  • Membres
  • PipPip
  • 246 messages
  • Gender:Male
  • Location:Angers, France

Posté 20 avril 2013 - 10:51

Bonjour,

C'est bizarre mais nous venons de refaire un retour à la page 3 de se post.

Un cahier des charges semble inévitable

Gyro49

#106 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 977 messages
  • Gender:Male
  • Location:Anglet

Posté 20 avril 2013 - 04:42

Un cahier des charges semble inévitable

Gyro49


En effet .


Hello!
Je reviens sur le but précis de ce robot, à mon sens. Je comprends les approches "ingé", mais je ne suis pas d'accord avec ces visions.
l'idée ne serait pas à mon sens de faire un robot capable de faire ceci, cela, et trucmuche, mais au contraire une "base robotique", comme dit par d'autres, à
savoir un robot de base, emportant les fonctions vitales, à savoir une alimentation pour le Raspberry pi, un moyen de se déplacer, des systèmes de commandes
pour les moteurs, de quoi lire des capteurs, et des entrées-sorties programmables disponibles, protégées, et accessibles.

Les spécifications plus précises concerneraient la puissance motrice, les dimensions, et un système de châssis qui permette l'extensibilité du robot.

Pourquoi? parceque si on décide de faire un robot capable de faire un certain nombre de tâches précises, alors ça sera juste un autre robot. Ici pour moi l'idée, ce
serait d'avoir une espece de "framework", un peu comme Arduino peut l'être, ou on a une base capable de faire plein de trucs, mais qui en elle même ne fait pas forcément grand chose.

A partir de là on pourrait proposer une configuration type assez simple, genre "robot éviteur d'obstacle", ou "robot suiveur de lignes", histoire que quelqu'un qui achete le KIT se retrouve avec un robot qui fait déjà quelquechose. Un peu comme le programme blink par défaut des arduinos.

Mais l'idée ne serait pas d'avoir une liste de fonctionnalités prévues au départ, mais une base capable de se déplacer, lire des capteurs, et utiliser des E-S programmables, et ce de façon autonome.

A partir de là, l'intérêt, c'est que si on a réussi a standardiser un système de châssis, de modules, etc, on pourra prendre cette base a 100€ qui fait deux trois trucs de base, mais les fait bien, et proposer à l'utilisateur d'ajouter tel ou tel capteur, un bras robotique de tel modèle, bref des modules, un peu au sens des "shields arduino", mais pas forcément aussi "plug and play", qui permettent à chacun de partir d'un robot générique pour arriver à un robot qui fait un truc bien précis. Par exemple, en ajoutant une webcam, faire de la navigation vidéo, reconnaissance de terrain, etc.

En ajoutant une tourelle "lance bidules", transformer le robot en un robot de combat qui embête les gens en leur balançant des bidules dans les cheveux, etc...

Et si c'est bien conçu, le tout serait combinable, de sorte que tant qu'on ajoute pas plus de X kg de modules, pour une consommation maximale de Y mA, avec des contraintes spatiales à définir, eh bien on puisse ajouter autant de modules qu'on veut.


Pourquoi cette approche? parceque ainsi, avec une bonne base, on pourrait tous partir de ça, débutants comme confirmés, et chacun pourrait tenter des expériences/idées à son niveau, mais en outre, de par la standardisation, les trouvailles de chacun seraient facilement exploitables par les autres. Et comme on aurait standardisé, il serait possible à plusieurs membres travaillant sur une base commune d'envisager un projet super ambitieux, chacun développant une partie avec son robot, et on combinerait le tout à la fin...

Par exemple transformer le robot de base en un robot qui gère sa charge automatiquement, se balade dans un environnement qu'il cartographie, et en utilisant des capteurs vidéo, serait capable de faire de la reconnaissance d'objets avec openCV pour reconnaître certains objets, avant de les saisir avec son(ses) bras articulé(s) pour les ranger à une place de référence...

Sur ça on pourrait avoir quelqu'un sur la reco avec openCV, quelqu'un sur la manipulation , quelqu'un sur la cartographie de la zone, et tous travaillant sur une base commune...

Et dans tout ça, celui qui est juste intéressé par un bras robotique pour un robot simple, qu'il télécommanderait, pourrait prendre les bidules développés pour la manipulation pour l'adapter à son projet...

Enfin c'est comme ça que je le vois moi.
Générique, extensible, abordable, modulaire et standardisé.

Et au passage, si on s'est bien débrouillés sur la standardisation, rien n’empêche d'envisager des versions différentes du châssis, par exemple une version plus grosse, plus puissante, ou une version "marcheur", mais compatible avec les modules...

"I have a dream. In my dream, every user, advanced or beginner, would be able to build a robot complying his needs using our base." :P/>


là je suis parfaitement d'accord avec toi, on est exactement sur la même longueur d'onde ! Cependant il faut quand même faire un cahier des charge de cette base !
contenant entre autre tes X kilogramme supportable
les Y mA que la base peut fournir.

Et les Z capteurs de bases ! Après il faut définir ce que sont X Y et Z entre autre ...

Donc même si on ne fait pour le moment que la base, comme je l'ai dit , cette base forme "un robot en elle même " même si elle est pas capable de grand chose ... Et il faut définir de quoi elle doit être capable pour 100 euros. Et cela se fait dans les cahier des charges.

Cependant l'objectif principale est bien d'avoir une base mobile autonome en énergie sur laquelle on pourra ensuite ajouter des modules !

J'ai bien l'impression qu'on est tous d'accord mais qu'on ne l'a pas tous compris ^^


Ensuite concernant le design de cette base :


Pour la forme en vue de dessus, je vois bien un carré voir un octogone ... Pour moi avoir des côtés droit ça simplifie un peu la mise en place des module.
Le carré étant pour moi le plus simple et le moins coûteux...

ensuite concernant le cahier des charges , je le trouve plutôt bien mais je vais le relire et essayer de compléter ce week end ! J'ai pas eu le temps cette semaine ^^

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 ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#107 thermo_nono

thermo_nono

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 825 messages

Posté 20 avril 2013 - 04:54

Justement, je regardais le cahier des charges dans la drop box et je me suis dit un truc :

"Etre évolutif", c'est bien mais c'est pas précis. ^^
Personnellement, j'aurais ajouté quelques détails sur la nature de cette évolutivité :
vu que (si j'ai bien tout suivi ^^ ), il y a déjà un bus I²C prévu pour communiquer avec le PIC, il pourrait être redirigé vers un connecteur externe (j'en profite pour dire que je ne crois pas que l'I²C soit implémenté sur les premiers RPi.. ).
de même, va-t on ajouter (rendre accessible) un port GPIO ?

edit : et quel type de connecteurs choisir ?

#108 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 20 avril 2013 - 06:38

Justement, je regardais le cahier des charges dans la drop box et je me suis dit un truc :

"Etre évolutif", c'est bien mais c'est pas précis. ^^
Personnellement, j'aurais ajouté quelques détails sur la nature de cette évolutivité :
(...)

Bien entendu que ça n'est pas précis, et ceux pour deux raisons :
- la première, c'est que j'ai fait ça de manière rapide pour illustrer ce que j'entends par cahier des charges, donc que ça n'est absolument pas fini ni figé : preuve en est le tableau de fonctions secondaires dont seule la première est très sommairement décrite. Par ailleurs, c'est un projet collaboratif, le but est que tout le monde puisse donner son avis, pas que j'impose mon idée.
- la deuxième est une question de méthodologie : comme je l'ai dit, l'approche que je propose consiste à définir de manière générale les objectifs et fonctions du robot, puis à décomposer ces points en sous-points jusqu'à en arriver à la solution technique (ce sur quoi vous avez déjà réfléchi). Allez jeter un oeil aux tutos de Mike118, il décrit les outils SADT, pieuvre, FAST. C'est la manière dont ces outils illustre le raisonnement (particulièrement le FAST). On commence donc en définissant notre problème, puis on le décompose autant qu'il faut et on propose une solution technique.
Par exemple, "être évolutif" se décomposerait possiblement en "permettre l'interchangeabilité des capteurs et effecteurs", "autoriser facilement l'ajout de nouveaux capteurs et effecteurs", "assurer l'indépendance de la programmation vis-à-vis du matériel", ... qui eux-même se re-décomposent jusqu'à un niveau suffisamment bas pour définir une solution technique.

Bien évidemment, toute proposition est à étudier ! :)
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#109 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 20 avril 2013 - 07:55

...

Je réagis par rapport aux posts sur le forum :)
Le choix entre la tourelle ultrasonique et la ceinture de capteurs, ce n'est pas à mon sens, un élément important pour le moment. L'idée étant d'avoir une base, le/les capteurs d'évitement d'obstacles ne sont pas "primordiaux", et dans tous les cas il s'agit de brancher 3 fils! Le tout c'est que pour moi, on aie des emplacements prévus
pour pouvoir facilement fixer ce genre de capteurs, des broches accessibles pour le faire, et des capacités de programmation sur le robot pour accéder à ce genre de capteur.
Le "brainstorming" dont tu parles, c'est à mon sens la conversation qui a lieu sur ce forum en ce moment :)
Pour ma part, je commence à avoir une vision précise du projet, je crois que Mike partage la même, et du coup on a déjà avancé. Maintenant, en effet, nous comprenons nous tous?
Pour ce qui est des modules, ce n'est pas à mon sens un problème pour le moment, car si on part sur une base centrale, à savoir :

  • chassis;
  • alimentation électrique/batteries;
  • fixation du raspberry pi/connection au(x) divers organes du robot;
  • motorisation;
  • circuit de commande des moteurs/roues et contrôle de trajectoire;

A ce moment on peut déjà définir une base de travail, pour déterminer les dimensions, la charge transportable, l'autonomie, le poids, la puissance motrice, la puissance électrique consommée et disponible pour des sous systèmes supplémentaires, etc...
ça fait déjà pas mal de variables à définir, de choses à mettre au point.
Une fois cette étape faite, on pourra alors décider qu'un module, ça doit consommer au plus X mA, se fixer de telle façon sur le reste, peser tant, etc etc.

Ce que je veux dire, c'est qu'on a un "coeur", qui doit être défini en premier à mon sens, car si on commence à penser à toutes les applications possibles de suite, on se retrouve avec une étude extrêmement large et complexe, qui prendra des mois. Je suis plus pour une approche incrémentale, en gardant en tête l'évolutivité bien sur, mais
en se focalisant d'abord sur les systèmes les plus critiques. Une fois qu'on a fait cette base, on pourra réfléchir à l'interface entre le robot et les modules, et se pencher par exemple sur différentes classes de modules (par exemple des modules de types A,B,C, avec un module A etant le quart d'un module B, un module B le quart d'un module C, de sorte que dans l'emplacement d'un module B on puisse installer 4 modules de types A...
Et la on aurait une sorte de "grille", qui nous permettrait de fixer des "petits bidules", ou des plus gros, en prenant plus ou moins de place, etc etc.)

Mais on pourrait se préoccuper du système de modules une fois qu'on aurait designé la base, et une fois le système de modules pensé, on pourrait alors réfléchir à la conception de modules (par exemple, commencer par un module "senseur ultrasons", puis ensuite faire un module "tourelle pouvant emporter un autre module", et ainsi de suite, de sorte qu'il soit possible de faire toutes sortes de trucs et de bidules).


...

Je crois qu'on se comprend bien :)
Pour le chassis, je suis d'avis de partir sur une forme simple, genre rectangle, pour la facilité de conception. On peut ensuite envisager des "modules passifs", qui viendraient se fixer sur les bords pour changer la forme du robot! Ou alors différentes tailles/formes de chassis, compatibles avec notre système de modules.


Justement, je regardais le cahier des charges dans la drop box et je me suis dit un truc :

"Etre évolutif", c'est bien mais c'est pas précis. ^^
Personnellement, j'aurais ajouté quelques détails sur la nature de cette évolutivité :
vu que (si j'ai bien tout suivi ^^ ), il y a déjà un bus I²C prévu pour communiquer avec le PIC, il pourrait être redirigé vers un connecteur externe (j'en profite pour dire que je ne crois pas que l'I²C soit implémenté sur les premiers RPi.. ).
de même, va-t on ajouter (rendre accessible) un port GPIO ?
edit : et quel type de connecteurs choisir ?

Pour le I2C, c'est supporté par les premiers pi, c'est juste que c'est le bus 0 dans les premières révisions, et le bus 1 dans les rev 2 et plus :)

Pour les connecteurs, je propose les connecteurs classiques comme ceux des GPIO, en mâle, avec l'espacement "breadboard", pour que ce soit facile à utiliser
et compatible avec le plus de "bidules" possibles. Et comme ça tout serait relié en jumper wire female-female.


Sinon globalement, je ne peux pas trop bosser dessus ces jours ci, car je pars à bruges lundi, jusqu'à samedi en symposium pour présenter un papier. A mon retour je bosserai un peu dessus :)

Mon site principal : http://www.nagashur.com/ (format blog, un wiki y est aussi)

Mon profil sur hackaday.io : https://hackaday.io/sky99 (hackerspace en anglais, j'y ai plein de projets)

Mon Github : https://github.com/sarinkhan/


#110 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 977 messages
  • Gender:Male
  • Location:Anglet

Posté 20 avril 2013 - 09:19

Bien entendu que ça n'est pas précis, et ceux pour deux raisons :
- la première, c'est que j'ai fait ça de manière rapide pour illustrer ce que j'entends par cahier des charges, donc que ça n'est absolument pas fini ni figé : preuve en est le tableau de fonctions secondaires dont seule la première est très sommairement décrite. Par ailleurs, c'est un projet collaboratif, le but est que tout le monde puisse donner son avis, pas que j'impose mon idée.
- la deuxième est une question de méthodologie : comme je l'ai dit, l'approche que je propose consiste à définir de manière générale les objectifs et fonctions du robot, puis à décomposer ces points en sous-points jusqu'à en arriver à la solution technique (ce sur quoi vous avez déjà réfléchi). Allez jeter un oeil aux tutos de Mike118, il décrit les outils SADT, pieuvre, FAST. C'est la manière dont ces outils illustre le raisonnement (particulièrement le FAST). On commence donc en définissant notre problème, puis on le décompose autant qu'il faut et on propose une solution technique.
Par exemple, "être évolutif" se décomposerait possiblement en "permettre l'interchangeabilité des capteurs et effecteurs", "autoriser facilement l'ajout de nouveaux capteurs et effecteurs", "assurer l'indépendance de la programmation vis-à-vis du matériel", ... qui eux-même se re-décomposent jusqu'à un niveau suffisamment bas pour définir une solution technique.

Bien évidemment, toute proposition est à étudier ! :)/>/>


Tiens mi qui croyait que j'entendrais plus parler de mes tutos ... x) En plus je reconnais que j'aurais eu le temps de continuer un peu ceux que j'avais annoncés ... Mais comme je suis pas sur qu'ils soient lus et qu'il plaisent.... j'ai pas trop continuer x)

Bon sinon pour décomposer et en reprennant un peu ce que sky 99 à dit :

Un bloc base roulante :
Un bloc cerveau principale :
un bloc alimentation :


La base roulante doit être une structure rigide et mobile et sa vitesse doit pouvoir être asservie.

en gros le bloc base roulante je le vois ainsi:
Châssis contenant des emplacement de fixation pour le bloc cerveau principale le bloc alimentation et les potentiels ajouts
roues
moteurs
capteur pour asservir la vitesse
carte de puissance pour le moteur
carte d'asservissement de vitesse pour la base


Le bloc cerveau principale basé sur le raspberry pi, doit permettre de relié le raspberry pi avec les différentes partie du robot tout en le sécurisant et en le laissant accessible à l'utilisateur.

En gros le bloc cerveau principale je le vois ainsi :

le raspberry pi avec accès aux prise GPIO accès et à la prise USB. genre un truc standard sur lequel en pourrait stacker d'autres module sur le même pricipe que les shields arduino
Système de fixation et protection,laissant le raspberry pi facilement accessible...
Prise pour alimentation
(Un microcontroleur low consommation relié en i2C à la raspberry pi ( pouvant être reprogrammer en USB )
puce permetant l'ajout de prot GPIO et de port analogique pour le raspberry pi
hub usb)


Le bloc alimentation : doit rendre la robot autonome de manière sûre (et permettre une gestion intelligente de l'alimentation)

en gros je le vois ainsi :
Une batterie
régulateur 5V + prise pour le raspberry
Sécurité,
Une prise de sortie pour alimentation moteurs
(Autre régulateur 3.3V pour alimenter autre chose chose comme un micro controleur low consomation
de quoi vérifier l'état des batteries
de quoi couper le ou les régulateurs
chargeur usb
prise de sortie pour D+ et D- de l'usb )


ces 3 blocs là c'est selon moi la base de la base avec entre parenthèse des options dont il faut définir si cela fait partie du strict minimum de notre base.

Ensuite il faut aussi surement ajouter un bloc et encore cela est à discuter :

"Le bloc capteurs de bases "
Il faut définir ce que ce bloc doit permettre :
détection du sol? détection de ligne ? détection d'obstacle ? etc ...

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 ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#111 Melmet

Melmet

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 522 messages
  • Gender:Male

Posté 20 avril 2013 - 09:27

Bon ok, voila comment je vois les choses:

*Base du robot: PVC ou autres peut importe.

*Moteurs:
=>roues :
ou
=>Chenilles:
=> Drivers: L293D ou L298 ou autres (à définir suivant le couple et la puissance des moteurs)

*µC: R Pi + Arduino (avec une méga on as déjà beaucoup d'options = plus coûteux)
R Pi + MCP 23017 + MCP 3008 (Merci Sky99 :on_the_quiet:/>/> )
Avec la R Pi ont peut faire ce que l'ont veux.

*Actionneurs : en option pour le moment!

*Carte d'alim: en fonction du calcul de toutes les puissances utiles dans le pire des cas!!!


Je sais pas, mais c'est pas une bonne base de début pour le robot (ou cahier des charges,si vous voulez). C'est a modifier peut être ou a compléter.

#112 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 977 messages
  • Gender:Male
  • Location:Anglet

Posté 20 avril 2013 - 09:32

Je sais pas, mais c'est pas une bonne base de début pour le robot (ou cahier des charges,si vous voulez). C'est a modifier peut être ou a compléter.

Je crois que j'ai pas compris ce que tu veux dire ... sinon je ne sais pas si tu as vu mais il y a un début de cahier des charges sur la drop box...

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 ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#113 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 977 messages
  • Gender:Male
  • Location:Anglet

Posté 22 avril 2013 - 03:25

Bon pour continuer de se répartir un peu les tâches je propose que même si on a pas encore défini complètement le cahier des charges, comme on est quand même d'accord sur certains points, je propose déjà de mettre de côté certains points :

Réalisation du bloc d'alimentation :
Réalisation du châssis
Réalisation du bloc asservissement vitesse
Réalisation de la partie puissance moteurs
Réalisation carte mère et interconnections entre les différents blocs
" Secrétariat "


"la section secrétariat" est d'autant plus important que c'est lui qui définit le cahier des charges des 6 autres sections, résume l'ensemble de nos avancées, et fait le rapport de nos discussion en complétant la drop box.
Ensuite la réalisation carte mère et interconnections entre les différents blocs c'est en fait le secteur permettant de penser à la modularité du système ! Tout ce qui est connecteur, spécification, point de fixation , Extension de ports du raspberry, protocole de communication ... C'est donc un point à ne pas négliger non plus !
la section partie puissance moteur doit aussi bien communiquer avec la section alimentation qui spécifie les critères de la batterie que la section châssis qui spécifie les moteurs mais aussi avec le bloc asservissement qui va commander l'interface puissance...
La section asservissement doit communiquer avec la section carte mère pour tout ce qui est protocole de communication de même pour la section alimentation ...

Bref cela fait un beau sac de noeuds !


Il me semble donc judicieux de mettre un pseudo responsable dans chacune de ses sections afin de faciliter au mieux la gestion tout en gardant à l'esprit que chacun est libre de participer à autant de sections qu'il le souhaite! ( il est même préférable que tout le monde participe un peu à tout ^^ ) surtout que les sections sont interconnectées les unes aux autres ... Il est donc important de travailler de concert !

Ainsi chacun des responsable de chaque sections devra définir "le cahier des charges de sa section " ( en prennant les avis de chacun de membres bien entendu )

Et le responsable "secretariat" devra harmoniser le tout quitte à faire des modification dans ce qui était prévu.

Le cahier des charges générale n'étant pas encore figé, des sections supplémentaires peuvent encore être ajoutées ...

Qu'en pensez vous ?

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 ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#114 Cocazero

Cocazero

    Nouveau membre

  • Membres
  • 9 messages

Posté 22 avril 2013 - 06:18

Bonjour,
Si je peux me permettre, je pense qu'il faudrait plusieurs topics afin de dissocier la partie mécanique de la partie électrique par exemple (autant de topic que de dossiers sur la DropBox). Ceci dans le but d'accélérer la mise en place du cahier des charges, puis la conception, car actuellement ce topic regroupe tout : de la puissance des moteurs à la forme du robot en passant par les personnes qui désirent s'inscrire.

Voilà

#115 Melmet

Melmet

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 522 messages
  • Gender:Male

Posté 26 avril 2013 - 11:13

Bonjour a tous.

Bon je suis en train de faire des recherches pour la cartes de puissance pour les moteurs:
j’hésite entre 2 drivers, le L293D et le L298N.

*L293D: supporte 1A
*L298N: supporte 2A

J'aimerais avoir votre avis pour essayer de faire des schémas et peut être aussi avoir vos versions.
Je ne peut pas faire les C.I. mais bon je pense qu'il y a un R-Maker qui va pouvoir nous faire cela :ignat_02: .

#116 Francky

Francky

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 967 messages
  • Gender:Male

Posté 26 avril 2013 - 03:19

Salut,
désolé d'intervenir pour dire une mauvaise nouvelle mais le L293D ne supporte que 600 mA ! (1.2 A en pique)

Bon courage pour la suite !

#117 Melmet

Melmet

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 522 messages
  • Gender:Male

Posté 26 avril 2013 - 03:41

Salut,
désolé d'intervenir pour dire une mauvaise nouvelle mais le L293D ne supporte que 600 mA ! (1.2 A en pique)

Bon courage pour la suite !

Oui c'est vrai, j'ai arrondie les valeurs c'est vrai :on_the_quiet:
Je voudrais avoir votre avis . :ignat_02:

#118 thermo_nono

thermo_nono

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 825 messages

Posté 26 avril 2013 - 04:05

Selon moi, il serait bon de s'en remettre au vieil adage :
"Qui peux le plus peux le moins !".
Après ce n'est plus que la question du coût... ça reviendrait beaucoup plus cher de taper directement dans le 2A ?

#119 Melmet

Melmet

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 522 messages
  • Gender:Male

Posté 26 avril 2013 - 04:14

Selon moi, il serait bon de s'en remettre au vieil adage :
"Qui peux le plus peux le moins !".
Après ce n'est plus que la question du coût... ça reviendrait beaucoup plus cher de taper directement dans le 2A ?

Non en effet, la différence de prix n'est pas trop large.

#120 thermo_nono

thermo_nono

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 825 messages

Posté 26 avril 2013 - 05:30

Je change de sujet pour poser une petite question :
Quel sera le diamètre des roues ?
C'est pour définir le diamètre des roues codeuses.

Selon mes réflexions personnelles sur ce sujet :
- Les roues codeuses devraient être fixées sur l'arbre de la roue car c'est l'axe le plus lent sur le rapport de réduction (jeu d'engrenages)
- La roue codeuse doit avoir le diamètre le plus grand possible car plus sa circonférence est grande, plus la résolution des marquages sera efficace.
contrainte :
Les roues devront être le moins large possible afin de réduire les effets de patinage lors des virages qui seraient néfastes sur les mesures d'odométrie.

Mes hésitations :
je me demande si il est préférable d'utiliser une roue codeuse "normale" (opaque et transparent) avec une fourche en U :
http://www.hobbyelectro.fr/shop/optoelectronique/446-capteur-infrarouge-reflectif-rpr220.html
ou si, en collant une rondelle de papier alu sur le transparent (réflectif ou non-réflectif), il ne serait pas plus simple d'utiliser ce genre de composant :
http://www.hobbyelectro.fr/shop/optoelectronique/163-capteur-infrarouge-reflectif-rpr220.html

Pour ce qui est du codage imprimé sur la roue, je pense que le mieux (plus simple à mettre en place et moins de composants nécessaires) serait d'utiliser un codage séquentiel sur deux largeurs :
blanc-étroit / noir-étroit / blanc-large / noir-large.
Ceci permet de déduire avec un seul capteur le sens et la vitesse de rotation.




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

0 members, 1 guests, 0 anonymous users