Shikijo

Bonjour à toutes et à tous. Après quelques mois sans publier ici mes derniers build, je partage mon expérience X8, qui peut, je pense, aider certains dans un futur proche. Voici donc la Turtle X8 en V1.2, développé par Frame Concept (BeeBumper). Après de nombreuses semaines d'essais, de développement, de test, j'arrive à un rendu exploitable pour ce (futur) concurrent du Shendrone Thicc, ce X8 développé pour porter des caméras de cinéma et DSLR en ayant une agilité proche du 5". Laurent (de Frame Concept) à présenté la première version de sa Turtle en Avril sur différents groupes. Cette machine m'a tout de suite intriguée et intéressée. Par manque de temps et d'expérience je ne me suis pas trop penché sur le sujet jusqu'en juillet. En effet, une demande croissante de prestation avec ce type de caméra et une envie de développer un drone m'ont fait me pencher sur les XClass et X8. J'ai d'abords fabriqué un 13" en lien avec KO, puis un 17" sur une base d'un vieux chassis mais le côtés 12S me dérangeait pour deux raisons : la fiabilité qui ne correspond pas aux attentes des réglementations européennes et le poids. Ces derniers m'ont donc poussé à monter un 6" pour essayer de porter un DSLR. Au même moment j'ai rencontrer une société grenobloise qui se nomme SteadXP et qui travaille sur de la stab vidéo avec un boitier contenant un Gyro. Ils travaillent déjà avec Gab707 et ont des résultats très encourageant avec le Thicc. Ne voulant pas partir sur un Thicc pour la même raison du 13" à savoir le poids je continue mes essais en 6". Le résultat est la, une machine exploitable, en dessous de 2kg, mais "volable" avec une charge max de 700gr mais en réalité un confort avec une charge de 500gr hors lipo. Très difficile de trouver un DSLR offrant les standard actuel avec une charge de moins de 500gr objectif compris. Je retourne donc sur une idée de montage d'un X8, mais je constate beaucoup trop de points faibles sur le Thicc, je ne souhaite pas trop partir au combat sur cette frame. De plus mon côtés chauvin me fait dire : pourquoi toujours acheter ricain alors qu'on a des ingénieurs de fou en France. Je regarde de plus près la Turtle de Laurent et je vois des idées de conception très intéressante (true X, bras liés, noeud centrale, fraisage intelligent etc...). Je commande donc la Turtle première du nom à Laurent et il me dit que le support caméra n'est pas exploitable et trop couteux à produire. Après réception de la frame je constate certains points faibles sur la Frame et à la suite de retour précis à Laurent, celui-ci repart sur le développement du Turtle. Après plusieurs mois, différents travaux d'amélioration, de gestion de poids, d'aérodynamique, de charge, de maintenance, d'essais de support caméra, etc... ont été effectués et on commence à voir un prémisse de cette future frame qui sortira je l'espère dans sa version 1.5. La Turtle V1.2 tourne sous Emuflight, elle fait exactement 1.98kg avec un Sony A6300 + objectif de 12mm et 2 batteries 1550mah lui offrant une autonomie de 6min en cruising cinématique et 3min en freestyle (oui). Une version avec parachute pour une charge de plus de 1kg hors batterie est en cours d'homologation. Si vous avez différentes questions ou autres n'hésitez pas. Je tiens à remercier Parkinson PID qui m'a aidé sur la conception de certaines pièces TPU et également Manu Bertholomet qui lui m'a aidé sur la partie légale et psychologique sur tout ça. La turtle en action : https://fb.watch/1I0hEVrq8k/

Désolé je réponds tard longtemps que je suis pas passé par ici. Quand j'ai monté ce quad le vista n'était pas encore dispo ah ah. Je sais même pas si il était déjà annoncé.

Bon confirmation par Holybro je suis tombé sur une mauvaise série, il me renvoie deux ESC neuf... J'ai remonté le bouzin avec une Tekko32 Metal que j'avais en spare, avec les fold le rendu est dingue. Un mot : compact J'en ai également profité pour monter le second avec du Ko en 1900KV et en version Light pour le TPU GoPro.

Je suis en R9mm et R9m lite pro sur tout mes quads @simdirt053. Il faut bien mettre le RX et le TX à jour sur la dernière version en Flex histoire d'être tranquille et hop ça roule 😉

L'idéal serait de pouvoir se passer de Smart Controller et de masque ;)...

Clairement une latence, de gros artefact et surtout, le freeze du masque au bout de X secondes.

Pour faire bref, avec la dernière Maj il y'a la possibilité d'envoyer le flux vidéo transmis en USB à un Smart Controller. Smart Controller étant une Radiocommande avec un affichage et des app le tout sur une vieille version d'Android. J'ai ouvert le FW des smartcontroller, récupérer et modifier l'app ainsi que certaine Lib et la j'attend un SC pour finir le portage clean. En gros.... Donc permettre d'avoir le retour sur USB pour n'importe quel android acceptant l'OTG.

Good choice 👍 Si jamais tu as envie de mettre Emuflight sur tout ça, j'ai un preset 6S qui fonctionne au poil sur cette frame 🙂

Bonjour tout le monde, je suis entrain de bosser sur un truc, si ça intéresse certain d'entre vous, que vous avez de bonne base en électronique, un fer à souder, une tablette/smartphone android avec un cable OTG ou USB C, je pense tenir un truc. Ce n'est pas stable pour le moment avec pas mal de bug (notamment crash du masque client) mais c'est un bon début.

Oula oui ah ah ! J'essaie de modifier ça au plus vite 🙂

Yes, j'ai mis réglages du GPS Rescue, de l'emuboost et des rates dynamics etc... histoire que ça soit pratique 🙂

Hello tout le monde, j'ai update le script lua pour qu'il fonctionne propre avec emu en donnant accès aux fonctions pratique de emu comme réglage emuboost etc... Compatible X7, X9, Horus et Tango II. J'ai pas toute les RC donc si certains veulent essayer et me faire un retour, you're welcome 🙂 Archive.zip

Alors pour infos, je commence à avancer sur la raison du crash. L'ESC dans la nouvelle série de Stack Kakute F7HDV est le nouveau Tekko32 45A - 55A durst, il se diffère par ses pad d'entrée lipo. Actuellement 4 personnes ont connu un problème de reboot/desync en vol identique à mon soucis. Par ailleurs, 3 ont vue leur ESC prendre feu. Donc je suspecte ce batch (Mai 2020) d'être limite... Le point commun également semblerai la mise en place du 48kHz sur le PWM au lieu du 96 d'origine, donc je continu à creuser, j'ai un autre stack je vais donc lancer un protocol de test pour vérifier si l'ESC est foireux de lui même ou si une configuration spécifique est nécessaire, mais ça sent pas bon du tout.

Non clairement pas ! Et la c'est vraiment pas tomber sur le bon angle. Par contre j'ai de sérieux doute sur les nouveau ESC Holybro du coup...

La dernière Tekko32 F3 45A 🙂 Kakute F7HDV en FC

Si vous avez un avis sur ça : Et ça du coup 🙂 :

On va dire que je fais partie des beta testeur ah ah

Yes, ils disent surtout c'est en cas de sur-tension non volontaire, type un beau pic de tension lipo a 30-40V, ils annoncent que ça fonctionne parfaitement sans condo. Bon le condo filtre également donc toujours préférable d'en mettre un.

Les velox pour le prix sont pas mal... Après, en vrai tout le monde adore les Tmotor mais bordel ce qu'il consomme des que tu ouvre c'est abusé. Je peux pas blairer iFlight mais leur Xing 1800kv ont vraiment Ue des bon retour aussi (dans cette gamme de prix).

Elle est très très bien abouti, je voulais dire : Fred c’est pas foutu de notre gueule sur ce coup. @Copykath attention j’ai mis des moteurs qui ont l’air de sucer un peu niveau ampère, qui donne une maxi poussée à mi niveau aussi. J’adore les 2208 et es xnova sont d’une fiabilité à toute épreuve. Mais comme beaucoup de moteurs, ils ont un défaut, quand t’ouvre ça tire fort... moins que les Tmotor mais quand même. J’ai un doute sur la tenu des ESC sur ce point, Holybro m’ont dit : t’inquiète ça passe ce nouvelle ESC c’est de la tuerie donc j’attend de voir... sinon j’ai encore des Tekko32 Metal en spare pour ça.

J'ai fini de monter mon premier Gravity. Une config que j'ai validé depuis plusieurs mois en MidRange/LongRange pour du ciné. Je suis monté d'un cran niveau KV par rapport à ma configuration FX HD en passant de 1700 à 1900kv toujours chez Xnova. J'ai reçu les nouvelles stack Kakute F7HDV, Elles contiennent le dernier ESC Tekko32 avec du 96k en PWM mais surtout qu'elles puissent encaisser 80V d'un coup et 200A en cas de pic d'intensité à haut voltage (d'après Holybro). En attendant de recevoir la lumener AXII 2 long range j’ai mis une Lollipop 3 en Stubby car ça fait le taff. Tous mes vista ont la Lollipop en UFL et y'a pas photo elle fonctionne vraiment bien, grosse différence par rapport au True RC ou les Candy d’origine. La finition de cette frame est vraiment un scandale, le montage est intelligent, pas à la portée de n’importe qui mais ont sent qu’une grosse réflexion à été faite sur ce point. Sans compter le côté compact de la frame qui lui donne un petit côté kart volant.

Même quad face à toi avec la batterie qui couvre ?

Ok je viens de voir, j'attend qu'un pote me donne mon token en claire pour peaufiner tout ça 🙂

Clairement @Jerome c'est le problème des techno fermé, j'ai analysé pas mal de trame fait pas mal de test pour affirmer ce que j'ai dit plus haut. Par contre t'as un lien vers le forum en question. Au début je suis parti sur cette théorie : le AU brodcast, le masque client transmet le token au second client les deux décrypte et décompresse le signal, un seul émet l'erreur et reçois la correction d'erreur, mais ça c'était avant de voir le retour sur le Smartcontroller qui est identique au second client, qui m'a fait orienter un scénario différent et donc des test d'analyse de trame. Sinon la remonté d'erreur en cas de grosse perte de paquet, ça prend un bout de BP quand même mais surtout, le masque doit envoyer la sauce en rapidité d'infos, donc dois y'avoir également un côté avant la transmission qui se doit d'être optimal et causerai la réduction d'émission du second flux.

Désolé de ma réponse si tardive @Jerome : Pour avoir piloter en mode audience, je ne trouve pas qu'il y ait plus de latence, le signal répété devrait en avoir davantage Il n'y a pas spécialement de latence mais clairement une compression supplémentaire + des saut de frame et perte de paquet dans la compression qui sont clairement visible. Quand le quad est derrière des obstacles ou que le signal a du mal à passer, le mode audience génère des artefacts ou freeze alors que les lunettes "pilote" demande au AU d'adapter sa compression grâce à sa connexion bidirectionnelle et/ou de renvoyer les paquets perdus, en tout cas il arrive à maintenir un flux non corrompu. Si c'était les lunettes pilotes qui répétaient le signal, on aurait pas ces artefacts liés à l'environnement du quad mais bien le retour des lunettes sans artefacts Alors il faut bien comprendre ça : quand ton quad est derrière un obstacle, le masque envoie au Air Unit qu'il commence à perdre énormément de paquet, plus il en perd, plus il envoi l'info sur les antennes qui émettent, plus le air unit renvoi, etc.. Durant ce moment, les antennes du haut donc, sont solicité à leur fonction première, l'envoi d'info d'erreur au Air Unit, elles libère donc également de la place sur les trame émise à cette fonction en limitant la transmission au second casque. C'est une histoire de bande passante je pense, sans compter la prise en compte du "diversity"/Mimo dans tout ça. Les artefact, qui sont présent également si tu te situ trop proche du casque principal, ou de dos, sont vraiment lié à la compression et la bande passante. C'est comme quand tu vas récuperer un flux udp en broadcast, si t'as des saut de frame ou une saturation de ta BP, t'as de la perte de paquet qui se résume de la même manière à l'affichage. Pourquoi s'embêter à répéter le signal alors qu'il existe déjà ? C'est une histoire de compression et de Token. Lors du bind Air Unit ou autre, un token est crée. Ce token le masque et le AU le partage, lors de l'allumage le masque va emettre son token, le AU le reçoit, le confirme, encrypte le signal et renvoi ce signal au masque. Le masque reçois le signal et le corrige, le recompose avec l'erreur, et le décrypte, puis l'affiche. Un token est unique, si le Air Unit doit compresser le flux 2 fois... laisse tomber la chauffe et le proc qu'il faut... déjà la c'est chaud ah ah. J'insiste sur ce côté de token unique, deux masque ne peux pas avoir le même token, au risque de, créer du conflit en cas de mauvaise re-génération de token. Un partage de token est possible, mais la liaison étant bi-directionnel entre 2 point, en rajouter un troisième demanderai trop de calcul au Air Unit. Le mode Audience se cale sur la même fréquence que le VTX, ce qui a du sens si c'est bien le VTX qui émet. Et le signal reçu par les lunettes spectateurs serait perturbé par le VTX. Et au contraire, quand le signal VTX faiblit, le lien avec les lunettes pilotes devait être meilleur (alors qu'au contraire, ça freeze) Alors.... déjà ce n'est pas un VTX, mais le mode audience, le masque client de l'audience, ne vas juste que ce brancher sur le canal de fréquence, du Air Unit oui, mais surtout du masque qui renvoi les messages d'erreur au AU et le signal vidéo en broadcast. Les techno dans le masque sont vraiment évolutive d'un point de vue software, donc ces propos émis peuvent changer dans l'avenir, notamment sur la gestion du token entre deux masque. Mais je doute vraiment que le Air Unit, Vista, ce que vous voulez soit assez performant pour drop 2 signal, corrigé et émis à deux clients différents.