Salut
Pour un quadricopter, je pense que le meilleur choix reste le wifi, la portée est bien plus grande

Au niveau de la communication java/C, ca ne doit pas poser de problème via TCP (utilisation des sockets, il y a un bon tuto sur le site du zéro)

Parfaitement d'accord... Il faut d'un côté mettre en place les treads sur les différents points... Ne mettre dans la drop box que des doc / codes schémas etc... et des fichiers types READ ME .

Idem je suis d'accord pour une communication un peu plus direct... Comment ? Quoi ? j'ai pas la réponse et je ne sais pas quoi proposer. Je suis ouvert à toute proposition.

Skype, forum pour ce projet + chat rattaché à ce forum, ca fait déjà 2possibilités

EDIT : je viens de voir le post de Wmickael. Il y a une erreur dans ce que tu dis : un codeur incrémental 2 voies ne donne d'information que sur UNE roue. Les deux voies sont les deux pistes de la roue dentée. Il faut deux codeurs pour mesurer la vitesse et le sens de chaque roue, et dans ce cas, la notion de déphasage n'a pas vraiment de sens : les deux roues peuvent tourner à des vitesses complétement indépendantes.

Oula wii, j'avais en effet pas du tout compris, et par conséquent, lors de ma 1ère réponse, j'ai dit n'importe quoi, je confirme, c'est bien dans 1seule roue le codeur avec le déphasage à 90° (honte à moi :$)

Tout dépend de ce que tu veux faire, dans l'absolu rien n'est obligatoire

Si tu lui dit toi d'avancer ou de reculer d'une certaine distance, tu apportes toi même l'information du sens, donc à mon avis l'information du déphasage n'est pas obligatoire

Salut />
Euh, moi non plus je ne vois pas trop où est le problème en fait, donc ne m'en veux pas si je répond à côté

EDIT : J'enlève l'énorme bêtise que j'ai mis , je me relierai la prochaine fois avant de poster

Voila />

Dans le cas du résultat qui prime sur le reste, on se fiche du "niveau" en électronique, mécanique et informatique de chacun. On investit donc dans du module type arduino, les roues toutes intégrées présentées par mike118 etc.
-> L'avantage c'est l' assurance d'arriver au robot fini sans avoir à faire beaucoup d'efforts.

Dans l'autre cas, on doit déterminer le "niveau" de chaque membre pour faire un robot pas trop compliqué pour dégouter personne et mener le projet à bien et pas trop simple pour que la portée pédagogique du projet (parce que c'est l'intéret premier de ce cas) n'en pâtisse pas et que ce soit amusant. On investit donc dans de l' électronique et de la mécanique "classique" (composants en vrac à souder, etc.).
-> L'avantage c'est le côté pédagogique en faisant un robot de A à Z.

Je pense que la 1ère proposition n'est pas l'objectif qui semblait être convenu (enfin je dis ca, je viens d'arriver />)
La 1ère semble plus pédagogique, plus intéressante et aussi moins couteuse (en € mais pas en temps) mais ca n'empèche pas non plus d'avoir un projet pas trop compliqué et surtout finissable

Sinon je suis d'accord avec R1D1, il faut savoir où on va, déja de manière générale, en fixant les objectifs, ca permettra aussi de mieux choisir la technologie employée

Sinon, moi je n'ai pas trop de temps, mais bon je veux bien participer

PS : j'ai oublié de dire que les roues que tu proposes mike118 me semble pas très optimisées, trop gros rapport de réduction, ce qui induit un gros couple qui me semble pas tellement utile ici surtout que ca m'étonnerait que le robot pèse très lourd (et bon imposer une grosse tension pour aller à 38cm/s grand max je trouve ca moyen)

Vu le prix de la roue et le budget du robot, je ne pense pas que ce soit la meilleure solution

Au pire, si le codeur pose trop de problème à cause des glissements sans frottement et que la solution accéléromètre + gyro peut logiquement présenter une certaine dérive (du aux approximations d'intégrales cumulées), on peut utiliser en plus des codeurs la solution accéléromètre + gyro (ou meme sans gyro vu qu'on souhaite un écart de position, donc 1D) pour mesurer l'écart entre les 2 (vu que l'accéléromètre ne subit pas l'effet des glissements sans frottements), de cette manière la dérive causée par l'accéléromètre serait complètement annulée, les glissements sans frottement aussi mais cela reposerait quand même entièremment sur la précision des codeurs

Si le robot ne connaît pas sa position, il ne pourra être que réactif, c'est à dire changer de direction/vitesse en fonction de l'environnement (ou pas, mais ça risque de faire rapidement un robot crashé dans un mur). Le défaut, c'est que le comportement du robot n'est pas dépendant d'un but. Si on imagine un robot qui évite les obstacles en tournant toujours du côté le moins encombré, il va finir par se coincer dans un cycle en fonction de la configuration de la pièce. Si c'est marrant au début, ça perd vite de son intérêt quand on veut permettre des comportements plus complexes. Pour que le robot soit autonome, il doit pouvoir sortir de ce cycle, et donc calculer sa commande non pas uniquement en fonction de son environnement mais aussi selon les lieux qu'il veut atteindre. Et pour atteindre un lieu, il faut pouvoir le situer dans l'espace et se situer dans ce même espace. Cette localisation nécessite une représentation de l'espace, une "carte" (au sens large). On tombe sur le problème du SLAM : pour construire une carte correcte, il faut savoir où l'on est, mais pour savoir où l'on est, il faut une représentation de l'espace. Les méthodes pour résoudre ce problème sont assez connus, je vous invite à jeter un oeil au cours de David Filliat "Robotique Mobile" (CC-BY-NC-SA 2.0 FR).

Pour ça ausi que je demande si un cahier des charges précis a été établi afin de connaître les objectifs du robot

Sinon exact, en pratique, le robot n'étant pas un point, ajouter un gyro est obligatoire (pour détecter les rotations du robot)

Un robot n'a pas besoin de connaître sa position pour se déplacer, connaître la position ca peut être utile si on lui dit de faire un déplacement précis (télécommandé ou préétabli)
Cela peut aussi permettre de faire l'asservissement, c'est vrai, c'est sur que si on veut que le robot aille tout droit (vu qu'il y aura au moins 2 moteurs) s'il n'y a pas d'asservissement et vu que les moteurs ne sont pas identique en tout point (même si c'est le même modèle), une déviation risque d'être observée, ça la dessus on est d'accord, après ce la dépend aussi ce qu'on veut que le robot fasse, s'il doit explorer son environnement sans forcément apprendre où se situe les obstacles ou bien suivre une ligne, est ce que c'est vraiment nécessaire que le robot connaisse sa position?

Cependant, peut être avez vous établi un cahier des charges précis? (car la je parle peut etre dans le vide)

Si tu utilises la solution que t'es en train d'exploiter, ca veut dire que le robot sera limité au parquet ou carrelage

Pour les roues codeuses, je doute que ce soit le plus fonctionnel de les mettre sur les roues folles, je pense que le mieux c'est de les mettre directemment en sortie des moteurs (d'ailleurs des moteurs sont vendus directement avec des codeurs)


Sinon, pourquoi ne pas avoir envisagé (ou éliminé) la solution accéléromètre pour accéder à la position? (surtout que ce n'est pas très compliqué à mettre en place, ni très couteux)

Après tout cela n'est que mon avis

Wii c'est exact ce que tu dis que ce soit sur le fonctionnement ou sur le problème de précision (sachant qu'on n'éffectue pas une intégrale de manière formelle mais en utilisant des approximations)

J'ai déja essayé, je sais que ca marche, j'ai pas eu le temps de tester la précision (c'était un projet scolaire)

Cependant je sais aussi qu'il y a possibilité d'utiliser un filtre de Kalman pour arranger la précision (c'est d'ailleurs ce qui est utilisé pour les gps)

Sinon, pourquoi forcément devoir accéder à la position du robot?

Honnêtement je pense que c'est difficile d'augmenter la distance sol-capteur à cause des perturbations extérieures (lumière ambiante notamment) mais bon c'est de l'optique aussi, donc il doit y avoir des questions d'angles, donc finalement si l'emetteur et le récepteur sont dans le "même composant" ca va être galère

Après faut voir comment ça fonctionne (ce que j'ai dit ne sont que des hypothèses qui me semblent cohérentes)

Sinon, pourquoi ne pas envisager l'utilisation d'un accéléromètre?

Bonsoir, je vois que tu essayes de faire de l'odométrie avec un capteur optique de souris, mais est ce que cela n'imposera pas une certaine distance (très faible) entre le capteur et le sol? Vu comme ça, ça semble être un inconvénient important

Bon je n'ai pas encore lu tout ce que vous avez mis, mais peut être qu'un accéléromètre pourrait être une bonne solution (après il faut voir pour la précision, je n'ai pas eu l'occasion de tester)

Sinon wii pour l'odométrie classique, ce qui n'est pas terrible c'est le glissement sans roulement (pour ca que t'as du laisser tomber)