Controller l'axe AD avec un Arduino et un moteur pas à pas

DrGkill2 · 18 novembre 2015

Voilà ma réalisation pour ceux qui pourraient être intéressés. La précision de rotation du moteur seul est de l'ordre de 99.999994% ou une erreur de 0.5 seconde d'arc sur une période de 24h.

Je suis en train de concevoir la boite de vitesse avec 5 étages de réduction en tout, 4 étages avec démultiplication 6 et le dernier étage avec une démultiplication 10.

Le tout composé de poulies et courroies dentées.

Si la tension des courroies est correcte, la précision globale devrait être extrêmement intéressante. A suivre.

Acticle complet :http://astrodiy.tumblr.com/post/133411784514/control-a-stepper-motor-with-an-arduino

Code : https://github.com/DrGkill/Astro-Mount-Control

Une partie du code est en cours d'écriture, pour contrôler le moteur avec un petit joystick et accélérer la rotation de l'axe AD afin de viser un objet sans avoir à débrayer.

José9 · 18 novembre 2015

Projet intéressant à suivre!

Je pense néanmoins que la plus grand erreur ne viendra pas de ton moteur mais plutôt de ton système de réduction.

Courage!

DrGkill2 · 18 novembre 2015

Projet intéressant à suivre!
Je pense néanmoins que la plus grand erreur ne viendra pas de ton moteur mais plutôt de ton système de réduction.

Courage!

Tout à fait ! C'est la raison pour laquelle je vais équiper le système de réduction uniquement avec des pièces de CNC. Je ne comprends d'ailleurs pas pourquoi plus de montures en sont équipées (Comme les montures Avalon par exemple). C'est fiable, résistant, précis, et pas plus cher à concevoir. Les seuls inconvénients sont que ça prend un peu plus de place et que le système de débrayage est complexe à mettre en oeuvre.

Si quelqu'un a une idée en passant pour le système de débrayage je suis preneur !!!

Modifié 18 novembre 2015 par DrGkill2

Leimury · 18 novembre 2015

Bonjour,

Il y'a toujours des problèmes vu la précision requise en astro.

Le moteur qui n'a peut subir des irrégularités dues au contrôle pas à pas.

Dans un train d'engrenage, à chaque fois qu'un contact se fait ailleurs que sur le cercle nominal il y'a également des variations de vitesse.

En fait le réglage des entraxes est vraiment critique quand on recherche la précision, même avec des roues dentées parfaites tu auras des problèmes si l'entraxe fait que le point de contact n'est pas sur le cercle nominal.

Même le matériau des roues dentées a son rôle car si à l'usage il n'est pas assez dur les dents perdront très vite leur belle forme de développante de cercle parfaite.

Dans l'absolu les roues dentées devraient être en verre et on devrait les finir à la pâte à roder, entrainées par des moteurs brushless :be:

DrGkill2 · 19 novembre 2015

Le moteur qui n'a peut subir des irrégularités dues au contrôle pas à pas.

Oui, tu as vu l'irrégularité L'erreur est pour l'instant plus qu'acceptable

entrainées par des moteurs brushless

J'utilise un moteur pas à pas qui est un moteur brushless.

Dans un train d'engrenage, à chaque fois qu'un contact se fait ailleurs que sur le cercle nominal il y'a également des variations de vitesse.

En fait le réglage des entraxes est vraiment critique quand on recherche la précision, même avec des roues dentées parfaites tu auras des problèmes si l'entraxe fait que le point de contact n'est pas sur le cercle nominal.

Je n'utilise pas d'engrenages mais des poulies et courroies dentée qui ont le bon goût d'offrir une surface de contact optimale et dont le seul paramètre pour avoir de la précision est la tension de la courroie. Une erreur d'axe de rotation des poulies (si la tension des courroies reste correcte) n’entraîne qu'une usure prématurée des courroies sans faire variatier la vitesse de rotation.

Même le matériau des roues dentées a son rôle car si à l'usage il n'est pas assez dur les dents perdront très vite leur belle forme de développante de cercle parfaite.

Dans mon cas, poulies en aluminium et courroie en polymères, et vu la vitesse de rotation du tout, avant que le polymère n'attaque l'alu il va falloir un bon moment surtout que les courroies se changent facilement.

Ce principe est utilisé sur les montures Avalon Linear et a fait ses preuves. De ce que j'ai pu lire sur des forums, les personnes qui ont utilisé cette monture sont plus que satisfait de la précision du suivi au regard du prix. (moins de 5000€)

dob300 · 20 novembre 2015

Oui, tu as vu l'irrégularité L'erreur est pour l'instant plus qu'acceptable

J'utilise un moteur pas à pas qui est un moteur brushless.

Je n'utilise pas d'engrenages mais des poulies et courroies dentée qui ont le bon goût d'offrir une surface de contact optimale et dont le seul paramètre pour avoir de la précision est la tension de la courroie. Une erreur d'axe de rotation des poulies (si la tension des courroies reste correcte) n’entraîne qu'une usure prématurée des courroies sans faire variatier la vitesse de rotation.

Dans mon cas, poulies en aluminium et courroie en polymères, et vu la vitesse de rotation du tout, avant que le polymère n'attaque l'alu il va falloir un bon moment surtout que les courroies se changent facilement.

Ce principe est utilisé sur les montures Avalon Linear et a fait ses preuves. De ce que j'ai pu lire sur des forums, les personnes qui ont utilisé cette monture sont plus que satisfait de la précision du suivi au regard du prix. (moins de 5000€)

On veut des photos ! on veut des photos ! oui ce système de boite de vitesse comme tu dis.

benjamindenantes · 20 novembre 2015

J'ai essayé pas mal de choses pour l'axe AD de ma monture.

Courroies et roues dentées, réducteur type harmonic drive et roue et vis sans fin.

Les meilleurs résultats je les ai eu et de loin avec le bon vieux système de roue et vis sans fin.

En fait ça fait des mois que j'attends qu'un petit génie de la programmation nous ponde un code avec quelques variables pour piloter un moteur CC en boucle fermée avec un codeur haute résolution.

L'idée c'est de corriger en temps réel l'ep sur la base de ce que le codeur compte.

Si il compte pas assez d'impulsions à la seconde, on fait accélérer le moteur.

Si il en compte trop on le fait ralentir.

C'est pas tout neuf comme principe et je suis persuadé que c'est pas si compliqué que ça.

Le seul hic c'est le cout du codeur...

Quand j'ai fabriqué ma monture j'ai rassemblé un peu de matos pour essayer le principe mais faute de connaissances en programmation, j'ai laissé tomber.

Pour mettre le programme au point je pense qu'il suffit de récupérer une imprimante. Le rouleau principal (qui simule l'axe ad) est a la fois entrainé par un moteur CC et sa position est controllée par un codeur optique.

Si tu veux faire avancé la "science" pour l'astram bricoleur, je pense que c'est par là qu'il faut creuser.

Je t'envoie mon épave d'imprimante équipée si tu veux.

Le but c'est de faire un programme avec quelques paramètres qui puisse s'adapter a n'importe quel couple moteur/codeur.

Modifié 20 novembre 2015 par benjamindenantes

DrGkill2 · 23 novembre 2015

Courroies et roues dentées, réducteur type harmonic drive et roue et vis sans fin.

[/Quote]

Les reducteur harmonic drive semblent générer des "vagues" j'imagine pour éviter les à coups (backlash) mais donc je n'ai pas trop l'impression que ce soit super intéressant en astro.
Les meilleurs résultats je les ai eu et de loin avec le bon vieux système de roue et vis sans fin.

[/Quote]

Quels étaient les problèmes avec les courroies ? Sur combien d'étages de réduction tu te plaçais ?
En fait ça fait des mois que j'attends qu'un petit génie de la programmation nous ponde un code avec quelques variables pour piloter un moteur CC en boucle fermée avec un codeur haute résolution.

L'idée c'est de corriger en temps réel l'ep sur la base de ce que le codeur compte.

[/Quote]

C'est ce que je fais en faisant bagotter la latence entre les steps. La latence va ici bagotter très précisément entre 2077 et 2078 microsecondes de latence entre deux pas. L'ajustement se fait toutes les microsecondes. Le tout fournissant une précision de l'ordre de 99.999994% soit une erreur de 0.5 seconde d'arc sur une période de 24h.
// Keep a track of the accumulated delay
uint32_t StepCons=(2077.64515817901292394)*pow(2,STEP_SHIFT);
uint32_t lastStepErr = 0;
uint32_t StepCurr = StepCons;

void sideralSpeed(void)
{ 
 digitalWrite(motStep,HIGH); // Impulse start   
 digitalWrite(motStep,LOW); // Impulse stop. 

 StepCurr = StepCons + lastStepErr;
 Timer1.setPeriod(StepCurr>>STEP_SHIFT);
 lastStepErr = StepCurr & (((uint32_t)~0)>>(32 - STEP_SHIFT) ); // On prend juste le poid faible
}
Le seul hic c'est le cout du codeur...

[/Quote]

Le driver que j'utilise est un Pololu A4498 qui est largement assez rapide pour l'application et est très bon marché (moins de 6$). Sa résolution est à la microseconde et avec assez d'étages de réduction on est normalement suffisamment précis.

Je l'utilise avec un moteur pas à pas de 200 pas et dont le driver peut réaliser des 16e de pas. Ca donne un moteur qui tourne au 1/3200e de tour.

Actuellement la boite de réduction que je suis en train de concevoir comporte 5 étages de réduction, ce qui fourni au final 2.4x1e-8 de tour par pas.

Modifié 23 novembre 2015 par DrGkill2

benjamindenantes · 23 novembre 2015

Les reducteur harmonic drive semblent générer des "vagues" j'imagine pour éviter les à coups (backlash) mais donc je n'ai pas trop l'impression que ce soit super intéressant en astro.

Quels étaient les problèmes avec les courroies ? Sur combien d'étages de réduction tu te plaçais ?

C'est ce que je fais en faisant bagotter la latence entre les steps. La latence va ici bagotter très précisément entre 2077 et 2078 microsecondes de latence entre deux pas. L'ajustement se fait toutes les microsecondes. Le tout fournissant une précision de l'ordre de 99.999994% soit une erreur de 0.5 seconde d'arc sur une période de 24h.
// Keep a track of the accumulated delay
uint32_t StepCons=(2077.64515817901292394)*pow(2,STEP_SHIFT);
uint32_t lastStepErr = 0;
uint32_t StepCurr = StepCons;

void sideralSpeed(void)
{ 
 digitalWrite(motStep,HIGH); // Impulse start   
 digitalWrite(motStep,LOW); // Impulse stop. 

 StepCurr = StepCons + lastStepErr;
 Timer1.setPeriod(StepCurr>>STEP_SHIFT);
 lastStepErr = StepCurr & (((uint32_t)~0)>>(32 - STEP_SHIFT) ); // On prend juste le poid faible
}
Le driver que j'utilise est un Pololu A4498 qui est largement assez rapide pour l'application et est très bon marché (moins de 6$). Sa résolution est à la microseconde et avec assez d'étages de réduction on est normalement suffisamment précis.

Je l'utilise avec un moteur pas à pas de 200 pas et dont le driver peut réaliser des 16e de pas. Ca donne un moteur qui tourne au 1/3200e de tour.

Actuellement la boite de réduction que je suis en train de concevoir comporte 5 étages de réduction, ce qui fourni au final 2.4x1e-8 de tour par pas.

Tu n'as pas compris ce que je voulais dire.

Je te parles d'un asservissement en boucle fermé. Chose qu'un driver et un moteur ne savent pas faire. Pour ça il faut introduire un codeur qui mesure la vitesse en temps réel. Ton pilotage électronique du moteur aura beau être théoriquement parfait, il ne pourra rien contre l'erreur périodique liée à la mécanique. Pour la corriger il faut mesurer la vitesse réelle de l'axe d'ou la nécessité d'un codeur monté sur l'axe ad et non pas sur l'axe moteur.

Pour les poulies courroies, ça nécessite un usinage très précis. Un mauvais entraxe et des alésages pas concentriques et c'est tout de suite une ep qui s'envole. Dans ce cas, on arrive a voir sur les courbes d'ep un engrenement de dent. (j'ai essayé sur 2 étages)

Pour les vagues liées aux harmonic drive, je confirme mais c'est là justement l’intérêt de mettre au point un programme utilisant un asservissement en boucle fermé. (les vagues seront compensées en temps réel)

Bien entendu, tu fais comme bon te semble, je me permet juste de te faire part d'un petit retour d'expérience ayant testé et mesuré différents types de transmission.

Si le sujet t'intéresse, tu peux trouver quelques infos ici:

http://www.webastro.net/forum/showthread.php?t=112440&highlight=ben%27s

DrGkill2 · 23 novembre 2015

Je suis allé voir peu de temps après ma réponse ton post sur ta réalisation !

Félicitations ! Ton boulot est super !

Je suis prêt à prendre toutes les remarques en compte, d'autant plus que j'en suis à la phase de conception !

L'idée des courroies et roues dentées est venue suite à la recherche sur les différentes méthodes de transmission.

En regardant les différentes montures (inspiré des avalon linear et AZ-EQ6) et ce que j'étais moi capable de réaliser, j'en ai conclu -peut être à tort- que l'entrainement par courroie synchrone était excellent.

Tu as raison, l'utilisation d'un codeur optique pour compenser l'erreur de transmission semble intéressante et visiblement pas hors d'atteinte :

http://www.pobot.org/Asservissement-d-un-moteur-a.html

Je vais me pencher un peu là dessus.

Eric S · 23 novembre 2015

En fait ça fait des mois que j'attends qu'un petit génie de la programmation nous ponde un code avec quelques variables pour piloter un moteur CC en boucle fermée avec un codeur haute résolution.

[...]

Le seul hic c'est le cout du codeur...

Ça fait un bout de temps que je rêve à la même chose que toi.

Donc, un moteur CC pour avoir une consommation électrique limitée (iOptron SkyTracker, SkyWatcher Star Adventurer je suppose aussi...).

L'encodeur pour l’asservissement. Actuellement, on a l'encodeur sur l'axe AD qui demande une très grande résolution et qui coute très cher. Sur l'iOptron SkyTracker, l'encodeur est en sortie sur moteur, en amont du réducteur. Résultat, on se mange les irrégularités du réducteur alors même que la stabilité long terme est bonne (voir mon post sur le sujet).

Pour moi, l'encodeur doit être sur la vis sans fin. Il faut moins de résolution que sur l'axe AD. Il faut un bon couple vis sans fin/couronne c'est-à-dire avec une erreur périodique bien régulière, pas nécessairement petite. Il faut coupler ça avec un système de correction de l'erreur périodique. Idéalement, il faut un réducteur qui ne produit que des harmoniques entières de l'erreur périodique principale, comme ça le système peut moduler préventivement la charge du moteur CC pour lisser les irrégularités du réducteur.

benjamindenantes · 23 novembre 2015

Tu as raison, l'utilisation d'un codeur optique pour compenser l'erreur de transmission semble intéressante et visiblement pas hors d'atteinte :

http://www.pobot.org/Asservissement-d-un-moteur-a.html

Je vais me pencher un peu là dessus.

C'est exactement ça!

Ça, ça ferait avancer les choses en astro.

Le programme idéal pourrait s'adapter a n'importe quel matériel avec des variables paramètrables.

Modifié 23 novembre 2015 par benjamindenantes

Leimury · 23 novembre 2015

Oui, tu as vu l'irrégularité L'erreur est pour l'instant plus qu'acceptable

J'utilise un moteur pas à pas qui est un moteur brushless.

Je n'utilise pas d'engrenages mais des poulies et courroies dentée qui ont le bon goût d'offrir une surface de contact optimale et dont le seul paramètre pour avoir de la précision est la tension de la courroie. Une erreur d'axe de rotation des poulies (si la tension des courroies reste correcte) n’entraîne qu'une usure prématurée des courroies sans faire variatier la vitesse de rotation.

Dans mon cas, poulies en aluminium et courroie en polymères, et vu la vitesse de rotation du tout, avant que le polymère n'attaque l'alu il va falloir un bon moment surtout que les courroies se changent facilement.

Ce principe est utilisé sur les montures Avalon Linear et a fait ses preuves. De ce que j'ai pu lire sur des forums, les personnes qui ont utilisé cette monture sont plus que satisfait de la précision du suivi au regard du prix. (moins de 5000€)

C'est bien parti

DrGkill2 · 23 novembre 2015

C'est exactement ça!

Ça, ça ferait avancer les choses en astro.

Le programme idéal pourrait s'adapter a n'importe quel matériel avec des variables paramètrables.

les montures 10micron avec leur 0.1" d'EP doivent forcément avoir un système comme ça, en plus du fait qu'ils utilisent des servomoteurs AC.

Par contre, aux regards de la vitesse de rotation de l'axe AD, ça va pas être facile de trouver un capteur qui permet de fournir assez de précision à la board principale en temps réel afin d'ajuster avec douceur et précision la rotation de l'axe moteur ...

Codeur laser avec gravure fine sur l'axe AD ? ahah ... hum ...

Modifié 23 novembre 2015 par DrGkill2

DrGkill2 · 23 novembre 2015

On veut des photos ! on veut des photos ! oui ce système de boite de vitesse comme tu dis.

Ca va venir ! pour l'instant il n'y a que des crobards sur papier. L'idée est de faire quelque chose qui ressemble à ça :

Si après ça t'amuse, voilà le moteur avec son driver et contrôleur arduino :

IMG_20151112_174338 by Guillaume Seigneuret

benjamindenantes · 23 novembre 2015

les montures 10micron avec leur 0.1" d'EP doivent forcément avoir un système comme ça, en plus du fait qu'ils utilisent des servomoteurs AC.
Par contre, aux regards de la vitesse de rotation de l'axe AD, ça va pas être facile de trouver un capteur qui permet de fournir assez de précision à la board principale en temps réel afin d'ajuster avec douceur et précision la rotation de l'axe moteur ...

Codeur laser avec gravure fine sur l'axe AD ? ahah ... hum ...

En effet, d'ou le coût important d'un tel codeur. Comme je le disait plus haut c'est le point négatif.

DrGkill2 · 24 novembre 2015

En effet, d'ou le coût important d'un tel codeur. Comme je le disait plus haut c'est le point négatif.

J'ai eu l'idée hier soir d'utiliser le capteur laser d'une souris de PC gamer, ça a une résolution de 8200dpi pour un taux de transfert d'information de 12000Hz. En pièce détachée sur Aliexpress on est à 11€ avec les frais de port. Ça devrait être juste assez pour "voir" tourner l'axe principal.

http://fr.aliexpress.com/item/Free-Shipping-1PCS-lot-ADNS-9500-IC-LASER-SENSOR-GAMING-9500-ADNS/32369960827.html?ws_ab_test=searchweb201556_3_79_78_77_80,searchweb201644_5,searchweb201560_6

Je vais voir si je ne peux pas faire de test rapidement avec de vieilles souris laser et je reviens avec les résultats.

Modifié 24 novembre 2015 par DrGkill2

scoubidoo72 · 24 novembre 2015

J'ai eu l'idée hier soir d'utiliser le capteur laser d'une souris de PC gamer, ça a une résolution de 8200dpi pour un taux de transfert d'information de 12000Hz. En pièce détachée sur Aliexpress on est à 11€ avec les frais de port. Ça devrait être juste assez pour "voir" tourner l'axe principal.

http://fr.aliexpress.com/item/Free-Shipping-1PCS-lot-ADNS-9500-IC-LASER-SENSOR-GAMING-9500-ADNS/32369960827.html?ws_ab_test=searchweb201556_3_79_78_77_80,searchweb201644_5,searchweb201560_6

Je vais voir si je ne peux pas faire de test rapidement avec de vieilles souris laser et je reviens avec les résultats.

Il y a quelques temps, l'idée de détourner une souris optique pour en faire un codeur m'avais aussi traverser l'esprit en lisant des forums de robotique. Mais en réalité même avec une résolution comme celle que tu décrit de 8200 dpi, le précision ne serait pas suffisante.

L'idée serait de voir le déplacement d'une roue fixée sur l'axe d'ascension droite d'un diamètre assez grand pour une plus grande précision. L'optique de la souris viendrait alors tangenter cette roue. Dans mes calcules, je partais sur une roue de diamètre 500mm ce qui représente déjà une roue difficile à intégrer.

Pour un résultat satisfaisant, l'objectif serait d'atteindre au moins une résolution d'une seconde d'arc.

J'ai donc calculé la résolution minimum en mm que devrait avoir le capteur de la souris pour satisfaire l'exigence mini d' 1" d'arc avec une simple règle de trois:

Un tour de complet de l'axe d'ascension droite représente 1 296 000 secondes d'arc(360°*60*60)

Le périmètre de la roue de 500mm de diamètre est d'environ 1570.79mm (2*pi*250)

Pour une rotation d'une seconde d'arc, le capteur de la souris devra voir un déplacement d'environ 0.0012 mm (1570.79/1296000)

Or la résolution du capteur de souris que tu décrit n'est que de 0.003 mm ( 1 pouce soit 25.4mm/8200)

Avec ce capteur, tu arriverais à voir une rotation de 2.5" et ce en prenant une roue de 500mm de diamètre ce qui prend quand même pas mal de place.

Je cherche aussi de mon côté une solution pour réaliser un codeur haute résolution à faible cout dans le but de réaliser une motorisation direct drive de ma monture mais sans résultat pour l'instant :confused:

Pour la motorisation j'avais l'idée de partir d'un moteur de machine à laver direct drive comme ce modèle http://www.pieces-tout-electromenager.com/description.php?id=4495&path=53

Ce moteur serait alimenter par des modules IGBT commander par un arduino en PWM.

Bon courage

Samuel

DrGkill2 · 25 novembre 2015

Il est clair que ça va être juste, mais je doute que le calcul soit si simple.

Il y a plus de paramètres à prendre en compte sur la sensibilité du capteur pour définir ses capacités à voir tourner l'axe AD.

1/ Le capteur embarque une optique. Il a une précision de 8200dpi oui, mais sur l'image qu'il a acquise. S'il y a un grossissement de la surface surveillées, alors il faut faire un calcul avec celui ci.

2/ Un pixel fait 0.003mm oui, mais ce que le capteur fait, c'est voir s'il y a eu changement au niveau d'un des pixel de cette taille. Si on veut faire un calcul rigoureux, il faut donc calculer la probabilité qu'au moins un pixels de la matrice change d'état sur 1 seconde. (1 des N pixels d'une ligne avec M lignes).

Il faudra de ce fait prendre en compte l’irrégularité de la surface surveillée. Plus la surface présente d’irrégularités, plus la probabilité d'un changement d'état de la matrice est fort.

Bref, pour 11€, je pense que l’expérience en dira d'avantage qu'un calcul qui me semble difficile à réaliser.

Pour la motorisation j'avais l'idée de partir d'un moteur de machine à laver direct drive comme ce modèle http://www.pieces-tout-electromenager.com/description.php?id=4495&path=53

Ce moteur serait alimenter par des modules IGBT commander par un arduino en PWM.

Intéressant ! J'ai hâte de voir comment tu vas réussir à intégrer un tel engin ! Ça parait passionnant !

Modifié 25 novembre 2015 par DrGkill2

DrGkill2 · 25 novembre 2015

J'ai trouvé ce site plutôt bien fait et qui fait la synthèse de tous les systèmes d'entrainement :

http://www.dfmengineering.com/news_telescope_gearing.html#direct

Et voilà la conclusion :

scoubidoo72 · 25 novembre 2015

Il est clair que ça va être juste, mais je doute que le calcul soit si simple.
Il y a plus de paramètres à prendre en compte sur la sensibilité du capteur pour définir ses capacités à voir tourner l'axe AD.

1/ Le capteur embarque une optique. Il a une précision de 8200dpi oui, mais sur l'image qu'il a acquise. S'il y a un grossissement de la surface surveillées, alors il faut faire un calcul avec celui ci.

2/ Un pixel fait 0.003mm oui, mais ce que le capteur fait, c'est voir s'il y a eu changement au niveau d'un des pixel de cette taille. Si on veut faire un calcul rigoureux, il faut donc calculer la probabilité qu'au moins un pixels de la matrice change d'état sur 1 seconde. (1 des N pixels d'une ligne avec M lignes).

Il faudra de ce fait prendre en compte l’irrégularité de la surface surveillée. Plus la surface présente d’irrégularités, plus la probabilité d'un changement d'état de la matrice est fort.

Bref, pour 11€, je pense que l’expérience en dira d'avantage qu'un calcul qui me semble difficile à réaliser.

Vu de cette façon, si tu arrives à interpoler la position renvoyer par le capteur de la souris alors là cette solution devient vraiment très intéressante. Je vais suivre ça de près.

Connexion

Controller l'axe AD avec un Arduino et un moteur pas à pas

Messages recommandés

DrGkill2

José9

DrGkill2

Leimury

DrGkill2

dob300

benjamindenantes

DrGkill2

benjamindenantes

DrGkill2

Eric S

benjamindenantes

Leimury

DrGkill2

DrGkill2

benjamindenantes

DrGkill2

scoubidoo72

DrGkill2

DrGkill2

scoubidoo72

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Webastro

Forums

Constellia

Noctua

Communauté

Grenier

Ephémérides

Activité

Information importante