Résolveur de Rubik's cube

Ma chaîne YouTube · par **PG52** » Jeu Fév 12, 2009 3:50 pm

Polo a écrit:PS : un one moc set, c'est un set dont on peut faire un seul moc ?

Non non, c'est un set qui n'utilise que les pièces d'un MOC :lolroule:

/HS

par **efjie2002** » Ven Fév 13, 2009 8:04 pm

hum, ça merde au niveau du calibrage...

par **Gyrocompa** » Sam Fév 14, 2009 1:14 am

Tu l'as déjà monté ? Hé bé, on peut dire que tu es rapide :resp:

!

par **efjie2002** » Sam Fév 14, 2009 10:07 am

Gyrocompa a écrit:Tu l'as déjà monté ? Hé bé, on peut dire que tu es rapide !

moui bof mais mon capteur de lumière n'est pas au top donc j'essaie de bricoler des adhésifs de substitution. En plus donc, le prgme de calibrage du déplacement du bras de "visée" me semble dysfonctionner et comme je ne connais pas grand chose au langage de prog utilisé...

par **efjie2002** » Sam Fév 14, 2009 11:58 pm

pas moyen même avec des stickers bricolés... je vais essayer avec un capteur de couleur...

par **Gyrocompa** » Dim Fév 15, 2009 12:21 am

Bon, de toute façon, il faut bien avouer que l'utilisation d'un capteur ne distinguant pas les couleurs n'était pas très satisfaisante... :think:

Dans le même genre, j'avais vu un montage où le robot avait l'air d'obéir à la parole. En fait, la seule chose qu'il différenciait c'était la longueur de l'ordre...
Quand on voit la puissance du module programmable tout ce qu'il peut faire, on a l'impression que c'est du gâchis que de lui coller des capteurs si limités...
M'enfin, je dis ça sans en avoir un et sans maîtriser les principes de base de la programmation (Désolé Roboleo, pas encore eu le temps de lire tes leçons très complètes...)

par **Darth Bug** » Dim Fév 15, 2009 3:38 am

J'avoue que commence à y en avoir un certains nombre qui traîne sur le net de ces petits robots, par contre le 2eme est connecté au PC si je ne m'abuse, ce n'est pas un NXT qui calcule la solution?
En tout cas, vous et vos robots je vous prends quand vous voulez :nana:

je suis en plein rodage pour mon tout nouveau...et j'ai bien l'intention de passer sous les 45s

par **efjie2002** » Dim Fév 15, 2009 12:08 pm

oui, enfin, si d'autres se penchent sur le problème, je suis preneur de leur trouvailles !

par **efjie2002** » Ven Fév 20, 2009 12:45 pm

hum, le remplacement du light sensor par un color sensor ne semble pas améliorer la résolution du "cube"...
Le problème pourrait prpovenir d'une mauvaise calibration: je m'y perd.

Personne n'a tenté le montage ?

par **kiko100** » Ven Fév 20, 2009 1:42 pm

Bonjour,
Je viens de voir ce topic et je vous fais part de mon expérience justement sur ce "résolveur de rubik's cube" (c'est mon premier "vrai" post sur ce forum, j'espère que ça sera utile).
Je l'ai monté (pendant les vacances de Noël) et j'ai été confronté aux problèmes suivants :
- Le calibrage des couleurs : un peu pénible mais j'y suis arrivé (je n'ai qu'un capteur de lumière). Pour le cube "standard" du commerce, ce sont les faces jaunes et blanches que j'ai recouvertes d'autocollants. J'ai pris des blancs et je les ai coloriés en faisant différents tests avec le capteur. Ça a fini par marcher. A noter que lorsque j'ai enlevé les autocollants, les couleurs d'origine ne tiennent plus, et tout fini par devenir blanc. Pour la face blanche, pas grave, mais pour la jaune

. J'ai donc enlevé les autocollants d'origine et j'ai maintenant une face noire. Mais comme je les ai enlevé après avoir démonté le robot, impossible de dire si c'est à tenter.
- Le pivotage du cube : Un des gros problèmes au début, car le cube ne retombait pas bien, ne pivotait pas... Pour moi, le problème venait des axes qui l'entourent et qui sont soit trop, soit pas assez serrés. J'ai viré les poutres en 'L' (désolé, je suis nouveau, je ne connais pas bien les noms) et j'ai utilisé le même principe de fixation que les axes gris. en faisant des essais, en serrant plus ou moins, ça marche.
- Le tournage du cube : C'est ici que ça n'a pas marché et que j'ai abandonné (faute de temps en fait) : Peut-être à cause de ma dose de "serrage" des axes, lorsque le cube tourne en étant maintenu, il ne tourne pas pile de 90°, mais un tout petit peu plus (ou moins), ce qui fait que au bout de deux trois mouvements, ça coince. Pour moi, c'est là que je me suis arrêté.

Cela dit, si on l'aide un peu lorsque ça commence à coincer, ça marche nickel.

Pour ce qui est des algorithmes de résolution, il en calcule trois et prend le meilleur. Le gars explique sur son site que c'est à cause de la mémoire et de la puissance du NXT qu'il a fait ça.

Voila, en espérant être utile.

par **Polo** » Ven Fév 20, 2009 1:46 pm

Il calcule le chemin optimal selon 3 algorithmes, ou il calcule 3 chemins avec le même algorithme, avant de prendre le meilleur?

Site Internet · par **Nico71** » Ven Fév 20, 2009 1:54 pm

si c'est un problème de puissance du nxt, pourquoi faire 3 fois plus de calcul ? Je comprends pas trop. C'est quoi la cadence du proc ?

par **Alban42800** » Ven Fév 20, 2009 2:16 pm

kiko100 a écrit:Bonjour,
Pour ce qui est des algorithmes de résolution, il en calcule trois et prend le meilleur. Le gars explique sur son site que c'est à cause de la mémoire et de la puissance du NXT qu'il a fait ça.

Voila, en espérant être utile.

Amha il calcule 3 solutions avec le même algorithme et prend celle qui a le moins de mouvements. N'ayant pas assez de mémoire pour stocker d'autres solutions qui pourraient être plus rapide.

Post utile kiko

par **kiko100** » Ven Fév 20, 2009 3:05 pm

Ce qui est sûr, c'est qu'il calcule 3 solutions. Il affiche le nombre de mouvements pour chacune des solutions (et joue même de la musique de plus en plus aigüe à mesure que le nombre de mouvements est élevé). Évidemment, il utilise la solution nécessitant le moins de mouvements.
D'après le type, il y a deux soucis : la mémoire et la puissance. Ça veut dire un programme pas trop long et ne nécessitant pas trop de calculs. Ce qui ne veux pas dire qu'il ne peut pas tester plusieurs algorithmes. Je ne m'y connait quasiment pas en Rubik's Cube, mais il existe des algorithmes assez simples à expliquer (donc peu de lignes à programmer) et qui ne doivent pas nécessiter beaucoup de calculs (j'arrive à le faire..) au détriment du nombre de mouvements. Les 3 algorithmes qu'il a choisi doivent être un mix de tout cela en optimisant la rapidité et la mémoire, sans trop faire de mouvements.

par **efjie2002** » Ven Fév 20, 2009 3:24 pm

Pour le problème de rotation on doit pouvoir regler cela en déserrant un peu les vis du rubiks et en graissant à souhait (ça a amélioré sensiblement la rotation pour le peu que j'ai essayé).
Mon problème vient au niveau du calibrage du deplacement du bras: en le plaçant au centre, il ne retrouve jamais la position après et est décalé. J'ai tenté de "forcer" en placant le capteur presque sur l'extérieur du carré: rien n' y fait... De plus il faut parfois que j'aide le bras du capteur à venir tilté sur le sensor de contact

pfffff

Résolveur de Rubik's cube

Qui est en ligne ?