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

#41 Gyro49

Gyro49

    Habitué

  • Membres
  • PipPip
  • 244 messages
  • Gender:Male
  • Location:Angers, France
  • Interests:Les nouvelles technologies

Posté 10 avril 2013 - 05:46

Bonjour,

Juste en passant, et je n'ai pas pris le temps de regarder les dernières posts.

Je viens de voir sur internet l'utilisation d'un alume-cigare comme alimentation 5V, ce qui pourrait permettre l'utilisation d'une batterie 12v pour les moteurs pas à pas (200 pas donc plus besoin d'encodeur).

Avec un simple L293B par moteur il n'y aurais pas besoin composant en plus.

Gyro49

#42 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 10 avril 2013 - 06:20

Moi je propose, avant de choisir le matos de réfléchir quelques temps sur l'architecture globale, pour la concevoir générique. Et de poser tout ça sur papier.
Une fois l'archi validé, alors on pourra réfléchir à notre petit robot et faire des choix techniques.
On a donc deux étapes :

  • Conception de l'architecture qui est indépendante de toute application
  • Faire de choix techniques pour utiliser l’architecture précédente en fonction de l’application choisie

Je comprends l'idée, mais, du coup faut savoir si on parle d'un robot a 100€ ou pas. Si on parle d'un robot à 100€, il faut tout de suite placer des limites... A un certain prix, on est limités en taille, vitesse, poids transportable, autonomie....


Le soucis avec la conception sans µC, c'est que je ne pense pas que le RPi fasse du temps réel ! Ce qui est gênant pour l'asservissement, la réception capteur, & co.
Rien n'empêche d'avoir une RPi pour le raisonnement haut niveau, et des µC pour une gestion du temps réel et des points critiques du robot (on en revient à notre discussion sur ta présentation ;)/> )


J'entends bien, Linux n'est pas un OS temps réel. Mais est-ce obligatoire? Mon robot Raspberry fonctionne avec son linux "pas temps reel" et évite
plutôt correctement les obstacles. Si je me rappelle bien, les latences qu'on peut attendre sont en millisecondes, approximativement...
Et en pratique, si on enlève l'interface graphique et ce qui ne sert pas au robot, celui ci dédie presque complètement le CPU au robot...

Je comprends parfaitement l'approche µC commandé par le PI, et pour mes projets j'y viens, simplement parce que ce modèle m'intéresse, etc.
Maintenant, est-il nécessaire pour beaucoup d'applications? pas nécessairement. Je trouve justement intéressant de voir ce qu'il est possible de faire en utilisant simplement
le linux non real time. Sinon j'ai une question : pourquoi ne pas utiliser directement le µC et asservir celui ci sans fil à un ordinateur quelconque?
A partir de quand parle t'on de "robot raspberry"?

Je pense que dans tous les cas l'idéal serait d'avoir une couche d'abstraction dans le code, qui permette de balancer des commandes à un module, et selon le choix de design, que ce module soit un µC, ou alors le raspberry pi lui même si la personne fait un choix sans... Ce qui m’embête avec un µC si on parle d'un robot à moins de 100€, c'est qu'il faut un programmateur. Si on peut s'en passer avec un bootloader, il faut quand même de quoi
connecter le PIC à l'ordinateur qui sert à programmer; donc un circuit additionnel. Et du coup, ça rajoute un surcoût ^^
Sauf bien sur si ce circuit peut servir à diverses choses et ainsi baisser les coûts.


Intégré à la carte d'alim par exemple, oui ça complique les choses, mais pourquoi pas.

Par exemple ici ça fait un léger surcoût, mais d'un autre coté en fusionnant des fonctionnalités, ça réduit le coût d'autres parties.


Ah, tu soulèves un point important !
Quel est le but de ce robot ??

  • Faire un robot modulaire. Donc simple à concevoir avec les briques de bases que l'on aura créé. Avec une simplicité dans l'ajout/le retrait de capteurs/moteur. Mais où chaque module est difficile à comprendre pour un débutant.
  • Faire un robot pour débutant : Donc simple à concevoir avec des composants élec, mais pas modulaire car sinon, ça serait trop compliqué
Moi, j'étais parti sur la première solution : faire un truc très compliqué à concevoir, mais très simple à utiliser. (Un peut comme une arduino : comprendre comment c'est conçu, c'est hard ! mais l'utiliser, c'est simple)



N'hésite surtout pas à exposer le matos perso dont tu disposes ! Cela pourrait nous influencer de manière positive !
Ensuite si il te manque du matos on se débrouillera pour t'en envoyer !

donc moi j'ai :


4 Raspberry modèle B;
Un arduino Uno; avec un shield "programmateur" pour mettre des bootladers dedans;
Des ATmega328p;
Des ATtiny85 et 2113
Des MCP3008 et 23018;
Plein d'autres puces que je n'ai pas utilisées/testées (shift registers, solenoid drivers, etc)
des moteurs "plastic gearmotors" de pololu, avec rapport réducteur 120:1 et 180:1 :
j'en ai 4 ou 5 paires. Leur axe de sortie est un axe en métal, en D, de 3mm. Ils valent environ 5.5$ pièce, et prennent au plus 800mA, alimentés en 3 à 6v
Des servomoteurs à rotation continue futuba

Après, je n'en ai pas, mais il existe des "pololu micro metal gearmotors", avec boite de vitesse, fixation standard vendue chez eux, et des modèles ou on a accès à l'axe, voire un double axe, dont l'un pour la roue, après la boite de vitesse, et l'autre sur le moteur même, de l'autre coté.
Ils font des versions 360, 700 et 1600mA, toujours en 3-6v si je ne m'abuse. En revanche, c'est déja 15$ le moteur.

Pour les roues/chenilles :

Pour les régulateurs de tension, j'ai le régulateur step-up/step down de pololu (http://www.pololu.com/catalog/product/2119)
et des régulateurs linéaires de base;

Comme capteurs, divers capteurs (température, LDR, pression atmosphérique, pression -les petits bidules ronds qui détectent les niveaux de pression-
humidité, etc), mais pour l'usage robotique, disons surtout :
[
Pour les driveurs de moteurs, je n'en ai que 2:
Le L293D;
le TI SN754410.

D'ailleur quel est la ref du composant pour le 5V régulé du RPi que tu propose ?

La référence, c'est le S7V7F5.
j'ignore si c'est un produit spécifiquement pololu, mais en tous cas, voici le lien :http://www.pololu.com/catalog/product/2119

Au passage, j'en profite pour signaler que le Raspberry Pi modèle A est sorti, et disponible. On perd l'ethernet et un USB, et on passe de 512 à 256 de RAM.
EN échange, la conso passe à moins de 400mA. Ce qui veut dire par exemple qu'avec le circuit au dessus, on peut alimenter le Pi avec tout ce qui produit entre 2.7 et 5V. Et également qu'on augmente l'autonomie du robot, bien sur.

ou alors il y a la solution compliquée mais efficace qui consiste à utiliser "Github". ( https://github.com/ )

Cette méthode permet à plusieurs personnes de bosser sur un même projet. J'avoue que c'est un peu compliqué à utiliser mais en contre partie, ça offre beaucoup d'avantages (possibilité de revenir en arrière, création de plusieurs branches pour tester différentes méthodes en //, mémorisation de "qui a fait quoi quand"...) et ça tourne sur à peu près n'importe quoi (Mac, Winwin, Linux...).

Je fini par un lien qui pointe vers un petit tuto vidéo histoire de vous faire une idée de ce à quoi ressemble cet outil.

Je suis parfaitement de cet avis, mais effectivement j'ignore comment github traite les autres fichiers que du texte. Mais pour du code ça me parait essentiel, pour le versioning.

Pour moi, je trouve que ce sont des questions qui ne se posent pas encore :)/>

Etape 1 : concevoir générique quelque soit l'application (faire donc quelques cartes/modules qui pourront être réutilisés dans n'importe quelle circonstance : carte asservissement, carte gestion capteurs, etc.)
Etape 2 : choisir le robot sur lequel on va se baser pour faire les tests (poids, nombre de moteurs, roues intérieur/ext, etc.)
Etape 3 : Concevoir le robot de base

Certes, mais "générique quelque soit l'application", ça veut dire un robot extrêmement complexe et cher, non? si on part sur générique pour un certain nombre d'applications, ça rend plus réaliste le concept des 100€!

Mais encore une fois, mike118 parlait de robot à 100€ au départ, est-ce toujours dans l'optique du projet?

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/


#43 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 10 avril 2013 - 08:30

Super de voir autant d'enthousiasme dans ce projet, autant de compétences chez les robots-makers mais au risque de faire le rabat-joie (pardonnez moi par avance ou mettez ça sur l'âge) je m'interroge vraiment sur la finalité de ce projet. Pour ma part une étude/réalisation doit répondre à un besoin /une utilisation.
Dans ce cas est ce purement didactique axé vers l'utilisation d'une carte Raspberry Pi ? Si cet objectif est retenu alors il me semble nécessaire de réduire et limiter le hardware à un strict minimum standardisé ( un plateau,2 roues, 2 moteurs,2(3) US, utilisation intérieure voire un kit mais tout de suite une vidéo, liaison wifi,,synthèse vocale,reconnaissance vocale... afin d'essayer d'utiliser un peu plus les possibilités d'une telle carte.Les exemples de robots disposant de capteurs basiques et ne nécessitant qu'un maigre PIC ne manquent pas. Amener une Raspberry Pi à piloter quelques servos est trop réducteur (pauvre bête, elle va déprimer :sorry:/>/> ).
De l'ambition donc! :)/>/>




Pour moi, le but de ce projet est de pouvoir disposer d'une base robotique standard et peu onéreuse, mais qui reste facilement modulable grâce au RPi.
Le principal est selon moi de déjà disposer d'une telle base, en ne perdant pas de vue, bien entendu, les capacités du RPi pour une utilisation future plus complexe.


C'est exactement cela ! Le tout en restant dans une " base poussée " mais en dessous des 100 euros !

exemple concret : proposé une batterie avec un chargeur usb pour 5 euros ça peut faite partie de ce côté "poussée" cependant comme le robot reste modulable ce bloc pourrait être remplacé par une autre batterie !
Par contre en effet si on embarque la raspberry pi c'est pas pour rien !

Le but améliorer le niveau de chacun de manière concrète en travaillant sur une même base que l'on pourra ensuite chacun faire évoluer dans les sens qu'il nous plaira le plus ... Un peu comme la raspberry : c'est un beau bijou autour duquel il y a une belle communauté mais on peut aussi bien en faire un serveur que le cerveau d'un robot !


Je comprends l'idée, mais, du coup faut savoir si on parle d'un robot a 100€ ou pas. Si on parle d'un robot à 100€, il faut tout de suite placer des limites... A un certain prix, on est limités en taille, vitesse, poids transportable, autonomie....



On est limité certes mais profitons de tous les avantages que l'on peut mettre en oeuvre pour réussir à faire ce que l'on peut faire de mieux ! à nous de définir notre standart !

J'entends bien, Linux n'est pas un OS temps réel. Mais est-ce obligatoire? Mon robot Raspberry fonctionne avec son linux "pas temps reel" et évite
plutôt correctement les obstacles. Si je me rappelle bien, les latences qu'on peut attendre sont en millisecondes, approximativement...
Et en pratique, si on enlève l'interface graphique et ce qui ne sert pas au robot, celui ci dédie presque complètement le CPU au robot...


Je comprends parfaitement l'approche µC commandé par le PI, et pour mes projets j'y viens, simplement parce que ce modèle m'intéresse, etc.
Maintenant, est-il nécessaire pour beaucoup d'applications? pas nécessairement. Je trouve justement intéressant de voir ce qu'il est possible de faire en utilisant simplement
le linux non real time. Sinon j'ai une question : pourquoi ne pas utiliser directement le µC et asservir celui ci sans fil à un ordinateur quelconque?
A partir de quand parle t'on de "robot raspberry"?


Je pense que dans tous les cas l'idéal serait d'avoir une couche d'abstraction dans le code, qui permette de balancer des commandes à un module, et selon le choix de design, que ce module soit un µC, ou alors le raspberry pi lui même si la personne fait un choix sans... Ce qui m’embête avec un µC si on parle d'un robot à moins de 100€, c'est qu'il faut un programmateur. Si on peut s'en passer avec un bootloader, il faut quand même de quoi
connecter le PIC à l'ordinateur qui sert à programmer; donc un circuit additionnel. Et du coup, ça rajoute un surcoût ^^
Sauf bien sur si ce circuit peut servir à diverses choses et ainsi baisser les coûts.

Par exemple ici ça fait un léger surcoût, mais d'un autre coté en fusionnant des fonctionnalités, ça réduit le coût d'autres parties.



Parfaitement d'accord ! la carte de puissance sera générique ! tu pourrais directement la bracher au PI... Par contre plus délicat serait de faire des trajectoire " propre" ...

ensuite le boutloader intégré, on met un micro usb femel sur la carte qu'on fait et il suffit de prendre le cable qu'on a pour recharger notre téléphone ! Et en même temps on recharge notre robot ! En plus autant faire en sorte de pouvoir le reprogrammer par le Rpi qui à ce qu'un programme fasse reprogrammer le pic esclave si nécessaire en reliant le pic au Rpi par usb ...






donc moi j'ai :


4 Raspberry modèle B;
Un arduino Uno; avec un shield "programmateur" pour mettre des bootladers dedans;
Des ATmega328p;
Des ATtiny85 et 2113
Des MCP3008 et 23018;
Plein d'autres puces que je n'ai pas utilisées/testées (shift registers, solenoid drivers, etc)
des moteurs "plastic gearmotors" de pololu, avec rapport réducteur 120:1 et 180:1 :

j'en ai 4 ou 5 paires. Leur axe de sortie est un axe en métal, en D, de 3mm. Ils valent environ 5.5$ pièce, et prennent au plus 800mA, alimentés en 3 à 6v
Des servomoteurs à rotation continue futuba

Après, je n'en ai pas, mais il existe des "pololu micro metal gearmotors", avec boite de vitesse, fixation standard vendue chez eux, et des modèles ou on a accès à l'axe, voire un double axe, dont l'un pour la roue, après la boite de vitesse, et l'autre sur le moteur même, de l'autre coté.
Ils font des versions 360, 700 et 1600mA, toujours en 3-6v si je ne m'abuse. En revanche, c'est déja 15$ le moteur.

Pour les roues/chenilles :

Pour les régulateurs de tension, j'ai le régulateur step-up/step down de pololu (http://www.pololu.com/catalog/product/2119)
et des régulateurs linéaires de base;

Comme capteurs, divers capteurs (température, LDR, pression atmosphérique, pression -les petits bidules ronds qui détectent les niveaux de pression-
humidité, etc), mais pour l'usage robotique, disons surtout :
[
Pour les driveurs de moteurs, je n'en ai que 2:
Le L293D;
le TI SN754410.



Waou tu as beacoup de matos surtout côté motorisation !

J'aime beaucoup l'idée de pouvoir mettre des roues ou des chaines faudra qu'on y pense quand on attaquera la méca du robot !
Je garde en tête tout ça !



La référence, c'est le S7V7F5.
j'ignore si c'est un produit spécifiquement pololu, mais en tous cas, voici le lien :http://www.pololu.com/catalog/product/2119

Au passage, j'en profite pour signaler que le Raspberry Pi modèle A est sorti, et disponible. On perd l'ethernet et un USB, et on passe de 512 à 256 de RAM.
EN échange, la conso passe à moins de 400mA. Ce qui veut dire par exemple qu'avec le circuit au dessus, on peut alimenter le Pi avec tout ce qui produit entre 2.7 et 5V. Et également qu'on augmente l'autonomie du robot, bien sur.


entre 2.7 et 11.8V ! c'est pas mal ! Par contre 1A c'est pas un peu limité non ? si on branche un petit truc en usb ... ça risque d'être un peu limite non ? Peux tu faire différents essais ?

Au pire c'est le genre de truc qu'on achète pas tel quel mais qu'on implante directement sur notre carte ! Pour moi pas de problème pour implanter cela !

Il faut se dire qu'on est pas limité au traversant ! Et qu'on ne doit pas forcément tout acheter tout fait ... En l'intégrant sur une carte qu'on doit faire de tout façon on va gagner la différence entre le prix affiché et le coût des composants !

pour la raspberry modèle A ça pourrait être une bonne idée pour limité les coûts ! On fera peut être un robot B et un robot A ! :P

En tout cas pour le moment je suggère de commencer avec le modèle B car c'est pour l'instant le plus répandu du moins il me semble ( j'ai un raspberry pi modèle B depuis peu ^^ )

Je suis parfaitement de cet avis, mais effectivement j'ignore comment github traite les autres fichiers que du texte. Mais pour du code ça me parait essentiel, pour le versioning.


Certes, mais "générique quelque soit l'application", ça veut dire un robot extrêmement complexe et cher, non? si on part sur générique pour un certain nombre d'applications, ça rend plus réaliste le concept des 100€!

Mais encore une fois, mike118 parlait de robot à 100€ au départ, est-ce toujours dans l'optique du projet?


Bon pour moi le code c'est encore loin mais il me semble important de commencer à créer des fichiers excels référençant les références énoncés etc ...

J'ai donc créer un dossier drop box. J'invite tous ceux qui le souhaitent à m'envoyer leur mail pour partager le dossier .

Concernant le versionning, je pense qu'en s'organisant bien ( en reprennant le modèle de l'entreprise dans laquelle je travaille ) juste drop box ça peut largement le faire :

Il suffit à chaque nouvelle version noter : faire le dossier à coté avec le numéro de version implémanté et faire un " release note " signé par la personne qui fait la modif ...


En tout cas les 100 euros sont bien toujours dans l'optique du projet ! Mais le robot ne s'arrêtera pas à ces 100 euros ! 100 euros c'est "la base ", ce qu'on va considérer comme " notre standard " et qu'on doit créer tous ensemble .

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  

 

 

 


#44 Gyro49

Gyro49

    Habitué

  • Membres
  • PipPip
  • 244 messages
  • Gender:Male
  • Location:Angers, France
  • Interests:Les nouvelles technologies

Posté 10 avril 2013 - 08:53

Je voudrais savoir, d'une façon très "vague" l'objectif du robot.
Je suis très cartésien, il me faut une vision claire du produit.

J'ai bien compris la démarche générale avec la notion de travail en groupe pour un projet évolutif -> oui et re-oui

def : Un robot-maker (faudra donner un nom au projet) -> unité mobile et autonome en énergie... euh ! des roues ou des pattes ?

Avant de parler du choix du matériel, est ce qu'il ne serait pas judicieux de parler finalité, objectifs:
pour le chassis :
"A la fin de ce module les participants auront produit une base capable de se déplacer sur un sol plat | accidenté | en extérieur pendant une heure sans recharge"

pour la vision :
"A la fin de ce module les participants auront produit une option de pour la base ci-dessus capable de reconnaître des formes | des couleurs et d'informer la base de l'environnement"

pour une pince :
"A la fin de ce module les participants auront produit une pince pour la base ci dessus capable de saisir un objet (poids, volume)" l'option vision sera une condition de bon fonctionnement ou la vision n'est pas une obligation.

la station de rechargement :
"A la fin de ce module les participants auront produit une station de rechargement pour la base ci-dessus capable d'indiquer sa position par IR"

Je suis très scolaire.

Pour moi si nous ne sommes pas tous sur la même vision d'un rendu final, il y aura divergence en milieu de parcours voir incompréhension et le pire grogne et aigreur de certaine personnes qui se sentirons évincée après des ANNEES et des ANNEES de participations.

Nous avons abordé le prix de départ (100€) mais avez vous un volume pour la machine.

Moi je suis en déplacement, glisser le châssis dans mon sac serait génial avec moins d'un kilo et le volume d'un dictionnaire pourrait correspondre.

Pour finir, dans le dernier MagPi, il y a un article pour une alimentation d'une RPi

Gyro49

#45 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 10 avril 2013 - 10:08

Je voudrais savoir, d'une façon très "vague" l'objectif du robot.
Je suis très cartésien, il me faut une vision claire du produit.

J'ai bien compris la démarche générale avec la notion de travail en groupe pour un projet évolutif -> oui et re-oui

def : Un robot-maker (faudra donner un nom au projet) -> unité mobile et autonome en énergie... euh ! des roues ou des pattes ?

Avant de parler du choix du matériel, est ce qu'il ne serait pas judicieux de parler finalité, objectifs:
pour le chassis :
"A la fin de ce module les participants auront produit une base capable de se déplacer sur un sol plat | accidenté | en extérieur pendant une heure sans recharge"

pour la vision :
"A la fin de ce module les participants auront produit une option de pour la base ci-dessus capable de reconnaître des formes | des couleurs et d'informer la base de l'environnement"

pour une pince :
"A la fin de ce module les participants auront produit une pince pour la base ci dessus capable de saisir un objet (poids, volume)" l'option vision sera une condition de bon fonctionnement ou la vision n'est pas une obligation.

la station de rechargement :
"A la fin de ce module les participants auront produit une station de rechargement pour la base ci-dessus capable d'indiquer sa position par IR"

Je suis très scolaire.

Pour moi si nous ne sommes pas tous sur la même vision d'un rendu final, il y aura divergence en milieu de parcours voir incompréhension et le pire grogne et aigreur de certaine personnes qui se sentirons évincée après des ANNEES et des ANNEES de participations.

Nous avons abordé le prix de départ (100€) mais avez vous un volume pour la machine.

Moi je suis en déplacement, glisser le châssis dans mon sac serait génial avec moins d'un kilo et le volume d'un dictionnaire pourrait correspondre.

Pour finir, dans le dernier MagPi, il y a un article pour une alimentation d'une RPi

Gyro49


Pour moi :

La base principale du robot doit :
coûter 100 euros ou moins,
être mobile précisément ( => asservissement sauf si on utilise des moteurs pas à pas ) en interieur pour la version de base ( donc sur sol plat pente inferieur à 5% )
être autonome en énergie ( Temps espéré : au moins 20 minutes avec la batterie de base! )
être modulable et extensible ( certaines parties judicieusement choisies pourront être remplacées par d'autres facilement et des ajouts pourront être fais )
Contrainte de volume à définir... Je partirais bien sur une base carrée ( pour la modularité : j'imagine déjà l'ajout d'un ou de plusieurs bras qui pourrai aussi bien se fixer à l'avant ou sur le côté du robot mais ça c'est pas compris dans les 100 euros ... )
Contrainte de poids : je dirais que la base ne dois pas peser plus d'un kilo mais pouvoir transporter 3 ou 4 Kilo ...
La base doit être facilement reproductible ( pas de "truc coller " on se débrouille pour faire les bonnes pièces directment ou on prévoit les fixations adéquate ! )

Ensuite il faudrait faire un cahier des charge par sous partie ... mais déjà définir ces sous partie...

Pour commencer on se base sur :

Une Raspberry et de base : des moteurs à courant continu ? Jusque là on est d'accord ?

à partir de là il y aura nécessairement une carte qui permet la gestion des moteurs à courant continu ...

Cahier des charge de cette carte selon moi :

accepter une tension d'alimentation des moteurs comprise entre 3V et 24V délivrer 2A en continu avec protection de sur intensité ...
commande simple en PWM + direction
autre ?

ensuite

Cahier du bloc d'alimentation
accepter entre 3V et 24V
alimenter le rpi en 5V de manière sécurisé etc ...
intégrer la recharge ?

Bref il faudrait rédiger un document complet sur la drop box ...

Ensuite ce n'est pas par ce que j'ai ouvert ce sujet que je dois décider ! Je souhaite avant tout à ce que ce robot soit un robot collectif intégrant les idées de tous ! exemple concret si la majorité veut rajouter une arduino et bien soit ! ^^

Du coup je propose à chacun de proposer un semblant de cahier des charges un peu comme ce que j'ai fais précédement !

Et j'invite gyro à être le premier à me suivre en donnant un cahier des charges plus scolaire que le miens afin de montrer le bonne exemple ! =)

EDIT : Concernant le pic qu'on souhaite utiliser pour l'asservissement en vitesse, voici de quoi s'inspirer un peu http://fribotte.free.fr/bdtech/PidSurPic/PidSurPic2.html =)

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  

 

 

 


#46 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 11 avril 2013 - 04:21

C'est exactement cela ! Le tout en restant dans une " base poussée " mais en dessous des 100 euros !
exemple concret : proposé une batterie avec un chargeur usb pour 5 euros ça peut faite partie de ce côté "poussée" cependant comme le robot reste modulable ce bloc pourrait être remplacé par une autre batterie !
Par contre en effet si on embarque la raspberry pi c'est pas pour rien !
Le but améliorer le niveau de chacun de manière concrète en travaillant sur une même base que l'on pourra ensuite chacun faire évoluer dans les sens qu'il nous plaira le plus ... Un peu comme la raspberry : c'est un beau bijou autour duquel il y a une belle communauté mais on peut aussi bien en faire un serveur que le cerveau d'un robot !
On est limité certes mais profitons de tous les avantages que l'on peut mettre en oeuvre pour réussir à faire ce que l'on peut faire de mieux ! à nous de définir notre standart !
Parfaitement d'accord ! la carte de puissance sera générique ! tu pourrais directement la bracher au PI... Par contre plus délicat serait de faire des trajectoire " propre" ...
ensuite le boutloader intégré, on met un micro usb femel sur la carte qu'on fait et il suffit de prendre le cable qu'on a pour recharger notre téléphone ! Et en même temps on recharge notre robot ! En plus autant faire en sorte de pouvoir le reprogrammer par le Rpi qui à ce qu'un programme fasse reprogrammer le pic esclave si nécessaire en reliant le pic au Rpi par usb ...

En tous cas, j'aime bien cette idée du composant USB multifonctions :)
Et puisque tu sais designer des circuits, c'est chouette, pour ma part, je me limite à soit des circuits simples, soit des modules dédiés pour le moment ^^


entre 2.7 et 11.8V ! c'est pas mal ! Par contre 1A c'est pas un peu limité non ? si on branche un petit truc en usb ... ça risque d'être un peu limite non ? Peux tu faire différents essais ?
Au pire c'est le genre de truc qu'on achète pas tel quel mais qu'on implante directement sur notre carte ! Pour moi pas de problème pour implanter cela !
Il faut se dire qu'on est pas limité au traversant ! Et qu'on ne doit pas forcément tout acheter tout fait ... En l'intégrant sur une carte qu'on doit faire de tout façon on va gagner la différence entre le prix affiché et le coût des composants !

En fait le 1A en sortie est très suffisant pour un pi modèle B. Le modèle B consomme 700mA. En pratique, j'ai déja fait des tests :
Sur ce post je démontre un montage d'un Raspberry Pi, avec une webcam USB, une clé Wifi, streamant un flux webcam, et avec des tests d'autonomie.
En pratique, avec 5 piles AA sur le modèle B, streamant un flux webcam en wifi, je tiens à peu près 3h (un peu moins).
De toutes façons j'ai lu que quand on tire trop sur l'USB du Pi, on peut avoir des tensions USB basses; il vaut donc mieux à priori ne pas alimenter des périphériques trop lourds en conso avec le PI.
Cependant, on a 1A disponible sur le régulateur; et le pi modèle B prend 700mA, donc ça nous laisse 300mA, ce qui est largement suffisant. Dans mon cas, la clé wifi était un modèle wifi n 300mbits/s, mais connecté en wifi G (mon routeur wifi est en 802.11G, je l'ai passé sous openWRT, du coup j'ai viré mon point d'accès wifi draft N qui lui a un firmware propriétaire).
Bref, en pratique, ce composant suffit largement pour un PI, une webcam HD, une clé wifi classique, sans compter tout ce qui est alimenté par le pi (un MCP3008, un MCP23017 et divers petits capteurs).
Partant du fait qu'on parle d'un robot, on ne devrait pas de toutes façons ajouter de périphériques consommant trop sous peine de grêver l'autonomie... le Pi modèle B consomme déja beaucoup!

pour la raspberry modèle A ça pourrait être une bonne idée pour limité les coûts ! On fera peut être un robot B et un robot A ! :P/>
En tout cas pour le moment je suggère de commencer avec le modèle B car c'est pour l'instant le plus répandu du moins il me semble ( j'ai un raspberry pi modèle B depuis peu ^^ )

Bah la différence de prix existe, mais n'est pas énorme, entre les deux. Mais pour moi l'intérêt du modèle A, c'est surtout sa conso de 400mA au lieu de 700... ça permet de simplifier le design si on utilise mon régulateur, en prenant 4 piles AA ou moins, des batteries lithium, etc, et en faisant du step-up...
Par contre, il y a un point sur lequel je ne te suis pas, c'est quand tu dis "partons sur le modèle B". En fait je suis d'accord pour bosser avec des modèles B en prototypage, mais comme les deux modèles sont TRES proches (normalement, ils sont interchangeables dans un montage qui n'utilise pas l'ethernet), on pas besoin d'optimiser le robot pour un modèle ou pour un autre, on peut faire une conception embarquant simplement un Raspberry pi, au choix de l'utilisateur :) Moi aussi, je n'ai que des modèles B pour le moment, donc c'est ce que j'utiliserai ^^ Mais à mon sens on devrait faire en sorte que l'utilisateur puisse indifféremment utiliser un modèle B ou un modèle A!

Au passage, le module caméra devrait être bientôt dispo, donc ça rajoutera une option vidéo de haute qualité, faible encombrement,avec un bus rapide, pour pas cher ^^


Bon pour moi le code c'est encore loin mais il me semble important de commencer à créer des fichiers excels référençant les références énoncés etc ...
J'ai donc créer un dossier drop box. J'invite tous ceux qui le souhaitent à m'envoyer leur mail pour partager le dossier .
Concernant le versionning, je pense qu'en s'organisant bien ( en reprennant le modèle de l'entreprise dans laquelle je travaille ) juste drop box ça peut largement le faire :
Il suffit à chaque nouvelle version noter : faire le dossier à coté avec le numéro de version implémanté et faire un " release note " signé par la personne qui fait la modif ...

Je t'envoie un MP ^^
Mais pour l'instant du coup je ne sais pas bien ce qu'on doit faire, si tu as des tests préliminaires que je peux faire avec mon matos, fais le moi savoir. Par contre il faudrait que
je me procure un équipement pour mesurer précisément la consommation des composants, car je m'appuie sur les specifications officielles, sans plus de précision que min-max.

En tout cas les 100 euros sont bien toujours dans l'optique du projet ! Mais le robot ne s'arrêtera pas à ces 100 euros ! 100 euros c'est "la base ", ce qu'on va considérer comme " notre standard " et qu'on doit créer tous ensemble .

Je vois; c'est dans cette optique que j'avais pensé mon robot Cerda. Je ne lui ai presque rien ajouté pour le moment, car je souhaitais voir le maximum que je pouvais tirer d'un robot doté uniquement d'un capteur ultrasonique et de capteurs de contact.


Au passage, ton approche montage de circuits sera très utile, car si on peut faire certains éléments nous même plutôt que d'utiliser un µC ou un composant tout fait, on peut sans doute optimiser le tout pour l'adapter à nos contraintes...

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/


#47 dydyouaki

dydyouaki

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 792 messages
  • Gender:Male

Posté 11 avril 2013 - 05:08

_ Une Raspberry / Arduino .
_ moteurs à courant continu , avec une boite a engrenage. reste a définir la réduction du moteur.
_ La carte qui permet la gestion des moteurs à courant continu comme l'a dit mike118. Avec asservissement des moteurs (régulation PID) , non ?
_ Alimentation (je ne sais pas du tout :whistle2: )
_ poids total(châssis et composants) : 5kg (je pense que l'on sera en dessous)
_ On utilise donc 2 moteurs (ou 4)
Merci a tous
Cordialement Dylan.

#48 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 11 avril 2013 - 05:20

Proposition de cahier des charges
Puisque nous sommes sur un cahier des charges de prototype, je vous propose mes idées, et les raisons qui me poussent à proposer ces solutions.

Coeur du robot
un Raspberry Pi, modèle A ou B, car c'est la définition même du projet. De plus, il y a dejà des tonnes de prototypes Arduino, PIC, etc...
Les deux modèles sont interchangeables, sauf pour l'Ethernet. Donc pas besoin d'optimiser pour un modèle ou un autre. Le B a plus de ram, donc potentiellement
la possibilité de faire plus vite certains calculs en optimisant pour plus de ram. Le modèle A consomme 400mA contre 700 pour le modèle B, ce qui peut très grandement
optimiser l'autonomie du robot en veille.

Environnement type cible
Terrains plats pas trop difficiles. Toutefois la base envisagée pourrait facilement être adaptée à un environnement différent, je détaillerai davantage dans la section motorisation.

Dimensions
Pour moi, on devrait partir sur des dimensions relativement compactes, du genre moins grand qu'une feuille A4. Pour moi, moins, ça serait mieux, le format idéal serait environ du A5, car ça ferait un bidule transportable, utilisable en appartement pour expérimenter, capable de se faufiler un peu partout, mais sans pour autant sacrifier l'autonomie, l'évolutivité, etc.
Pour le poids, le mien fait 610g hors batteries, donc environ 750g en incluant tout. Mais j'ai pris du contreplaqué très dur pour faire le châssis, en 12mm d'épaisseur, et c'est simplement un gros rectangle plein. Donc il y a a mon sens une large marge d'optimisation. Mais pour l'échelle, je pense qu'on peut dire sous le kilogramme.

Charge utile
Sur ce paramètre, je n'ai aucune expertise pour estimer la charge utile d'un robot. Je comprends comment calculer des choses par rapport au couple, mais je n'ai pas fait de calculs
du point de vue physique pour voir la masse que peut déplacer un robot en fonction du couple sur un plan horizontal, car je n'ai aucun moyen d'estimer le frottement, ni même l'efficacité
avec laquelle le robot transmet la force mobile à la route. Mais je pense qu'on pourrait parler de robots déplaçant des charges mesurées, car si le robot doit déplacer 10kg, il faudra sans doute des moteurs consequents, incompatibles avec l'optique de faire moins de 100€ :)

Mode de locomotion
Pour ma part j'opterais pour un robot roulant, car les marcheurs sont souvent plus complexes à fabriquer, et coûtent vite cher. Il faudrait un circuit de contrôle pour les servos, et au moins 2 servos par patte, soit 8 pour un quadripède, si on a 4€ par servo, ça monte déjà à 32€ rien que pour les servos, soit le tiers du budget.

Motorisation
Je vote pour les moteurs DC, avec boite de vitesse intégrée. Il en existe des tonnes, on en trouve des pas chers du tout, c'est facile à utiliser, et pour l'évolutivité c'est extrêmement simple, car on peut facilement remplacer un moteur par un autre, tant que le driver peut fournir la puissance nécessaire. D'autre part, avec des steppers, il faudrait un driver plus complexe, ce qui augmenterait les coûts, sans compter que les steppers coûtent un peu plus cher de base, et je n'en ai pas vu des masses avec boite de vitesse intégrée... Pour les servos à rotation continue, ils sont simples et permettent de se passer d'un IC pour les commander, mais le RPI n'est pas très bon en PWM, donc il faudrait quand même une puce pour s'en charger, et en plus ils sont chers, un peu gros si on veut un couple sympa, et comme c'est plus rare et spécifique, moins interchangeable. Mais je pense qu'on pourrait se débrouiller pour envisager un châssis modifiable pour accepter d'autres types de motorisation!

Système de propulsion
Cette question se pose elle réellement? il faudra prévoir des roues/chenilles standard, mais il est facile de trouver des systèmes interchangeables, en laissant à tout un chacun le choix
d'utiliser des roues, des chenilles, ou même d'autres systèmes (roues omnidirectionnelles, ou des "roues-pattes", pourquoi pas?).
De la même manière, on peut facilement faire un système qui permet de passer d'une configuration 2 roues motrices à 4 roues motrices, d'une configuration 2 roues motrices + roulette ou 2 roues motrices + 2 roues libres, traction ou propulsion, etc...
Je reviens donc ici sur l'environnement cible. Si on s'est bien débrouillés, il deivent donc ici facile de passer à des chenilles, ou 4 roues motrices, ce qui nous permet d'envisager une utilisation en terrain moins clément, donc avec des bosses, des creux, une surface irrégulière, etc...

j'ai testé mon robot en extérieur, sur un sol pas si plat, et avec les chenilles il se débrouille plutôt correctement... Je vois pas mal de façons pour lui de se coincer, mais avec une meilleure conception ou tout simplement des chenilles plus grosses, il pourrait franchir déjà beaucoup plus d'obstacles!

bref, on peut envisager une adaptabilité du robot au terrain par une possibilité de modifier facilement l'aspect motorisation et l'aspect propulsion, dans les contraintes de la carte de contrôle des robots... Et même sur ça, comme on aura bien standardisé, on peut envisager la possibilité d'utiliser un modèle plus puissant. Mais bon si on consomme plus, il faut de plus grosses batteries, donc un plus gros chassis, et la ça commence à faire beaucoup de changements :)

Module de gestion des moteurs
Je reprends les propositions de mike :
  • Tension d'alimentation des moteurs comprise entre 3V et 24V;
  • Capable de délivrer 2A en continu;
  • Protection de sur intensité;
  • Commande simple en PWM + direction;

Circuit d'alimentation
Je reprends les suggestions de mike:
accepter entre 3V et 24V -> moi j'aurais vu moins large, genre 3-12v, ou alors même plusieurs modules adaptés à des plages plus étroites à choisir selon les batteries qu'on choisit, pour réduire le cout.
alimenter le rpi en 5V de manière sécurisé -> obligatoire sinon le Pi ne fonctionnera tout simplement pas
intégrer la recharge -> moi je suis complètement pour, mais peut on le faire pour pas cher?
J'ajouterais toutefois ceci : qu'il y aie une/des broches qui pourraient nous permettre de mesurer la tension de la batterie.
Idéalement, si on pouvait avoir des broches ou brancher un circuit de mesure de l'intensité ce serait parfait, ça permettrait d'envisager
des applications du genre "le robot fait des essais pour voir ce que lui coûte en énergie l'activation de chaque organe", et on pourrait envisager
d'avoir un robot qui optimise ses actions en fonction de l’énergie que ça coûte, ou bien du temps, etc, selon les priorités...
A noter que la mesure de la conso peut permettre d'établir quand les moteurs sont coincés... Mais du coup la ce serait plus précis si on a possibilité
de mesurer ce paramètre aux bornes des moteurs.

Organes sensoriels
A mon sens, ici, on doit être le plus générique possible, et prévoir la possibilité d'utiliser divers types de systèmes.
Cependant, pour un modèle type, il serait souhaitable d'avoir un capteur répandu, éprouvé, et je propose les capteurs ultrasons.
Le capteur infrarouge est envisageable, mais il faudrait sans doute un servo avec pour l'orienter et faire un balayage devant le robot, non?

Châssis
Si on pouvait avoir un système modulaire, un peu à la meccano, mais tout en étant pas trop cher et solide ça serait parfait.
Sinon bah je ne sais pas trop, du plexi? avec des trous réguliers pour assembler des trucs dessus? je n'ai pas trop d'idée ici,
dans mon cas je fabrique les châssis avec ce que j'ai, ou alors sur mesure si j'ai envie d'optimiser. Je n'ai pas beaucoup d'expérience
dans le domaine des châssis de robots, et je suis séduit par le tuto que j'ai lu ici sur la fibre de verre/fibre de carbone, mais la encore
c'est du sur mesure, et difficile à proposer comme "bidule standard à acheter à tel ou tel endroit".

Programmation
Idéalement, ce serait parfait si on pouvait programmer le robot dans le langage de notre choix. Du coup si il y a un µC, il faudrait avoir
des codes sources/exemples dans divers langages pour la communication avec ces puces. Pour mon robot, par exemple j'utilise python parce que
j'ai un MCP23017, et que je ne sais pas m'en servir avec du C (établir la communication en I²C, et tripatouiller la puce depuis le C/C++)
Idem pour mon MCP3008.

Composants annexes
SI il faut un ADC, je propose le MCP3008. Mais simplement parceque c'est le seul que je connais, et je sais l'utiliser sur le Raspberry Pi.
Maintenant si vous en avez des mieux (par exemple un modèle I2C, qu'on pourrait chainer pour avoir plus d'entrées analogiques si le souhaite),
ou tant qu'à faire un µC connecté en I2C avec le PI qui s'occuperait de ces questions?

Communications entre modules
Pour l'instant je ne m'y connais pas énormément entre les protocoles de communications. j'aime bien le I2C parce qu’il prend peu de GPIO (juste 2),
qu'on peut chaîner plein de modules tant qu'on met des adresses différentes, et que du coup on garde quand même l’accès aux GPIO dédiés à l'I2C.

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/


#49 geek maxou

geek maxou

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 663 messages
  • Gender:Male
  • Location:Pas-de-Calais 62
  • Interests:Monde UNIX, Développement Web, Jeux Vidéo & tout se qui touche à l'électronique

Posté 11 avril 2013 - 06:55

Bonjour,
Je m'incruste un peu ici pour vous donnez un petit lien d'un contrôleur de moteur (la personne utilise des moteurs de visseuse/dévisseuse avec ce contrôleur)
Le lien:
http://www.franciscodias.net/boards/motor-driver-board
Bon journée à tous :bye:

A.R.M.I

Autonomous Robotics Mechanics Intelligent


#50 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 10:33

Par contre, il y a un point sur lequel je ne te suis pas, c'est quand tu dis "partons sur le modèle B". En fait je suis d'accord pour bosser avec des modèles B en prototypage, mais comme les deux modèles sont TRES proches (normalement, ils sont interchangeables dans un montage qui n'utilise pas l'ethernet), on pas besoin d'optimiser le robot pour un modèle ou pour un autre, on peut faire une conception embarquant simplement un Raspberry pi, au choix de l'utilisateur :)/> Moi aussi, je n'ai que des modèles B pour le moment, donc c'est ce que j'utiliserai ^^ Mais à mon sens on devrait faire en sorte que l'utilisateur puisse indifféremment utiliser un modèle B ou un modèle A!



Pour pouvoir utiliser les deux model A ou B il faut "partir sur le modèle B " car si on peut alimenter le modèle B on peut alimenter le modèle A mais c'est pas réciproque ! D'où le "partons sur le modèle B "

Au passage, le module caméra devrait être bientôt dispo, donc ça rajoutera une option vidéo de haute qualité, faible encombrement,avec un bus rapide, pour pas cher ^^



Je l'attends avec impatience ce module :P j'aimerais bien qu'il soit compris dans les 100 euros :P
normalement il aurait du être disponible au début du mois ! On est le 11 et toujours rien ...

Je t'envoie un MP ^^
Mais pour l'instant du coup je ne sais pas bien ce qu'on doit faire, si tu as des tests préliminaires que je peux faire avec mon matos, fais le moi savoir. Par contre il faudrait que
je me procure un équipement pour mesurer précisément la consommation des composants, car je m'appuie sur les specifications officielles, sans plus de précision que min-max.


Pour les test il faut en faire sur le materiel qu'on a retenu ^^ Pour l'instant, le raspberry ...

déjà faire quelque tests de conso sur le raspberry brancher et débrancer différents périphérique usb etc... ( ce que tu as déjà commencé à faire visiblement ) afin d'être sur! Pareil pour ton régulateur ça serait pas mal ... genre lui demander 1,2 A et voir si il s'éffondre lamentablement ou si il tient quand même un peu ... ( quand on branche quelque chose en usb sur un PC on peut avoir des appel de courants ... ) De même mesuré sa dissipation thermique ! On néglige bien trop souvent ce point ! Ensuite déterminer les références des composants qui sont sur ton régulateur et l'implantation moi je peux me charger de faire le pcb qu'on pourra ensuite implanter directement dans nos cartes et même le modifié de manière à ce qu'il soit " commandable " ... On pourrait par exemeple désactiver le RPI et le reactivé de temps en temps pour économiser la conso !



Au passage, ton approche montage de circuits sera très utile, car si on peut faire certains éléments nous même plutôt que d'utiliser un µC ou un composant tout fait, on peut sans doute optimiser le tout pour l'adapter à nos contraintes...


Je suis plus élec que programmation ou méca ^^ Mais je me soigne et j'espère me soigner aussi grâce à ce projet ^^
( D'ailleurs je découvre presque linux avec ce projet donc j'ai vraiment beaucoup de choses à apprendre ! )

Par contre cela serait vraiment bien d'avoir quelqu'un qui puisse faire des pièces que cela soit par CN ou par imprimante 3D ... de manière à avoir des pièces répétables !

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  

 

 

 


#51 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 11:43

Module de gestion des moteurs
Je reprends les propositions de mike :

  • Tension d'alimentation des moteurs comprise entre 3V et 24V;
  • Capable de délivrer 2A en continu;
  • Protection de sur intensité;
  • Commande simple en PWM + direction;

Circuit d'alimentation
Je reprends les suggestions de mike:
accepter entre 3V et 24V -> moi j'aurais vu moins large, genre 3-12v, ou alors même plusieurs modules adaptés à des plages plus étroites à choisir selon les batteries qu'on choisit, pour réduire le cout.
alimenter le rpi en 5V de manière sécurisé -> obligatoire sinon le Pi ne fonctionnera tout simplement pas
intégrer la recharge -> moi je suis complètement pour, mais peut on le faire pour pas cher?
J'ajouterais toutefois ceci : qu'il y aie une/des broches qui pourraient nous permettre de mesurer la tension de la batterie.
Idéalement, si on pouvait avoir des broches ou brancher un circuit de mesure de l'intensité ce serait parfait, ça permettrait d'envisager
des applications du genre "le robot fait des essais pour voir ce que lui coûte en énergie l'activation de chaque organe", et on pourrait envisager
d'avoir un robot qui optimise ses actions en fonction de l’énergie que ça coûte, ou bien du temps, etc, selon les priorités...
A noter que la mesure de la conso peut permettre d'établir quand les moteurs sont coincés... Mais du coup la ce serait plus précis si on a possibilité
de mesurer ce paramètre aux bornes des moteurs.



Hum concernant la plage d'alimentation je pense qu'il faut essayer d'être cohérent entre la carte d'alim et la carte de gestion des moteur de manière à ne pas avoir à brancher 36 truc non plus même si le robot est modulaire...

Pour moi l'idée c'est : un bloc batterie pouvant entre autre contenir le chargeur intégré qui se connecte aussi bien sur le bloc "alimentation sécurisé " que sur le bloc carte moteur ... Donc si l'une peut accepter 24V et pas l'autre c'est dommage ...

Concernant le chargeur intégré,
Par exemple je peux proposer un bloc d'une batterie 1s 1750 mah + chargeur intégré pour pas trop cher... ça doit être jouable à 5 euros . il suffit d'un câble usb ... par contre dès que ça passe à plus de cellules ... c'est plus pareil ...

De même j'en viens à proposer le raspberry pi + la carte SD avec raspbian intégré pour 35 euros ! ( Tous frais inclus )

Il reste donc 65 euros ...

Communications entre modules
Pour l'instant je ne m'y connais pas énormément entre les protocoles de communications. j'aime bien le I2C parce qu’il prend peu de GPIO (juste 2),
qu'on peut chaîner plein de modules tant qu'on met des adresses différentes, et que du coup on garde quand même l’accès aux GPIO dédiés à l'I2C.


Parfaitement d'accord !

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  

 

 

 


#52 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 01:58

Bon je commence à mettre des logiciels à télécharger sur la drop box.

Je compte mettre un logiciel de cao méca un logiciel de cao elec un logiciel pour programmer les pics...

Si quelqu'un vient à les installer qu'il fasse des imprim écran de l'installation pour aider les suivants s'il vous plait ! ( moi j'ai pas pensé à le faire lors de mes installation et comme je ne compte pas les réinstaller ...

Si vous avez des idées d'autres choses à ajouter n'hésitez pas !

Ps j'attend toujours vos MP pour vous ajouter sur le dossier drop box ! On est seulement 3 sur 9 pour le moment a être inscrit.

D'ailleur au niveau des documents écrits : La gamme office de microsoft, ça convient à tout le monde ou il faut passer en open office ?

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  

 

 

 


#53 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 11 avril 2013 - 02:21

Bon je commence à mettre des logiciels à télécharger sur la drop box.

Je compte mettre un logiciel de cao méca un logiciel de cao elec un logiciel pour programmer les pics...

Si quelqu'un vient à les installer qu'il fasse des imprim écran de l'installation pour aider les suivants s'il vous plait ! ( moi j'ai pas pensé à le faire lors de mes installation et comme je ne compte pas les réinstaller ...

Si vous avez des idées d'autres choses à ajouter n'hésitez pas !

Ps j'attend toujours vos MP pour vous ajouter sur le dossier drop box ! On est seulement 3 sur 9 pour le moment a être inscrit.

D'ailleur au niveau des documents écrits : La gamme office de microsoft, ça convient à tout le monde ou il faut passer en open office ?


Pour rester dans l'optique d'accessibilité à tous, je pense que privilégier des outils et des formats libres et/ou multi-plateforme est vraiment important. Les documents en version définitive devraient être exportés en pdf, les documents de travail devraient être dans un format indépendant d'un logiciel (Word en l'occurrence). Voici une petite liste pour choisir : http://fr.wikipedia.org/wiki/Format_ouvert#Les_principaux_formats_ouverts . Je sais que tous les formats ne sont pas aussi pratiques, mais a-t-on besoin de documents complexes ? Du .txt sera suffisant (avec éventuellement des réf vers les autres documents) pour le contenu. À mon avis, l'idéal est le .tex mais je ne vais pas imposer à tout le monde de s'y mettre juste pour ça (mais vous devriez essayer, c'est pas dur ;)).
On est sûrement pas tous sous Windows, donc pour permettre à tous de lire/modifier les documents, c'est vraiment plus pratique. Pour ce qui est des logiciels de CAO, le plus important est que le format d'échange soit lisible par les différents outils (d'où l'intérêt des formats libres).

Accessoirement, l'intérêt de Google Drive (le nouveau google docs), c'est d'avoir tout en ligne (éditeurs + fichiers) et sûrement plus de place que DropBox (dans mon cas, Dropbox fait 3 Go dont une partie utilisée par les autres fichiers que je partage avec mes contacts). Ca demande forcément une connexion internet, mais il est possible d'exporter dans divers formats. L'aspect multi-sources viendra par manque de place sur DropBox, donc il vaut mieux multi-sourcer en fonction du type de données qu'on échange (code versionné sur svn, logiciels sur DropBox, documents divers sur Google docs) plutôt qu'effectivement avoir plusieurs sources hétérogènes. Par ailleurs, soyons réalistes : il n'y a pas besoin d'échanger par un tel système des logiciels téléchargeables sur internet.

Modifié par R1D1, 11 avril 2013 - 03:34 .

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

#54 thermo_nono

thermo_nono

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 825 messages

Posté 11 avril 2013 - 03:57

Je plussoie la requête de R1D1 :
je viens d'éditer la liste des motivés sur la dropbox afin de m'y ajouter.. j'utilise open office qui ne pose pas de souci pour ouvrir le fichier, par contre il ne peux pas le sauvegarder en '.xlsx', un bon vieux '.ods' m'aurait permis de sauvegarder.

#55 Black Templar

Black Templar

    Membre

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

Posté 11 avril 2013 - 04:01

Je plussoie la requête de R1D1 :
je viens d'éditer la liste des motivés sur la dropbox afin de m'y ajouter.. j'utilise open office qui ne pose pas de souci pour ouvrir le fichier, par contre il ne peux pas le sauvegarder en '.xlsx', un bon vieux '.ods' m'aurait permis de sauvegarder.


Plop !

Normalement, tu peux !
J'ai utilisé open-office pour éditer le doc et il me l'a bien sauvegardé au format office.

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


#56 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 04:42

Je plussoie la requête de R1D1 :
je viens d'éditer la liste des motivés sur la dropbox afin de m'y ajouter.. j'utilise open office qui ne pose pas de souci pour ouvrir le fichier, par contre il ne peux pas le sauvegarder en '.xlsx', un bon vieux '.ods' m'aurait permis de sauvegarder.


Pour ce genre de chose n'hésitez pas à prendre l'initiative de changer le format en recopiant les données qui étaient présente ! Sans oublier de compléter le release note ! =)

Plop !

Normalement, tu peux !
J'ai utilisé open-office pour éditer le doc et il me l'a bien sauvegardé au format office.


Il faut choisir le format le plus adapté pour tout le monde ! C'est pas par ce que j'ai ouvert un format Xls qu'il doit rester ainsi ;)

N'hésitez pas à compléter les dossier que j'ai ouvert ! Et à rajouter les dossiers qui vous semblent utile ! faisons juste attention à ce que cela reste efficace !

Il faudrait rédiger un cahier des charges complet par exemple ... quel format ? Word ? Si il y a quelqu'un qui se sent motivé de reprendre ce qu'on a commencé à dire qu'il se sente libre de faire ! Pareil pour l'ensemble des références dont on a parlé ... un excel ? Un doc récapitulant les prix de ce qu'on met dans le robot et qui commence donc par ce dont on est sur : la raspberry avec son prix ...

Ainsi de suite ! Si chacun fais un peu on peut faire beaucoup !

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  

 

 

 


#57 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 11 avril 2013 - 05:17

Pour en rajouter une couche (sur l'intérêt de subversion), que se passe-t-il en cas de conflit : deux utilisateurs travaillent sur le même fichier en même temps, l'un fait une sauvegarde (et envoie en ligne la version modifiée) et l'autre sauvegarde ses modifications puis envoie, sauf que le fichier que renvoie le second ne contient pas la modification du premier ?
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#58 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 05:35

Pour en rajouter une couche (sur l'intérêt de subversion), que se passe-t-il en cas de conflit : deux utilisateurs travaillent sur le même fichier en même temps, l'un fait une sauvegarde (et envoie en ligne la version modifiée) et l'autre sauvegarde ses modifications puis envoie, sauf que le fichier que renvoie le second ne contient pas la modification du premier ?


en fait dans ce cas, une copie est créé avec le titre du document l'ajout de la mention "copie en conflit " et le nom de la personne qui l'a modifié.

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  

 

 

 


#59 dydyouaki

dydyouaki

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 792 messages
  • Gender:Male

Posté 11 avril 2013 - 07:14

Je viens de mettre en ligne le cahier de charge. "Cahier de Charges ( 11/04/2013 )" . Si il faut modifier ou ajouter , faites le car je l'ai mis en WORD , tout le monde a WORD(je crois)
Merci a tous
Cordialement Dylan.

#60 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 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é 11 avril 2013 - 08:33

Je viens de mettre en ligne le cahier de charge. "Cahier de Charges ( 11/04/2013 )" . Si il faut modifier ou ajouter , faites le car je l'ai mis en WORD , tout le monde a WORD(je crois)


Bravo pour cette initiative =)
Au pire des cas si quelqu'un trouve que word c'est pas bien il copiera le contenu et le mettra sous un nouveau format ! Au fait retourne voir dans liste des motivés =) il y a deux trois truc à compléter ;)

Ps n'oublie pas de gérer le release note ça prend 30 secondes mais c'est super pratique !


Bon je pense qu'il faudrait qu'on se répartisse certaine tâches ! Si quelqu'un veut bien se dévouer à noter les différentes références qui on été donné dans la discussion par exemple en les rangeant dans différentes catégorie ça serait pas mal ...

de même si quelqu'un pouvait trouver des référence sur des codeurs sympas et peu cher voir même un motoréducteur CC avec le codeur intégré à moins de 10 euros ça serait top !

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  

 

 

 





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

0 members, 0 guests, 0 anonymous users