Cette page contient les informations nécessaires pour utiliser le drone parrot bebop2 sous linux avec des programmes "maison". Tous les capteurs et actionneurs sont utilisables. N'hésitez pas à contribuer en envoyant un mail à drones(at)hds.utc.fr

Le drone bebop2 fonctionne avec une distribution linux Parrot. Certains logiciels spécifiques ajoutés par Parrot ont leurs sources sur ​https://github.com/Parrot-Developers On y trouve notamment les sources du noyau utilisé.

Une doc sur le "hack" du drone ​ici.

Connexion

Pendant son boot le drone crée un point d'accès wifi Bebop2-xxxxxx. Il faut s'y connecter depuis son PC. Ensuite il faut appuyer 4 fois rapidement sur le gros bouton rouge à l'arrière sous la batterie et un serveur telnet est lançé. Il suffit alors de taper telnet 192.168.42.1

Si après les 4 appuis un câble USB est branché, alors le drone crée une connexion ethernet over USB. On peut donc aussi accéder au drone par cette interface avec telnet 192.168.43.1 , ce qui est pratique en cas de problème avec une configuration wifi custom.

Procédure de démarrage standard

Au démarrage le premier processus exécuté ("init") correspond au binaire /sbin/boxinit (programme maison Parrot, fork d'android init. Non publié sur Parrot-devs).

Celui-ci exécute les instructions présentent dans /etc/boxinit.rc. Les instructions sont organisées par "classes" qui contiennent des "services". La classe "core" est lancée au boot. Apparemment la classe "core-main" est lancée ensuite. Le service rcs-init, membre de la classe core, correspond au principal script de démarrage, /etc/init.d/rcS. Ce script effectue les actions "one shot" qui doivent être faites au démarrage: configurer le réseau et les IOs notamment.

A la toute fin du processus de démarrage, le programme "dragon-prog" se lance. Il s'agit du programme qui gère le vol du drone (lois de commande).

Logs

Toutes les opérations sont loguées par le démon ulogger. Il s'agit d'un binaire Parrot (sources fournis sur Parrot-devs, projet "ulog"). ulogger -h pour les options. Les logs peuvent être consultés avec le binaire ulogcat. Très intéressant pour suivre toutes les étapes du démarrage.

Réseau

mac address

The mac address is defined in /data/mac_address.txt. It can be easily overwritten.

Démarrage

Lors du démarrage le script /etc/init.d/rcS démarre udev (/usr/bin/udevd_init). La configuration d'udev se trouve dans /lib/udev (histoire qu'on galère un peu pour la trouver...). le fichier rules.d/50-network.rules rassemble les règles associées à la gestion du réseau principal (wifi). Au démarrage le bsp créé un périphérique usb broadcom. Udev le détecte, ce qui active une règle qui exécute /sbin/broadcom_setup.sh insmod. En conséquence les modules wl (driver broadcom propriétaire) et bcm_dbus sont chargés. Le chargement du driver wl entraîne la déclaration de l'interface eth0 dans le noyau. Udev le détecte, ce qui active une règle qui exécute /sbin/broadcom_setup.sh create_net_interface. En conséquence l'interface eth0 est configurée en mode wifi access point.

Watchdog

Au démarrage un démon de surveillance est démarré /usr/bin/bcm-watchdog. bcm-watchdog -h pour les options. Appelle broadcom_setup.sh reboot en cas de perte de connexion. Ce script appelle broadcom_reset.sh. Ce script désactive l'interface réseau, attend 3s et la réactive (ça doit faire bizarre en vol!)

Gros bouton

Pendant le démarrage un démon est lancé pour surveiller les appuis sur le gros bouton rouge à l'arrière sous la batterie. Les différents comportements sont décrits dans le répertoire /bin/onoffbutton. Les comportement sont

• 1 appui court: shutdown
• 4 appuis courts: mode debug. Démarrage du démon telnet, du démon adb (android debug) et configuration d'une liaison "ethernet over usb" sur l'interface réseau rndis0.
• 1 appui long: changement de bande wifi
• 1 appui trèèèès long: DANGER! factory reset: toute la partie /data est écrasée, on perd tout ce qu'on a installé

rootfs

A la fin de la procédure parrot le drone est prêt à voler avec les lois de commande de parrot. Pour remplacer ces lois de commande et utiliser les nôtres, nous pourrions installer notre programme dans le système de fichier de parrot et le lancer à la place de celui de parrot ("dragon-prog"). Mais cela a 2 inconvénients

• le système de fichier original est modifié. Si on fait des erreurs, on risque de ne plus pouvoir démarrer!
• nous ne sommes pas certains que le programme original de parrot ne termine pas la configuration du drone. Si c'est le cas nous pourrions avoir des problèmes pour utiliser certains capteurs par exemple

En conséquence nous préférons démarrer nos programmes dans un "chroot", c'est à dire un système de fichier à part. L'idée est de lancer un serveur ssh (dropbear) dans un système de fichier créé avec robomap3. C'est dans ce système de fichier que nous trouverons nos programmes de vol.

Attention, il faut éviter que nos lois de commande et celles de parrot entrent en conflit (par exemple l'une veut accélérer un moteur alors que l'autre veut le ralentir). Pour cela il faut commencer par faire "kk" 💩. C'est un script fournit par parrot qui termine le processus dragon-prog. Notons que c'est un kk dur car le script utilise le signal SIGKILL...

chroot script

A titre d'exemple, voici le script script de chroot complet que nous utilisons (/data/ftp/internal_000/start.sh):

#!/bin/sh
#rerun ourself with redirections to log actions
ls -l /proc/$$/fd/1 | grep /dev/null
if [ $? -eq 0 ]; then
  exec $0 $* 2>&1 > /data/ftp/internal_000/start.log
fi
echo HDS script started at: $(date)

#kill parrot flight control program (dragon-prog)
kk

mount -o bind /dev /data/ftp/internal_000/rootfs/dev/
mount -o bind /sys /data/ftp/internal_000/rootfs/sys/
mount -o bind /proc /data/ftp/internal_000/rootfs/proc/

mount -t tmpfs -o mode=0755,nodev,nosuid tmpfs /data/ftp/internal_000/rootfs/run
mount -t devpts devpts /data/ftp/internal_000/rootfs/dev/pts

chroot  /data/ftp/internal_000/rootfs/ /etc/chroot_init

Our /etc/chroot_init (/data/ftp/internal_000/rootfs/etc/chroot_init from the original filesystem) contains

#! /bin/sh
/etc/init.d/networking start
/etc/init.d/dropbear start

it is already included in the robomap3 filesystem image.

The chroot.sh script is started automatically by adding the file /etc/boxinit.d/99-chroot.rc containings

on property:system.ready=1
        start chroot

service chroot /data/ftp/internal_000/chroot.sh
        disabled
        oneshot

notes:

• surprisingly enough, the events "post-fs" and "post-fs-data" occur in a row right at startup (I was hoping for using "on post-fs-data" to start the chroot after /data is available but it doesn't work). We could probably set a specific property with the "sprop" command after /data is mounted in /etc/boxinit.standalone.milosboard.rc and wait on that in 99-chroot.rc
• it's not possible to launch the standard "init system V" binary on the "chrooted" environment. Hence the init binary behaves differently whether it has pid 1 or not. If it has pid 1 it starts the system (and listen to the pipe /dev/initctl). If it doesn't have pid 1 it will send a command to its pid 1 coutnerpart by writing in /dev/initctl. Since there can be only one pid 1 and it's already running in the original parrot environment, all the "init system V" logic is useless on the chrooted filesystem (it's just bloat that could be removed). That's why we're using the chroot_init script.
• the currently set properties list can be obtained with the gprop command. In the above 99-chroot.rc file, you may choose a more convenient "on property:" condition depending on what you're waiting for. On some versions of the bebop2 I used a "state.wifi" property but it's not available on every versions