cocothebo

Salut,

Je te souhaite de réussir ton projet, mais j’émets quelques interrogations...

Tu parles de coder un OS...tu es programmeur? bas niveau? parce que même dans ce cas réaliser un OS c'est loin d'être facile et surtout très très long, surtout pour un vrai ordinateur...

Pour les calculs, tu parles d'avoir dimensionné ça par le calcul, tu peux nous expliquer ta méthode, je trouve en faisant un rapide calcul de puissance nécessaire que tes moteurs sont un peu surdimensionnés.

prenons les bras:

• 140W 30rpm
• besoin de faire une traction en une seconde.
• Partons de P(W) = C(N.m) w(rad/s)
  • ici on connait P=140W et w=3.2rad/s (environ)
  • on a donc C=140/3 = 43.75N.m => environ 440kg.cm et la trouver un servo de ce couple, ça va être cher et compliqué donc faut faire ça toi même, un moteur, un réducteur, un asservissement...
• Pour simplifier disons que lors d'un traction, on part bras tendu, et on éloigne jamais le corps de plus de la longueur du bras (la partie entre l’épaule et le coude).
  • D'après http://villemin.gerard.free.fr/Biologie/CorpsPro.htm#bras, pour un humanoide de 135cm, son bras fera environ 18cm.
  • On a donc un moteur qui en théorie (i.e. sans perte ce qui est très optimiste je l'avoue) pourra soulever au bout des 18cm de ses bras
    • (440/18) *2 bras => plus de 48kg
  • mais en vrai, pour faire des tractions, on a pas les avants bras fixes à la verticale sous la barre, le poids est donc très franchement plus proche que la longueur du gras ; d'ailleurs en faisant un mouvement presque parfait on devrait être au pire à environ la moitié de l'épaisseur du robot, ce qui dans ton cas devrait être vers disons 10cm (à la louche), bref ça donne plutôt que tes moteurs permettent de faire les tractions pour
    • (440/10) * 2 => 88kg
  • même si on considère l'efficacité:
    • 70% d'efficacité pour le moteur et que la puissance donnée est la puissance en entrée pas sur l'arbre en sortie
    • 60% pour le réducteur
    • on trouve 88 * 0.7 * 0.7 = plus de 35kg soit 50% de plus que ton objectif de poids.
    • et ça ne tient pas compte qu'en fait il y a moteur pour le coude et l'épaule, ça doit aider encore un peu.

Après le devis poids a été évalué ou c'est juste un souhait le moins de 25 kg? je trouve ça très peu, prenons toujours l'exemple d'un bras:

• 3 moteurs 140W => exe https://hobbyking.co...nner-motor.html, 180g les trois
• faut un réducteur 230* qui supporte les 44N.m style http://www.banebots.com/product/P60S-5433-3.html, presque le kg les trois
• doigts et paumes, 10 servos , 600g
• reste encore quelques moteurs de torsion, faudrait faire les calculs comme avant, mais disons pour les 6 moteurs 600g

La déjà sans structure, on est à 2.3 à 2.4 kg et pour un seul bras. Même avec une structure très légère (vu le couple déployé) on sera vers 6kg pour les deux bras.

Les jambes logiquement seront encore plus lourdes, à la louche vu les moteurs annoncés, 10kg. Reste la tête et le buste, mettons 1kg la tête et 4kg le buste.

Paf 21kg déjà.

On a pas l'electronique, ni les batteries, bref ca va être très très juste, surtout que j'ai du oublié des morceaux...

Bref je suis pas la pour dire c'est tout faux, au contraire, mais si je voulais me lancer dans un projet (pe en plus petit ça me semble trop compliqué la), je ferrai ce style de calculs, et pour moi la on est vraiment aux limites du cahier des charges. 

Je suis en revanche très intéressé par tes calculs de dimensionnent, les miens sont simplistes et à la louche et pe aussi que je me trompe

Bref si je peux comparer ton dimensionnement avec ce que je ferrais, ça serait super!

Salut,

super projet!

Je pensais moi qu'en fait ce type de système fonctionnait sur une comparaison de déphasage d'une source pulsée.

Genre les mètres bosh, j'en ai un ça marche bien et la précision est de l'ordre du mm, dès quelques cm et vu le tarif, il ne doit pas y avoir une electronique bien avancée.

Tu as mis le calcul dans un post précédant et donc pour 5 cm minimum, il faut avoir un circuit 0.4ns ce qui commence à être costaud, ça fait du > à 2Ghz.

sachant que pour avoir en plus une précision mettons de 1cm, faut du 10GHz, ce qui me semble hors de portée.

Suis pas très calé en phototransistor mais je serai très étonné qu'un phototransistor puisse allé aussi vite.

Par contre avec le déphasage, en ayant la bonne modulation ça doit être accessible. Par contre ça contraint un peu plus la distance max possible, vu qu'elle va être modulo de la période de modulation. Mais après tu peux faire quelque chose multi fréquence si c'est trop facile

Dans tous les cas je vais suivre avec intérêt tes avancées!

Bonjour,

Si débat il ya alors moi je vais pas présenter de solutions parce que pour moi yen a surement des sous optimales mais qui au final ne feront pas le job...

Je m'explique, comme le décrit bien Mike118, un servomoteur "simple" type modélisme est asservi en position et seulement en position. Ici on veut passer d'un asservissement en position pour aller plus vers un asservissement en vitesse (voir après aussi accélération) et en position:

la consigne passe de "va a 152,354°" à "passe de ta position actuelle à 152,354° en 2s".

Dans l'absolu, je pense que ça rajoute une couche dans l'asservissement, il faut gérer la position dans le temps.

La solution proposée de découper avec una base de temps fixe et/ou incrémentation fixe fonctionnera très bien à un point de fonctionnement donné du système, cad par exemple servo à vide, on avec un effort de 1kg.cm ou plus ou moins.

Bref le problème vient du fait que le servomoteur n'a pas une vitesse fixe mais une vitesse qui est fonction du couple qu'il doit fournir, plus la charge est élevée plus il va lentement.

Ce phénomène doit donc être pris en compte, mais malheureusement sur un servo simple, il n'y a aucun retour, on ne peut donc pas soit savoir la position actuelle (ce qui permet d'accélérer ou ralentir pour rester dans le tempo imposé) ou encore connaitre la consommation qui est liée au couple demandé qui lui est lié à la vitesse du servomoteur.

Bref sans bricolage physique du servomoteur (je ne parle pas de servo style dynamixel qui fournit je crois ces infos), on aura une sorte d'asservissement qui est juste théorique, donc toute variation sur la vitesse réelle du servo fera qu'on aura une erreur non détectée, et donc un tempo complétement faux.

Je pense que c'est à cause de cela que la plupart des robots marcheurs (pas seulement humanoïdes) amateurs ne fonctionnent au final pas très bien, ils sont fait indirectement pour bien fonctionner à un effort donné, mais si cet effort change, ça fonctionne de moins en moins bien voir plus.

Une façon toute aussi sous optimale régulière de faire et de par exemple ne faire bouger les membres durant la marche qu'une fraction du temps, en gros on lève la patte, on l'avance, on la repose puis on attend...

Effectivement si le mouvement est moins rapide, la marche fonctionnera toujours vu q'uon avait prévu du temps "au cas ou", par contre ça limite énormément les possibilités, et je pense que ça doit même être très dur au final à dimenssioner correctement.

(Une autre façon est de franchement surdimensionner les sera, comme ça l'impact de l'effort est diminué, mais ça a aussi très vite des limites)

Attention, ici je ne juge absolument pas le travail sous conséquent réalisé par d'autre, loin de moi cette idée, j'essaye de comprendre pourquoi c'est si difficile à faire "correctement". Après je n'ai jamais (encore) fait de robot mobile ou autre, donc la théorie c'est joli, en pratique on commence petit (donc pas de double triple quadruple asservissements), et même comme ça on a déjà beaucoup de problèmes

Pour pas être globalement juste dans le négatif, moi si je devais faire ce genre de manip, j'essayerai de mettre en place deux choses:

• niveau physique, le hack du servo pour avoir un retour sur sa position (facile à faire, faut juste avoir accès au potentiometre de recopie)
• niveau soft, un fonctionnement par interruptions avec un échantilonage de la position un ordre de grandeur plus rapide que ma durée minimum souhaitée pour le système. En gros si on dit je veux gérer des déplacement jusqu'à 10ms, avoir un échantillonnage de la position du servo à 1ms, et une interruption qui arrive toute les ms aussi. L'idée après est de faie un PID ou autre pour corriger la vitesse en fonction de l'ordre de base et de la position réelle du servomoteur, en simplifiant du genre "durant cette ms je devais me déplacer de X°, en fait j'en suis à X+Y°, donc je réduis l'angle de mon prochain ordre", bien sur si dans la ms la position n'est pas atteinte, je suis au dessus des capacités de mon système, donc à voir comment réagir.

Un point important ici est le fonctionnement par interruption qui est pour moi beaucoup plus flexible et performant pour faire des taches répétitives, mettre des delay partout dans un arduino, c'est facile et rapide à mettre en place, mais ce n'est ni flexible, ni une bonne façon de faire pour quelque chose de cyclique.

Attention aussi à ton poids, si je compte bien il te faut:

• 7 servos par jambe
• 6 par bras
• 4 de colonne

Soit 30 servomoteurs minimum, a 50g chaque, tu as déjà 1,5kg sans compter la structure, ni électronique et ni batterie (si tu veux de l'autonomie, il va te falloir genre 2 voir 3kg de batterie).

Bref ça me semble un peu léger 10k au final (pour rappel Nao qui fait 50cm de haut pèse déjà presque 5kg)

@ashira oui bien sûr, moi j'ai réduit le problème à chaque fois à une articulation parce que je ne sais pas faire pour plusieurs (ça doit se calculer mais ça devient quand même plus complexe), j'ai le sentiment (pe mauvais) que c'est le cas le pire de travailler comme ci on avait q'une seule articulation et tout le poids à bouger dessus.

Donc mes pseudos calculs ci dessus ne sont la que pour essayer de dégrossir rapidemment (quoi montrer comment je ferrai, là il manque des infos pour être sur)

En plus ça devrait être un calcul itératif, je fais une première estimation du poids, et donc de ce qu'il me faut, si ca existe dans le poids de départ, super, sinon on recommence avec pe un peu plus de poids mais des actuateurs plus performants...

Je te rejoins grandement sur le problème de jeu sur un humanoïde, de mémoire poppy ne marche pas /à beaucoup de mal à cause de ça et même si les servomoteurs utilisés sont pourtant plutôt précis.

Moi le gros problème que je vois à utiliser des servo linéaire, c'est la non réversibilité (je sais pas si c'est le terme), bref un servo moteur tu peux le faire tourner/bouger à "vide", un moteur + crémaillière c'est plus compliqué (même si surement mieux qu'une vis sans fin qui ne l'est pas du tout), on risque de faire suater des dents...

je suis aussi d'accord que faire un bras, même pas très bien propotionné, pour voir, le poids, la cinématique et les efforts en jeu permet de voir si les calculs simplifiés théoriques tiennent la route. Parce que entre théorie et pratique, hein !

Salut,

Alors dur dur de dimensionner un moteur de cette façon...

Si on prend un couple en rotation, on a une belle formule qui dit que la puissance = couple * vitesse

Donc pour une même puissance, si tu diminues la vitesse, le couple augmente à l'inverse, c'est ce qui est fait partout dans les servo moteurs: un moteur qui tourne vite mais qui a très peu de couple (les moteurs DC quoi, on sait les faire tourner vite mais moins leur faire avoir bcp de couple), auquel on ajoute un réducteur qui dimininue la vitesse, ce qui augmente le couple!

Si on prend ton exemple de moteur maxon (moteurs de très bonne qualité, mais le prix va avec), il est défini comme un moteur de 5W.

Si tu prends la vitesse nominale et son couple associé, tu vas voir que tu arrives à presque ces fameux 5W ce qui donc est cohérent (couple en N.m et vitesse en rad.s-1):

7300rpm = 764,45 rad.s-1   ==> 764,45 * 0,00622 = 4,76 W

Bref un couple tout petit mais une vitesse de rotation élevée, 7300rpm (ou tour par minute en français), ça fait quand même plus de 120 tours par seconde.

Si on prend un servomoteur de modélisme plutôt rapide, on est entre 1 et 2 tours seconde, avec ce moteur (en néglgeant les pertes dans cet exemple) pour 2tours par secondes, la puissance restant en gros la même (puissance du moteur), le couple devient 60 fois plus fort (passage de 7300 rpm a 120 rpm) soit 0,37 N.m soit presque 3,7kg.cm

Au final pas de miracle, à des vitesses "décentes", il faut plus de puissance au moteur, 5W sera peut être un peu faible (même à 1 tour seconde, on aura moins de 7kg.cm), si tu vises le 60kg.cm à mettons 1,5 tour seconde, il te faut une puissance de sortie d'environ 55W

(5,88 N.m * 9,43 rad.s)

Mais ça c'est la puissance en sortie du réducteur, si on prend 60% d'efficacité au réducteur (5 étages environ) on doit alors avoir environ en sortie moteur une puissance de 55/,6, soit 92W, mais idem ton moteur à une efficcité qui est pas 100%, mettons 85% (en ayant de bon moteurs), soit 92/,85, soit 108W

Bref il commence à falloir un peu de puissance.

Maintenant si tu veux comparer à un servomoteur type modélisme ou même dynamixel, c'est plus dur, vu que dans les specs tu as souvent la vitesse à vide et le couple de maintien (donc à vitesse nulle), ce qui permet d'avoir des servo moteurs de 60kg.cm qui ont des moteurs bcp bcp plus petits; mais vers leur valeur de couple maximal, leur vitesse est plus faible que celle annoncée.

Donc pour conclure, le plus dur la dedans, c'est de trouver la vitesse maximum à laquelle tu voudras bouger l'articulation visée. Une fois cette vitesse connue, il te faut trouver le couple nécessaire (un coup de trigonométrie en approché, sauf si tu veux avoir un mouvement passant par l'horizontale); si ta jambe ne doit pas aller jusqu'à l'horizontale, alors le couple nécessaire sera moindre.

Bonne continuation

Ajout: Par contre pour calculer la force engendrée par un moteur et une vis (le cas de tes actionneurs linéaires), la je sais pas faire, mais il me semble qu'il n'y a pas longtemps qqn avait fait un post pour expliquer comment faire ce calcul, par contre je ne sais plus ni ou ni qui :s

Ya pas de quoi

Ca m'a permis de me remettre et approfondir cette problématique du stockage de données en flash ce qui ne peut qu'être bénéfique.

Ca permettra aussi à aider d'autres personnes si un jour ya besoin, d'ailleurs si un modo (ou toi) peut rajouter les mots clés qui vont bien dans le titre du sujet, par exemple PROGMEM ou qqc en raaport avec le stockage en flash de données programme.

bonne continuation

Bon déjà c'est une "bonne" nouvelle, on sait qu'on accède pas correctement aux animations.

Reste à corriger ça!

N'ayant pas pu encore testé (même si je désespère pas de le faire), ça m'embête de te donner des bouts de codes qui ne marchent pas, mais bon je tente une dernière chose, à voir si ça passe

Si tu ne comprends pas ce que j'explique là, c'est normal, je le fais pour potentiellement d'autres developpeurs qui pourront alors corriger si besoin est mes propositions. Si tu veux voir ce que je propose saute une 20aine de lignes, tu auras le bout de code modifié (remplacement de ppm_read_byte_near)

Donc le problème vient je pense du fait que les animations sont des tableaux à 2 dimensions, ce qui peut être vu comme des tableaux de tableaux, ou encore pour un programme C comme un pointeur de pointeur.

Revenons rapidemment à la base de la représentation mémoire, quand on déclare un tableau genre

char monTableau[] = "ceci est une chaine de carac";

Au final, monTableau est un pointeur sur une zone mémoire continue de 29 octets (28 char de la chaine + la fin de chaine), le pointeur est donc l'adresse du début de cette zone mémoire.

Si maintenant on fait un tableau de tableau

char monTableau2dim[][]={"Chaine 1","chaine 2","chaine 4","chaine 5"}

Cela est équivalent à

char chaine1[] = "chaine1"; char chaine2[] = "chaine2";
char chaine3[] = "chaine3"; char chaine4[] = "chaine4";
char monTableau2dim[] = {"chaine1","chaine2","chaine3","chaine4"};

Bref on a donc monTableau2dim qui est un pointeur sur une zone mémoire qui contient 4 pointeurs vers des chaines de caractères. Chaque pointeur vers des chaines pointant lui même sur une autre zone mémoire de la bonne taille (8 octets a priori).

Pourquoi toutes ces explications? parce que maintenant on ne veut plus mettre le tableau en RAM mais en mémoire flash, pour cela on utilise PROGMEM qui le permet, mais après il faut utiliser des fonctions spéciales pour accèder aux données, puisque elles ne sont plus en RAM (pgm_read_XXX_YYY).

Hors dans notre cas présent on utilise 

pgm_read_byte_near(anim[i][x]);

qui va lire la données en flash située à l'adresse du pointeur anim[i][x], mais ce pointeur est en fait un pointeur de pointeur de données toutes en mémoire flash.

Il faut donc utiliser les fonctions d'accès à la mémoire flash et non pas accéder au pointeur en RAM.

Bref pour résumer mon idée, il faut utiliser 2 fonctions pg_read_machin pour que ca retourne un caractère de l'animation.

il faut donc remplacer

pgm_read_byte_near(anim[i][x]); 

par (et j'ai bien sur un doute sur l'ordre des pointeurs)

pgm_read_byte_near(((char*)pgm_read_word_near(&anim[i]))[x]); 

Alors j'utilise un pgm_read_word_near parce que la on récupère le pointeur (et pas la valeur pointée) de l'animation voulue (anim[i]), comme c'est le pointeur, il faut mettre un & devant, et de mémoire un pointeur pour arduino fait 2 octets, d'ou la lecture d'un word et non un byte.

Bonjour la modification peut être faite relativement facilement, et donc seule

La première chose à faire est de modifier chaque animation de "bouton" (ou chaque occurence si c'est dans un seul fichier)

tu passes le 

int anim1[][50]= {

par 

char anim1[ ][50]= {

et de la même façon (puisque cette méthode utilise tes animations)

void drawAnimation(int anim[][50], int framecount)

par

void drawAnimation(char anim[][50], int framecount) 

avec cette modification, tes tableaux prendrons déjà 2 fois moins de place.

Si à la compilation ça te dit encore que tu as un manque de place alors il va falloir modifier un peu plus mais toujours très simple:

tu remplaces:

char anim1[][50]= {

qu'on a modifié au dessus par 

PROGMEM prog_char anim1[][50]= {

toujours pour chaque animation de "bouton" et il faut rajouter au tout début du fichier ou tu as rajouté les PROGMEM, la ligne

#include <avr/pgmspace.h>

et dernière modification, tu remplaces dans drawAnimation

void drawAnimation(char anim[][50], int framecount)
{
 Serial.print("showing animation FRAMES:");
 Serial.println(framecount); 

 for(int i=0;i<framecount;i++)
 {
  //display frame
  for(int x=0;x<50;x++)
  {
    uint32_t c = Color(0,0,0);
    if(anim[i][x]=='r') c = Color(255,0,0);    
    if(anim[i][x]=='g') c = Color(0,255,0);
    if(anim[i][x]=='b') c = Color(0,0,255); 
    

par

void drawAnimation(prog_char anim[][50], int framecount)
{
 Serial.print("showing animation FRAMES:");
 Serial.println(framecount); 

 for(int i=0;i<framecount;i++)
 {
  //display frame
  for(int x=0;x<50;x++)
  {
    uint32_t c = Color(0,0,0);
    if(pgm_read_byte_near(anim[i][x])=='r') c = Color(255,0,0);    
    if(pgm_read_byte_near(anim[i][x])=='g') c = Color(0,255,0);
    if(pgm_read_byte_near(anim[i][x])=='b') c = Color(0,0,255); 

et normalement (sauf si les tableaux d'animatons sont utilisées ailleurs mais j'ai vu que ça dans le code fourni), avec cette deuxième modification, tes tableau seront en mémoire flash et plus en RAM.

Par contre tu risques de perdre un peu de vitesse d'accès à ces animations.

Bonjour à tous!
Ca fait quelques jours que je me pose la question : Est il possible de faire un suivi de personne avec une vue en 2d?
J'ai actuellement une webcam classique (2d) dans la tête du robot, comme j'aimerai qu'il interagit avec des personnes je me demande si je vais la garder..
J'ai regardé plein de video sur Youtube, notamment avec des kinects. Ca semble très efficaces!
Alors y'a t'il des algorithmes efficaces avec la 2d pour arriver a ces résultats?

Salut,

Oui cela est tout à fait est possible avec un simple flux video.

Un algo "connu" pour la détection de visage (ou d'objet d'ailleurs) est celui de Viola et Jones (http://fr.wikipedia.org/wiki/M%C3%A9thode_de_Viola_et_Jones).

Si tu ne veux pas t'embêter avec le traitement d'image (ou que tu ne veux pas un algorithme vraiment très particulier), le plus simple reste d'utiliser openCV qui possède tout ce qu'il faut ou presque pour faire du traitement d'image.

Après suivant ton processeur, tu ne pourras pe pas utiliser openCV directement, mais comme cette lib est open source, tu peux regarder comment c'est implémenté.

Un exemple de détection basique de visage avec openCV : 

http://studio-horatio.fr/2012/03/16/tuto-opencv-facetracking/

(après je connais pas cet exemple la, mais sur google, en cherchant openCV visage detection par exemple tu auras pleins d'exemples)