Aller au contenu


Photo

R.Damil, un mini robot ultra simple, à très basse consommation


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

#1 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 10 avril 2013 - 05:04

Bonjour à tous! Je souhaiterais vous présenter un petit projet qui a commencé comme un simple test. Au départ, je me suis demandé quel était le robot le plus simple que je pouvais faire avec le matériel à ma disposition. J'ai donc décidé de faire un Robot basé sur une puce Atmel ATmega328p, la puce qui équipe le Arduino Uno R3. Seulement, je n'utilise ici que la puce. Pour la motorisation, je m'appuie sur 2 servomoteurs à rotation continue, car il suffit du coup d'envoyer les signaux adéquats pour les faire tourner dans un sens ou dans l'autre, et je n'ai donc pas besoin de ponts en H, ou d'un quelconque driver de moteurs. Enfin, pour les capteurs, je m'appuie sur un capteur de distance infrarouge, parceque j'en ai un, qu'il ne requiert qu'une entrée analogique pour fonctionner, et que c'est une méthode éprouvée.

Je vais donc me lancer dans la construction d'un robot à évitement d'obstacles quasi minimal. Il ne sert à priori à rien d'autre qu'à faire des tests et valider des hypothèses. En commençant la construction, je me suis décidé également à le faire le plus petit possible, et devant sa simplicité, je me dis que tant qu'à faire, je peux tenter de lui donner la plus grande autonomie envisageable. Je vais donc maintenant vous décrire ma démarche.

Durant le sujet, les images seront cliquables pour avoir une version haute résolution.

Le robot : R.Damil.
Je vous présente donc R.Damil, mon mini robot. Ses dimensions sont relativement réduites : 70mm de long, 95mm de haut, et 85mm de large. Il est assez léger, puisque sa masse est de 335g, batteries incluses.
La conception est simple: il s'agit d'un robot basique à conduite différentielle, à deux roues motrices, et avec deux roulettes omnidirectionnelles pour la stabilité. Les roues font 65mm de diamètre, et sont entraînées par des servomoteurs à rotation continue basés sur les Futuba S148.
Ce sont d'assez gros servomoteurs, avec 45g pièce. Je les ai assemblés de la façon la plus compacte possible :
Image IPB

Sur la photo, on peut voir que les servomoteurs sont fixés sur des équerres en plastique avec des vis et écrous, et ces équerres sont fixées de la même manière sur une planchette de bois de 5mm d'épaisseur, qui correspond au fond du châssis du robot. Cela suffit à maintenir le tout en place, et le plastique autorise un peu de flexibilité, ce qui permettra plus ou moins d'amortir les vibrations.
Sur la photo, vous pouvez voir un logement à piles AA à coté, pour la référence en taille.
J'ai alors fixé la roulette, une petite d'un demi pouce, en plastique (ce que j'avais sous la main):
Image IPB Image IPB

J'ai fixé une paroi en bois sur l’arrière du robot, qui me servira à installer le logement des batteries et
le capteur à ultrasons. Cette planchette de bois se visse sur le reste du châssis par 3 vis à bois, par en dessous. J'en profite pour visser le logement à batteries dessus. Voici le résultat :
Image IPB Image IPB


Il suffit alors de refermer le logement avec son couvercle, sur laquelle j’accroche la mini breadboard avec de l’adhésif double face.
Je connecte alors les câbles :
  • Le VCC et le Ground, qui proviennent directement de la batterie. L'alimentation des servomoteurs et du capteur sont directement prises ici;
  • L'alimentation du convertisseur analogique-numerique, et la tension de référence sont connectés au VCC;
  • La masse du convertisseur analogique-numerique à la masse générale;
  • Les fils de contrôle des servos sur les broches numériques 5 et 6 car elles sont PWM;
  • Le fil de signal du capteur sur la broche A0 du ATmega.
A ce moment, nous avons fini la construction physique du robot. En effet j'ai choisi de ne pas utiliser de régulateur de tension, justement pour voir si c'était possible. Cela réduit également les sources de consommation électrique. On a donc un robot complet :
Image IPB

Il suffit maintenant de passer à la partie programmation du robot.
Le code est simple : si le robot trouve un obstacle tout près, il recule. Entre tout près et près, il tourne. Plus loin que près, il avance. Je ne donne pas de valeur en cm, car j'utilise la valeur brute du capteur sans me préocuper de la distance réelle. J'ai juste essayé quelques valeurs en mettant ma main devant le capteur, et j'en ai choisi deux qui me plaisaient, 300 et 200. Le capteur IR renvoie une valeur d'autant plus faible que l'objet et loin, et en plus l'échelle n'est pas linéaire. Donc je ne m’embête pas à faire des calculs, la valeur brute suffit à savoir si l'obstacle est proche ou non.

Voici le code complet :
#include <Servo.h>

Servo s1;//gauche
Servo s2;//droite

int s1Pin=5;
int s2Pin=6;
int rangeFinderPin=A0;//broche du capteur d'obstacles à distance

void setup()
{
  s1.attach(s1Pin);
  s2.attach(s2Pin);
}

void s1Forward()
{
  s1.write(180);
}
void s1Backward()
{
  s1.write(0);
}
void s1Stop()
{
  s1.write(90);
}

void s2Forward()
{
  s2.write(0);
}
void s2Backward()
{
  s2.write(180);
}
void s2Stop()
{
  s2.write(90);
}

void moveForward()
{
    s1Forward();
    s2Forward();
}

void moveBackward()
{
    s1Backward();
    s2Backward();
}

void turnLeft()
{
  s1Backward();
  s2Forward();
}

void turnRight()
{
  s1Forward();
  s2Backward();
}

void stopMotors()
{
  s1Stop();
  s2Stop();
}

void motorsTest()
{
    moveForward();
    delay(1000);
    moveBackward();
    delay(1000);
    turnLeft();
    delay(1000);
    turnRight();
    delay(1000);
    stopMotors();
    delay(1000);
}

int readRawDistanceOnce()
{
  return analogRead(rangeFinderPin);
}

int readAvgRawDistance(int count, int delay1)
{
  int i=0;
  int sum=0;
   for(i=0;i<count;i++)
   {
     sum=sum+readRawDistanceOnce();
     delay(delay1);
   }
   return sum/count;
}

void r1()
{
  int dist=readAvgRawDistance(10, 2);
  if(dist>250)
  {
    moveBackward();
  }
  else if (dist >180)
  {
    turnLeft();
  }
  else
  {
    moveForward();
  }
  delay(2);
}


void loop()
{
    r1();
}

A noter que la position neutre du moteur, c'est l'angle 90°. J'ai donc mis les servo à 90 avec le code ci dessus, et j'ai ajusté la petite vis de réglage jusqu'à ce que le servo soit immobile. A ce moment, j'ai pu utiliser la fonction de déplacement r1() dans la boucle principale du robot. Vous noterez que j'ai fait plein de sous-fonctions, car en fait il m'a fallu déterminer quelle valeur correspondait à quel sens. Mais on peut aussi modifier les valeurs saisies pour changer la vitesse du robot dans un sens comme dans l'autre. Cette programmation évite d'avoir à tout modifier si on décide de faire ce genre de modifications.

A partir de là, j'ai pu tester le robot :http://www.youtube.com/watch?v=Y-W6V6ugtqk
Comme vous pouvez le voir, il fonctionne. Ce n'est peut être pas tout à fait parfait, mais ça marche :)
En pratique, j'ai du rajouter une roulette à l'arrière, car quand le robot tournait, il basculait vers l'arrière. Une autre solution serait une tête de brosse à dents, ainsi le robot ne basculerait pas car les poils résisteraient à la compression, mais cela ne générerait pas beaucoup de frottement, car les poils résisteraient assez peu à la flexion.

Dans le prochain post je détaillerai un peu plus l'électronique, et discuterai de l'autonomie.

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/


#2 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 10 avril 2013 - 07:35

Dans un premier temps, j'ai donc pu vérifier qu'il est possible de se passer de régulateur de tension. J'ai pu faire un robot relativement compact, et j'essaierai plus tard
de faire plus petit avec des composants adaptés. Toutefois, pour le moment je vais me pencher sur la question de l'autonomie.

J'ai donc éliminé tout ce qui n'était pas essentiel : pas de régulateur de tension, pas de circuits suplémentaires de commande, rien qui ne serve directement à faire fonctionner le robot.
La liste complète du matériel est donc:
-Un puce ATMega328p (peut être remplacé par un ATtiny85, plus petit, moins gourmand et moins cher) (http://www.adafruit.com/products/123);
-Deux servomoteurs à rotation continue (http://www.adafruit.com/products/154);
-Deux roues (http://www.adafruit.com/products/167);
-Un capteur de distance infrarouge (http://www.adafruit.com/products/1031);
-Une trappe à piles AA contenant 4 Batteries AA rechargeables de 1.2V (3 suffiront, avec des non rechargeables, mais l'autonomie pourrait en pâtir) (http://www.adafruit.com/products/830)
-du fil type jumper wire (bobine de fil rigide à dénuder, ou câbles mâle-mâle) (http://www.adafruit.com/products/288)
-une mini breadboard (facultative) (http://www.adafruit.com/products/65);
-une ou deux roulettes;
-Des vis;
-Deux petits bouts de bois ou de plastique.

Les sources de consommation électrique sont donc :
1-Les servomoteurs;
2-Le capteur infrarouge;
3-le ATmega328p;


Pour les servomoteurs, je n'ai pas les spécifications sur la consommation en charge maximale. Ils sont donnés pour quelques dizaines de mA pour la charge minimale. En prenant large, on peut imaginer 1A en charge maximale. Au vu du couple des servos et du poids du robot, en prenant large, nous pourrions estimer que le robot utilisera 1/3 de la puissance maximale, soit environ 300mA. Comme on a deux moteurs, le couple disponible est doublé, mais du coup les moteurs prendront chacun moins, ce qui fait qu'on aura en fin de compte probablement une consommation du même ordre. Si les deux servos consomment 300mA au total, cela ferait 9h d'autonomie en mouvement continu. Au repos, les servos sont censés consommer moins de 10mA chacun, soit environ 135h d'autonomie.

Le capteur est donné pour une consommation typique de 30mA, et maximale de 40mA. On peut donc s'attendre à une autonomie maximale pour ce seul capteur de 67h.

Une carte Arduino complète consomme assez peu, mais cela se compte quand même en centaines de mA. Cela est du aux régulateurs de tension, à la puce USB, etc. Ici, nous utilisons la puce nue, à une fréquence plus basse (8Mhz). Les spécifications donnent 0.2mA de consommation dans les meilleures conditions, tablons sur 100 fois plus pour être larges, soit 20mA. Au pire, la puce consommera autant qu'une LED classique.

Si on prend la consommation totale estimée, ça ferait 300+40+20, soit 360.
La batterie fait 2700mAh, donc on peut attendre une autonomie de 7.5h en déplacement continu. Sachant que la consommation des servos est estimée, il faudra attendre des expérimentations pratiques pour savoir.

Concernant le robot hors déplacement, on tomberait à 20+40+20=80mA. On pourrait donc avoir 33h d'autonomie si le robot n'utilise pas ses moteurs. Il est possible d'améliorer ce résultat en désactivant les systèmes inutilisés. Je compte faire cela dans une version ultérieure, ou le micro-contrôleur sera capable de couper l'alimentation électrique des servomoteurs et du capteur quand ils sont inutilisés. Ainsi, on n'aurait plus que la consommation éléctrique du microcontroleur, et on multiplierait AU MOINS par 4 l'autonomie, soit 135h d'autonomie au minimum.

Il est sans doute possible d'aller largement plus loin, et en considérant la consommation réelle du ATmega328p, on peut facilement imaginer d'avoir plus de deux mois d'autonomie en mode immobile; et sachant qu'on peut utiliser des modes de veille, on peut baisser la consommation à quelques micro Ampères, ce qui nous mènerait à une autonomie théorique se comptant en années. Toutefois, à ce niveau, le taux d'auto-décharge des batteries serait supérieur à la consommation du circuit.

Je vais donc explorer cette voie, et voir dans quelle mesure il serait possible de concevoir un robot utilisant le soleil pour se recharger, et gérant ses déplacements pour ne jamais tomber à cours, ou au moins capable de s'économiser quand il n'a plus de quoi se déplacer.

De la même manière, on peut imaginer d'utiliser des condensateurs plutôt que des batteries, avec un condensateur pour le µC, et un autre pour le moteur. Celui du contrôleur serait prévu pour que le robot tienne au moins toute une nuit, et le second serait conçu pour que le robot puisse bouger un peu, après une charge d'une certaine durée. Par exemple, une minute de charge pour 25cm. Ainsi on aurait un robot capable de faire des petits déplacements de proche en proche, et pas de batteries s'usant. Reste à voir les condensateurs qui seraient adaptés, si c'est réaliste, ou non.

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/


#3 Mike118

Mike118

    Staff Robot Maker

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

Posté 10 avril 2013 - 07:58

Il aurait juste fallu mettre la planche en bois supportant le capteur du côté de la balle caster au lieu de la mettre du côté opposé !

De la même manière, on peut imaginer d'utiliser des condensateurs plutôt que des batteries, avec un condensateur pour le µC, et un autre pour le moteur. Celui du contrôleur serait prévu pour que le robot tienne au moins toute une nuit, et le second serait conçu pour que le robot puisse bouger un peu, après une charge d'une certaine durée. Par exemple, une minute de charge pour 25cm. Ainsi on aurait un robot capable de faire des petits déplacements de proche en proche, et pas de batteries s'usant. Reste à voir les condensateurs qui seraient adaptés, si c'est réaliste, ou non.


Le principe ( sans microcontrolleur ) existe déjà =) et ce sont des robot assez intéressant du point de vue de leur relative simplicité mais aussi de la gestion de l'alimentation par contre je les trouve peu évolutif selon moi ...

ici tu as un exemple de " solarbot" mais je les connaissais sous un autre nom plus en rapport avec les insectes il me semble mais impossible de m'en rappeler -____-'

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  

 

 

 


#4 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 11 avril 2013 - 12:19

Il aurait juste fallu mettre la planche en bois supportant le capteur du côté de la balle caster au lieu de la mettre du côté opposé !



Le principe ( sans microcontrolleur ) existe déjà =) et ce sont des robot assez intéressant du point de vue de leur relative simplicité mais aussi de la gestion de l'alimentation par contre je les trouve peu évolutif selon moi ...

ici tu as un exemple de " solarbot" mais je les connaissais sous un autre nom plus en rapport avec les insectes il me semble mais impossible de m'en rappeler -____-'

J'ai mis le support du capteur à l'arrière, car ces capteurs IR ont une zone morte assez importante, ainsi je réduis la zone de données bidon. Mais en effet, ça ajoute du poids à l'arrière!
Comme c'est un montage vite fait, je laisse comme ça pour me moment, je corrigerai dans une V2 ^^

Les robots du type dont tu parles, j'en ai vu quelques uns, mais pour ma part ça ne m'intéresse pas réellement, car ils ne peuvent rien faire d'autre que bouger comme ci comme ça... Pour moi il DOIT y avoir un microcontrôleur pour que ce soit programmable, qu'on puisse y mettre un peu d'intelligence, et surtout que le robot obtenu puisse servir à quelque chose en communiquant par ex. L'idée serait d'en mettre un sur mon toit par exemple, avec un module radio, et qu'il mesure des trucs et des machins, en se déplaçant quand c'est nécessaire :)
J'ai tendance à penser que ces machines sans microcontroleurs sont juste des automates :) (maintenant quelle est la définition du robot? ou commence le robot?)

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/


#5 Mike118

Mike118

    Staff Robot Maker

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

Posté 11 avril 2013 - 01:04

J'ai mis le support du capteur à l'arrière, car ces capteurs IR ont une zone morte assez importante, ainsi je réduis la zone de données bidon. Mais en effet, ça ajoute du poids à l'arrière!
Comme c'est un montage vite fait, je laisse comme ça pour me moment, je corrigerai dans une V2 ^^


Je connais ces capteur j'ai les même ;) Mais par contre essaye de retourner la situation ;) En gros je suis en train de te dire qu'il fallait intervertir l'avant et l'arrière ! Mettre la balle caster à l'arrière avec la plache supportant le capteur ;)

Si tu cherches " RMAD le robot fou " dans le forum tu tombera sur mon TIPE. Dedans il y a un robot en tout analogique avec une bille en métale ;)
Un robot peut être sympatique même sans micro controlleur =) D'ailleurs je pense que des fois on confis des tâches à des pics qui seraient 100 fois mieux traité en analogique mais bon ce n'est que mon intuition il faudrait que je le démontre ^^

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  

 

 

 


#6 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 11 avril 2013 - 03:54

Je connais ces capteur j'ai les même ;)/> Mais par contre essaye de retourner la situation ;)/> En gros je suis en train de te dire qu'il fallait intervertir l'avant et l'arrière ! Mettre la balle caster à l'arrière avec la plache supportant le capteur ;)/>

Si tu cherches " RMAD le robot fou " dans le forum tu tombera sur mon TIPE. Dedans il y a un robot en tout analogique avec une bille en métale ;)/>
Un robot peut être sympatique même sans micro controlleur =) D'ailleurs je pense que des fois on confis des tâches à des pics qui seraient 100 fois mieux traité en analogique mais bon ce n'est que mon intuition il faudrait que je le démontre ^^

Je comprends!
Mais la bille est à l'avant l'est car l'equilibre des masses fait que le poids des servo fait le robot pencher vers l'avant, si la bille n'est pas là!
Donc du coup j'ai mis deux ball casters ^^

Je dis pas qu'on ne peut pas faire des trucs rigolos en electronique analogique classique. Le fait est que ça fera des automates adaptés à une tâche, mais du coup, pas de programmation
possible; et encore moins de communications avec d'autres robots...
Ce que j'aime avec le fait d'avoir un bidule programmable, c'est de pouvoir adapter le robot, le transformer, etc :)

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/


#7 Mike118

Mike118

    Staff Robot Maker

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

Posté 11 avril 2013 - 10:47

Je comprends!
Mais la bille est à l'avant l'est car l'equilibre des masses fait que le poids des servo fait le robot pencher vers l'avant, si la bille n'est pas là!
Donc du coup j'ai mis deux ball casters ^^


Hum ... je crois vraiment que je suis pas assez claire en fait ^^ ce que je veux dire c'est qu'il faut changer qui est l'avant et qui est l'arrière et du coup on se retrouve avec la bille à l'arrière sans avoir rien touché et la plaque supportant le capteur on la met au niveau de "l'arrière " le nouveau ^^ là ou se trouve la bille et le côté vers le quel l'équilibre des masse fait pencher le servo !

2 ball caste c'est nécessaire uniquement si tu fais une répartition symétrique des masse avec tes roues au milieu là c'est un peu du gaspillage ^^ ! =)


Je dis pas qu'on ne peut pas faire des trucs rigolos en electronique analogique classique. Le fait est que ça fera des automates adaptés à une tâche, mais du coup, pas de programmation
possible; et encore moins de communications avec d'autres robots...
Ce que j'aime avec le fait d'avoir un bidule programmable, c'est de pouvoir adapter le robot, le transformer, etc :)/>


Les asservissement en analogique ça peut être terrible !

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  

 

 

 


#8 olivthill

olivthill

    Membre occasionnel

  • Membres
  • Pip
  • 143 messages
  • Gender:Male
  • Location:Normandie

Posté 11 avril 2013 - 01:12

Bravo, bravo, bravo !
Super conception, réalisation, et explications.
Merci d'avoir partagé cette expérience sur le forum.

Quelques petites questions :

- A quellle vitesse roule cette petite merveille ?
- Est-ce qu'elle peut rouler bien en ligne, ou est-ce qu'elle dévie d'un côté ou de l'autre ?
- Est-ce qu'elle peut monter et descendre une pente ?

#9 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 12 avril 2013 - 04:51

Hum ... je crois vraiment que je suis pas assez claire en fait ^^ ce que je veux dire c'est qu'il faut changer qui est l'avant et qui est l'arrière et du coup on se retrouve avec la bille à l'arrière sans avoir rien touché et la plaque supportant le capteur on la met au niveau de "l'arrière " le nouveau ^^ là ou se trouve la bille et le côté vers le quel l'équilibre des masse fait pencher le servo !

2 ball caste c'est nécessaire uniquement si tu fais une répartition symétrique des masse avec tes roues au milieu là c'est un peu du gaspillage ^^ ! =)
Les asservissement en analogique ça peut être terrible !

Je comprends maintenant :)/>
En effet, ça a du sens, j'essaierai!


Bravo, bravo, bravo !
Super conception, réalisation, et explications.
Merci d'avoir partagé cette expérience sur le forum.

Quelques petites questions :

- A quellle vitesse roule cette petite merveille ?
- Est-ce qu'elle peut rouler bien en ligne, ou est-ce qu'elle dévie d'un côté ou de l'autre ?
- Est-ce qu'elle peut monter et descendre une pente ?

Merci des encouragements :)/>
Mais pour l'instant c'est loin d'être fini, ce petit robot me servira à beaucoup d'expérimentations :)/>
D'ailleurs je dois vérifier les points que soulève Black_templar, et je referai le châssis de façon plus "carrée", avec les suggestions de mike :)/>

Concernant la vitesse, j'ai fait des tests pour pouvoir y répondre, et le robot fait 120cm en environ 7-7.5s.
En prenant 7.5s comme temps, ça fait une vitesse de 16cm/s. Du coup il est aussi rapide que mon autre robot, R.Berion (lui basé sur un Raspberry Pi)

Dans les premiers tests, j'ai été surpris de voir à quel point il roulait droit. Mais aujourd'hui je l'ai bringuebalé, et il tourne un peu... Ceci dit, vu que les fixations des servomoteurs sont souples (c'est du plastique fin), et elles sont flexibles, sans compter que les roues ne sont pas forcément parallèles, le montage a été fait un peu "à l'arrache". Au départ c'était plus pour m'amuser que pour faire un truc serieux :)/>

Bref, j'espere faire une version 2.0 sous peu, et je ferai des tests de rectitude de la trajectoire. Comme ce sont des servos, je m'attends à une vitesse indiviudelle bien identique pour chaque roue. De par la conception, les masses sont parfaitement équilibrées à droite comme à gauche (le robot est symétrique). En revanche, vu que la finition est approximative, j'ai peut être des déviations... Donc rendez vous à la prochaine version pour déterminer si un tel engin peut rouler droit sans y ajouter des mécanismes de surveillance des roues/sol etc.

Pour les pentes, je vais faire des essais, il faut que je récupère un peu de matériel et je vais tester ça :)
D'ailleurs, c'est un point intéressant, il faudrait que je réfléchisse à un banc d’essai pour tester la capacité de robots à grimper!

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/


#10 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 12 avril 2013 - 05:13

Bon, j'ai fait les tests de pente.

J'ai pris une planche de bois de 50cm de long, dont un coté est placé au sol. L'autre coté est élevé de 5cm, ce qui fait une dénivellation de 10%.
Le robot monte sans problème.

Avec 10cm d'élévation, ça nous fait donc 20% de dénivellation, et le robot monte toujours sans problème.

A 15cm, on passe donc à 30%, et là ça devient plus dur. Le robot monte moins bien, il dérape un peu parfois, mais il monte tout de même systématiquement.

Par contre au dela de 16cm, le robot ne fournit plus assez d'adhérance, et il reste sur place, les roues patinant. Manifestement les pneus n'offrent pas assez d'adhérance.
Si j'appuie sur le robot perpendiculairement au plan de la pente, il parvient à avancer. Donc la puissance n'est pas en question, le problème est au niveau des roues. Je suppose qu'avec des roues offrant une meilleure surface de contact, on pourrait aller plus loin que 30%. J'ai d'autres roues qui semblent avoir une meilleure adhérance, mais elles sont toutes pour moteurs DC, et ce sont les seules roues pour servomoteurs dont je dispose. J'essaierai de faire une version DC de ce robot un jour ou l'autre (d'autant plus que j'ai aussi des chenilles, et là je pense qu'on pourra aller loin en terme de capacité en pente.

Mais bon, c'est quand même pas trop mal, dans l'absolu, 30%... Compte tenu du fait qu'en plus le robot est plus haut que large et long (la longueur avant-arrière est sa plus faible dimension, 70mm, contre 95mm de haut), je trouve ce résultat honorable. Ceci dit les masses sont aussi bas que possible, à moins de faire passer les batteries sous le robot.

Ce serait intéressant d'essayer de faire des robots spécifiquement grimpeurs, je garde cette idée dans un coin de ma tête :)

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/


#11 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 13 avril 2013 - 04:36

Sur la basse consommation, voici un lien ou je résume des choses trouvées sur le net :
http://www.robot-maker.com/index.php?/blog/45/entry-41-tout-ce-que-vous-pourriez-vous-demander-sur-la-consommation-dune-puce-atmega328p-puce-darduino/
Lisez l'article original, il vaut réellement le coup!

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/





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

0 members, 0 guests, 0 anonymous users