bonjour
petit challenge "alakon" posé par un de mes neveux qui va se passer la corde au cou en octobre .
electro/meca comme j'aime bien
Le challenge :
fabriquer une roue genre loterie foraine "pipée" de douze secteurs, D= ~ 1m
et donc pouvoir "choisir" le secteur d’arrêt (vecteur de comm à determiner plus tard)
tout ça avec un comportement visuel (accélération/décélération/stop) "naturel" , le lancé sera évidemment manuel
Mon idée de départ (un peu testée sur paillasse)
utiliser un moteur CC+encodeur en quadrature/index 0 (la notion de quadrature étant même là assez inutile , la roue ne tournant que dans un sens, mais j'ai trouvé une petite appli plutôt pas mal)
monter la roue sur l'axe moteur et utiliser le moteur CC en "libre,maintien partiel de rotation ou frein , test paillasse avec LMD18200 "
si vous avez d'autres voies d'approches "abordables" sur le problème , je suis à l’écoute
salut Artouste,
arfffffff faillis tomber de ma chaise.
question inutile évidemment,
l'arrêt de la roue sera toujours sur le même secteur?
arrêt de la roue par télécommande?
j'aurais plus penché sur un effet hall pour déterminer sur quel secteur se trouve le capteur, avec un moteur et une courroie crantée afin de freiner la roue et la faire avancer gentiment pour arriver sur le secteur voulu.
autre solution, un capteur de lumière avec des fenêtres par secteur, calcul de la lumière pour déterminer le secteur.
Tu pourrais utiliser un servo 360° ou un pas-à-pas 12 pas pour pouvoir sélectionner le secteur, et un mécanisme à engrenages (toi qui a l'air d'aimer la méca) pour pouvoir faire un lancer manuel . Ensuite tu met un encodeur rotatif pour sélectionner le quartier et un LCD pour afficher le quartier sur lequel la roue vas s’arrêter . Mais il te faudra un moteur assez puissant pour arrêter la roue, et un bon jeu d'engrenages pour avoir un mouvement naturel . (ou bien un servo qui puisse tourner sur plusieurs tours, mais je sais pas si ça existe ...)
Bonne chance !
Sympa comme truc
On pourrait imaginer d'une part de déterminer les caractéristiques mécaniques de la roue pour pouvoir la modéliser: genre moment d'inertie, coeff de frottements, etc... de façon à pouvoir déterminer, à partir d'un lancer à une vitesse angulaire V et secteur S, sur quel secteur la roue va s'arrêter (à peu près).
A partir de ce modèle, piloter le moteur pour obtenir un arrêt sur la position désirée en influant légèrement sur la vitesse de rotation de la roue. L'idée c'est d'avoir une rotation la plus naturelle possible
C'est un bon projet pour réviser un peu ses maths (moi ça fait trop longtemps que je suis sorti de l'école XD)
l'arrêt de la roue sera toujours sur le même secteur?
arrêt de la roue par télécommande?
j'aurais plus penché sur un effet hall pour déterminer sur quel secteur se trouve le capteur, avec un moteur et une courroie crantée afin de freiner la roue et la faire avancer gentiment pour arriver sur le secteur voulu.
autre solution, un capteur de lumière avec des fenêtres par secteur, calcul de la lumière pour déterminer le secteur.
bonjour infobarquee
ha ba non, sinon je fais une roue immobile
oui en gros , envoie de la "decision ON AIR" par un vecteur à determiner une fois que la partie electro/meca sera fiabilisée
oui, mais il faut que ça reste un peu credible pour les curieux qui ne manquerons evidemmentpas , d'où mon "idée" d'un moteur capteur directement axial
l'impression "rendue" d'un equipage CC+encodeur est celle d'un simple axe de maintien en rotation, sans "action autre" ça reste une simple roue libre
avec un encodeur indéxé (top index par tour), je sais "exactement" quel secteur est présenté, la difficulté eenvisageable est de valider les courbes de décelaration/stop pour un rendu "acceptable".
patg_:
Sympa comme truc
On pourrait imaginer d'une part de déterminer les caractéristiques mécaniques de la roue pour pouvoir la modéliser: genre moment d'inertie, coeff de frottements, etc... de façon à pouvoir déterminer, à partir d'un lancer à une vitesse angulaire V et secteur S, sur quel secteur la roue va s'arrêter (à peu près).
A partir de ce modèle, piloter le moteur pour obtenir un arrêt sur la position désirée en influant légèrement sur la vitesse de rotation de la roue. L'idée c'est d'avoir une rotation la plus naturelle possible
C'est un bon projet pour réviser un peu ses maths (moi ça fait trop longtemps que je suis sorti de l'école XD)
Bonjour Patg
c'est peu ou prou, mon approche actuelle
In fine ce n'est que du PID , à voir si un uno va s'en sortir (ou le codeur )
Et âpres on va venir se plaindre que personne ne gagne à la roue de la fortune
Moi je verrai bien un morceau de fils à mémoire de forme pour durcir le "click" qui fait ralentir la roue.
Ou alors un petit goujon avec une bobine qui viendrait forcer sur le cadre pour le freiner petit à petit.
skywodd:
Et âpres on va venir se plaindre que personne ne gagne à la roue de la fortune
Moi je verrai bien un morceau de fils à mémoire de forme pour durcir le "click" qui fait ralentir la roue.
Ou alors un petit goujon avec une bobine qui viendrait forcer sur le cadre pour le freiner petit à petit.
je retiens l'option flexinol (tiens ! peut etre commander la roue par DMX karistouf ? ---->[] )
moins le frein (gestion TOR)
l'ideal dans l'absolu serait de traiter tout "discrètement" au niveau de l'axe de rotation, mais "cacher/alimenter" un flexinol why not.
le but du jeu est quand même à la fin d'expliquer comment (et commandée par qui) la roue était "pipée" 8)
je vais faire qq test avec un plateau d'une 40taine de cm et d'un motoencodeur 2000 points
Une roue, vous avez dit une roue !
Ben oui bon sang . La roue de barlow et son héritier moderne le moteur pancake.
Diamètre 1m, va falloir calculer : moment d'inertie, couple de démarrage, freinage, ... .
12 secteurs ! suffit d'une résolution de 24 points, je te le fais à 32 (5 bits) .
Je vois bien une roue en carton plume avec des enroulements en fil fin collé, un ou deux capteurs à fourche et des trous bien placés, une bobine et un bout de tôle pour le stator, tout le reste par logiciel.
On peut remplacer les capteurs à fourche par des réflectifs.
alienboats:
Une roue, vous avez dit une roue !
Ben oui bon sang . La roue de barlow et son héritier moderne le moteur pancake.
Diamètre 1m, va falloir calculer : moment d'inertie, couple de démarrage, freinage, ... .
12 secteurs ! suffit d'une résolution de 24 points, je te le fais à 32 (5 bits) .
Je vois bien une roue en carton plume avec des enroulements en fil fin collé, un ou deux capteurs à fourche et des trous bien placés, une bobine et un bout de tôle pour le stator, tout le reste par logiciel.
On peut remplacer les capteurs à fourche par des réflectifs.
Pouir un truc inutile, autant s'amuser !
Bonsoir Alienboats
comme de toutes façons le but est l'amusement
et que rien n'est figé , je suis preneur de toutes suggestions
le pancake est un un peu trop much
mais ça me fait penser à voir du coté du principe des synchro-resolver
merci
Pour faire bon marché, j'essaierai un frein tambour de récup avec un servo qui tire dessus plus ou moins fort.
Avec un frein à disque on pourrait peut-être profiter des trous comme compte tours
Ensuite j'essaierai de faire une forme de régulation à freinage constant, le freinage à appliquer étant
calculé juste peu après le lancé afin que ça aie l'air naturel. Je pense évidemment qu'il faut
recalculer la force de freinage en permanence, mais si la force de départ est pas trop fausse
cela devrait être assez naturel.
bonsoir
suite à quelques tests et discussions ici ... et ailleurs
changement de fusil d'epaule pour la détermination de position
avec de l'incremental (A/B + index) l'arduino passe le plus clair de son temps à determiner la position et par derivée le secteur présenté, ça fonctionne mais c'est tres consommateur.
Apres reflexion et compte tenu du relatif faible nombre de secteurs (12) je vais partir sur de l'encodeur absolu (4 bits) (et je ne vais meme pas m'em....er à gerer du code gray )
Avec ce taux de resolution , un codeur DIY est simple à mettre en oeuvre avec 4 capteurs (type de capteurs à determiner : opto, contact ou autres, là c'est la meca qui va decider 8) )
l'avantage = connaissance instantané du secteur presenté sans calcul (pour un pin de plus qu'un encodeur en quadrature + index )
information sur les décélérations plus simples à déterminer (delai entre entrée et sortie de secteur)
je vais essayer dans un premier temps de simplement et seulement (vite dit ) de gerer du frein, en evitant d'ajouter de la motorisation de maintien
bonjour
pour test je vais graver cet encodeur sur pcb (12 secteurs en absolu sur 4 voies entre 1 et 12, ça me laisse 0 /13/14/15 pour le "futur" )
ça devrait me permettre de valider la partie "c'est où qu'on est ? " soit par palpeur purement electrique, ou opto en reflectif.
au passage pour ceux que cela interesserait
ce petit soft pour fabriquer ses roues codeuses en absolu et incremental
dommage que ça ne prenne pas en compte (pour de l'absolu et évidemment dans la limite) un nombre de secteur différents d'une puissance de 2 http://code.google.com/p/wheel-encoder-generator/
Bonsoir
La roue tourne
petit test ce matin de tentative de recup de courbe (durée par secteur) à chaque changement pour analyser l'amortissement (deceleration) et l'effet feuillard cliquet.
ça marche plutôt pas mal pour recuperer en log pour analyse
avec ce code.
Si les petits genies du C 8) peuvent y jeter un oeil, et m'indiquer des pistes d'optimisations (pas dans la façon de rédiger avec concision 8) , mais dans celle de gagner du "temps"
je suis preneur
enum PinAssignments {
encoderPinA = 2,
};
unsigned long Tparc=0; // temps de parcours du secteur
unsigned long Tact=0; // Test pour micros() en entrée
unsigned long ParcMax=3000000; // delai max en µs pour parcourir un secteur, si > arret theorique de la roue sur le secteur arrivée
unsigned long Tparct[256] ; // tableau de long stockant les valeurs micros() à chaque interruption
// A 12 secteurs/tour ça permet de tester + de 20 rotations = large pour l'appli en amortissement naturel
byte Iparc=0; // indice pour parcourir Tparct
byte Iinit=1; // numero du 1er secteur concerné par Tparc[0] V= 1--->12 , pas encore utlisé ici
boolean Sint=false; // passé par l'interruption oui/non
void setup() {
pinMode(encoderPinA, INPUT);
// encoder pin on interrupt 0 (pin 2)
attachInterrupt(0, doEncoderA, CHANGE);
Serial.begin(115200);
}
void loop(){
if (Sint==true)
{
Serial.print(">"); // pour test d'entre/sortie de secteur (rotation) ,indique passage par int0
Sint=false;
}
if (micros()-Tact > ParcMax) { // tempo en µsecondes pour test si pas eu d'interruption = roue à l'arret sur 1 secteur (theorie)
Tact=micros();
Serial.println();
Serial.print("-- passe tempo --> SECTEURS PARCOURUS = ");
Serial.println(Iparc-1);
for (byte i=1; i < Iparc; i++){
Tparc=Tparct[i]-Tparct[i-1];
Serial.print(Tparc);
Serial.print(";"); // delimiteur pour log tableur
}
Serial.println();
Iparc=0;
}
}
// Interrupt on A changing state
void doEncoderA(){
//Tparc=micros()-Tact;
// Tparct[Iparc]=Tparc;
// mettre le calcul du delta T pour alimenter les postes du tableau ici est trop consommateur en temps d'int
// cette fonction est derivée ensuite
Tparct[Iparc]=micros(); // plus rapide
Iparc ++;
Sint=true;
}
bonjour
vu hier la realisation en nature de mon neveu (assisté à distance par tonton )
comme finalement c'est plutôt assez "rigolo" je ferais un rapport détaillé de la construction après son mariage en octobre.
mais pour ceux que ça intrigue :
le principe est basé sur la gestion de décélération apres apprentissage In situ (et pas entretien de vitesse comme initialement imaginé)
la capteur de position est un encodeur absolu de chez AMS AS5043
le freinage/ralentissement est aussi basé sur du magnétisme
reste maintenant à gérer le "vecteur transmission du choix" pour la soirée
pour l'instant c'est simplement géré par une simple entrée sur serial (01 - 12 )
-se degage les options :
-IR (telco TV)
Bluetooth
Wifi
je pense que l'option bluetooth sera privilegiée pour sa discretion (smartphone comme "maitre du jeux" ) et moins lourde à mettre en place que du wifi...
aussi étonnant qu'il semble , je n'ai jamais pratiqué/développé du bluetooth sur arduino (ni ailleurs d'ailleurs 8) ), si vous avez des bons liens et/ou retour d'expe arduino sur l'interfaçage arduino/BT/smartphone , je suis preneur
Merci
salut Artouste,
en démontant une imprimante, j'ai pensé à toi ce WE.
j'ai récupéré des moteurs avec disque encodeur et le lecteur qui va avec, si ca te dis, je te les envoie.
infobarquee:
salut Artouste,
en démontant une imprimante, j'ai pensé à toi ce WE.
j'ai récupéré des moteurs avec disque encodeur et le lecteur qui va avec, si ca te dis, je te les envoie.
sinon pour le BT, quel type de smartphone?
bonjour infobarquee
merci pour ta proposition, mais j'en ai des "caisses pleines"
