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 ​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

At the end of the boot sequence, the drone is ready to fly with Parrot's flight laws. To replace these laws with our owns, we could install our program in the original parrot file system, and start it instead of the original dragon-prog executable. But this has 2 drawbacks

• the original filesystem is modified. If we make mistakes, we could brick the drone!
• we are not certain that the original Parrot program isn't necessary to complete the drone setup. If it's indeed the case we could have problems using some devices, sensors for example.

As a consequence, we prefer to start our programs in a "chrooted" environment, meaning in a separate file system. The idea is to start à ssh server (dropbear) in a file system created with robomap3. It's in this file system that we'll put our flight control programs.

Caution: our command laws must not intefere with Parrot"s ones (for example one could require a motor to accelerate, while the other one would require it to brake). First thing to do is to call the "kk" script (💩). It's a script provided by Parrot that kills the dragon-prog process. It's a hard "kk", since it uses SIGKILL signal :)

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