Aller au contenu


Photo

THESEE³ le solveur de labyrinthe


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

#1 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 24 juillet 2019 - 09:27

J'ouvre un sujet dédié à un de mes projets évoqué dans un autre fil , un solveur de labyrinthe en Lego. Comme d'habitude mon objectif modeste est de découvrir un nouvel univers. Lego présente de gros avantages mais aussi des contraintes qui rendent les projets intéressants, que j'aime partager ici.

Je ne vais pas forcément aller chercher sur le web des algorithmes existants mais essayer de faire mon propre apprentissage. 

Je suis donc parti sur les préconisations de Mike118 , concernant le dimensionnement du projet. Le labyrinthe aura 100 cases de 18 cm x 18 cm et le robot une dimension de 16cm x 16cm.

 

C'est mon premier défi et je touche du doigt les inconvénients du Lego, l'encombrement de ses moteurs et de son cerveau... Au bout de 2 semaines d'essai, entre roue folle, roue mecanum et omniwheels, je suis enfin arrivé à un résultat correct, qui respecte cette contrainte. De plus je m'en suis fixé une totalement arbitraire c'est de sortir de l'apparence Lego et de faire un beau robot, je suis content du résultat, pas évident non plus en Lego: Je vous présente THESEE³ :

 

DSC_0839.JPG

 

 

A noter que j'ai été obligé de tricher pour parvenir à loger tout ce beau monde dans ce cube, que les puristes me pardonnent, mais les pièces chinoises percées sur toutes les faces m'ont permis de mettre 4 servomoteurs pour piloter les omniwheels qui me permettront de faire des déplacement perpendiculaires dans le labyrinthe:

 

DSC_0841.JPG

 

La première partie est réalisée, la deuxième sera la réalisation du labyrinthe de 4m². J'ai pris en compte les conseils avisés se Mike118 et d'Oracid mais je ne sais pas encore comment je vais faire. Tout cela n'étant que préparatifs à la phase primordiale que j'imagine complexe de la résolution du labyrinthe et son optimisation.

 

Enfin je n'ai pas résisté à la tentation de faire un teaser spécialement pour Robot Maker !

 



#2 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 juillet 2019 - 06:49

Voilà le labyrinthe, 100 cases de 18cm x 18cm... option retenue, bois collé, mais avec deux murs escamotables, qu'il suffit de placer à d'autres endroits pour changer totalement le parcours...

 

Maintenant vacances et à Thésée³ de jouer !

 

DSC_0855.JPG



#3 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 28 juillet 2019 - 07:22

Super ça avance bien ! =) Par contre j'ai pas vu quels sont les murs escamotable ... 
ça fait combien de possibilité de labyrinthe ? 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#4 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 juillet 2019 - 07:56

Super ça avance bien ! =) Par contre j'ai pas vu quels sont les murs escamotable ... 
ça fait combien de possibilité de labyrinthe ? 

Les portions escamotables sont scotchées au scotch fort translucide. cela fait au moins 4 labyrinthes qui sont du coup vraiment différents. C'est suffisant pour tester mes algorithmes, sachant que pour l'instant je n'ai aucune idée comment je vais procéder. En revanche, vu le peu de jeu entre le robot et les cases, je vais peut-être échanger mes détecteurs lumineux contre des détecteurs de contact. J'ai peur que l'odométrie avec les omniwheels ne soit pas assez précise et je risque de buter contre les murs en voulant franchir une case.



#5 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 27 août 2019 - 12:00

Bonjour, quelques nouvelles de THESEE³  qui avance tout doucement et qui pose des problèmes intéressants à résoudre, c'est le but d'ailleurs, pas de challenge ni compétition en vue, juste de l'intérêt personnel que je partage ici.

 

La première difficulté est le déplacement du robot de façon précise dans le labyrinthe, ce qui n'est pas une mince affaire. Petit à petit le moindre décalage d'angle génère un écart sur le positionnement et le robot finit par taper sur un mur. je l'ai complètement refait pour qu'il fasse 14.5 cm x 14.5 cm, avec un détecteur ultrason sur chaque face. Mais cette réduction de taille n'apporte rien, la déviation est toujours là et prohibitive.

 

Je vois deux solutions, la première est de repositionner le robot à chaque case avec les 4 détecteurs mais cela ne garantit pas la perpendicularité, la deuxième est de se déplacer en frottant systématiquement sur un mur, ce qui n'est pas très élégant, mais probablement le plus efficace, à tester. A moins qu'il y ait d'autres idées ici ?  :)

je n'ai malheureusement pas d'entrée supplémentaire pour positionner un ou deux gyroscopes.

 

Deuxième partie attaquée en parallèle: l'analyse, et j'évite d'aller sur le web pour pomper des algorithmes, je préfère explorer moi-même. L'idée est de partir de façon aléatoire (peut-être en frottant toujours du même côté ?) et de tester chaque case parcourue, et de stocker en mémoire l'état de la case. Si une case comporte 3 murs elle est stockée "mauvaise" ou alors 2 murs et adjacente à une case mauvaise, elle est aussi "mauvaise". J'utilise pour la première fois les tableaux dans le langage Ev3, ce qui me semble très puissant. Un tableau comporte 1 ligne de n données, dans mon cas le premier tableau comporte 100 données, adressables de 0 à 99 correspondant au numéro de la case du labyrinthe. Les données peuvent être numériques ou logiques, dans mon cas c'est du numérique, 0 (case non explorée), 1 (case bonne), 2 (case mauvaise) Une fois que le robot a identifié des cases mauvaises il ne devra pas y retourner. J'imagine aussi d'autres tableaux pour stocker la position exacte des murs et tracer en temps réel le labyrinthe.

je peux aussi stocker toutes les informations dans une seule donnée numérique par case, à tester.



#6 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 259 messages
  • Gender:Male

Posté 28 août 2019 - 02:34

Pour le parallélisme aux murs, un gyro ne te sera pas très utile : il ne te donne que la vitesse de rotation, pas l'orientation. À la limite un magnétomètre (boussole) pour t’orienter par rapport au nord, mais en intérieur ça risque d'être assez bruité voir faire du n'importe quoi.

 

Ce que je te suggérerais, ce serait de mettre 2 capteurs ultrason de chaque coté (ou au moins sur un coté). Par exemple, sur le coté gauche du robot, tu en place un proche de l'avant du robot, l'autre proche de l'arrière : si tu es bien aligné, alors tu mesureras la même distance, sinon, en fonction duquel te donne la dimension la plus élevée, tu sais si tu t'approche ou si tu t'éloigne du mur. A noter qu'il faut des capteurs "suffisamment" précis pour mesurer la différence distance. Il faut aussi faire attention à gérer le cas où un des capteurs voit encore un mur et l'autre voit déjà la case vide qui suit.

 

Une autre variante, utilisant un seul capteur par coté : pendant que tu avances, si la distance au mur gauche grandit lentement, tu sais que tu vas un peu trop à droite, et inversement, si elle diminue, que tu vas trop à gauche. Nb : cette variante ne fonctionne que quand tu es en mouvement

 

Enfin, une dernière variante serait de dire que quand tu as un mur à gauche et un autre à droite, la distance vers les deux murs doit être égale : si c'est pas le cas, tu te dirige vers le mur le plus éloigné. Alternativement, tu peux juste fixer la distance aux murs et tourner un peu si tu es trop proche d'un mur à gauche ou à droite


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#7 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 août 2019 - 03:11

Pour le parallélisme aux murs, un gyro ne te sera pas très utile : il ne te donne que la vitesse de rotation, pas l'orientation. À la limite un magnétomètre (boussole) pour t’orienter par rapport au nord, mais en intérieur ça risque d'être assez bruité voir faire du n'importe quoi.

 

Ce que je te suggérerais, ce serait de mettre 2 capteurs ultrason de chaque coté (ou au moins sur un coté). Par exemple, sur le coté gauche du robot, tu en place un proche de l'avant du robot, l'autre proche de l'arrière : si tu es bien aligné, alors tu mesureras la même distance, sinon, en fonction duquel te donne la dimension la plus élevée, tu sais si tu t'approche ou si tu t'éloigne du mur. A noter qu'il faut des capteurs "suffisamment" précis pour mesurer la différence distance. Il faut aussi faire attention à gérer le cas où un des capteurs voit encore un mur et l'autre voit déjà la case vide qui suit.

 

Une autre variante, utilisant un seul capteur par coté : pendant que tu avances, si la distance au mur gauche grandit lentement, tu sais que tu vas un peu trop à droite, et inversement, si elle diminue, que tu vas trop à gauche. Nb : cette variante ne fonctionne que quand tu es en mouvement

 

Enfin, une dernière variante serait de dire que quand tu as un mur à gauche et un autre à droite, la distance vers les deux murs doit être égale : si c'est pas le cas, tu te dirige vers le mur le plus éloigné. Alternativement, tu peux juste fixer la distance aux murs et tourner un peu si tu es trop proche d'un mur à gauche ou à droite

Merci pour toutes ces pistes, en particulier la première que j'explorerai si je ne m'en sors pas même si je ne suis pas sûr que les ultrasons lego soient suffisamment précis. Actuellement chaque face est dotée d'un détecteur ultrason parce que je comptais faire comme ta dernière piste, sauf qu'on peut avoir les bonnes distances mais ne pas être du tout parallèle. J'ai plus un problème d'angle que de distance, je sais les mesurer. Le gyroscope lego me donnerait une orientation si j'avais une entrée supplémentaire, mais sa précision ne serait pas suffisante. Il faut vraiment que je me déplace parallèlement au mur, ou alors mais ce serait fastidieux, que je me repositionne au centre de la case avec les détecteurs à ultrasons à chaque case !

je vais explorer tout ça, merci



#8 Sandro

Sandro

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 259 messages
  • Gender:Male

Posté 28 août 2019 - 03:31

Un moyen indirect de connaitre ton orientation est d'avancer tout droit et de mesurer le changement de distance par rapport au mur : si tu sais que tu as avancé d'une distance donnée, et que pendant ce temps ton écart au mur à changé d'une distance donnée, alors, par trigonométrie, tu connais l'angle que tu fais par rapport au mur : de cette manière, tu peux corriger l'angle tout en avançant (et si tu es vraiment trop proche, tourner un peu).

A noter que si tu as déjà un gyroscope, et que tu as du mal à estimer de combien tu tourne, tu peux utiliser le gyro pour ça (pour tourner une fois je pense qu'il fera l'affaire, en revanche il ne faut pas compter dessus pour connaitre ton orientation sur le log terme)


Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...

Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.


#9 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 août 2019 - 03:35

Un moyen indirect de connaitre ton orientation est d'avancer tout droit et de mesurer le changement de distance par rapport au mur : si tu sais que tu as avancé d'une distance donnée, et que pendant ce temps ton écart au mur à changé d'une distance donnée, alors, par trigonométrie, tu connais l'angle que tu fais par rapport au mur : de cette manière, tu peux corriger l'angle tout en avançant (et si tu es vraiment trop proche, tourner un peu).

A noter que si tu as déjà un gyroscope, et que tu as du mal à estimer de combien tu tourne, tu peux utiliser le gyro pour ça (pour tourner une fois je pense qu'il fera l'affaire, en revanche il ne faut pas compter dessus pour connaitre ton orientation sur le log terme)

Oui je suis d'accord mais pas sûr que les détecteurs ultrasons soient suffisamment précis pour le calcul de l'angle soit fiable. A tester.



#10 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 28 août 2019 - 03:36

Sinon tu veux te "simplifier " la tâche pour creuser directement la partie labyrinthe sans trop à gerer le problème d'orientation tu peux utiliser des capteurs de couleurs au sol et mettre des lignes à suivre ... 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#11 Oracid

Oracid

    Pilier du forum

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

Posté 28 août 2019 - 06:08

Le gyroscope lego me donnerait une orientation si j'avais une entrée supplémentaire, mais sa précision ne serait pas suffisante.

Es tu certain de cela ?
As-tu testé le Gyroscope tout seul, indépendamment du reste ?

#12 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 août 2019 - 07:58

Es tu certain de cela ?
As-tu testé le Gyroscope tout seul, indépendamment du reste ?

Non je ne suis pas sûr... mais le manque d'entrées disponibles m'a fait éliminer cette solution d'emblée. 



#13 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 28 août 2019 - 08:07

Pour illustrer mon propos : 

 

 

d'ailleurs si tu as pas assez d'entrées sorties, l'idée d'un capteur motorisé plutôt que 4 capteurs ça peut permettre d'économiser des entrées sorties ? 


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#14 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 28 août 2019 - 09:06

Pour illustrer mon propos : 

 

 

 

d'ailleurs si tu as pas assez d'entrées sorties, l'idée d'un capteur motorisé plutôt que 4 capteurs ça peut permettre d'économiser des entrées sorties ? 

Je prends toutes ces bonnes idées, je vais voir ce que je peux faire de mieux. Je n'étais pas parti sur un capteur motorisé pour des raisons de vitesse, mais si je dois mettre des plombes à trouver mon chemin, ça peut être la solution. Pour ce qui est des traits sur le parcours je trouve que c'est la solution de facilité, je veux me creuser un peu les méninges, c'est le seul intérêt de ce projet pour moi



#15 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 9 934 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 28 août 2019 - 09:34

Ok ok pas de soucis. Ma remarque c'était juste si tu souhaitais te concentrer plus sur la partie labyrinthe que sur la partie déplacement =) 
Pas besoin d'un labyrinthe pour cette problématique là.  =)


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 
Si vous souhaitez un robot pilotable par internet n'hésitez pas à visiter www.vigibot.com et à lire le sous forum dédié à vigibot!

 

Les réalisations de Mike118  

 

 

 


#16 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 29 août 2019 - 06:48

Ok ok pas de soucis. Ma remarque c'était juste si tu souhaitais te concentrer plus sur la partie labyrinthe que sur la partie déplacement =) 
Pas besoin d'un labyrinthe pour cette problématique là.  =)

Je connaissais cette vidéo et je trouve le robot très lent et très inesthétique. mais je ne me souvenais pas des lignes. je te remercie pour tes suggestions, tout cela participe à mes réflexions lors de mes insomnies matinales... :mellow:

Je vais aussi programmer une transmission par bluetooth pour tracer en temps réel sur un écran l'évolution du robot dans le labyrinthe  et sa résolution. Je pense le faire sur l'écran d'un autre module EV3 et si possible (mais je doute de la possibilité) sur un écran de pc.. 



#17 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 01 septembre 2019 - 01:50

Bonjour à tous

 

J'ai fait des essais en mixant les différentes propositions précédentes pour avoir un déplacement fiable avant d'attaquer la résolution du labyrinthe:

 

* Ma proposition de frotter contre les murs ne fonctionne absolument pas et ce pour 3 raisons: les capteurs ultrasons donnent des valeurs fausses quand ils sont plaqués contre les murs, ils identifient le robot comme étant très loin du mur ! D'ailleurs cela remet en question un certain nombre de principes que j'avais imaginés.

Ensuite lors des virages, si toute la face du robot n'est plus plaquée, le mouvement des omniwheels fait que le robot pivote autour de l'angle et c'est la catastrophe. Et 3ème raison quand on frotte un mur, la moindre aspérité dans la construction du labyrinthe modifie totalement l'orientation du robot.

* J'ai obtenu l'optimum en mesurant toutes les distances par rapport aux murs les plus proches (ça fonctionne très bien) pour le positionner au centre de la case mais comme j'ai absolument besoin de remettre un angle droit de temps en temps, je viens plaquer le robot contre un mur, seulement quand il change de direction: exemple si dans une case il tourne à droite et qu'il y a un mur à gauche, je viens plaquer sur ce mur gauche avant d'attaquer le déplacement à droite. On le voit bien sur la petite vidéo ci-dessous.

Sur la video on voiti un petit temps d'arrêt sur chaque case, c'est le temps de l'analyse de la case, je verrai si je peux le faire à la volée.

On distingue aussi les vibrations du robot dans son déplacement. Ca c'est du au jeu entre dents des 4 renvois d'angle des 4 roues omniwheel. Ma solution de déplacement fonctionne très bien, mais par souci d'esthétisme je voudrais réduire ce jeu, qui est la source de la rotation parasite du robot et qui n'est pas très élégant.

 

Des idées pour réduire ce jeu ? Une friction quelconque sur les axes ?

 

DSC_0841.JPG

 

 



#18 Oracid

Oracid

    Pilier du forum

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

Posté 01 septembre 2019 - 02:12

Des idées pour réduire ce jeu ? Une friction quelconque sur les axes ?

Pas évident. Personnellement, je n'ai pas d'idées.
Peut-être que la solution serait d'accepter ce jeu et de faire en conséquence. Pas facile.
la capteurs à ultrasons fonctionnent bien à partir de 5cm environ.

Sinon, 4 contacts, un par face, cela ne ferait-il pas l'affaire ?

#19 pmdd

pmdd

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 932 messages
  • Gender:Male

Posté 04 septembre 2019 - 11:39

Pas évident. Personnellement, je n'ai pas d'idées.
Peut-être que la solution serait d'accepter ce jeu et de faire en conséquence. Pas facile.
la capteurs à ultrasons fonctionnent bien à partir de 5cm environ.

Sinon, 4 contacts, un par face, cela ne ferait-il pas l'affaire ?

Non j'ai vraiment besoin de mesurer les distances de loin sur les 4 faces pour stocker un maximum d'informations. 

 

En regardant de près, le tressautement du robot est inhérent aux roues omniwheel. C'est la première fois que je les utilise. En effet quand le robot se déplace vers l'avant, ce sont les deux roues latérales qui l'entraînent et ce sont des roulements non motorisés sur les roues avant/arrière qui permettent le mouvement. C'est la géométrie de ces roulement non motorisés et leur positionnement qui crée ce tressautement parasite.

Autres inconvénients des omniwheels, leur positionnement au centre des faces du robot (du cube en ce qui me concerne) empêche le positionnement des capteurs au centre de ces mêmes faces, ce qu'il faudrait avoir dans l'idéal. De plus ces roues ne permettent pas d'embarquer des charges même minimes ou de subir des efforts, sans risque de patiner. Ainsi si mon robot cube frotte un mur, il patine !

 

Bref je dois remettre en question mon choix. même je veux rester sur un choix de roues omnidirectionnelles pour l'efficacité et l'élégance du mouvement.

 

Je repars donc à zéro et j'essaie de construire le même robot, avec le même encombrement avec des roues mecanum. J'ai échoué une première fois avec des entrainement directs, je vais voir si je peux positionner les moteurs de façon astucieuse avec des trains d'engrenages pour laisser la place au positionnement des capteurs ultrasons. L'inconvénient des roues mecanum est leur taille et une gestion plus complexe. Elles ont tendance aussi à chaque démarrage et arrêt de provoquer une très légère déviation mais qui peut se corriger. Le challenge est chaud de faire rentrer 4 roues mecanum , 4 moteurs, 4 capteurs ultrasons et une brique EV3 dans un cube de 14 cm de côté... même si en hauteur je me laisse la possibilité de dépasser cette cote.



#20 Oracid

Oracid

    Pilier du forum

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

Posté 04 septembre 2019 - 01:44

Le challenge est chaud de faire rentrer 4 roues mecanum , 4 moteurs, 4 capteurs ultrasons et une brique EV3 dans un cube de 14 cm de côté... même si en hauteur je me laisse la possibilité de dépasser cette cote.

Pourquoi 14cm ?

Sinon, une sphère actionnée par des Omniwheels ou des Mecanums. Le cube étant soutenu aux angles par des billes libres. Il y en a chez Lego.
J'ai déjà fait quelque chose comme ça, mais cela n'a pas abouti.




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

0 members, 0 guests, 0 anonymous users