This page contains all the required information to use the Parrot bebop2 drone with homebrew software under Linux. All sensors and actuators are usable.
You're welcome to contribute by sending us a mail at drones(at)hds.utc.fr

The stock bebop2 drone works with a Parrot tuned linux distribution. Among the Parrot specific sotware, some have their sources available at https://github.com/Parrot-Developers. There you'll find the kernel sources for example.

This document gives a lot of information on hacking the bebop [https://github.com/nicknack70/bebop/blob/master/UBHG/UBHG1_7_3.pdf ici].

== Connection ==
While booting the drone create a Wifi access point named Bebop2-xxxxxx. Connect to it from your machine. Then you have to press 4 times shortly the big red button at the rear of the drone, under the battery pack. This will start a telnet server. Then you can remote connect to the drone by simple typing {{{ telnet 192.168.42.1 }}}

If a USB cable is plugged while you do the 4 short presses, then the drone sets up an ethernet over USB connexion. So you can also access the drone through this interface, should something go wrong with the wifi {{{ telnet 192.168.43.1 }}}.

== Standard startup procedure ==
Upon startup, the first run process ("init") is the binary executable /sbin/boxinit (Parrot specific program, fork of android init. Not released on Parrot-devs).

This program executes the instructions contained in the /etc/boxinit.rc file. Instructions are organized in "classes" that contain "services". The "core" class is launched on boot. Looks like the "core-main" class is started thereafter.
The rcs-init service, member of the core class, corresponds to the main startup script, /etc/init.d/rcS. This script does all the one shot actions necessary upon startup, including network and I/O configuration.

At the very end of the startup process, the "dragon-prog" program is launched. It is the program that governs the drone flight laws.

== Logs ==
Most operations are logged by the ulogger deamon. It's a Parrot binary which sources are available on Parrot-devs, under the "ulog" project.
{{{ ulogger -h }}} for options.
Logs can be read with the ulogcat binary.
Very convenient to follow all startup steps.

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

=== Startup ===
When /etc/init.d/rcS script runs, it starts udev (/usr/bin/udevd_init). Udev configuration is in /lib/udev. The rules.d/50-network.rules contains the main network interface rules (wifi).
Upon startup, the BSP creates a usb broadcom device. Udev detects it, and activates a rule which runs {{{/sbin/broadcom_setup.sh insmod}}}. As a consequence, the wl (proprietary broadcom driver) ans bcm_bus modules are loaded in the kernel.
The wl driver creates the eth0 network interface in the kernel. Udev detects this, and activates an other rule that runs {{{/sbin/broadcom_setup.sh create_net_interface}}}. As a consequence, the eth0 interface is configured as a wifi access point.

=== Watchdog ===
Upon startup, a watchdog daemon is started: /usr/bin/bcm-watchdog. {{{bcm-watchdog -h}}} for options.
It calls {{{broadcom_setup.sh reboot}}} if the network connection is lost. This script runs the broadcom_reset.sh script, which disables the network connection, waits for 3s, then re-enables it (should feel strange while inflight!)

== Big Button ==
Upon startup, a deamon is started to monitor presses on the big red button, at the rear of the drone, under the battery. Different press patterns are detected and described in the /bin/onoffbutton directory.
Implemented behaviors are
  * 1 short press: shutdown
  * 4 short presses: debug mode. starts telnet daemon, adb (android debug) daemon, and sets up the "ethernet over usb" link on rndis0 network interface.
  * 1 long press: wifi band change
  * 1 veeeeery long press: '''DANGER! ''' factory reset: all the /data directory is blanked, you loose all custom work

== 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 ===
As an example, here is the whole chroot script we're using (''/data/ftp/internal_000/chroot.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