Page 1 sur 1

Posté : 16 sept. 2010, 19:00
par Slamy
Bonjour à tous,

Petit nouveau sur ce forum, j'ai décidé de m'inscrire après avoir pas mal parcouru et apprécié le forum. Merci à Proteus pour avoir géré mon inscription :wacko:


Je suis débutant dans le modélisme "helico" mais suite à des tests sur l'appareil d'un ami d'un ami, j'ai vraiment accroché. je voudrais donc me lancé sur l'assemblage d'un octo. Mais avant tout, faire un peut de théorie, calculs, ... avant de vraiment me lancer.
J'ai par contre pas mal de questions et j'en aurais surement encore beaucoup d'autre !


- Je rencontre souvent des termes utilisés que je ne connais pas comme "la FC", "Lipo" (Liposucions :D ), ... existe t'il un article qui donne la traduction pour débutant ?

- Il existe plusieurs parties (plusieurs cartes) sur les octo, quels sont les fonctions de ces cartes ?

- J'ai aussi croisé des quadri avec 8 hélices restent t'ils des quadri ? Quel est l'avantage entre un quadri avec 8 hélices, et un octo ? (peut on envisagé un octo avec 16 hélices ? :wub: )

- J'ai aussi vu que la taille des hélices peut varier sur un même model, si je prends des hélices plus grandes pour un même appareil, quels sont les gains / les pertes ?



Voila pour un début ! En tout cas j'ai trouvé le forum et le site vraiment simpa !


Edit: en lisant un peut plus le fofo et les articles je viens de voir la différence entre les octo et les quadri à 8 hélices : les quadri à 8 hélices sont plus compacts mais le rendement n'est semble t'il pas aussi bon qu'un vrais octo. (ce serait quand même envisageable avec 16 hélices un Octo? :P )

Posté : 16 sept. 2010, 20:10
par khead19
Pour les termes employés , je ne connais pas de dictionnaire disponibles, mais on apprends vite par le simple fait de la manipulation.

Oui il existe plusieurs cartes:
-BL-CTRL............... controleurs moteurs, elle gèrent la vitesse de moteurs
-FLIGHT-CTRl...............Carte mère principale qui permet en fait de gérer l'ensembles de l'appareil
- Navictrl............... carte pemettant le transfert de communications entre la carte mères et les cartes additives et l'enregistrement des données de vol.
- MK3 MAG............... carte boussole electronique(comme son nom l'indique c'est une boussole)
- GPS...............bon ben là tu doit comprendre .... c'est un GPS

c'est un peu simplifié mais c'est en gros ce que font les cartes sur un MK

un 8 quadri à 8 moteurs comme tu le dit est un Okto en coaxial. dés l'instant où il y a 8 moteurs c'est un Okto, 6 moteurs un Hexa, 12 moteurs un Dodeka.... un 16 moteurs serait un HEXADEKAKOPTER mais c'est impossible à faire pour le moment étant donné qu'on ne peut, pour le moment, adresser plus de 12 moteurs.

Pour les termes en voici quelques unjs:
FC ---> flight ctrl
NC---> navi ctrl
Lipo---> batteries Lithium Polymère
RC---> la radiocommande
RX---> emeteur
TX---> recepteur

Posté : 16 sept. 2010, 20:24
par catlord
déjà avec un dodécacoptère tu peux soulever un gros chien (pas un St bernard non plus hein ^^) alors l'interet de l'hexadodécatruc avec zibulateur a impédance... mweh .... claquer une brique de fric pour rien quoi ^^

Renseigne toit sur les tarifs hin parce que 1 moteur c'est entre 16$ et 99€ avec une bonne moyenne à 35€ .
35*8=280€
8 controleurs à 39€ pièce
8*39=312€
une carte de vol 300€

et là tu n'as aucune option (GPS,compas, OSD, camera etc...)

donc commencer par un quadri et le faire fonctionner c'est bien :D

Posté : 16 sept. 2010, 21:03
par Adreakor
catlord @ 16 Sep 2010, à 20:24 a écrit : Renseigne toit sur les tarifs hin parce que 1 moteur c'est entre 16$ et 99€ avec une bonne moyenne à 35€ .
Les moteurs doubles (coax) sont encore plus chèrs ! :P :ph34r:

Ricky

Posté : 16 sept. 2010, 21:25
par Slamy
snif je pourrai pas faire de Dodeka ... :(

Bon blague à part ... Merci pour ces premières réponses, je commence à y voir un peut plus claire !

Mon budget étant de (normalement) 1500 - 2000 l'octo reste dans mes budget de ce que j'ai pu lire et de ce que vous me dites. Je compte prendre un petit appareil à 100 - 150€ pour apprendre à voler puis monter mon octo pour l'avoir fini dans 1 ans (j'espère entre temps avoir appris les bases de maniement) Ayant fais du pilotage ULM 3 axes, je pense avoir quelques bases utiles sur l'importance de la patience et d'y aller en douceur, par étapes, etc. !

J'ai un étais tenté par l'idée du quadri sur châssis octo, mais après réflexion je préfère faire un octo directement.

Je me demande maintenant si la programmation intervient sur la FC ou sur toutes les cartes ! je suppose que la prog est en C de base mais je n'ai pas encore trouvé où me confirmer ce point.

Je me demande aussi s'il existe des châssis de type "repliable" ou s'ils sont tous rigides. Car je peux programmer et souder des Circuits électroniques mais pour ce qui est de découper et travailler des matières 1ières ... c'est une autre histoire.

J'avais lu dans un poste que je ne retrouve plus ... qu'un utilisateur réalisait un octo, mais qu'il remplaçait les hélices de 10,5 par des hélices de 12,5 je crois. Je me demande quel est l'avantage de faire cela ?!

Micaël.


Edit: je vois souvent écrit : "brushless" c'est quoi exactement ?! <_<

Posté : 16 sept. 2010, 22:01
par catlord
Slamy @ 16 Sep 2010, à 20:25 a écrit : snif je pourrai pas faire de Dodeka ... :(

Bon blague à part ... Merci pour ces premières réponses, je commence à y voir un peut plus claire !

Mon budget étant de (normalement) 1500 - 2000 l'octo reste dans mes budget de ce que j'ai pu lire et de ce que vous me dites. Je compte prendre un petit appareil à 100 - 150€ pour apprendre à voler puis monter mon octo pour l'avoir fini dans 1 ans (j'espère entre temps avoir appris les bases de maniement) Ayant fais du pilotage ULM 3 axes, je pense avoir quelques bases utiles sur l'importance de la patience et d'y aller en douceur, par étapes, etc. !

J'ai un étais tenté par l'idée du quadri sur châssis octo, mais après réflexion je préfère faire un octo directement.

Je me demande maintenant si la programmation intervient sur la FC ou sur toutes les cartes ! je suppose que la prog est en C de base mais je n'ai pas encore trouvé où me confirmer ce point.

Je me demande aussi s'il existe des châssis de type "repliable" ou s'ils sont tous rigides. Car je peux programmer et souder des Circuits électroniques mais pour ce qui est de découper et travailler des matières 1ières ... c'est une autre histoire.

J'avais lu dans un poste que je ne retrouve plus ... qu'un utilisateur réalisait un octo, mais qu'il remplaçait les hélices de 10,5 par des hélices de 12,5 je crois. Je me demande quel est l'avantage de faire cela ?!

Micaël.


Edit: je vois souvent écrit : "brushless" c'est quoi exactement ?! <_<
tention hein, avec le kit il te faut la radio (Tx) le recepteur (Rx), deux batterie LiPo, chargeur de baterie, matos divers et varié etc...
la facture grimpe TRES vite.

Si tu veu apprendre le pilotage, prends toi un mini hélico type blade MSX: tu peux le crasher ss pb et ça te mermet de bien apprendre :)
sinon si tu veux avoir un quadri de débutant pas top cher : le QC450 de chez conrad : châssis fragile mais electronique de compe (TRES stable) et increvable :D

Pas de programmation !
il faut juste apprendre à se servir du soft de paramétrage mais c'est tout du clic and play.


Pour les châssis type repliable bah .... bon je me fait de la pub mais je vais pas tarder à ouvrir une boutique internet avec des châssis ( X8/Y6/Hexa) qui ont TOUS des bras repliables :D.
Ca prendra un peu de temps ( je compte encore 6 à 8 semaines) mais je bosse comme un fou sur les plans (regarde le post [commande groupée châssis SLE-X9.01])

Pour les hélices c'est plutôt compliqué: tu as 4 paramètres a mixer:
-caractos de ton moteur (à quelle puissance est il en régime idéal)
-alim electrique
-controleurs brushless ( cf + loin pour savoir ce qu'est un brushless :D)
-hélice
Ces 4 paramètres jouent tous sur le choix de l'hélice

brushless: "sans balais" c'est les moteurs éléctriques qu'on utilise sur nos multicoptères :)

Posté : 16 sept. 2010, 22:44
par Slamy
Encore Merci pour ces nouvelles réponses.

Oui l'idée d'un appareil du type "blade MSX" me semble le plus adapté.

j'ai survolé le poste "[Commande groupée châssis SLE X9.01]". Avec le nombre de page, dure de tout lire :huh: ! Mais par contre ce châssis là, il n'est pas repliable; si? Si oui en version plié qu'est-ce que cela donne ? En tout cas, si tu fais un châssis repliable pour Octo, je serais surement preneur.

Je viens de retrouver le sujet que j'avais perdu !! c'est un sujet de "Boomslang" sauf erreur ! Si tu passe par là Boomslang, je suis preneur de tes lumières pour cette histoire d'hélice. Il fraudai aussi que je trouve un bon site avec plusieurs moteurs pour comprendre un peut mieux !

Enfin, comme je le pensais, la programmation est en C se qui me motive d'autant plus :P !

Micaël.

Posté : 16 sept. 2010, 23:09
par Boomslang
Oui on parle de moi !! Qu'est ce qu'il se passe ?! :o ^_^

Qu'est ce qu'elles ont mes hélices ?

Posté : 16 sept. 2010, 23:56
par catlord
Slamy @ 16 Sep 2010, à 21:44 a écrit : Encore Merci pour ces nouvelles réponses.

Oui l'idée d'un appareil du type "blade MSX" me semble le plus adapté.

j'ai survolé le poste "[Commande groupée châssis SLE X9.01]". Avec le nombre de page, dure de tout lire :huh: ! Mais par contre ce châssis là, il n'est pas repliable; si? Si oui en version plié qu'est-ce que cela donne ? En tout cas, si tu fais un châssis repliable pour Octo, je serais surement preneur.

Je viens de retrouver le sujet que j'avais perdu !! c'est un sujet de "Boomslang" sauf erreur ! Si tu passe par là Boomslang, je suis preneur de tes lumières pour cette histoire d'hélice. Il fraudai aussi que je trouve un bon site avec plusieurs moteurs pour comprendre un peut mieux !

Enfin, comme je le pensais, la programmation est en C se qui me motive d'autant plus :P !

Micaël.
Le SLE-X9.01 n'est pas repliable mais les prochains le seront :)

j'envisage un chassis hexa de cette forme, octo je ne sais pas ça va devenir une usine à gaz ....

Posté : 17 sept. 2010, 08:59
par Slamy
Boomslang @ 16 Sep 2010, à 22:09 a écrit : Oui on parle de moi !! Qu'est ce qu'il se passe ?! :o  ^_^

Qu'est ce qu'elles ont mes hélices ?
Oui elles m'intriguent tes hélices ! pourquoi des 12 ... comme dirai l'autre "pouuuuurrrquoiii" :blink:

Posté : 17 sept. 2010, 11:59
par khead19
moi ausi j'ai mis des 1245 au lieu des 1045, parce que j'avais fait une structure plus grande améliorant ainsi, un peu, la portance. ;)

Posté : 17 sept. 2010, 13:07
par Boomslang
Slamy @ 17 Sep 2010, à 08:59 a écrit : Oui elles m'intriguent tes hélices ! pourquoi des 12 ... comme dirai l'autre "pouuuuurrrquoiii" :blink:
Je n'ai pas des 12" mais des 10" !

D'ailleurs ça m'étonnerai qu'avec la structure d'origine de l'Hexa les 12" passent sans se toucher...

Posté : 17 sept. 2010, 14:06
par Slamy
Ha j'ai donc peut être inversé avec "khead19" ! trop de lecture tue la lecture :wacko:

je viens de faire des recherches sur google, et de se que j'ai pu comprendre, la taille des hélices augmente la portance en effet

Cela voudrait dire que si sur un même moteur je let une hélice 12 puis une 10 le moteur pourra soulever plus avec la 12 :blink: ... hum il faudrait que je regarde cela d'un peut plus prés ! Je connais le principe de portance, trainés ... sur les ailes d'avions mais pas sur les hélices.

Posté : 17 sept. 2010, 14:38
par madmax52
en gros plus ton hélice est grande plus le brassage d'air est importante plus y à de portance. Toute fois il faut faire attention que le moteur supporte ce changement car pour lui y à plus de contrainte.

Je me demandais si des tri pales augmentait elle aussi la portance. Et comment savoir si le moteur supporterait des tri-pales ? Y à t'il pas une usure plus importante du moteur ?

Posté : 17 sept. 2010, 15:37
par khead19
Slamy @ 17 Sep 2010, à 13:06 a écrit : Ha j'ai donc peut être inversé avec "khead19" ! trop de lecture tue la lecture  :wacko:

je viens de faire des recherches sur google, et de se que j'ai pu comprendre, la taille des hélices augmente la portance en effet

Cela voudrait dire que si sur un même moteur je let une hélice 12 puis une 10 le moteur pourra soulever plus avec la 12  :blink:  ... hum il faudrait que je regarde cela d'un peut plus prés ! Je connais le principe de portance, trainés ... sur les ailes d'avions mais pas sur les hélices.
Attention tu auras une meilleure portance mais tu n'augmenteras pas ta charge utile, plus l'hélice est grosse plus le moteur doit fournir d'effort pour la mouvoir(logique) puisqu'il brasse une plus grosse quantité d'air! ;) CQFD.

Donc j'ai améliorer une peu ma portance et ma stabilité grace à un appareil plus grand et des hélices elles aussi plus grandes mais ma charge utile est bien la même ! ;)

Posté : 17 sept. 2010, 18:47
par Slamy
Merci pour cette info khead19, en effet, j'ai lu le wiki et d'autre PDF sur les hélices cet après-midi est c'est se que j'ai pu lire !

Après la question sera de savoir si la différence de stabilité est intéressante pour mon but final: la vidéo !

Posté : 17 sept. 2010, 19:13
par Coptaire
un simple quadri avec une motorisation/hélices adaptée, permet d'obtenir la stabilité nécessaire pour la vidéo/photo.
Je penses au quadri custom de "NYCMoreno", (utilisateur de forum mk.de) qui embarque un DSLR sans problème.
Il a pris des AXXI et un BLC 1hoch4 et des hélices en 1é ou 14 de chez APC.

Un coax mal conçu (aérodynamiquement) est, et sera instable. C'est à déconseiller pour l'appli photo/vidéo.

L'oktokopter 8 à plat avec un très bonne tête roll/pitch est une très bonne plateforme, bien configurée, bien maniée aussi.
Ce que je n'aime pas chez MK, c'est le risque de panne bus I2C: Si un BLC tombe en panne, tout le bus I2C est perturbé. risque important pour le matériel.

Posté : 17 sept. 2010, 19:33
par khead19
Coptaire @ 17 Sep 2010, à 18:13 a écrit :
Ce que je n'aime pas chez MK, c'est le risque de panne bus I2C: Si un BLC tombe en panne, tout le bus I2C est perturbé. risque important pour le matériel.
Chez MK dans un hexa ou un okto, sur un cas pareil la carte mère compense avec les autres moteurs, tu n'as pas du bien lire les docs de chez MK... ;)

Posté : 17 sept. 2010, 19:38
par Slamy
j'ai lu en effet que les moteurs et les hélices doivent être "de pair" pour avoir une performance et une stabilité optimale. Je suppose donc que les solutions proposés par défault sur les Kit (comme les kits MK) sont adaptés !

j'entends beaucoup parler des MK dans mes recherches sur les octo. Quels sont les autres alternatives existantes?

Posté : 17 sept. 2010, 20:10
par Coptaire
khead19 @ 17 Sep 2010, à 18:33 a écrit :
Coptaire @ 17 Sep 2010, à 18:13 a écrit :
Ce que je n'aime pas chez MK, c'est le risque de panne bus I2C: Si un BLC tombe en panne, tout le bus I2C est perturbé. risque important pour le matériel.
Chez MK dans un hexa ou un okto, sur un cas pareil la carte mère compense avec les autres moteurs, tu n'as pas du bien lire les docs de chez MK... ;)
Ben non.
Je ne parle pas de ce qui se passe lorsqu'un moteur ou BLC est en panne, et que le bus I2C n'est pas atteint. Bien évidemment.
J'ai eu un problème en vol sur un moteur/BLC (détachement en vol), et j'ai vécu la réaction, et l'ai posé sans casse.

TOUT BUS est susceptible d'une panne, c'est comme ça.
La partie I2C de tous les composants attachés au bus peuvent tomber un panne.
Un BLC en panne est susceptible de gêner le bus I2C.

C'est le problème d'une config BUS par rapport à une config ETOILE.
Les premiers hub ethernet réagissaient en BUs et un controlleur ethernet pouvait gêner un bus entier (collision paquets).
Les hub "switch" ethernet vinrent isoler chaque controlleur, en adoptant une topologie ETOILE.

Tu parles d'une compensation LOGICIELLE;
Je parle d'une panne HARDWARE.

Je viens d'avoir un gyro en panne HW (qui génère n'importe quoi au niveau ROLL), et le SOFT n'y peut rien du tout.
J'ai du poser un balancier en plein vent!

Posté : 17 sept. 2010, 20:33
par khead19
Coptaire @ 17 Sep 2010, à 19:10 a écrit :
khead19 @ 17 Sep 2010, à 18:33 a écrit :
Coptaire @ 17 Sep 2010, à 18:13 a écrit :
Ce que je n'aime pas chez MK, c'est le risque de panne bus I2C: Si un BLC tombe en panne, tout le bus I2C est perturbé. risque important pour le matériel.
Chez MK dans un hexa ou un okto, sur un cas pareil la carte mère compense avec les autres moteurs, tu n'as pas du bien lire les docs de chez MK... ;)
Ben non.
Je ne parle pas de ce qui se passe lorsqu'un moteur ou BLC est en panne, et que le bus I2C n'est pas atteint. Bien évidemment.
J'ai eu un problème en vol sur un moteur/BLC (détachement en vol), et j'ai vécu la réaction, et l'ai posé sans casse.

TOUT BUS est susceptible d'une panne, c'est comme ça.
La partie I2C de tous les composants attachés au bus peuvent tomber un panne.
Un BLC en panne est susceptible de gêner le bus I2C.

C'est le problème d'une config BUS par rapport à une config ETOILE.
Les premiers hub ethernet réagissaient en BUs et un controlleur ethernet pouvait gêner un bus entier (collision paquets).
Les hub "switch" ethernet vinrent isoler chaque controlleur, en adoptant une topologie ETOILE.

Tu parles d'une compensation LOGICIELLE;
Je parle d'une panne HARDWARE.

Je viens d'avoir un gyro en panne HW (qui génère n'importe quoi au niveau ROLL), et le SOFT n'y peut rien du tout.
J'ai du poser un balancier en plein vent!
Ok je réalise mieux ce que tu voulais dire , par contre ce qui tout changé en ethernet c'est surtout qu'un switch calcule l'adresse du PC concerné par le packet et ne le distribue qu'au PC concerné alors qu'un HUB le diffuse à tous les PC et c'est seulement ensuite que le PC concerné peut valider le packet.
Ou pour etre plus clair pour les néophites: le hub divise la bande passante alors que le switch la conserve . CQFD

;) B)

Posté : 17 sept. 2010, 20:42
par Coptaire
khead19 @ 17 Sep 2010, à 19:33 a écrit :
Coptaire @ 17 Sep 2010, à 19:10 a écrit :
khead19 @ 17 Sep 2010, à 18:33 a écrit :
Coptaire @ 17 Sep 2010, à 18:13 a écrit :
Ce que je n'aime pas chez MK, c'est le risque de panne bus I2C: Si un BLC tombe en panne, tout le bus I2C est perturbé. risque important pour le matériel.
Chez MK dans un hexa ou un okto, sur un cas pareil la carte mère compense avec les autres moteurs, tu n'as pas du bien lire les docs de chez MK... ;)
Ben non.
Je ne parle pas de ce qui se passe lorsqu'un moteur ou BLC est en panne, et que le bus I2C n'est pas atteint. Bien évidemment.
J'ai eu un problème en vol sur un moteur/BLC (détachement en vol), et j'ai vécu la réaction, et l'ai posé sans casse.

TOUT BUS est susceptible d'une panne, c'est comme ça.
La partie I2C de tous les composants attachés au bus peuvent tomber un panne.
Un BLC en panne est susceptible de gêner le bus I2C.

C'est le problème d'une config BUS par rapport à une config ETOILE.
Les premiers hub ethernet réagissaient en BUs et un controlleur ethernet pouvait gêner un bus entier (collision paquets).
Les hub "switch" ethernet vinrent isoler chaque controlleur, en adoptant une topologie ETOILE.

Tu parles d'une compensation LOGICIELLE;
Je parle d'une panne HARDWARE.

Je viens d'avoir un gyro en panne HW (qui génère n'importe quoi au niveau ROLL), et le SOFT n'y peut rien du tout.
J'ai du poser un balancier en plein vent!
Ok je réalise mieux ce que tu voulais dire , par contre ce qui tout changé en ethernet c'est surtout qu'un switch calcule l'adresse du PC concerné par le packet et ne le distribue qu'au PC concerné alors qu'un HUB le diffuse à tous les PC et c'est seulement ensuite que le PC concerné peut valider le packet.
Ou pour etre plus clair pour les néophites: le hub divise la bande passante alors que le switch la conserve . CQFD

;) B)
Y'a beaucoup plus simple.

Fil partagé et fil pas partagé:
Comparons la guirlande de noël et la multiprise! :)

D'ailleurs mon okto ressemble à une guirlande la nuit!! :D

PS: Tu ne crois pas si bien dire: Il existe un concept "TurboPWM" où 8 fois la bande passante (ETOILE de 8 ESC indépendants) est supérieur à la bande passante I2C partagée (BUS répartissant bande passante sur 8 I2C BLC).

Posté : 17 sept. 2010, 20:44
par khead19
Moi c'est le quadri: une vrai boite de nuit, j'ai utilisé a donf le sytème de masque de la flight ctrl. :P

Posté : 17 sept. 2010, 20:50
par Coptaire
khead19 @ 17 Sep 2010, à 19:44 a écrit : Moi c'est le quadri: une vrai boite de nuit, j'ai utilisé a donf le sytème de masque de la flight ctrl. :P
Rires!

Je te montrerai le light-show pris la nuit.

Mais ton chenillard volant, chuis battu à plate couture!

Posté : 17 sept. 2010, 20:57
par khead19
A l'occas je ferais une petite vidéo pour montrer "la bête" en plein boulot . ;)

Posté : 18 sept. 2010, 09:01
par Slamy
khead19 @ 17 Sep 2010, à 19:57 a écrit : A l'occas je ferais une petite vidéo pour montrer "la bête" en plein boulot . ;)
Ce serai sympa en effet ^_^

Par contre, je suis toujours prenneur pour savoir si il existe des alternatives aux MK pour faire un Octo !

Ou, si ma question ci-dessus est un sacrilège :ph34r: !

Posté : 18 sept. 2010, 09:18
par Coptaire
Slamy @ 18 Sep 2010, à 08:01 a écrit :
khead19 @ 17 Sep 2010, à 19:57 a écrit : A l'occas je ferais une petite vidéo pour montrer  "la bête" en plein boulot .  ;)
Ce serai sympa en effet ^_^

Par contre, je suis toujours prenneur pour savoir si il existe des alternatives aux MK pour faire un Octo !

Ou, si ma question ci-dessus est un sacrilège :ph34r: !
Pas de tabou!

"Selon plusieurs incarnations tu kopteriseras." Shiva planait déjà, nous on vole!

Kopter & Kopter - Tableau comparatif

Crois(x), et décollage viendra.

Posté : 18 sept. 2010, 09:21
par Coptaire
Coptaire @ 17 Sep 2010, à 19:42 a écrit :
khead19 @ 17 Sep 2010, à 19:33 a écrit :
Coptaire @ 17 Sep 2010, à 19:10 a écrit :
khead19 @ 17 Sep 2010, à 18:33 a écrit : Chez MK dans un hexa ou un okto, sur un cas pareil la carte mère compense avec les autres moteurs, tu n'as pas du bien lire les docs de chez MK... ;)
Ben non.
Je ne parle pas de ce qui se passe lorsqu'un moteur ou BLC est en panne, et que le bus I2C n'est pas atteint. Bien évidemment.
J'ai eu un problème en vol sur un moteur/BLC (détachement en vol), et j'ai vécu la réaction, et l'ai posé sans casse.

TOUT BUS est susceptible d'une panne, c'est comme ça.
La partie I2C de tous les composants attachés au bus peuvent tomber un panne.
Un BLC en panne est susceptible de gêner le bus I2C.

C'est le problème d'une config BUS par rapport à une config ETOILE.
Les premiers hub ethernet réagissaient en BUs et un controlleur ethernet pouvait gêner un bus entier (collision paquets).
Les hub "switch" ethernet vinrent isoler chaque controlleur, en adoptant une topologie ETOILE.

Tu parles d'une compensation LOGICIELLE;
Je parle d'une panne HARDWARE.

Je viens d'avoir un gyro en panne HW (qui génère n'importe quoi au niveau ROLL), et le SOFT n'y peut rien du tout.
J'ai du poser un balancier en plein vent!
Ok je réalise mieux ce que tu voulais dire , par contre ce qui tout changé en ethernet c'est surtout qu'un switch calcule l'adresse du PC concerné par le packet et ne le distribue qu'au PC concerné alors qu'un HUB le diffuse à tous les PC et c'est seulement ensuite que le PC concerné peut valider le packet.
Ou pour etre plus clair pour les néophites: le hub divise la bande passante alors que le switch la conserve . CQFD

;) B)
Y'a beaucoup plus simple.

Fil partagé et fil pas partagé:
Comparons la guirlande de noël et la multiprise! :)

D'ailleurs mon okto ressemble à une guirlande la nuit!! :D

PS: Tu ne crois pas si bien dire: Il existe un concept "TurboPWM" où 8 fois la bande passante (ETOILE de 8 ESC indépendants) est supérieur à la bande passante I2C partagée (BUS répartissant bande passante sur 8 I2C BLC).
NEWS: Un oktokopteriste a mis au point une platine de distribution I2C octuple.
(khead19 > idem switch).

Il lit l'I2C de la FC, et crée 8 fils I2C afin qu'une panne BLC I2C ne compromette pas les 7 autres BLCs.
Il doit faire une démo où il court circuite un BLC, et constate que les 7 autres BLC/Prop continuent leurs bons offices.

Un sacré sacristain!

Posté : 18 sept. 2010, 12:57
par khead19
voila une bonne avancée ! ;)

Posté : 18 sept. 2010, 13:52
par Slamy
Je préfére voir un test où il force une carte à flooder se serai plus logique il me semble.

Si une carte se coupe elle ne va pas être trop bloquante, si elle n'arrête pas de parler comme ma femme ( :wub: ) ... c'est une autre histoire :P

Posté : 18 sept. 2010, 14:15
par Coptaire
Slamy @ 18 Sep 2010, à 12:52 a écrit : Je préfére voir un test où il force une carte à flooder se serai plus logique il me semble.

Si une carte se coupe elle ne va pas être trop bloquante, si elle n'arrête pas de parler comme ma femme ( :wub: ) ... c'est une autre histoire  :P
T'en fait pas, j'ai peut-être mal formulé, on se comprend, il simulera un bus I2C (donc local) HS, qui ne se propage pas au reste.

Voici l'isolateur de bus I2C, signal I2C vers 8 I2C alimentant chaque BLC indépendamment.
Lorsque l'isolateur détecte une anomalie I2C (d'un des 8 côtés BLC) il se déconnecte du bus automatiquement.

La carte est au format MK, donc s'intègre parfaitement.

Okto I2C isolator

J'en ai commandé un. Mon okto va pouvoir s'alourdir avec ce "poids" de la panne I2C en moins. :D