AsKman

Merci à tous pour vos réponses rapides et enrichissantes.

C'était la première chose à laquelle je pensais. Je vais voir comment je peux faire.

Tout d'abord, merci à vous deux pour vos réponses rapides.

Merci @ Oracid pour les liens, cela rejoint ce sujet 

1) 5V voir 6V c'est plus standard, 
Par contre c'est sur que si tu veux plus de couple après ça monte en voltage ...

Ok, alors admettons que je dois choisir un servomoteur capable de supporter au minimum 6kg.cm. Je me tourne vers, par exemple, un servomoteur de capacité 10kg.cm par sécurité. Imaginons que deux servomoteurs n°1 et n°2 de la même marque (même qualité), puisse supporter un couple de 10kg.cm mais le n°1 à 6V et le n°2 à 7.4V. Hormis la consommation qui favorise le n°1 et le poids qui favorise le n°2, y a t il d'autres paramètres à prendre en compte sans compter la rapidité d'orientation?

2) Ton coefficient de sécurité en terme de couple c'est à toi de voir ça dépend de à quel point tu penses pouvoir te fier à tes calculs et aux chiffres annoncés ,  que  ce soit les poids que tu comptes comment tu comptes etc... 

En fonction de ce que je fais et de la gravité de ce que je fais je met un coeff de sécurité entre 1,5 et 3 ...

Oui, le coefficient de sécurité concernant mes calculs est effectivement estimable. Cependant, pour le coefficient de sécurité "constructeur", il arrive que celui-ci (fabricant de servomoteurs ou autres) embellisse les performances de ses produits pour pousser à l'achat. De part ma question, je voulais savoir quelles marques manipulent ses chiffres afin de les écarter.

3) 4)  ça dépend de ce que tu as besoin...

Le bras disposant de longues "poutres", le plus faible angle d'orientation fixé serait le mieux. Pour la rapidité de déplacement angulaire, moins de 0.5s/60° serait bien pour l'ensemble de l'action.

5) si tu imprimes tout en en 3d tu fais ce que tu veux ... Après sinon tu as du makeblock du lynxmotion et beaucoup d'autres ...

Ne connaissant pas les caractéristiques physiques (masse volumique, résistance en traction...) des "pates" (ABS, PLA...) qui servent à l'impression d'objet 3D, je ne sais pas si je peux me tourner vers ce type de produit. Actuellement, j’utilise de l'aluminium connu, je peux donc tester sa résistance et sa déformation via des logiciels selon diverses contraintes et re-dimensionner en fonction.
Je connais Makeblock mais pas Lynxmotion et suis friand de ce genre de sites si tu en a d'autres

6) Pourquoi une seule marque pour tout tes besoins ?

Hormis l'aspect "visuel" (pas primordial du tout), et pratique (avoir qu'un seul type de vis (filetage) par exemple), j'aimerai avoir une cohérence dans la qualité des produits choisis. Il serait dommage de prendre un servomoteur de très bonne qualité pour la pince avec un autre servomoteur pour la base qui marche une fois sur deux...

J'ai vu que l'on peut connecter une Arduino et une Pixhawk (en "esclaves") directement sur une Raspberry Pi (RPi).

Avantages:
- profiter de la programmation de l'Arduino pour le BR* (comme @ Donovandu88)
- profiter de la puissance de calcul de la RPi pour la cinématique inversée et le traitement d'image (problématique de @Leon)
- profiter d'un contrôleur de vol fiable

"Schéma" de connexion:

        (1)           
Rpi  ---->   Arduino   ->   BR*
  \  \
   \  \    (2)   
    \  \   ---->   Pixhawk
     \
      \    (3)
       \   ---->   Camera

Est-ce une piste à creuser selon vous?

Liens d'explications des connexions:
Raspberry et Arduino (1):
http://www.pihomeserver.fr/2013/08/13/raspberry-pi-home-server-arduino-lier-les-deux-via-bus-i2c/
RPi et Pixhawk (2):
http://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
Arduino et camera (ou stéreovision) (3):
http://www.framboise314.fr/jai-teste-pour-vous-une-camera-compatible-raspberry-pi/

Bref, pour moi, c'est un projet sans doute beaucoup trop ambitieux vu ta faible expérience.

Le risque de se bruler les ailes est très très fort sur un tel projet!

Je veux d'abord apprendre les bases pour fabriquer un bras robot avant de me lancer dans ce projet plus complexe (mise en garde par toi et les autres Makers avant).
Jusqu'à ton message, les Makers m'ont donné des pistes de recherche et soulever des interrogations (problème du poids, grappin, pantographe, pince auto-serrante, cinématique inverse...). J'ai échangé avec eux sur les avantages inconvénients de ces solutions.

Les réponses que je t'ai données (message #20), ce sont des pistes de recherches que je ne veux/peux pas exploiter pour le moment car je ne connais pas l'électronique et la programmation. Je ne peux donc pas comprendre l'environnement de ces domaines, les composants, leurs utilités, leurs fonctionnements et donc essayer de dialoguer avec toi par rapport à tes connaissances.

Je n'ai pas cessé de souligner le fait que je sois débutant:

N'ayant aucune connaissance dans le domaine de la robotique (électronique et programmation), serait-il possible, dans un premier temps, de m'orienter vers les termes/notions/fonctions/composants de bases à savoir en rapport avec la fabrication d'un BR*?

Armé de ces nouveaux acquis, je pourrai parler techniquement et rentrer dans le vif du sujet plus facilement avec vous!

 

Merci d'avance pour vos suggestions!

N'ayant pas de connaissances en électronique et programmation, quelles sont les bases que je dois acquérir avant de me lancer dans la réalisation d'un BR* avec la méthode de cinématique inversée?

- connaitre le fonctionnement d'Arduino?
- le fonctionnement d'un servomoteur?
- la trigonométrie 3D?
- ...?

Vous avez très justement raison de souligner la difficulté des 2 premières étapes et plus particulièrement, selon vous et je suis d'accord avec vous, la première.
Par conséquent, je vais essayer de réaliser cet objectif final petit à petit.

Pour moi, en tant que néophyte je le rappel...

Pour résumé, je veux mettre les bœufs avant la charrue.

En revenant à la gestion d'une webcam sur Raspberry Pi, j'ai vu que l'on peut y fixer une caméra ou une vision nocturne infrarouge (pour cette dernière, je ne sais pas si cela peut m'être utile):
Caméra:
http://www.framboise314.fr/jai-teste-pour-vous-le-camera-v2-du-raspberry-pi-8-megapixels/
et
http://www.framboise314.fr/jai-teste-pour-vous-une-camera-compatible-raspberry-pi/

ou

Vision stéréo (image la plus en bas, personnellement je ne me suis pas encore pencher dessus)?

http://www.arducam.com/24-24mm-coin-size-raspberry-pi-compatible-board/

ou
Vision nocturne infrarouge :
http://www.raspberrypi3.fr/module-cam%C3%A9ra-raspberry-pi-full-hd-infrarouge-17.html?gclid=CI3J1sG47NICFQ_gGwodd6cHFg

Pour la précision du GPS, je vais me renseigner sur la technologie REACH de chez EMLID.


@ Donovandu88
Pour la connexion entre une Pixhawk (contrôleur de vol) et la Raspberry Pi, je pense que cela soit faisable:
http://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
ou
https://docs.emlid.c...tup-navio-plus/
Cependant pour la deuxième option, je crois qu'Ardupilot est l'"ancêtre" de la Pixhawk. La communauté Ardupilot se tournant désormais vers la Pixhawk, l'Ardupilot n'a plus trop de mises à jour...

Pour moi, en tant que néophyte je le rappel, je vois l'Arduino diriger l'ensemble du système et la Pixhawk en tant qu'"adjoint" dédié au drone.

Je pense que les rôles se répartissent ainsi:
L'Arduino (ou moi via Mission Planner) rentre les coordonnées GPS de l'objet dans la Pixhawk.
- Pixhawk dirige le drone vers les coordonnées GPS acquises
- Validation des coordonnées GPS au dessus de l'objet: Arduino dicte au BR* d'attraper l'objet pendant que Pixhawk stabilise au mieux le drone.
- Validation de la prise de l'objet: Pixhawk ramène le drone à la base (coordonnées GPS pré-enregistrées)
- Validation des coordonnées GPS de la base: Arduino libère l'objet
C'est comme ça que j’entends répartir les tâches en les deux cartes

@ Leon
Pour votre premier et troisième point:
Comme vous le soulignez dans la vidéo de la prise de balle, il y deux différences notables par rapport à mon cas: la hauteur z fixe et la position x,y fixe du bras qui permet de réaliser UN seul calcul.
Dans mon cas, l'altitude z et les coordonnées x,y de l'objet varie dans le repère ce qui entraine une MULTITUDE de re-calcul avant d'atteindre l'objet.

1) Concernant la hauteur (l'objet sera sur une surface plane), je pense me tourner vers deux idée
- soit je confie l'acquisition de la hauteur au baromètre + GPS du drone qui informe l'Arduino
- soit j'installe un système ultrason pointant vers le bas qui informe l'Arduino
2) Pour les coordonnées x,y:
- une webcam pointant vers le bas détermine les coordonnées x,y de l'objet

L'acquisition de l'altitude et des coordonnées sont envoyées simultanément à Arduino qui met à jour la position de l'objet.

Concernant l'ajustement en temps réel, j'ai comparé les cartes Arduino et Raspberry Pi afin de connaitre leurs performances. Voici un petit tableau comparatif (image ci-dessous, je n'ai pas la date de ces informations...). N'est-il pas plus judicieux de se tourner vers Raspberry (notamment par rapport à la vitesse d'horloge?)
J'aimerai savoir si il est possible, quasi en "temps réel", de faire avancer le bras pendant que l'Arduino re-calcul et met à jour la nouvelle position de l'objet?