Juste pour comprendre, pourquoi tu veux une caméra "gimbal", certes tu pourras l'orienter comme tu veux, mais ce type de gimbal est fait pour du drone, pour contrer les vibrations et dérives.

Dans ton cas ce n'est pas nécessaire, une caméra fixe (ou à la limite sur 2 axes) sera suffisante.

Sur ton lien je pense que tu payes très cher pour le système de stabilisation qui n'aura pas vraiment d'intérêt, idem pour le zoom qui me semble pas nécessaire.

Pour de l'exploration, à mon avis il faut deux choses, une bonne résolution si tu veux exploiter joliment les images et surtout une très bonne sensibilité (ben oui dans un monument abandonné, la lumière manque). Même le zoom est surement superflu, à la limite faire comme les smartphones actuels, une caméra plutôt grand angle et une plus longue focale.

A mon avis il faut mieux que tu investisses dans une bone caméra quitte à y mettre presque le prix de ton lien plutôt que prendre qqc de packagé qui ne sera surement pas bien adapté à ton robot.

Moi limite je partirais sur un APN reflexe (ou pour le poids et la compacité un hybride) pas trop cher, certains peuvent s'interfacer avec un ordi (cherche ce qui est fait pour les photobooth ), ça permet souvent de faire des superbes vidéos, avec un objectif fixe, tu peux avoir une superbe ouverture. Au pire tu prends un petit zoom, un servo et tu le motorises.

Je rejoins Oracid, c'est quand même un prix conséquent.

Vu la taille c'est pas pour quelque chose nécessitant de la puissance, si c'est bien le cas un système à base de servomoteur est simple à mettre en place je pense (avec des servo tout petit)

Moi je connais Plan Do Check Act, mais c'est plus pour la gestion qualité la

Suis pas un expert en oscillo mais si je me souvient bien, il y a deux facteurs super importants sur un oscillo:

1. la bande passante: c'est la frequence jusqu'à laquelle on perd 3dB sur amplitude du signal mesuré (une sinusoide je crois). En gros donc ne lire plus que 70% du signal réel, par exemple ta un signal sinusoidal de 1V crête à crête par exemple, si ta bande passante est 5 fois supérieure à la fréquence du signal, tu liras a peu pret ce 1V (normalement à 2% pret), par contre si ta bande passante est égale à la frequence du signal, ton amplitude sur l'oscillo ne sera que de 0.7V.
2. le taux d'échantillonnage: lui c'est le nombre de fois que l'oscillo va faire une mesure, par défaut sur un signal périodique style sinusoïde, on considère qu'il faut au moins 5 points pour refaire une belle sinusoïde, bref il faut donc par défaut que le taux d'échantillonage soit environ (minimum) 5 fois plus grand que la bande passante.

Donc sauf si la bande passante donnée sur le descriptif n'est pas la vraie, cet oscillo est vraiment très limité.

Autre point sur la bande passante, vu que c'est lié à des filtres/amplis (je crois), la chute du signal n'est pas linaire, donc quand on dépasse la bande passante d'un oscillo en essayant de "voir" un signal de fréquence trop élevée, le signal sera tout plat vu l'atténuation.

Attention, a priori la bande passante de l'oscillo n'est que de 20kHz, donc pour avoir une précision correcte, on doit pouvoir mesurer des signaux analogiques jusque vers 4kHz, bref c'est rien du tout.

(Sur un oscillo la bande passant est donnée pour 3dB de perte, ie que l'amplitude du signal donné par l'oscilloscope n'est plus qu'environ 70% de l'amplitude réelle, si on passe à 5 fois moins que cette bande passante, la précision est d'environ 2%, ce ui reste pas mal)

Après effectivement je ne comprends pas ce qu'ils appellent la mesure de fréquence qui monterait jusque 5MHz...

C'est pas une émanation de feu le forum caliban?

Me semble qu'au départ l'idée était de faire un robot humanoides puis à force ils ont monté une boite (du moins une partie)

Effectivement c'est sympa comme truc

Tiens suis pas vraiment d'accord, pour moi la marche (comme la marche humaine) c'est être capable de rattraper un déséquilibre permanent. Bon ok on pourrait dire que c'est un équilibre qui "bouge" mais bon pour moi la marche dynamique c'est une succession de chutes rattrapées.

Après c'est sur que pour la "base" en robotique c'est une marche purement stable mais c'est aussi ça qui fait que c'est pas du tout "humain".

Salut,

En exemple de classes pour arduino (donc en C++), le plus simple c'est d'aller dans l'API, toutes les APIs style servo ou autre sont des classes et donc en cherchant le servo.h et .c tu as des exemples fonctionnels de classes "arduino" , pour l'utilisation ben un sketch genre pour l'utilisation des servomoteurs dans les exemples de l'IDE et c'est tout bon

J'adore ton travail, cette modélisation est superbe!

Pour les trappes d'accès, ce qui se fait aussi beaucoup en modélisme est d'utiliser des petits aimants pour tenir le tout, c'est pas trop lourd, on peut avoir un bon centrage quand même, et c'est super pratique avec un accès total.

Pour le reste de tes questions malheureusement tu dois déjà en savoir beaucoup plus que moi sur le sujet.

Et aussi ne pas oublier que la fonction "loop()" d'arduino ben en fait comme son nom l'indique c'est une grosse boucle. Pourtant on ne dit pas que c'est bloquant un programme arduino par défaut

en gros le "vrai" programme compilé c'est un truc du genre:

int main(void) 
{
  setup();

  while(true)
  {
    loop();
  }

}

Après pour refaire à la main en non bloquant ya bcp de solutions plus ou moins précises, la plus simple c'est de regarder un début de la fonction le temps et faire le traitement associé en fonction de celui ci.

Par contre ça manque cruellement de précision.

Bien sur on ne fait pas de boucle d'attente (ou delay) ou continuetjs l'exécution, on teste juste si le temps demandé est échu.

Ah ok, moi je parlais plutôt de documentation fonctionnelle, toi tu parles ici plutôt d'architecture du logiciel.

Sur ce point, je ne sais pas si des méthodes existent pour décrire "correctement" une architecture, j'avoue que ça reste compliqué, surtout pour faire une description a priori (la description a posteriori est facile elle )

Dans le monde de la sécurité informatique, une base a été définie pour un référentiel (presque) commun pour évaluer la sécurité d'un produit, ça s'appelle les Critères Communs (ou Comon Criteria en english), une demande est justement d'avoir ce type de documentation (spécification fonctionnelle et de design), mais la méthode pour construire ces documents n'est pas décrite il me semble. Souvent la spécification d'archi ou design est faite a posteriori et décrit les interfaces avec leur éventuelles implication sécuritaires (parce que c'est pour faire des évaluations de sécurité).

Si on lie ce post avec celui sur l'UML qui me semble être la même question, oui un bon diagramme UML permet de décrire un système, mais c'est vite complexe et incompréhensible en fait.

Oui il y a au moins une carac qui est parfois donnée sur les datasheets de servo c'est la "dead band width", bande morte on va dire en français, qui donne le changement minimum dans l'ordre donné pour que le servo bouge, par exemple avec une bande morte de 6µs, un changement dans l'ordre de +/-3µs commencera à faire bouger le servo.

Pour rappel, le servo de modélisme a une commande analogique avec des trames qui suivant la longueur de l'état haut donne la position désirée (d'environ 1ms pour le minimum et 2ms pour le max, après ça dépend aussi du servo), cette impulsion étant envoyée 50 fois par seconde.

C'est pourquoi on a besoin de cette bande morte (ou hysteresis), comme ça si la longueur de l'impulsion change de moins de +/- la bande morte divisée par deux, le servo considère que c'est du "bruit".

Si on contrôle avec un arduino par exemple en utilisant les timers, il se peut qu'avec la précision, même en voulant faire des impulsions de 1.5ms, on ait en vrai des impulsions de 1.51ms ou 1.49ms, sans cette bande morte, le servo moteur essayerai de corriger sa position 50 fois par seconde

=> ca consomme et ca fait du bruit.

Et cette bande morte affecte par contre aussi le jeu "électronique" du servo, si l'angle du palonier change dans dans cette bande morte, la position ne sera pas corrigée. 

Si on reprend l'exemple d'avant, un servo moteur ayant une course 180° entre 1ms et 2ms aura donc une précision de 0,18° par µs, avec une bande morte de 6µs, le jeu permis par l'électronique sera de +/- 0,54°.

=> le servo ne réactualisera sa position qu'après un changement d'environ max 1° dans sa position.

Si on revient à ce que disait Forthman, avec un servo moteur ayant une faible bande morte et un générateur de signal (de contrôle) du servo de faible qualité (qui a bcp d'imprecision), le servo risque de bouger en permanence même si on ne le veut pas.

Dans ce cas deux solutions:

• comme Forthman, on évite d'envoyer trop de trames (si le servo garde sa consigne), donc le signal ne sera plus de période 20ms
• on choisi un servo avec une bande morte plus importante pour filtrer ce bruit, en contre partie d'un jeu électronique plus important.

Après il faut aussi voir la qualité de la commande, pe que la carte maestro (je crois que tu utilises celle la dans Glenn) à un bruit très petit et donc autant chosir dans ce cas un servo avec une bande morte petite, il maintiendra mieux la position demandée.

Ben sur tout ça ne changera pas le bruit fait par la mécanique du servo qui est plus ou moins prononcé en fonction de celui ci. Ca permet juste d'éviter de le faire bouger quand ce n'est pas nécessaire et donc de réduire indirectement le temps ou il fait du bruit.

Salut,

Moi je ne code plus c'est plus simple

Sinon pour moi pas de secrets, si tu fonctionnes avec un lanagage objet il faut bien travailler le découpage en classes pour avoir qqc de "léger". Ce que je veux dire c'est que même si certains traitements sont très complexes, s'ils sont "cachés" par un appel de méthode (avec un nom compréhensible) sur une classe dédiée, ça permet à la lecture de comprendre rapidemment ce que ça fait sans rentrer dans les détails.

Par exemple, le code pas trop optimisé d'une fonction crypto genre AES est pas si simple à comprendre, mais si tu as juste un appel genre 

myCryptoEngine.encryptAES(...)

n'importe qui comprendra que c'est un chiffrement AES, de même si les paramètres sont clairs, ça permet de savoir ce qui est vraiment processé:

myCryptoEngine.encryptAES(buf1, buf2, buf3, buf4, 1, 0)

reste compréhensible sur la fonction elle même mais les param ne vont pas aider à comprendre, alors que (par exemple):

myCryptoEngine.encryptAES(myAESKey, IV, bufferToEncrypt, result, AES_CBC_MODE, AES128)

sera plus parlant, on voit ce que l'onchiffre, avec quel algo etc. (bien sur qqu ne connaissant pas du tout la cryptographie ne comprendra pas tout).

dans mon troisième exemple, j'utilise des constantes qui permettent de nommer des paramètres de façon compréhensible, genre AES_CBC_MODE (correspond au 1 du deuxième exemple), là on voit que c'est de l'AES avec un mode de chainage CBC (certes faut savoir ce qu'est un mode de chainage).

Bref plus on met d'abstraction, plus le code est lisible (sous réserve de bien nommer ses variable, constantes et méthodes), mais faut pas non plus tomber dans trop d'abstraction sinon ça devient casse pied à suivre, genre 

maClasseMagique.maFonctionQuiFaitTout(...)

obligera d'aller dans cette classe et méthode pour voir ce qui se passe.

Le deuxième point c'est de commenter le code même si il est de tradition de dire qu'un code clair n'a pas besoin de commentaires, c'est toujours bien d'en mettre, le mieux à mon avis reste à minima de mettre des entête par classe et méthode genre doxygen ou javadoc qui permet d'extraire une documentation utilisateur des interfaces (en gros ce que fait chaque classe, méthode, description des constantes etc) mais ça demande quand même pas mal de boulot.

Ne pas oublier de mettre par contre des commentaires dans le code pour chaque "hack" ou lignes de codes qui ne seraient pas trop standard ou usuelles. Par contre commenter chauque ligne ou presque est inutile, je considère qu'il faut commenter pour que quelqu'un qui connaisse déjà le langage et les APIs s'y retrouve, ce n'est pas un tuto ou autre.

Bonjour,

Je ne suis pas du tout expert en mécanique... mais pour le coup je pense avoir bon, c'est juste une idée pour savoir comment dimensionner (grossièrement à mon avis) un moteur en fonction du couple nécessaire et sa vitesse de rotation. EN fait c'est le genre de calcul que je ferrai pour dégrossir si j'essayais de faire un humanoïde, mais n'étant pas du tout spécialiste pe que je me trompe...

Donc si on reprend le robot d'Olivier17, il manque encore des infos, mais je peux essayer d'estimer ce qu'il faut.

Ce qu'on sait, un robot de maximum 10kg, mettons 1m de haut, soit des jambes (pour simplifier) de 50cm.

Il y a deux mouvements principaux différents au niveau de la hanche:

• la marche (pour schématiser, on lève la jambe juste de son poids, et on la bascule d'avant en arière de maxi 30° de chaque côté)
• les flexions (on se baisse et on remonte, la faut lever le poids presque total, mais a priori avec très peu de différence par rapport à la verticale)

Je pense que ce qui demande le plus d'effort sont les flexions, mais pas complétement sur, on va voir de suite.

Pour la marche, mettons une jambe fait 1kg (?), en appliquant la trigonométrie, puisqu'on connait l'angle (30° max) et la longueur de jambe (50cm), on a:

sin 30° = opposé / hypoténuse, soit   coté opposé = sin 30° * hypoténuse, coté opposé = sin 30° * 50 cm = 25 cm

Donc notre poids n'est décalé de l'axe de rotation que de 25cm et non plus 50cm (pour info si la jambe se lève a 20° c'est 17cm, 45° c'est 35cm, et à 90° c'est 50cm))

Ce qui nous donne 1kg.25cm, soit 25kg.cm.

Attention, ce calcul ne prend pas en compte si on doit supporter le poids du haut du corps, je considère que c'est l'autre jambe qui fait le boulot)

De même j'espère pas me tromper sur la distance "apparante" du poids par raport à l'axe.

Je considère aussi ici que l'on fait monter la jambe, puis on bascule le corps, ce qui nous met en appui (à la verticale) sur cette nouvelle jambe, et on ramène l'autre jambe...

Pour les flexions maintenant, la il faut relever tout le corps, je ne sais pas si c'est les genoux les plus solicités ou la hanche ou cheville, mais mettons que seule une articulation travaille (le cas le pire) à remonter les 10kg du robot. Bien sur, je considère le cas ou on fait quand même une "petite" optimisation, donc le haut du corps bascule pour que le centre de gravité reste le plus possible à la verticale de l'axe de l'articulation visée (ça demande plus de travail mais ça limite l'effort nécessaire), disons qu'on est au maximum à 5cm de l'axe de rotation.

Le calcul ici donne directement 10kg.5cm soit 50kg.cm mais sur deux jambes soit 25kg.cm.

Bon c'est pas fait exprès, mais on retombe sur la même valeur de couple nécessaire.

Mais la comme dit dans le précédent post, on à la aleur du couple nécessaire (si je me suis pas trompé), mais il faut aussi trouver la vitesse qui te semble adéquate.

Si on parle de 1km/h, on est a environ 27cm seconde, ce qui est proche des 25cm de foulée calculé plus haut (la c'est fait exprès ).

Donc une foulée par seconde, mais comme faut faire beacoup de chose, pas juste bouger la jambe des 30°, mettons qu'il faut que ça se fasse en 1/4 seconde (pour faire basculer le corps après, attention valeur arbitraire choisie totalement au pif), on arrive donc a 0,5s pour 60° (qui est la vitese donnée souvent pour les servomoteurs, la durée pour parcourir 60°).

Donc théroqiement il te faut 25kg.cm à 20rpm (ce qui donne une puissance d'environ 5W).

Je dirai qu'en partant sur du servomoteur 40kg.cm a 0,2s/60°, ça devrait laisser de la marge pour atteindre la valeur du dessus (toujours un peu du pifomètre, le mieux tu prends un servo de ce type et tu vérifies que ça semble être cohérent.

(Chez hobbyking, ya pas de servo de ce type, a priori pas grand chose dans le stock européen au dessus de 30kg.cm)

Faudrait comparer par exemple avec Nao, pour savoir la puissance installée pour ses 4,5kg.

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

Oui ça ressemble a l'agile eye, mais pour deux rotations, de mémoire l'agile eye c'est 3 rotations possible (X Y Z)

Mais au moins la, le design est beaucoup plus simple.

Par contre le cou à 3DDL qui sont trois rotations

Pour les sevomoteurs, si on prend ceux de modélisme, par exemple hobbicity classe par poids

• Sub-Micro Servo 0-5g
• Micro Servo 5-10g
• Mini Servo 11-20g
• Park Servo 21-30g
• Std. Servo 31-49g
• X-Large Servo 50gplus

Juste une remarque en passant...

Dernière remarque, tu es sur raspberry, pas un microcontroleur. Mets toujours des petits time.sleep() dans ta boucle pour laisser ton processeur respirer un peu. Il n'a pas que ton programme à exécuter  Même si il a 4 coeurs, c'est mal.

Alors là j'ai des gros gros doutes.

Que pour une raison quelconque ajouter des time.sleep() améliore qqc pourquoi pas, mais pas pour la raison donnée.

D'une comme tu le dis, si c'est un pi 3 ya 4 coeurs donc 4 threads matériels en parallèle. De deux, on est sur un linux, qui gère le multi tache comme un grand, ya un ordonnanceur qui donne du temps à chaque process qui tourne en fonction de bcp de chose dont sa priorité.

Bref heureusement que l'on doit pas "penser" aux autres process sur un système d'exploitation, ça serait de toute façon complètement impossible à gérer.

En fait dans tous les cas, même si quand on exécute un script python c'est peu visible, celui ci est interrompu de multiples fois pour que d'autres processus s'exécute dans un semblant de multi tâche, quoi avec 4 coeurs on a un vrai 4 tâches en // mais sur un seul coeur même si on a l'impression de multi tavhe sur un linux/windows, en vrai il n'y a qu'un seul process qui s'exécute pour un petit moment puis un autre puis un autre etc.

Désolé pour le hors sujet, mais ça me semblait important!

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 !

Bonjour,

Attention aussi pour faire de la vision stéréoscopique "de qualité" il faut pouvoir synchroniser les caméras entre elles.

Si tu analyses deux images qui n'ont pas était pris au même moment, ça sera moins précis.

En gros en focntionnant sans être synchronisé, sur des prises d'images mettons à 10images/secondes, tu peux avoir pratiquement 100ms d'écart entre les deux images droite/gauche. Si tout est fixe, on a pas de problème, mais si le robot est en mouvement ou qu'il analyse par exemple un objet qui lui est en mouvement, cette différence peut fausser le calcul. Sachant que 100ms, à 1 m.s (3,6km.h) c'est déjà des images qui sont prises avec 10cm d'écart.

Moi si je devais faire de la vision stéréoscopique, je partirai sur une ps eye qui intégre déjà tout ce qu'il faut. Le seul problème, c'est qu'il faut une carte compatible usb3 pour fonctionner.

Si le problème de synchronisation n'est pas problématique, moi j'essayerai de faire des sortes de CMUCam avec un Pi zero et une camPi, c'est pas plus cher, ya plus de puissance mais ça demande de bosser un peu (beaucoup ) sur la prog. l'avantage c'est que la camPi en théorie va jusqu'au 1080p à 30img/s (après à voir si le traitement vidéo tient le choc...).

Sinon, hop tu fais un facteur 1.5 et hop tu as plein de place 

Salut,

A première vue on pourrait dire que c'est assez équivalent, mais en fait il y a quand même plusieurs avantages à monter en tension:

• Plus on monte en tension, pour une puissance équivalente, on baisse la consommation, donc on réduit les pertes (cf les lignes hautes tension), vu que P = RI2 (loi de Joule de mémoire)
• passer d'un servo moteur à 6V mettons à un de 7,5V ça permet d'utiliser une lipo 2S directement sans convertisseur qui lui aussi à un rendement de 70 à 80% (c'est le même cas pour ton dernier exemple qui permet de passer en 4S direct)

Bref à priori quand on veut monter en couple, c'est logique que la tension monte sinon les servos vont chauffer de plus en plus et le rendement diminuer.

Salut,

Je trouve personnellement le concept d'objet assez merveilleux en terme d'organisation propre du code. Ça permet de poser des limites assez claire entre quel bout de code fait quoi, là où une approche par fonction manque de hiérarchie (c'est mon point de vue en tout cas).

Peut être que tu voulais dire la même chose, mais pour moi le très gros avantage de la programmation orientée objet, ça reste le polymorphisme (qui découle de la notion d'héritage), le reste c'est du plus (dont la hiérarchisation qui oblige à couper son code).

Le polymorphisme, quand bien géré c'est quand même très puissant.

En un mot, le polymorphisme permet de faire de la résolution dynamique de fonction (la phase de link ou édition de lien lors de la compil), contrairement à une résolution statique qui est faite lors de la compilation. Ca permet une souplesse qu'il est parfois compliquée d'avoir en C.

Si un jour j'avais du temps, c'est ce que je ferrai...

malheureusement pour le moment j'ai le temps de lire des choses, de faire un peu de théorie, mais pas d'essayer. Mais je pense vraiment que ça peut être pas mal, ne serait ce qu'avec l'utilisation directe d'openCV ou autre. 

A voir niveau perf ou ça se situe bien sur.

Mais le gros gros truc de faire ça, c'est qu'il faut au final pas mal de temps pour mettre en place le tout.

Question bête tu es sur à la base de tes valeurs min/max?

Parce que normalement, pour un servo ca devrait être (à peur prêt) linéaire, à l'asservissement pret (surtout la linéarité du potentiomètre dans le servo).

La tes servos on l'air d'aler en butée...

En gros si au lieu de 100, tu mets 150, les paloniers changent de position? idem pour 550 au lieu de 600?

Une fois le min/max (par servo, ca risque qd meme de changer un peu) trouvé, normalement vers le milieu ca devrait être le milieu de la course (à affiner par servo si nécessaire).

A voir aussi si les servos ont pas par exemple 170° de course ou 190 par exemple.