Saccade servomoteur ( avec émetteur radio 868mhz ) sur projet parachute drone

[invite928ea98e]

Bonjour à tous;

Je travaille actuellement sur un projet de déclenchement de parachute embarqué sur les drones . Le fonctionnement est le suivant :

Un boitier est embarqué sur le drone, un autre reste au sol, en cas d'anomalie on appuie sur un bouton d’arrêt d'urgence qui envoie l'info par liaison radio au boitier embarqué déclenchant ainsi la rotation d'un servomoteur qui libère un parachute.

L’électronique du boitier embarqué se compose d'un module radio (868 mhz-500 Mw) émettant un caractère à 1 hz environ (ce caractère est réceptionné sur le boitier récepteur pour contrôler la liaison radio), il est envoyé par un pic16 f.

Ce pic contrôle également le PWM du servomoteur, la commande d'un relais et teste également si un caractère et reçu ( signalant le déclenchement du parachute émis par le boitier au sol)

Seulement j'ai un problème d'ordre CEM, puisque le servomoteur de façon aléatoire saccade au même rythme que l'envoi du caractère.

J'ai pu réaliser plusieurs tests en séparant la commande PWM et l'alimentation du servomoteur de la carte afin d'isoler le servomoteur de mon montage ==> Légère amélioration mais problème persistant

Mise en place de deux ferrites sur le cordon du servomoteur ==> pas d’amélioration

J'ai également entouré de feuilles d'aluminium le fil du servomoteur ainsi que le servomoteur le tout relié a la masse ==> plus de problème

Donc ma question est la suivante, est-il possible de se prémunir de ses perturbations récupérées par le servomoteur au niveau de la conception du circuit ? Mise en place de ferrite sur le PCB, découplage du signal, alimentation ?

Ou la seule solution est le blindage du câble (moyen très contraignant)

Je vous remercie d'avance
-----

[vincent66]

Bonjour,
Une petite cartouche pyrotechnique me semblerait préférable pour l'éjection rapide du parachute...

Si un blindage du câble résout le problème ce n'est pas si contraignant, on trouve du câble blindé en général à paires torsadées pour pas cher chez tout distributeur...

[invite928ea98e]

Merci la cartouche pour des questions de sensibilité (déclenchement par étincelle) n'a pas été retenue pour ce projet


Pour le câble blindé contraignant dans le sens ou il faut mettre en place un connecteur avec une reprise de masse ,ces connecteurs sont en général encombrant et lourd (contraignant pour une application drone) mais pourquoi sans autres solutions

[invite60c6fa7f]

Bonjour, la pyrotechnique me semble aussi le meilleur moyen, très généralement utilisé pour le déclenchement de toutes sortes de systèmes de sécurité. Car c'est bien là le but si j'ai bien compris.
Maintenant, pour le problème de saccades du servo si c'est synchro avec le caractère envoyé ou reçu, je chercherais d'abord dans le code du pic avant les perturbations. Un scope sur la commande t'en dirai sûrement plus...

[A voir en vidéo sur Futura]

[invite928ea98e]

Je suis bien d'accord avec vous sur la pyrotechnique, cependant la mise en oeuvre du système et surtout les différents tests a effectué avant de certifier le système sûr, rend le processus de test laborieux ( système non rearmable), j'estime le déclenchement du parachute après bouton à environ 1s ce qui signifie une chute du drone de 5m pendant ce laps de temps ce qui reste tout à fait acceptable ( auteur de vol généralement 50 m)

Regarder au niveau du code . J'ai réalisé différents tests sans émetteur et avec un pic nu ==> aucun problème ! Le problème ne se manifeste qu'en présence d'un émetteur, provoquant une chute de tension sur l'alim du servo.

Même avec une alimentation de laboratoire directement sur le servomoteur et indépendante de la carte (même chose pour le PWM) la saccade est présente.

Le fil du servomoteur joue le rôle d'antenne et "récupère" l'impulsion RF.

[invite60c6fa7f]

As-tu essayé le blindage, pour voir si ça règle le problème? As-tu mis un scope sur la ligne de commande?

[vincent66]

Hello,
r4ph as-tu lu tous les posts avant de poster..?
Le blindage du câble du servo a résolu le problème mais est trop contraignant pour notre demandeur...
J'en reste sans voix...!

[invite60c6fa7f]

Au temps pour moi... Il m'arrive de lire en diagonale et je m'en excuse.
Si blinder est trop contraignant, peut-être mieux découpler ou charger la ligne de commande du servo... Peut-être un servo d'un autre modèle sera mieux protégé contre les perturbations...

[invite928ea98e]

Pas de soucis

Justement c'est ce genre d'info que j'aurais besoin au niveau découplage

La perturbation génère une chute de tension au niveau de l'alimentation du servomoteur mais pas au niveau du PWM.

Je pensais déjà placer sur les trois pattes du connecteur une ferrite cms (5v-pwm-gnd) , un decouplage avec un gros condo d'une centaine de uF sur le 5v au plus prés du connecteur vous semble utile ?

[invite928ea98e]

Qu'en pensez vous ?

[jiherve]

Bonjour,
la perturbation peut rentrer par l'alim mais plus vraisemblablement par le fil de commande et c'est le circuit d'asservissement qui "détecte" la HF, si le blindage ne convient pas alors il faut intervenir dans le servo!
JR

[invite928ea98e]

Nouvelle expérience de ce matin.

J'ai séparer le circuit de contrôle du servomoteur du reste du montage donc j'ai cablé sur une platine le meme PIC controlant le servomoteur moteur avec sa propre alimentation et j'ai alimenter egalement le circuit habituel qui envoie le caractère.

Le problème disparaît !

J'ai du mal a l'expliquer , le caractère devrait également etre capter par le circuit (certe indépendant ) et perturber ainsi le servomoteur ?

Des idées ?

[jiherve]

bonjour
je pense que tu viens de découvrir une des joies de la CEM: le résultat dépend du câblage et de la distribution de l'alimentation. Il faudrait avoir un schéma et une photo du montage qui pose problème.
JR

[invite928ea98e]

Sans titre.png

DSCN1747.jpg



Si vous egalement des conseils sur le montage dans son ensemble je suis preneur.

Je précise que je m’apprête a passer en 4 couches.

[jiherve]

bonsoir,
je présume que c'est une subtilité CAO mais je ne vois pas la masse sur le PIC.
Donc si j'ai bien compris c'est le PIC qui est maintenant alimenté séparément de la tête HF?
As tu essayé de placer une self de choc(VK200 par ex) dans l'alim VCC_PA de l’émetteur?
Pour finir la liaison vers le servo est vraiment longue , là un bout de tierce torsadée blindée serait un plus.
JR

[invite928ea98e]

Bien vu en effet le masse n’était pas câbler (ce n'est pas la source du probleme , c'est la CAO d'une nouvelle version 4 couches ).

En effet mais comme le module radio est dependant du pic ( pin RX pour l'envoie du caractere ) j'ai cablé un deuxieme PIC sur une platine avec le PWM un 5V et une masse indépendante en reliant le servomoteur et en envoyant le caractere depuis la carte comme ceci



Le probleme disparait (a part si on colle le fil a l'antenne ,mais bon ... ) ,pour la self j'ai placé deux ferrites deja sur (VCC (F2) et VCC_PA (F1)) http://fr.farnell.com/murata/blm18sg...56?ost=1515756 la VK200 apporterait une amélioration tout de même ?

En effet le câble est long mais même problème avec un câble court , d'apres le dernier test ( en photo ) j'ai tendance a me dire que c'est pas forcement la HF capté par le fil qui perturbe directement le servo (sinon elle devrait l'etre egalement sur ce dernière test ) mais plus cette HF qui se propage dans la carte ==> Problème CEM ?

[jiherve]

Bonjour,
dans ce nouveau montage il n'y a donc plus rien de commun ni masse ni alim?
JR

[invite928ea98e]

bonjour,

voila exactement !

Pour essayer d'ou venais le problème j'ai fait différents test par étape :

1 er : Alimentation du servomoteur par un 5V externe à la carte ==> Toujours le problème (PWM provenant de la carte et masse commune )

2 em : Envoie du PWM par un PIC externe a la carte ( Alimentation provenant de la carte et masse commune ) ==> Toujours problème

3 em : Alimentation du servomoteur par un 5V externe a la carte et envoie du PWM par un PIC externe mais masse commune ==> Problème diminue mais toujours présent en collant le servomoteur a l’antenne de l’émetteur

4em : Tout est indépendant de la carte ( montage photo précédente ) ==> Plus de problème même en collant le servo a l'antenne

[f6bes]

Un boitier est embarqué sur le drone, un autre reste au sol, en cas d'anomalie on appuie sur un bouton d’arrêt d'urgence qui envoie l'info par liaison radio au boitier embarqué déclenchant ainsi la rotation d'un servomoteur qui libère un parachute.

L’électronique du boitier EMBARQUE se compose d'un module radio (868 mhz-500 Mw) EMETTANTun caractère à 1 hz environ (ce caractère est réceptionné sur le boitier récepteur pour contrôler la liaison radio), il est envoyé par un pic16 f.

Ce pic contrôle également le PWM du servomoteur, la commande d'un relais et teste également si un caractère et reçu ( signalant le déclenchement du parachute émis par le boitier au sol)

Seulement j'ai un problème d'ordre CEM, puisque le servomoteur de façon aléatoire saccade au même rythme que l'envoi du caractère.


Donc ma question est la suivante, est-il possible de se prémunir de ses perturbations récupérées par le servomoteur au niveau de la conception du circuit ? Mise en place de ferrite sur le PCB, découplage du signal, alimentation ?

Ou la seule solution est le blindage du câble (moyen très contraignant)

Je vous remercie d'avance

Bonjour à toi,
Ta description parait assez ...scabreuse !
Ton mondule EMBARQUE ne peut etre qu'UN récepeteur (RECOIT un ordre)...depuis le sol), pas un ...émetteur (500mW)
Donc je ne vois pas l'utilité d'une EMISSION "embarquée" sur ton drone.

De plus dans quels cas envisages tu d'actionner le parachute ? Si t'as un probléme d'énergie, comment vas tu alimenter ton
servomoteur de parachute.

Me demande si t'as bien choisi la bonne solution ?

Bonne journée

[invite928ea98e]

Bonjour,

Non je me répète le module embarqué émet bien a 1hz un caractere en direction du sol. L'envoi de se caractère permet de tester la liaison entre le module embarqué et au sol (caractere recu par le boitier au sol ? oui ==> communication ok , non ==> alerter l’opérateur )

le système embarqué a une alimentation indépendante du drone d'une autonomie bien plus consequente que celui ci

[jiherve]

bonsoir,
donc c'est ton émetteur qui pisse dans l'alimentation, as tu observé avec un oscillo ce qui se passe sur les rails d'alimentation lors de l'emission?
Ne peux tu pas alimenter le PA directement à partir de la batterie ?
JR

[f6bes]

Bonjour,

Non je me répète le module embarqué émet bien a 1hz un caractere en direction du sol. L'envoi de se caractère permet de tester la liaison entre le module embarqué et au sol (caractere recu par le boitier au sol ? oui ==> communication ok , non ==> alerter l’opérateur )

le système embarqué a une alimentation indépendante du drone d'une autonomie bien plus consequente que celui ci

Remoi, Pourquoi tiens tu à "tester" ta liaison (drone --> sol) ?
A mon avis c'est strictement inutile. Suppose que tu recoives un " non"...tu prends QUELLE décision ?
Rien ne dit que suivant la "position" de ton drone ton signal 868 mW (et du récepteur au sol )puisse etre reçu durant quelques instants (fading,pertubations...etc).
C'est pas pour autant que tu va devoir déclencher ton parachute et tu ne sais RIEN du pourquoi de la non réception du signal.

Pus on complexifie un montage , plus on risque les pannes inopinées ( bugs, etc..)

Bonne journée

[invite928ea98e]

Tout simplement car c'est un système de sécurité et une procedure dans le pilotage de drone.

Il est indispensable de connaitre si liaison il y a , a partir du moment ou il a plus de liaison le systeme ne peux plus assurer la sécurité du drone, l'operateur est prevenue , libre a lui de prendre le risque de franchir cette limite.

En ce qui concerne l'alimentation du vcc_pa je ne peux l'alimenter directement sur la batterie (tension variable ) mais vous penser que le problème viendrait de la ?

J'essaierai de l'alimenter séparément

affaire a suivre

En tous cas merci de votre aide

[jiherve]

Bonsoir,
Il faut bien essayer de séparer les variables.
JR

[invitef29758b5]

Salut
En plus d' être commandable par le pilote , le déclenchement du parachute doit être automatique en cas de perte de signal et lié à l' activation du "fail safe" .
Pas besoin d' un signal retours .