Aller au contenu


Photo

Glenn Robot Humanoide


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

#401 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 02 mai 2017 - 07:10

Je voulais juste retrouver tes variables sur un dessin :)

#402 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 766 messages
  • Gender:Male

Posté 02 mai 2017 - 08:15

Il y a longtemps que j'ai été largué sur ce fil.
Je vais peut-être dire une énorme connerie, mais quand je vous vois vous débattre, je me dis que je vais le faire quand même.

Alors voilà, pourquoi ne pas mettre un potentiomètre sur chaque articulation pour maitriser le positionnement, plutôt que de se reposer sur les servos ?
Même si vous arrivez à maitriser la position des servos, cela ne garantit pas la réelle position des articulations.

Je suis inquiet, parce que j'aimerais bien me lancer sur un quadripède, mais là j'hésite.

#403 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 02 mai 2017 - 08:20

Il y a déjà un potentiomètre dans les servo, sinon, c'est pas des servo :)



#404 Telson

Telson

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 975 messages
  • Gender:Male
  • Location:Punaauai - Tahiti

Posté 02 mai 2017 - 09:58

Hi,

 

Alors oui effectivement il serait possible de rajouter un deuxième potentiomètre pour récupérer l'angle réel atteint par le servomoteur.

 

Il est aussi possible de hacker les servomoteurs pour ajouter un fil sur le potar du servo afin d'en récupérer la position réelle .....

 

Il faut ensuite gérer la lecture de cette donnée et la comparer à la consigne....

 

Dans un premier temps il faut surtout calculer l'angle de chaque servo et là c'est pas de la tarte !!!

 

Il est possible pour calculer ces fameux angle d'utiliser cette méthode :

 

Fichier joint  Calcul de la cinématique inverse des jambes.pdf   88,38 Ko   115 téléchargement(s)

 

J'ai avancé sur le calcul par matrice, il me reste encore du taf mais j'essaierai de vous faire un retour d'expériences !!!

 

++



#405 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 766 messages
  • Gender:Male

Posté 03 mai 2017 - 06:49

Il y a déjà un potentiomètre dans les servo, sinon, c'est pas des servo :)

Oui, je sais bien ! Mais ce potentiomètre sert au positionnement du servo et non pas de l'articulation.
Il peut y avoir une grande différence. Et comme là, vous parlez de quelques degrés, je me disais que ce qui est important, au final, c'est la position de l'articulation.

J'avais pensé à un truc. Ce serait d'ouvrir le servo, (une trépanation en quelque sorte...), de retirer le potentiomètre pour le mettre dans l'axe de l'articulation.
C'est vrai que c'est un peu chirurgical, mais à mon avis, ça ce serait le top !

Tiens, d'ailleurs, si j'ai le temps, aujourd'hui. Non, j'ai pas le temps !!!

#406 Path

Path

    Made By Humans

  • Modérateur
  • PipPipPipPipPip
  • 2 504 messages
  • Gender:Male
  • Location:Paris

Posté 03 mai 2017 - 07:21

ça me paraît compliqué pratiquement de rajouter un potar sur l'articulation d'un robot humanoïde.
Le potentiomètre de ce type de servo est déjà sur l'axe, juste sous le réducteur.
Et, on a un lien linéaire entre la commande et la position.
Et si il est pas linéaire, le lien mathématique doit exister.
Il "suffit" de relever les angles des commandes min et max du servo.
Je comprends peut être pas ce que vous voulez faire mais il utilise un servo, il ne veut pas faire un servo :)

#407 Telson

Telson

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 975 messages
  • Gender:Male
  • Location:Punaauai - Tahiti

Posté 03 mai 2017 - 07:37

C'est plus compliqué d'ajouter un second potar sur l'axe de l'articulation....Il est par contre plus simple de hacker les servomoteurs pour ajouter un fil sur le potar du servo afin d'en récupérer la position réelle ....il existe bien d'autres solutions pour faire ça....

 

Dans un premier temps notre plus gros problème est de calculer tous les angles et de gérer les mouvements sur l'hypothèse qu'aucune contrainte ne vienne bloquer les mouvements....



#408 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 766 messages
  • Gender:Male

Posté 03 mai 2017 - 07:37

Non, faire un servo, peut-être pas, quoique...

Je suis à peu certain que vous pouvez bouger le palonnier de vos servos à la main.
Donc, en fonction des mouvements, une force va s'exercer sur les palonnier et perturber la position des servos, même en cours de positionnement.
Pour cette raison, je pense que ce qui est important de considérer, c'est la position des articulations et non pas la dernière position que l'on a affecté au servo.
Pour le potentiomètre, peut-être qu'il serait plus simple de couper la connexion de celui existant, et d'en relier un nouveau à l'électronique du servo.

#409 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 03 mai 2017 - 08:12

Merci les gars de vos retours, en fait comme l'a dit Path le but est de bien utilisé le servo, et non d'en fabriquer un autre.

 

Les lignes de codes plus haut sont juste là pour m'aider à comprendre (et si ça peut aider d'autres personnes tant mieux), mais j'ai vu une erreur qui me plait pas vraiment, avez vous déjà eu ce genre d'erreurs sur ces calculs ???

 

Je vais faire un autre test en tapant direct dans le cosinus plutôt que le sinus, mais j'ai une fâcheuse impression qui me dit que ça va être pareil.

 

Au final, le map c'est nickel, mais par contre mes calculs à un truc prés c'est pas bon, surtout si on cherche à se caller au degrés prés ce qui me semble normal, non ? :(

 

 

@ Path : tu as un exemple de schéma pour placer les variables etc etc, car je ne vois pas trop comment te faire ça. Merci :)

 

@ Telson : Ben tu n'es plus sur de la cinématique direct ?

tu es passé à la cinématique indirecte :), mais les deux vont ensemble pour certaines situations j'ai l'impression, j'ai lu que sur la C.D. cela sert pas mal avec la gestion d'une central inertiel, et pour la C.I. est super pratique pour gérer une position dans l'espace (j'en parle dans les grandes lignes hein), donc ouais, avoir les deux ça va être chaud ^^

 

@ Oracid : "Même si vous arrivez à maîtriser la position des servos, cela ne garantit pas la réelle position des articulations." il y a un peu de ça dans mon problème, mais cela vient de mes calculs qui apparemment ne sont pas bon, après avoir un retour de position aurait été intéressant, mais, cela implique de rajouter un fils, alors sur deux ou trois servos ok ça peut le faire, mais quand tu arrives à 26 servos minimum, je ne me vois pas rajouter 26 fils en plus sur le robot ^^ (vite les gars, faut piquer l'idée de dynamixel lol).

 

Merci :)

 

Edit : Bon je crois que j'ai trouvé mon problème, ben en fait j'arrondi de 10 chiffres après la virgule, ça m'a l'air d'être nickel.

En fait j'arrondi juste mon résultat tout au final pour que tous soient au 1 degré prés, ça a l'air d'être bon.


Modifié par Oliver17, 03 mai 2017 - 01:23 .

signature_01.png -->

 

Mon Tipeee
 


#410 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 766 messages
  • Gender:Male

Posté 03 mai 2017 - 01:24

après avoir un retour de position aurait été intéressant, mais, cela implique de rajouter un fils, alors sur deux ou trois servos ok ça peut le faire, mais quand tu arrives à 26 servos minimum, je ne me vois pas rajouter 26 fils en plus sur le robot

Sur Lego, on peut interroger le servo pour connaître sa position. C'est peut-être possible également avec d'autres servos.

#411 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 20 mai 2017 - 09:57

Hey les Maker's, la forme j'espère ? :)

 

Bon, depuis quelques jours je cogite pour essayer de bien poser mon code (pour tester), alors voilà, j'avais pensé à ça : 

 

un script genre pour le programme principal appelons le pp.py (c'est dans l'exemple hein)

 

ensuite un script regroupant tous les calculs et algo possible  algo.py

 

et pour finir un script regroupant toutes les informations sur chaque servomoteur activitemotrice.py

 

R1D1 m'avait répondu sur le tuto pour python, et donc si j'ai bien compris ça démarche il serait peut être bien de réunir chaque servo dans une classe avec toutes les informations que l'on a besoin, R1D1 serait il possible de développer un ptit peu plus stp si tu as un moment. (merci merci merci ^^)

 

Ce qui me faire peur, bon en même temps j'apprend et je n'ai pas l'habitude, mais c'est de voir un script pour réunir tous ça, cela risque de faire une sacré tartine de code pour chaque servo.

 

J'avais aussi dans l'idée d'écrire dans le script algo.py les algos pour la cinématique directe et inverse, je me plante peut être dans l'idée, pouvez vous me donner votre avis m'sieurs dames.

 

 

Merci :)


signature_01.png -->

 

Mon Tipeee
 


#412 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 20 mai 2017 - 09:38

Here I am !

Quand ton code commence à grossir, c'est effectivement une bonne chose de séparer le code principal et les différents composants qui vont servir. En python, on peut créer des modules, que l'on peut ensuite importer dans d'autres scripts.

Il faut faire la différence entre le programme que tu fais tourner sur ton robot (pp.py, on peut l'appeler aussi main.py) et les fichiers python de tes modules. La différence principale, c'est que pp.py contient une fonction main, ou au moins, produit un effet (commander les moteurs, traiter du texte, afficher des images, etc.), tandis que les autres fichiers n'auront que des définitions de fonction ou de classe. Si tu fais "python fichiermodule.py", rien ne doit se passer (en dehors d'éventuels tests, mais je ne rentre pas dans les détails).
Pour ces fichiers modules, l'intérêt de faire de la programmation orienté objet (POO, c'est à dire déclarer et manipuler des classes), c'est que tu vas associer au sein d'un même objet les données et méthodes.
Tu peux donc définir une classe qui gère un servo, puis créer autant d'objets de cette classe que tu as de servos à commander. Quelques attributs/méthodes utiles : le pin de commande du servo, l'angle actuel (mesuré de préférence, dernière commande sinon ?), un angle de "repos" (position initiale), une méthode appliquerAngle(angle_but), une méthode retourInit pour revenir en position de repos, une qui gère la vitesse, etc.
Pour gérer la cinématique/dynamique, tu peux par exemple créer des classes "Jambes", "Bras", qui permettent de contrôler plus facilement tes servos. Par exemple, une classe Bras pourrait avoir un attribut qui est une liste d'objets Servo, une liste de longueurs pour les différents segments du bras, une méthode "calculCinematiqueDirecte" et une "calculCinematiqueInverse" qui font les calculs pour passer de l'espace articulaire à l'espace cartésien et vice-versa, une méthode "atteindre" qui envoie effectivement les commandes aux servos.
Pour les méthodes de cinématique directe et inverse, tu peux créer une classe DKSolver (Direct Kinematic Solver) et IKSolver qui implémentent les calculs pour un nombre N d'articulations ...

Dans tous les cas, n'hésite pas à créer autant de fichiers python différents que tu le juges nécessaire pour avoir une bonne lisibilité de ton code. Une bonne pratique en général : une classe a un rôle particulier. Si deux méthodes d'une classe n'ont rien à voir, il faut probablement diviser la classe existante en deux.
Tous tes fichiers, tu peux les regrouper dans un dossier avec le nom que tu souhaites (e.g. monsupermodule) dans lequel tu mets un fichier nommé __init__.py vide. En ajoutant le dossier qui contient "monsupermodule" à la variable d'environnement $PYTHONPATH, tu devrais pouvoir faire "import monsupermodule" dans n'importe quel autre fichier (donc par exemple dans pp.py) sur la Raspberry.
Et une fois que tu as fais cet import, tu peux créer des objets que tu auras défini précédemment. À noter que je ne maîtrise pas très bien cette notion de modules dans python, et j'ai toujours tendance à bricoler un peu pour que ça marche correctement. Tu peux ausi chercher du côté des "egg" et "wheel" en python, ça permet de créer des packages proprement.
Dernière précision, j'utilise python 2.7, donc il est possible qu'il te faille adapter des choses à python 3 le cas échéant.
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#413 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 21 mai 2017 - 08:25

Cool, dans l'idée, j'avais certaines choses en tête pas si mauvaise que ça finalement, mais je m’aperçois tout de même que la route va être encore longue, longue, très longue :'(

 

Je vais bien lire et relire ton post R1D1, déjà certaines choses mon sautés aux yeux, et qui, en te lisant paraisse effectivement évidentes. ;)

 

Je vais chercher de mon coté bien évidemment, mais si tu as des tutos ou autres conseils sur le sujet je suis preneur :)

 

Va falloir que je creuse plus sur la POO, et sur cette histoire de module etc etc ^^

 

Encore merci R1D1 d'avoir pris le temps de répondre, et si tu as d'autres conseils ... comme déjà dis je suis preneur ^^

 

Merci ^^


signature_01.png -->

 

Mon Tipeee
 


#414 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 21 mai 2017 - 12:57

N'hésite pas à poser tes questions si des choses ne te semblent pas claires, et à montrer ton code de temps en temps :)
Je suis loin de maîtriser tous les rouages de python, mais au moins, ça me poussera à reformuler ce que je connais !
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#415 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 21 mai 2017 - 02:38

Ok, merci beaucoup, là je survole certains cours d'open class room pour mieux m'attaquer aux restes ^^


signature_01.png -->

 

Mon Tipeee
 


#416 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 29 mai 2017 - 06:21

Plop les maker's, bon j'ai réussi à faire un ptit truc, je pense avoir compris pour les objets = attribut, méthode etc etc, le hic, j'ai peut être pris au pied de la lettre les propos de R1D1 et je m'y perd un peu, comme "Par exemple, une classe Bras pourrait avoir un attribut qui est une liste d'objets Servo" j'ai bien fais plusieurs tentatives pour placer un attribut qui est une liste de mes objets Servo, mais je suis un peu larguer pour la suite, c'est pas faute d'avoir chercher, donc je tourne en rond sur le pourquoi du comment.

 

Ou alors je créer un objet qui regroupe la total, du servo, sa potision dans l'espace, longueur du segment etc etc

 

Bon j'ai fais un truc tout simple un qui va paraitre incomplet, mais bon, si on peut m'éclairer un peu, merci

 

 

main_03.py

from activite_motrice_03 import *

servoepgy = Servo (9, 0, 340, 94, 537, 225)
servocogy = Servo (8, 0, 180, 100, 515, 180)
servopogz = Servo (4, 0, 180, 100, 515, 180)

brasgauche = [servoepgy, servocogy, servopogz]

info = -90

angle = servoepgy.envoiangle(info)
print (angle)
print ("-----")

angle = servocogy.envoiangle(info)
print (angle)
print ("-----")

angle = servopogz.envoiangle(info)
print (angle)
print ("-----")

for servo in brasgauche :
    print (servo.servo)

activite_motrice_03.py

from Adafruit_PWM_Servo_Driver import PWM
import numpy as np

pwm = PWM(0x40,  debug = False)
pwm.setPWMFreq(50)

class Servo  () :
    """Paramètres des servomoteurs"""

    def __init__(self, servo, amin, amax, smin, smax, initservo) :
        self.servo = servo
        self.amin = amin
        self.amax = amax
        self.smin = smin
        self.smax = smax
        self.initservo = initservo

    def envoiangle (self, angle) : 

        convertisseur = round(self.initservo + angle, 0)
        print ("convertisseur initservo + angle : ", convertisseur)
        result = int((convertisseur - self.amin) * (self.smax - self.smin) / (self.amax - self.amin) + self.smin) 

        pwm.setPWM(self.servo, 0, result)
       
        return (self.servo, angle)
       

class BrasG :

    def __ini__ (self, brasg) :
        """calcul"""
        self.brasg = brasg

Je rappel que je test un peu tous ça, les classes méthodes attributs etc etc histoire de prendre le bon plis pour la suite, autant faire ça le plus propre possible :)

 

Merci


signature_01.png -->

 

Mon Tipeee
 


#417 R1D1

R1D1

    Modérateur et Membre passionné

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

Posté 29 mai 2017 - 08:13

Ça m'a l'air pas mal tout ça (je réponds vite, j'ai pas trop de temps en ce début de semaine).
Pour ta classe Bras, tu peux avoir un attribut self.articulations et un attribut self.longueurs, puis ton code un peu comme ça :
 
import toutesMesSuperLibrairiesQuiFontLeCafe as tmslqfc

class Bras():
  def __init__(self, name):
    self.name = name
    # On crée nos listes, vides pour l'instant 
    self.articulations = []
    self.longueurs = []
    self.nb_articulations = 0

  def addArticulation(self, servo):
    self.articulation.append(servo)
    self.nb_articulations += 1

  def addOs(self, l):
    self.longueurs.append(l)

  def IK(self, pos):
    # calcule les angles des servos étant donné la position à atteindre et la géométrie du bras
    tmslqfc.IKSolver()
    return angles

  def goTo_cartesien(position):
    # position est un tuple en 2 ou 3D
    angles = IK(position)
    s = self.articulations # parce que j'ai la flemme d'écrire self.articulations à chaque fois
    for i in np.arange(len(self.articulations)):
      #s[i] est un objet Servo
      s[i].envoiangle(angles)
import numpy as np
import toutesMesSuperLibrairiesQuiFontLeCafe # juste pour invoquer magiquement les bouts de code que j'ai pas envie d'écrire :)

# On crée les servos avec leurs paramètres en dur dans le code (les lire depuis un fichier de config est une bonne option aussi)
servoepgy = Servo (9, 0, 340, 94, 537, 225)
servocogy = Servo (8, 0, 180, 100, 515, 180)
servopogz = Servo (4, 0, 180, 100, 515, 180)

# on crée un bras qui est une instance de la classe Bras
brasDroit = Bras()
# On peut ajouter un servo au bras directement ...
brasDroit.articulations.append(servoepgy)
# ... mais la manière "propre" permet de faire d'autres updates dans "Bras" si nécessaire (ici, le nb_articulations)
brasDroit.addArticulation(servocogy)
brasDroit.addArticulation(servopogz)
lesOsDuBras = [0.7, 0.6] # deux barres de 70 et 60 cm
for o in lesOsDuBras:
   brasDroit.addOs(o)

# On envoie une position cartésienne à atteindre et le bras calcule les angles à appliquer 
brasDroit.goTo_cartesien((0.3,0.5))
Ce bout de code ne fonctionne probablement pas, mais c'est pour te montrer très grossiérement comment on peut faire avec une classe "Bras", et une liste de Servo. Parmi les choses qui ne sont pas explicités du tout ici, il y a la question des repères attachés aux articulations pour pouvoir calculer la cinématique inverse. Je me souviens que j'avais promis un tuto sur tout ça en début d'année, heureusement, vous ne m'avez pas attendu pour progresser :).
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#418 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 29 mai 2017 - 08:43

Merci beaucoup, j'ai survolé vite fais et j'avais eu cette idée de liste dans le constructeur, mais bon, vu que je me suis égaré sur des cours python, me suis un peu mélanger en fait ^^

 

Cool, merci encore, je regarde ça demain de plus prés ^^


signature_01.png -->

 

Mon Tipeee
 


#419 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 30 mai 2017 - 12:21

Bon, j'ai regardé cette histoire d'établir une liste d'objets dans un fichier config, c'est clair que je trouve l'idée plutôt bonne, mais, après avoir lu des courts sur le sujet, en fait je ne trouve pas ça pratique, (bon ceci dis je me plante surement), et cela juste sur un point, admettons j'établis mon fichier config.txt regroupant mes objects : (ou alors utiliser aussi pickle)

 

servoepgy = Servo (9, 0, 340, 94, 537, 225)
servocogy = Servo (8, 0, 180, 100, 515, 180)
servopogz = Servo (4, 0, 180, 100, 515, 180)

 

j'ai tous ça dans mon fichier (avec pickle je me suis aperçu que c'était nettement plus pratique dans la démarche), et donc, chaque fois que tu veux récupérer un des objects de la liste tu dois obligatoirement faire redéclarer une variable de cette objet, donc, autant créer l'objet direct dans le script, on fait moins de manip, non ?

 

En plus, faire un nouvelle import pickle juste pour faire appel dans un fichier ou tu vas rajouter des lignes de codes, plus réimporter chacun des objets dans une variable, hum, ça en rajoute, bon après hein, j'ai surement mal compris le principe.

Sinon c'est bon pour stocker des informations et pouvoir les récupérer plus tard lorsque l'on relance le programme :)

 

Je met l'exemple tout de même que j'ai trouvé avec pickle. :

>>> import pickle
>>> a, b, c = 27, 12.96, [5, 4.83, "René"]
>>> f =open('donnees_test', 'wb')
>>> pickle.dump(a, f)
>>> pickle.dump(b, f)
>>> pickle.dump(c, f)
>>> f.close()
>>> f = open('donnes_test', 'rb')
>>> j = pickle.load(f)
>>> k = pickle.load(f)
>>> l = pickle.load(f)
>>> print(j, type(j))
27 <class 'int'>
>>> print(k, type(k))
12.96 <class 'float'>
>>> print(l, type(l))
[5, 4.83, 'René'] <class 'list'>
>>> f.close()

C'est cette exemple qui m'a mis dans le doute.

 

Edit : 

PS : j'ai lu au dessus ton exemple de code, d'ailleurs au passage encore merci ^^ et une question me vient, lorsque tu marques : 

lesOsDuBras = [0.7, 0.6] # deux barres de 70 et 60 cm

à qui attribut tu la longueur du segment ? (ou je n'ai pas compris)

 

Par exemple de l'épaule au coude cela nous fait un segment, ce segment je compte le calculer à partir de mon servo sur l'axe Y, ensuite, du coude au poignet j'ai un autre segment, qui lui sera attribué bien entendu au servo du coude sur l'axe Y aussi, etc etc.

 

Donc comment attribut tu ce segment au servo ?

Je vais continuer à retourner le code à titre d'exemple que tu m'a posté, ça se trouve je suis passé à coté d'un truc ^^ 

 

 

Edit :

(hum hum, tu attributs tous ça avec le for juste en dessous apparemment ?)


Modifié par Oliver17, 30 mai 2017 - 01:04 .

signature_01.png -->

 

Mon Tipeee
 


#420 Oliver17

Oliver17

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 2 758 messages
  • Gender:Male

Posté 03 juin 2017 - 11:09

Coucou les maker's, bon là je vais surtout m'adresser à R1D1 (sauf si quelqu'un à une idée sur le sujet) :)

 

Voilà, bon je crois avoir compris le sens de ton exemple, un truc me turlupine (et oui ça se dit encore lol), dans ton exemple lorsque tu joins les articulations avec lesOsduBras tu joins deux servo entres eux si je ne me trompe, en fait dans mon idée, pour une épaule j'ai trois degrés de liberté, pour le coude un, et au poignet deux, (épaule, coude, poignet effectivement on a trois articulations) donc là ou je bloque un peu c'est pour faire la liaison entre tous ça, j'avais cela en tête : 

 

- Création d'un membre : brasdroit 

    - création d'une articulation : epaule

      - position (on retrouve sa position dans le référentiel du monde sous forme de matrice)

      - nb_dof (on retrouve le nombre de matrices correspondant aux nombres de dof)

      - segment (on retrouve la longueur de l'os qui rejoins le coude sous forme de matrice ce qui nous donnes l'orientation de cette os)

      - id_servo (assignation du/des servos aux matrices de rotation "id_servo")

 

    - création d'une articulation : coude
      - position (on retrouve sa position dans les coordonnées local de l'épaule sous forme de matrice)
      - nb_dof (on retrouve le nombre de matrices correspondant aux nombres de dof)
      - segment (on retrouve la longueur de l'os qui rejoins le poignet sous forme de matrice ce qui nous donnes l'orientation de cette os)
      - id_servo (assignation du/des servos aux matrices de rotation "id_servo")

 

    - création d'une articulation : poignet
      - position (on retrouve sa position dans les coordonnées local du coude sous forme de matrice)
      - nb_dof (on retrouve le nombre de matrices correspondant aux nombres de dof)
      - segment (on retrouve la longueur de l'os qui rejoins le poignet sous forme de matrice ce qui nous donnes l'orientation de cette os)
      - id_servo (assignation du/des servos aux matrices de rotation "id_servo")

 

J'ai donc : 

 

un membre : bras droit

trois articulations : epaule, coude, poignet

6 degrés de liberté / 6 dof : correspondant aux servos qui vont bien ^^

 

Ceci dis je me doute que j'ai oublié des trucs, mais déjà si j'arrive à établir ce code correctement, je pourrai le peaufiner par la suite.

Grace aux exemples de R1D1 je récupère déjà une liste que je transforme en matrice pour la position, enfin j'arrive à certaines choses.

 

Le truc, c'est comment faire la liaison une fois que je vais déclarer un nouvel objet pour le coude et ensuite le poignet, j'avais pensé au système d'héritage des classes si je ne dis pas de bêtises, mais, gros doute......

 

Une autre question par la suite, une fois tous ça déclarer, ça n'a pas vraiment besoin de se retrouver dans le main, cela pourrait être une sorte d'initialisation au lancement qui se fera une fois, et ainsi récupérer toutes les positions et matrices dans le référentiel du monde. ??

 

Bien entendu, plus tard et je l'espère, il y aura le cou, l'autre bras, un bassin et si c'est possible des jambes (mais je n'en suis pas encore là).

Et donc il faudra faire la liaison de tous ce ptit monde.

 

Je mélange tout, suis un peu largué, et épuisé, le servo, euh non, le cerveau commence à cramer  :)

 

PS : si vous avez des idées en tête n'hésitez pas.

 

Merci


signature_01.png -->

 

Mon Tipeee
 





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

0 members, 0 guests, 0 anonymous users