Démontage d'un drone, Épisode 3 : La revanche de la télécommande.

Rédigé par Salamandar - - 5 commentaires

Le protocole de communication

Comme je l'avais dit au second épisode, j'ai besoin de comprendre le protocole de communication entre la télécommande et le drone. Comme c'est quasi impossible de souder des fils directement sur le drone, je vais écouter ce qu'il se passe sur la télécommande.

Sur la télécommande, un bus SPI communique entre la puce principale (un PIC ?) et le composant radio (probablement un XN297). J'ai utilisé un Arduino Nano pour écouter sur le bus et afficher en temps réel sur mon PC les trames SPI.

Plusieurs frames se répètent : les 4 premières correspondent à la configuration du XN297. Il m'a suffit de lire la datasheet du nRF24L01 pour connaître quelle configuration est envoyée.
La dernière frame contient les données à envoyer au drone. J'ai décortiqué cette dernière frame et j'ai indiqué quel octet correspond à quelle commande.

0x20 0x0e // Write byte config (Power up, CRC 1 byte enabled)
0x25 0x48 // Write byte RF_channel (freq channel : 100 1000 = chann 72)
0x27 0x70 // Write byte status (clear TX_status/RX_status/MAX_RT status bits)
0xe1 0x00 // Flush TX (clean and new TX buffer)
0xa0 0x55 0x3a 0x88 0x89 0x8a 0xdc 0x05 0xdc 0x05 0xe8 0x03 0xdc 0x05 0x00 0x00
// Write TX buffer data

// Data frame :
//                   Côté  av/ar Gaz   Rotat
// A0 55 3A 88 89 8A cc cc aa 0a gg 0g rr Xr XX X0
// 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
// byte 14 : 1000 .... Looping
// byte 15 : .1.. .... (press repeat) calibration B (btn2)
// byte 15 : ..1. .... (press repeat) calibration F (btn1)
// byte 15 : ...1 .... (press repeat) calibration L (btn3)
// byte 15 : .... 1... (press repeat) calibration R (btn4)
// byte 15 : .... ..xx Difficulté (0, 1, 2)
// byte 16 : .100 0000 (toggle button) photo
// byte 16 : 1.00 0000 (toggle button) video

J'ai donc ici l'intégralité du protocole de communication. Le drone ne répond jamais, c'est plus simple comme ça.

Prochaine étape : programmer le drone !

Démontage d'un drone, Épisode 2 : Un peu d'électronique

Rédigé par Salamandar - - Aucun commentaire

La prise de vidéo

Dans notre premier épisode, on a vu l'existence d'un fil de signal pour la prise de photos. Ce signal est maintenu par le STm32 en permanence à ~3V (1 logique, donc), et une photo est demandée par une courte mise à zéro (entre 230 et 320ms), et la vidéo par une plus longue (610~710ms).
Eh oui, j'ai accès à un simple oscilloscope analogique, alors si vous voulez des mesures plus précises, offrez-moi un oscilloscope numérique ;)
N'ayant aucune information sur le SoC vidéo, c'est la seule information que je peux avoir.

L'électronique

Toute première étape, établir un schéma de fonctionnement du drone. Autrement dit, comprendre comment les différents composants sont connectés entre eux pour savoir, ensuite, quel code écrire.

On m'a donné la bonne idée d'utiliser Gimp pour superposer des photos des deux couches du PCB, et dessiner les vias et les pistes, histoire de s'y retrouver facilement. À côté, j'utilise Kicad pour représenter le PCB.

J'ai uniquement représenté les trois composants principaux : le STm32, le contrôleur radio, et la centrale inertielle. On arrive donc à un schéma assez simple.
La centrale inertielle Invensense comunique vraisemblablement en I2C avec le STM32. Pour le contrôleur radio, ça sera du SPI.
Vous pouvez tout trouver sur mon dépôt Github.

Les 3 "pads" que j'ai notés A,B,C sur la photo ci-dessus sont directement connectés au STm32, sur les pins permettant de le reprogrammer, en passant par le Serial Wire du JTAG :

  • PA13 = SWDIO (Serial Wire Debug I/O)
  • PA14 = SWDCLK (Serial Wire Debug Clock)
  • VDD : L'alimentation, simplement 

J'ai donc soudé un header de 4 pins sur ces pads, de façon plus ou moins crade, en le collant à l'époxy pour ne pas risquer d'arracher les pistes dessus en le (dé)branchant (ce qui a déjà commencé à arriver…).

Un peu de logiciel

Pour accéder au Serial Wire du STm32 depuis mon PC en USB, j'ai besoin d'un ST-Link. Et justement, les Nucleo de STMicroelectronics en embarquent un pour programmer leur STm32, et la possibilité a été laissée d'utiliser le ST-Link pour programmer d'autres STm32.
Parfait donc ! J'utilise aussi l'alimentation de la Nucleo pour ne pas tirer inutilement sur la batterie.

J'utilise OpenOCD pour communiquer avec le ST-Link.

$ sudo openocd -f /usr/share/openocd/scripts/board/st_nucleo_f0.cfg &
Open On-Chip Debugger 0.10.0-dev-00419-gbcaf775 (2016-11-07-18:43)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control.
       The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v14 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.250952

$ telnet localhost 4444
Trying ::1...
Connection failed: Connexion refusée
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Info : accepting 'telnet' connection on tcp/4444
Open On-Chip Debugger
> init
> flash probe 0
# Pour avoir quelques infos sur le microcontrôleur
Info : device id = 0x10006444
device id = 0x10006444
Info : flash size = 16kbytes
flash size = 16kbytesflash 'stm32f1x' found at 0x08000000
flash 'stm32f1x' found at 0x08000000
> dump_image drone.bin 0x08000000 0x20000
# Pour tenter de récupérer le firmware actuel.
# Résultat : drone.bin est vide !
>

Je détecte bien le STm32F0 ! Bon, c'est plutôt un stm32f1 qui est détecté, mais on s'en suffira. Par contre, aucun moyen de sauvegarder le firmware actuel : ils ont activé les protections du Stm32.

Dommage, ça veut dire qu'une fois le drone bidouillé, je ne pourrai pas revenir en arrière !

Les étapes suivantes ?

  • Lire la datasheet du transceiver radio XN279, ou plutôt, vu que celle-là est en chinois, celle du nRF24L01+.
  • Tenter de "lire" les paramètres radio envoyés par le STM32 au transceiver, si je n'ai pas réussi à les deviner (ce qui est probable), ainsi que le "protocole" utilisé entre la télécommande et le drone. Pour ça, il va falloir utiliser utiliser un analyseur logique.
  • Pour l'accéléromètre ça sera plus simple, il suffira de lire la doc', je verrai donc une fois que la radio fonctionne.

Démontage d'un drone, Épisode 1 : Le contenu.

Rédigé par Salamandar - - Aucun commentaire

J'ai récemment fait l'heureuse acquisition d'un nano-drone (35mm d'axe à axe !) avec caméra intégrée. Le genre chinois sans marque, et ça se voit jusqu'aux composants. Du coup, je me suis lancé le défi de le démonter, le comprendre et le reprogrammer. Un vrai boulot de hacker :)

L'intérieur est composé de deux PCBs :

  • Une première carte, qui fait aussi office de squelette physique du drone.
    • Un STm32f031K4, basé sur un petit core ARM-M0 cadencé à 48MHz. Un tout petit cerveau mais largement suffisant, quoi.
    • Un Invensense MPU-6052C, qui contient un gyroscope et un accéléromètre. Je trouvais le drone assez mal stabilisé, on va changer ça !
      D'ailleurs, les seules infos que j'ai trouvées sur le net sur ce composant sont dans une datasheet "préliminaire et confidentielle"… À part ça, il n'est commercialisé nulle part et aucune datasheet "publique" n'est trouvable. Ça commence bien… !
    • Un Panchip XN297, qui gère la communication sans fil. Il a l'air assez commun, et même un clone des Beken BK2425 et nRF24L01+. Même si la seule datasheet que j'ai trouvée est en… Chinois :)
  • Une seconde carte, plus petite, gère la partie vidéo.
    • Un BoyaMic 25Q40A gère vraisemblablement la partie enregistrement sur la carte microSD. Funny fact, d'autres drones sont équipés d'une puce semblable "BergMic 25Q40A". Sérieux, les gars ? Vous avez monté une boîte avec un nom ressemblant à celui d'origine ?
    • Un SoC, assez épais, avec un très joli logo, mais totalement inconnu par moi et par Internet. Et le "BD8A534" est tout simplement inexistant. Bon, c'est clair, il gère la compression vidéo depuis la caméra.

    En fait, je me fous assez de la deuxième carte : les deux cartes ne sont reliées que par trois fils (W/R/B donc Masse/Puissance/Signal), le fil de signal doit simplement déclencher la prise de photo/vidéo. Il suffira de comprendre ce signal.

C'est tout pour cette fois, la suite au prochain épisode !

Imprimante Delta Part 1 : L'électronique

Rédigé par Salamandar - - Aucun commentaire
Bon, il faut savoir que c'est la première imprimante 3D que je monte, donc je n'irai pas dans l'innovation pour le moment. L'imprimante sera donc assez proche de la Kossel d'origine.

Le cerveau de l'imprimante 3D est constitué d'une carte électronique, qui fonctionnera soit en exécutant les instructions qu'un ordinateur connecté lui enverra, soit de manière autonome, lorsque la présence d'une carte mémoire le permet.
Il existe différents "niveaux" de cartes électroniques de contrôle :
  • Les cartes RAMPS et apparentées : peu chères (~30€), elles sont basées sur l'Arduino Mega, un contrôleur 8bits : elles permettent le strict minimum, qui est pour la plupart largement suffisant.
  • Des cartes, elles aussi basées sur Mega, avec quelques fonctionnalités supplémentaires : bus de communication annexes, plus de moteurs gérables, lecteur de carte SD intégré,… Leur prix peut aller jusqu'à 100€ comme pour l'Azteeg X3.
  • La "nouvelle génération" d'électronique est beaucoup plus ambitieuse : gestion du réseau pour un contrôle à distance, voire même véritable petit serveur avec un Linux embarqué ! Même STMicroelectronics y est allé de sa contribution tout récemment. Forcément, les prix sur cette gamme décollent au-delà de la centaine d'euros. Mention spéciale à la SmoothieBoard qui justifie assez bien ses 185€.
Pour le moment, on va partir sur le plus simple et le moins cher : une carte Arduino Mega avec un shield RAMPS1.4. Ce shield permet notamment de gérer jusqu'à 5 moteurs pas-à-pas, un écran et une carte mémoire. J'utiliserai ma vieille Raspberry Pi 1 quand je voudrai la contrôler à distance.
J'ai eu la chance de tomber sur ce kit complet sur Banggood, en réduction à 30€. Ça, c'est fait. Après, on verra ce que la future génération de cartes nous réserve comme surprises.

Imprimante 3D Delta : Ça commence !

Rédigé par Salamandar - - 1 commentaire
Bon, ça fait un bout de temps que je voulais me monter une imprimante 3d, ce mois-ci, je me lance.
Un certain Linconnu m'a convaincu que les imprimantes Delta sont cool, et effectivement elles ont tout pour plaire :
  • Un design quand même intéressant (et vraisemblablement plus simple à construire) et une mécanique particulièrement classe
  • Une vitesse et une précision d'impression meilleures que les imprimantes classiques Prusa, et avec un déplacement plus "lisse"
  • Un volume d'impression assez flexible et en général plus grand que les Prusa

Imprimantes Kossel delta

Voilà un exemple d'imprimante Delta absolument hallucinante (et non, la vidéo n'est pas accélérée…) :

Je vais me baser sur le design de la Kossel, qui fait partie du projet RepRap, bien connu pour avoir permis le développement d'imprimantes 3D open-source et auto-réplicatrices telles que la Prusa Mendel.
Je ne suis pas encore fixé sur les dimensions, mais comme je l'ai dit les imprimantes Delta sont très flexibles donc je n'aurai aucun mal à me décider au dernier moment sur ce point.
Première étape, se décider sur la mécanique de déplacement, qu'on verra dans un prochain billet.
Fil RSS des articles