Tipe élève en prépa

Échange entre membres, demande d'aide,...
Règles du forum
Comme son nom l'indique cette section est destinée a recevoir vos petites annonces: offre d'emploi ou de stage, d'outillage, de matière première ou autre.
StingKnight
Messages : 4
Enregistré le : 25 janv. 2020, 22:46

Tipe élève en prépa

Messagepar StingKnight » 25 janv. 2020, 22:52

Bonjour j'aurai besoin de savoir si cela est possible de synchroniser les signals d'horloge pour les capteurs ultrasons HC-SR04
Modifié en dernier par StingKnight le 26 janv. 2020, 10:05, modifié 1 fois.
StingKnight
Messages : 4
Enregistré le : 25 janv. 2020, 22:46

Re: Tipe élève en prépa

Messagepar StingKnight » 26 janv. 2020, 10:05

Je suis étudiant en CPGE au lycée Jean Mermoz,et dans le cadre de mon
TIPE je fais une expérience avec une Arduino. Mon TIPE consiste à faire
un suivi d'une personne faisant du ski nautique,ou du wakeboard,(pour
faire un enregistrement vidéo pour son loisir). Afin de détecter la
personne je comptais utiliser une triangularisation grâce à des capteurs
à ultrasons(les HC-SR04). Déjà premièrement est il possible d'utiliser
que la fonction récepteur/ ou émetteur de ce capteur? Je comptais mettre
un capteur à ultrasons sur la barre(convention récepteur) qui tire la
personne et 2 autres capteurs aux extrémités du bateau en convention
récepteur. Grâce à ce système je pourrai donc savoir où se trouve la
personne et pouvoir déterminer un angle par rapport au milieu de
l'arrière de mon bateau (endroit où se trouvera ma caméra). Grâce à un
servomoteur je ferai donc tourner ma caméra.Et si oui comment faire pour
synchroniser les signals d'horloge (que ce soit sous Arduino ou
directement grâce aux branchements)?
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1592
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Tipe élève en prépa

Messagepar Flax » 27 janv. 2020, 00:36

Bonjour,
StingKnight a écrit :est il possible d'utiliser que la fonction récepteur/ ou émetteur de ce capteur?

Pour être sûr : on parle bien d'utiliser uniquement l'émission ou la réception n'est-ce pas ?
Si l'on en croît ce schéma tout tourne autour du composant U1 / EM78P153S, qui est un microcontrôleur 8-bits basique, et U3, qui doit sans doute être un driver intelligent pour haut-parleur ultra-sons (sans doute une version beaucoup plus basique que celui-là). C'est U1 qui prend le signal trigger, et qui doit indiquer à U3 les impulsions à générer via TX1 et TX2 (je suppose tout ça, s'pas ? Je n'en ai aucune idée en vrai). De l'autre côté il reçoit le signal du récepteur, après un conditionnement (le haut du circuit autour de U2B, U2C, U2D), et il génère un signal de seuil (THRESHOLD, selon toute vraisemblance généré via une sortie PWM qui est lissée par R11-R12-C8) qui est utilisé pour référence pour le comparateur U2A.

https://www.davidpilling.com/wiki/index.php/HCSR04

Ce qui est flagrant, c'est qu'il y a visiblement un retour du signal reçu vers l'émission, via les entrées SLICE et SIGIN de U3, donc je suis quasi-sûr qu'il y a modulation de la puissance d'émission en fonction de l'amplitude du signal reçu, et donc je doute fortement qu'il soit possible de décorréler l'émission et la réception sur ce module. En étant vraiment gruiiiik on peut imaginer forcer U3 à émettre à puissance fixe, mais pour ça il faudrait avoir sa datasheet pour savoir comment il fonctionne.
Bon, je ne pense pas qu'il soit nécessaire de faire des choses aussi compliquées.
Faire de l'émission seule est relativement facile : il suffit de ne pas lire ECHO :mrgreen:
Pour la réception seule, si on émet des trains d'impulsion à 40kHz (à priori c'est la fréquence des signaux utilisés sur ce module) par une autre source, on devrait avoir ECHO qui bagotte quand il voit passer les signaux. Et ce sans envoyer de commande sur TRIGGER, à priori ça devrait marcher. Ptet je me trompe et U1 n'envoie rien sur ECHO tant qu'on ne lui demande pas d'émettre ... Mais ça me semble un peu trop compliqué comme comportement. A mon avis, il mesure juste ce qu'il se passe sur SIGNAL, et quand il voit qu'il y a une impulsion qui passe il envoie une impulsion sur ECHO (et en parallèle il mesure l'amplitude du signal et il adapte sa sortie THRESHOLD en fonction pour moduler la puissance de l'émetteur, mais ça pour de la réception seule on s'en fiche un peu).

(Grmpf ... chuis bête, ils décrivent le fonctionnement du circuit ici : http://www.pcserviceselectronics.co.uk/arduino/Ultrasonic/electronics.php#circuit)

Par contre je ne comprends pas du tout quelle est la question concernant la synchronisation des horloges. Quelle synchronisation ? Entre quelles horloges ?

Vu la première question et vu que tu parles de triangulation, je suppose que ton idée est de mettre un émetteur sur le bonhomme à suivre, et deux capteur à l'arrière du bateau, un de chaque côté, et de comparer les distances mesurées pour en déduire l'angle entre l'arrière du bateau et le bonhomme, c'est bien ça ? En tous cas moi je ferais comme ça.

Je suppose que ton problème est de savoir identifier au niveau des récepteurs quel train d'impulsion d'un côté correspond à quel autre train d'impulsion de l'autre côté quand il commence à y avoir beaucoup de trains envoyés à intervalle régulier. Pour moi, avec un module aussi simpliste que celui-ci, il n'y a aucun moyen de discriminer les signaux, car pour cela il faudrait les "marquer" pour les différencier, or ici le module envoie juste des impulsions à fréquence fixe, et fait une détection tout-ou-rien pour savoir s'il reçoit ou non cette fréquence. Si c'est bien ça ton problème, je pense qu'il serait plus simple de le contourner, et envoyant des trains d'impulsions suffisamment éloignés les unes des autres pour que le temps entre deux trains soit largement supérieur à la longueur d'onde la propagation du son entre le bateau et le bonhomme à suivre. De cette façon, quand tu reçois de chaque côté des signaux qui reviennent, s'ils sont suffisamment éloignés de base, même si le bonhomme est très désaxé par rapport à l'axe du bateau cela ne provoquera pas un décalage suffisamment grand pour être du même ordre de grandeur que le temps entre deux impulsions émises. De cette façon, pour savoir quel train reçu d'un côté correspond à quel train reçu de l'autre, il suffit de regarder lesquels sont proches.
Si on dit, 8 impulsion à 40kHz, on est dans les 250µs. Si on suppose que la source est ~10m derrière le bateau (je prends cette longueur au pif, c'est à réadapter) on a donc un temps de propagation de 10m / (300m/s) = ~33ms, donc 66ms aller-retour. Ça c'est la latence du signal, le retard entre l'émission et la réception. L'écart max qu'il y aura entre les deux côtés ça va dépendre de l'angle maximal que prendra le bonhomme par rapport à l'axe du bateau. Cet angle sera de toutes façons limité par la directivité du capteur. Si on dit qu'il s'écarte de +/-45° (je donne ce nombre au pif, ça me semble déjà beaucoup), et que le bateau fait ~1.5m de large (toujours au pif), ça fera une différence max entre la source et les deux capteurs de +/- ~1m (approximation à la hache), donc un délai de +/- (1m / (300m/s)) = ~3ms. Pour pouvoir les discriminer, il faut donc envoyer des impulsions écartées d'une durée notablement supérieure, genre 3 fois, genre 20ms.
Ça veut dire envoyer des TRIGGER une fois toutes les 20ms, et donc aussi que le rafraichissement serait de cet ordre de grandeur, donc 50 fois par seconde. Ça devrait être suffisamment rapide. Par contre, ne pas oublier qu'il y a la latence qui fera que la correction de l'angle aura toujours 66ms de retard sur le déplacement effectif de la cible. Ça m'a l'air relativement tolérable.

Sinon, autre idée plus pointue : créer un motif, en envoyant des trains plus rapprochés, mais pas à des intervalles égaux, mais avec un motif périodique facilement identifiable, qui fasse au minimum 20ms de période totale (genre 1ms - 2ms - 3ms - 4ms). En regardant l'écart entre deux ECHOS, on peut savoir à quel niveau du motif on se trouve, de chaque côté, et donc retrouver quelle impulsion d'un côté correspond à quelle impulsion de l'autre côté. Bon, c'est surdimensionné, à priori pas besoin d'un truc aussi évolué, la méthode précédente doit donner de bons résultats.

Si tu as des questions ...
Avatar de l’utilisateur
3dsman
Electrolab::CA
Messages : 810
Enregistré le : 24 avr. 2016, 19:13

Re: Tipe élève en prépa

Messagepar 3dsman » 27 janv. 2020, 14:56

A mon avis tu pars sur un truc trop compliqué et qui ne sera pas fiable de toute facon:
les HR04 sont des capteurs ultrason bas de gamme qui ne dépassent pas les 3m de portée, vont te renvoyer des échos de partout (il y a des vagues autour de ton gars) et de toute facon faire de la triangulation a plusieurs mètres de distance avec deux capteurs espacés de quoi...2m en environnement réel c'est un poil plus galère.
les HR04 sont en plus pas étanches et vont décéder avant même d'avoir démarré.

Ce qui me semble plus crédible et a porté d'un TIPE de lycée ce serait de passer par de la reconnaissance d'images:
- une webcam fixe a l’arrière de ton bateau avec un champ assez large pour toujours voir le skieur
- un QR code ou autre motif reconnaissable à distance sur la barre ou directement sur le gars (combi?)
- une raspbery pi pour traiter le signal de la webcam avec un petit script en python utilisant la librairie openCV pour faire la reconnaissance d'image et piloter le servomoteur de la caméra de suivi

une version basique peut être mise en place très rapidement (et même testée sur n'importe quel ordi avant même de l'envoyer sur la raspbery pi)
tu trouvera sûrement sans aucun problème des codes d'exemple pour faire ce genre de chose sur github (je suis sur qu'il y a des projets du même style avec du tracking de visage par exemple)

en bilan tu aura découvert le python, le raspberry pi, et openCV, ca te donnera de quoi jouer a faire plein d'autres trucs derrière ;)
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1592
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Tipe élève en prépa

Messagepar Flax » 27 janv. 2020, 15:53

Grmpf ... J'avais pensé à la solution traitement d'image, mais je me disais que c'était trop compliqué :P
Plus sérieusement, oui, ces remarques sont pertinentes.

Après, pour robustifier, sans parler parler portée et étanchéité, là on est peut-être plutôt dans une config qui conviendrait au Lidar ? Mais là on part peut-être VRAIMENT dans le compliqué.
Quand tu dis qu'il va y avoir de l'écho, tu penses à quoi ? Rebonds sur la surface de la flotte ? Parce que dans ce cas, peut-être ça veut dire qu'il faut faire un truc du même tonneau (source unique sur le bonhomme, deux capteurs à l'arrière du bateau) mais travailler à une autre fréquence. Si le bonhomme a un émetteur, on a pas besoin qu'il y ait des réflexions (il vaut mieux qu'il n'y en ait pas d'ailleurs ...), donc on peut choisir quelque chose qui ne rebondit pas sur l'eau. Genre dès que tu montes en fréquence l'eau absorbe pas mal, non ? Donc ptet il faut travailler sur des fréquences radio pour être sûr de ne pas être trop perturbé par les réflexions sur la flotte. Après yaura les vagues, certes ...
D'ailleurs ça peur être une problématique à traiter pour un TIPE : comment choisir la longueur d'onde du signal pour avoir du signal mais pas de réflexion sur la surface de l'eau ?
Après, portée (donc puissance) et étanchéité, ce sont d'autres sujets. En particulier, pour émettre dans le spectre radio on ne fait pas ce qu'on veut (https://www.ebds.eu/applications-docs/documentation/fr%C3%A9quences-libres-en-france/). Mais ptet en y allant mollo sur 169MHz ou 2.4GHz ya moyen de faire kekchose ?
Bon, c'est troquer de la complexité software et traitement d'image contre de la complexité hardware, radio et législative.
StingKnight
Messages : 4
Enregistré le : 25 janv. 2020, 22:46

Re: Tipe élève en prépa

Messagepar StingKnight » 28 janv. 2020, 01:00

Bonjour,

Oui c'est cela tu as bien compris, donc pour n'utiliser que la cellule émettrice ou réceptrice il suffirait juste de n'utiliser que la branche echo et la branche trigger des capteurs si j'ai bien compris? De plus étant donné que le capteur émet des ondes de fréquence 40 kHz cela serait-il vraiment nécessaire de marquer les impulsions ? Car en y réfléchissant à chaque instant la carte arduino va déterminer la distance à laquelle se situe le wake-boardeur en comparant à l'instant précédent il est donc possible de trouver la zone où se situe la personne. J'avais aussi penser à mettre 3 capteurs à l'arrière de mon bateau et de procéder par un repérage de la zone où se trouve la personne.
Je comptais essayer de faire ce modèle sous forme de maquette et non de système réél, sachant bien que les capteurs ne sont pas étanches et ne possèdent qu'une très faible portée et un faible angle de mesure.
Donc une solution à mon problème de signal d'horloge serait d'émettre des ondes à intervalle régulier afin de pouvoir les diffférencier ?

J'avais aussi pensé à la solution du traitement d'images mais le traitement d'image en direct me posait problèmes je ne savais pas comment y remédier, les capteurs me paraissant dès lors bien plus efficaces et pratiques. Je suis déjà habitué au python mais je me demandais si les capteurs ne seraient pas une solution plus faciles d'accès. Pensez vous que la solution avec la raspberry pi soit plus abordables ?
merci beaucoup en tout cas de vos réponses !
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1592
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Tipe élève en prépa

Messagepar Flax » 28 janv. 2020, 13:57

Pour info : utiliser plusieurs récepteurs et corréler les déphasages des signaux d'une même source pour identifier la direction de provenance de la source, on appelle ça "beamforming". C'est ce qui est utilisé par les antennes relais GSM pour identifier la direction d'un téléphone et concentrer l'émission radio vers ce téléphone particulier plutôt qu'en omnidirectionnel C'est aussi utilisé sur les appareils de téléconférences (pieuvres, kits mains-libres ...) pour éliminer le bruit ambiant (j'avais bossé là-dessus sur mon stage de fin d'études chez ST, je n'en tire pas une fierté inoxydable, mais j'avais quand-même bien taffé le sujet). C'est aussi utilisé par les systèmes de détection militaires pour détecter la position d'un émetteur ennemi ...
Avatar de l’utilisateur
3dsman
Electrolab::CA
Messages : 810
Enregistré le : 24 avr. 2016, 19:13

Re: Tipe élève en prépa

Messagepar 3dsman » 30 janv. 2020, 13:23

si c'est pour une maquette c'est peut etre jouable d'utiliser les HR04 mais le choix technologique risque de t'empecher de le faire en réel.
il fut te poser des question importantes avant de choisir ta méthode: que captent les différents capteurs utilisables (ultrason -> distance, webcam -> angle) et quelles sont leurs résolutions, temps de rafraîchissement, portée, taux d'erreur,...
Tu cherche un angle (pour orienter ta caméra) donc dans la solution ultrason il te faut convertir tes 2 distances en angle -> triangulation. Jusque la c'est bon.
questions a se poser:
- quel delta aura tu entre les temps de tes 2 capteurs et quelle résolution tu peux espérer?
- a quelle frequence tu pourra faire tes mesures (dans la maquette et dans le monde réel)?
- quel taux d'erreur tu aura et comment les détecter et corriger?
- comment tu stabilise ta caméra en cas d'erreur de mesure?

pour la première question imaginons un cas simple: tu as 2 capteurs écartés d'1m, ta cible est a 10m, sachant que le son voyage a 340m/s, quel différence de temp mesurerait tu dans l'idéal si ta cible etait décalé de 10° sur la droite ou la gauche? question de trigonométrie, vous avez 2h)
Plus ta cible sera éloignée plus la différence sera faible et donc plus tu aura d'imprécision sur ton angle

question 2:
si ta cible est a 10m, avec un son qui se déplace a 340m/s tu pourrait faire une mesure tous les 34eme de secondes dans le meilleur des cas (probablement moins pour savoir repérer une non détection) si tu as un émetteur sur ta cible et un récepteur sur le bateau. Plutôt 1/17eme de seconde si émetteur/récepteur sont sur le bateau (le temps de l'aller/retour du son).
Admettons 25 mesures par seconde. Attention ce taux de rafraîchissement t'interdit que ta cible soit a 15m!

question 3:
quel est le taux d'erreur des capteurs HR04? bonne question, ça se teste!
Pour en avoir utilisé a la coupe de robotique pour faire de la détection de robots adverses je peux te dire que la fiabilité de la mesure de distance est pas ouf. De mémoire on faisait des séries de 5 mesures et on faisait une moyenne des 3 plus "fiables" (mesures proches avec élimination des valeurs fantaisistes) et la on parle de détecter un robot de la coupe a moins de 50cm...

question 4:
il s'agit que ta caméra se mette pas soudainement a tourner a 90° parce qu'une erreur de mesure lui dira que ta cible est soudainement passé sur le coté
C'est aussi la question d'éviter les vibrations, tes mesures ayant un certain niveau de précision elles vont passer leur temps a envoyer des résultats bruités (avec une part d'aléatoire) comment faire pour que ta caméra elle soit stable?
Ce problème est traitable en soft mais il faut le prévoir et réfléchir a un algorithme qui fera un mouvement propre a partir d'informations bruitées.
Tu peux faire ça avec un simple moyennage des mesures ou dans le cas ou tu voudrait vraiment un truc utilisable un filtre de kalman (oublie dans ta situation)


Voila pourquoi je proposait la solution de tracking en optique, il y a des gens qui ont déjà fait des modules pour ça et ça marche très bien.
Tu as directement une mesure d'angle (apres une petite calibration) et une résolution et un taux de rafraichissement tres largement superieurs a ce que tu pourra obtenir avec des ultrasons
Les modules d'openCV te disent direct s'ils ont rien détecté, tu n'a que la dernière question a traiter pour que ta caméra ne risque pas de faire des mouvements débiles (et ca se fera facilement avec un simple moyennage des mesures apres élimination des valeurs débiles
Et si tu as déjà fait du python y a un petit challenge mais ça devrait pas être un trop gros problème.
C'est aussi un truc que tu pourra mettre dans ton rapport: écriture de ton cahier des charges -> identification de plusieurs options, analyse des contraintes et de tes capacités -> choix d'une solution technique -> réalisation d'un prototype

quelques pistes tirée de https://github.com/search?l=Python&q=op ... positories (il y en a 83 pages ;) )
https://github.com/Mjrovai/OpenCV-Object-Face-Tracking
https://github.com/bikz05/object-tracker
https://github.com/gaborvecsei/Color-Tracker


@flax: faire de la mesure de temps de vol en radio sur ces distances ça se fait mais pas au lycée :-) et pour de la triangulation on est pas vraiment sur le même niveau, ni le même ordre de tarif
Avatar de l’utilisateur
nats
Electrolab::Membre
Messages : 207
Enregistré le : 25 févr. 2018, 10:13

Re: Tipe élève en prépa

Messagepar nats » 30 janv. 2020, 15:44

J'ai pas vraiment eu le temps de lire tout ce qui est proposé au dessus mais je vais rester sur la demande de départ car tu propose une modification du module ultrason et c'est exactement ce qu'il faut faire pour vraiment utiliser ces modules la.

J'ai bricolé un modèle rapide de comment je vois ce que tu décris:
elec_lab_skieur.png
elec_lab_skieur.png (68.2 Kio) Vu 5895 fois


On va considérer que le vent est uniforme dans le système pour faciliter la chose (c'est sûrement complètement faux mais si on ne fait pas ça rien ne fonctionne en ultrason car leur vitesse de déplacement est directement liée à la vitesse du vent et à sa direction). On va aussi considérer que le skieur est toujours du même cote de la barre et qu'il s'est pas envolé de l'autre coté :D

On va aussi considérer que le skieur a un émetteur sur lui qui envoie une trame codée régulièrement, cette trame est choisie car elle est facile à détecter et facile à synchroniser, pour ça faut pas réinventer l'eau chaude sur une petite démo il y des choses toutes faites dans le domaines du radar/sonar comme les code de barker ou les séquences d'auto-corrélation (kazami, gold, etc).

L'idée ici c'est que les récepteur sont soit acquis par le même contrôleur et on reçois donc la même trame décaler dans le temps et ce temps de décalage dépend donc uniquement du temps de trajet dans l'air, soit on arrive a synchroniser les récepteur d'une autre manière (honnêtement la deuxième solution est beaucoup trop compliqué pour une démo simple !)

Vient la question de l’implémentation, il y a plusieurs types de modules et j'en ai eu personnellement deux mais je ne me rappelle plus des références, sur certains c'est un PIC16 qui fait tout et qui sors les IO TRIG/DETECT, celui la est chiant il faut beaucoup de modification, par contre sur l'autre c'est des AOP et des comparateurs ! Et la on peut facilement interfacer un MCU pour n'utiliser que la voie intéressante (le circuit imprimé étant en deux couches et pas cher on peut même couper au cutter les pistes gênantes !)

Implémentation de l’émetteur:
Cette partie est simple il faut remplacer le train d'impulsion du module par la sortie du MCU qui envoie la bonne séquence le mieux étant de garder l’étage de pilotage analogique déjà existant.

Implémentation récepteur:
Il faut généralement récupérer la sortie du comparateur du premier étage (valable que sur certains modèle) pour récupérer en faite la sortie du récepteur en niveau logique et la faire entrée sur un périphérique type Capture/Compare du MCU et faire la détection en soft (cette partie la fait appelle a des corrélation et a du traitement de signal, on peut le faire de manière simple dans une demo, dans la réalité ça peut devenir plus compliqué)

J'ai voulu collé au mieux a la demande initial par contre je ne garantie pas que ce soit une réponse plus intelligente et plus simple que celles proposés au dessus par mes camarades ! (je suis même sûr que certains points peuvent-être pièges) :D

EDIT: Apparemment le HRC04 aurais ce schema la:
KY-050-and-HC-SR04-Utrasonic-Sensor-schematic.jpg
KY-050-and-HC-SR04-Utrasonic-Sensor-schematic.jpg (54.05 Kio) Vu 5890 fois

Si c'est bien celui il n'est pas trop dur de se greffer au bon endroit pour réaliser les fonctions de TX et RX spécifiques avec des séquences dédiées à ton applications ;)
StingKnight
Messages : 4
Enregistré le : 25 janv. 2020, 22:46

Re: Tipe élève en prépa

Messagepar StingKnight » 02 févr. 2020, 13:06

Bonjour,

Pour la première question je m'en suis déjà occupé avec un modèle simple avec de la trigonométrie et un développement limité pour les petits déplacements de la personne au bout de la corde. De plus je supposerai mon système linéaire de façon à ce que quand j'augmente mes valeurs cela correspond au système réel(différents facteurs rentrent en compte comme la température, les limites du capteurs mais pour commencer il faut déjà simplifier le problème).
L'autre solution sinon serait d'utiliser plusieurs HC-SR04 et de les fixer à l'arrière de mon bateau. Car en discriminant les signals de mes capteurs et de les émettre à intervalle de temps régulier. Ainsi j'aurai une zone ou se situera la personne. Le nombre de capteurs permettant ainsi d'augmenter la précision. J'ai cette semaine fait une expérience afin de mesurer l'incertitude et l'angle de mes capteurs, concernant l'incertitude de mes capteurs elle est de plus ou moins 1cm pour 1m de distance. Et concernant l'angle c'est correct vis à vis de la notice donc à peu près 15°.
Pour éviter que ma caméra se tourne brusquement dû à une erreur de mesure je ferai attention à l'erreur de mesure entre 2 mesures. C'est à dire que si l'écart se révèle être trop grand 2 solutions sont possibles: soit il y a eu une erreur de mesure soit la personne est sortie du champ de la caméra.


Si l'on voulait donc lire les signals d'entrée et de sortie il suffirait donc de lire les entrées et sorties sur les TX et RX respectifs de mes capteurs "émetteurs" et "récepteurs" ?Il faudrait donc modifier le circuit électronique ou juste arrivé à faire lire à ma carte arduino les différentes sorties voulues ?

je vous remercie une fois de plus de vos réponses qui m'apportent beaucoup d'aides

Retourner vers « Petites Annonces »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité