projet inutile donc absolument necessaire

patg_:
Sympa comme truc :grin:
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 :grin:

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 :grin: )

Et âpres on va venir se plaindre que personne ne gagne à la roue de la fortune :grin:

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.

Un beau challenge avec un système de freinage à courants de Foulcault (Telma chez les routiers).

Pac2Kro:
Un beau challenge avec un système de freinage à courants de Foulcault (Telma chez les routiers).

Tant qu'à faire autant en faire un système qui récupère l'énergie électrique pour recharger la batterie qui alimente le système :grin: (HSD sur ma voiture :grin:)

skywodd:
Et âpres on va venir se plaindre que personne ne gagne à la roue de la fortune :grin:

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 ? ---->[] :grin: )
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.

Pouir un truc inutile, autant s'amuser !

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 :grin:
et que rien n'est figé , je suis preneur de toutes suggestions

le pancake est un un peu trop much :grin:
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 :slight_smile:

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 :grin: )
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 :grin: ) de gerer du frein, en evitant d'ajouter de la motorisation de maintien

to be continued

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" :grin: )
ça devrait me permettre de valider la partie "c'est où qu'on est ? " :grin: 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 :grin:
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 :grin:

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 :grin: )
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 :grin:

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.

sinon pour le BT, quel type de smartphone?

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" :grin:

sous android , samsung ace en ce qui me concerne

tiens un truc sous processing via android
http://arduinobasics.blogspot.fr/2013/03/arduino-basics-bluetooth-android.html

infobarquee:
tiens un truc sous processing via android
http://arduinobasics.blogspot.fr/2013/03/arduino-basics-bluetooth-android.html

ça semble une bonne base de depart
merci infobarquee

de rien :wink:
si je trouve quelque chose plus approchant je manquerai pas de le mettre

Ça fait une très bonne idée de caméra cachée :

  • Un forain qui tient un stand de loterie confie celui-ci à un jeune employé et s'absente
  • Quelque clients viennent et gagnent systématiquement, le stand est dévalisé

Je vous laisse imaginer la tête du jeunot quand le patron revient...

ou la tête du patron si c'est lui qui ne sait pas que la roue est pipée :stuck_out_tongue: