bebop_autonomy - ROS Driver for Parrot Bebop Drone (quadrocopter) 1.0 & 2.0¶

Changelog for package bebop_driver¶

Changelog for package bebop_tools¶

Changelog for package bebop_msgs¶

Changelog for package bebop_description¶

Compiling From Source¶

Pre-requirements:

• ROS Indigo or Jade (Only tested on Ubuntu)
• Internet connection
• Ubuntu packages: build-esstential, python-rosdep, python-catkin-tools
• Basic familiarity with building ROS packages

$ sudo apt-get install build-essential python-rosdep python-catkin-tools

To compile from source, you need to clone the source code in a new or existing catkin workspace, use rosdep to install dependencies and finally compile the workspace using catkin. The following commands demonstrate this procedure in a newly created catkin workspace.

# Create and initialize the workspace
$ mkdir -p ~/bebop_ws/src && cd ~/bebop_ws
$ catkin init
$ git clone https://github.com/AutonomyLab/bebop_autonomy.git src/bebop_autonomy
# Update rosdep database and install dependencies
$ rosdep update
$ rosdep install --from-paths src -i
# Build the workspace
$ catkin build -DCMAKE_BUILD_TYPE=RelWithDebInfo

The first time build may take up to 15 minutes, since ARDroneSDK3’s build script downloads and compiles ~20 packages from Internet.

$ cd ~/bebop_ws/src
$ git clone https://github.com/ros-teleop/teleop_tools.git
# Do rosdep steps again

Running the driver as a Node¶

The executable node is called bebop_driver_node and exists in bebop_driver package. It’s recommended to run the Node in its own namespace and with default configuration. The driver package comes with a sample launch file bebop_driver/launch/bebop_node.launch which demonstrates the procedure.

$ roslaunch bebop_driver bebop_node.launch

<?xml version="1.0"?>
<launch>
    <arg name="namespace" default="bebop" />
    <arg name="ip" default="192.168.42.1" />
    <arg name="config_file" default="$(find bebop_driver)/config/defaults.yaml" />
    <arg name="camera_info_url" default="package://bebop_driver/data/bebop_camera_calib.yaml" />
    <group ns="$(arg namespace)">
        <node pkg="bebop_driver" name="bebop_driver" type="bebop_driver_node" output="screen">
            <param name="camera_info_url" value="$(arg camera_info_url)" />
            <param name="bebop_ip" value="$(arg ip)" />
            <rosparam command="load" file="$(arg config_file)" />
        </node>
        <include file="$(find bebop_description)/launch/description.launch" />
    </group>
</launch>

Running the driver as a Nodelet¶

To run the driver as a ROS Nodelet, you need to first run a Nodelet manager, then load the driver’s Nodelet (bebop_driver/BebopDriverNodelet) in it, along with other Nodelets that need to communicate with the driver. bebop_tools/launch/bebop_nodelet_iv.launch is a sample launch file that demonstrates these steps by visualizing Bebop’s video stream using an instance of image_view/image Nodelet. Similar to bebop_node.launch, it also runs everything in its own namespace and loads the default configuration.

$ roslaunch bebop_tools bebop_nodelet_iv.launch

<?xml version="1.0"?>
<launch>
    <!-- include the nodelet launch file from bebop_driver -->
    <arg name="namespace" default="bebop" />
    <include file="$(find bebop_driver)/launch/bebop_nodelet.launch">
      <arg name="namespace" value="$(arg namespace)" />
    </include>
    <!-- use the same nodelet manager and namespace, then load image_view nodelet -->
    <group ns="$(arg namespace)">
       <node pkg="nodelet" type="nodelet" name="bebop_image_view_nodelet"
          args="load image_view/image bebop_nodelet_manager">
          <remap from="image" to="image_raw" />
        </node>
    </group>
</launch>

<?xml version="1.0"?>
<launch>
    <arg name="namespace" default="bebop" />
    <arg name="ip" default="192.168.42.1" />
    <arg name="config_file" default="$(find bebop_driver)/config/defaults.yaml" />
    <arg name="camera_info_url" default="package://bebop_driver/data/bebop_camera_calib.yaml" />
    <group ns="$(arg namespace)">
        <!-- nodelet manager -->
        <node pkg="nodelet" type="nodelet" name="bebop_nodelet_manager" args="manager" output="screen"/>
        <!-- bebop_nodelet -->
        <node pkg="nodelet" type="nodelet" name="bebop_nodelet"
          args="load bebop_driver/BebopDriverNodelet bebop_nodelet_manager">
            <param name="camera_info_url" value="$(arg camera_info_url)" />
            <param name="bebop_ip" value="$(arg ip)" />
            <rosparam command="load" file="$(arg config_file)" />
        </node>
        <include file="$(find bebop_description)/launch/description.launch" />
    </group>
</launch>

Takeoff¶

Publish a message of type std_msgs/Empty to takeoff topic.

$ rostopic pub --once std_msgs/Empty [namespace]/takeoff

Land¶

Publish a message of type std_msgs/Empty to land topic.

$ rostopic pub --once std_msgs/Empty [namespace]/land

Emergency¶

Publish a message of type std_msgs/Empty to reset topic.

$ rostopic pub --once std_msgs/Empty [namespace]/reset

Piloting¶

To move Bebop around, publish messages of type geometry_msgs/Twist to cmd_vel topic while Bebop is flying. The effect of each field of the message on Bebop’s movement is listed below:

linear.x  (+)      Translate forward
          (-)      Translate backward
linear.y  (+)      Translate to left
          (-)      Translate to right
linear.z  (+)      Ascend
          (-)      Descend
angular.z (+)      Rotate counter clockwise
          (-)      Rotate clockwise

Acceptable range for all fields are [-1..1]. The drone executes the last received command as long as the driver is running. This command is reset to when Takeoff, Land or Emergency command is received. To make Bebop hover and maintain its current position, you need to publish a message with all fields set to zero to cmd_vel.

Moving the Virtual Camera¶

To move Bebop’s virtual camera, publish a message of type geometry_msgs/Twist to camera_control topic. angular.y and angular.z fields of this message set absolute tilt and pan of the camera in degrees respectively. The field of view of this virtual camera (based on our measurements) is ~80 (horizontal) and ~50 (vertical) degrees.

angular.y (+)      tilt down
          (-)      tilt up
angular.z (+)      pan left
          (-)      pan right

GPS Navigation¶

Flat Trim¶

Publish a message of type std_msgs/Empty to flattrim topic.

$ rostopic pub --once std_msgs/Empty [namespace]/flattrim

Flight Animations¶

Bebop can perform four different types of flight animation (flipping). To perform an animation, publish a message of type std_msgs/UInt8 to flip topic while drone is flying. The data field determines the requested animation type.

0       Flip Forward
1       Flip Backward
2       Flip Right
3       Flip Left

Take on-board Snapshot¶

To take a high resolution on-board snapshot, publish a std_msgs/Empty message on snapshot topic. The resulting snapshot is stored on the internal storage of the Bebop. The quality and type of this image is not configurable using the ROS driver. You can use the official FreeFlight3 app to configure your Bebop prior to flying. To access the on-board media, either connect your Bebop over USB to a computer, or use a FTP client to connect to your Bebop using the following settings:

• Default IP: 192.168.42.11
• Port: 21
• Path: internal_000/Bebop_Drone/media
• Username: anonymous
• Password: <no password>

Toggle on-board Video Recording¶

To start or stop on-board high-resolution video recording, publish a std_msgs/Bool message on the record topic. The value of true starts the recording while the value of false stops it. Please refer to the previous section for information on how to access the on-board recorded media.

Camera¶

The video stream from Bebop’s front camera is published on image_raw topic as sensor_msgs/Image messages. bebop_driver complies with ROS camera interface specifications and publishes camera information and calibration data to camera_info topic. Due to limitations in Parrot’s ARDroneSDK3, the quality of video stream is limited to 640 x 368 @ 30 Hz. The field of view of this virtual camera (based on our measurements) is ~80 (horizontal) and ~50 (vertical) degrees.

To set the location of camera calibration data, please check this page: Configuring Bebop and the Driver. Since v0.4, the package ships with a default camera caliberation file located at bebop_driver/data/bebop_front_calib.yaml. Both default node/nodelet launch files, load this file when executing the driver.

Standard ROS messages¶

TF¶

The driver updates the following TF tree based on a simple kinematic model of the Bebop (provided by bebop_description) pacakge, the current state of the virtual camera joints and the calculated odometery (if publish_odom_tf is set, see Driver Parameters).

States (aka Navdata)¶

Unlike Parrot ARDrone, Bebop does not constantly transmit all on-board data back to the host device with high frequency. Each state variable is sent only when its value is changed. In addition, the publication rate is currently limited to 5 Hz. The driver publishes these states selectively and when explicitly enabled through a ROS parameter. For example setting ~states/enable_pilotingstate_flyingstatechanged parameter to true will enable the publication of flying state changes to topic states/ARDrone3/PilotingState/FlyingStateChanged. List of all such parameters and their corresponding topics and message types are indexed in the following pages:

Common States

List of common States and Corresponding ROS Parameters and Topics

Bebop-specific States

List of ARDrone3 States and Corresponding ROS Parameters and Topics

Driver Parameters¶

Following parameters are set during driver’s startup:

Dynamically Reconfigurable Parameters for Bebop¶

Following ROS parameters change Bebop’s settings. They can be tweaked during runtime using dynamic reconfigure GUI. Setting ~reset_settings parameter to true will reset all these settings to factory defaults.

List of Ardrone3 Settings and Corresponding ROS Parameter

ROS Standard Message Types (i.e Twist, Odometery) - REP 103¶

• More information: http://www.ros.org/reps/rep-0103.html

Bebop Velocities¶

Bebop Attitude¶

SDK’s setPilotingPCMD¶

Contribute to bebop_autonomy¶

You can contribute to bebop_autonomy by:

• Reporting bugs using driver’s Issue Tracker on Github.
• Submitting patches, new features, sample codes, documentation and supplementary materials (i.e. launch and configuration files) as Github Pull Requests.
  • Please check current open issues and Features and Roadmap section for a list of known bugs and feature request.
• Joining driver’s developers forum and participate in technical discussions on new features, bugs and roadmap.

List of Developers¶

• Mani Monajjemi

List of Contributers¶

• Anup Parikh
  • #19 Add bebop ip address as ROS parameter
• Jacob Perron
  • #26 Bebop now follows right-hand rule
• Jake Bruce
• Charuvahan Adhivarahan
  • #30 Fixed breaking build due to legac macro usage

Acknowledgments¶

• Mike Purvis for his help with designing the initial architecture of the driver.

Is bebop_autonomy based on ardrone_autonomy?¶

No. ardrone_autonomy is based on Parrot’s legacy SDK for AR-Drone 1.0 and 2.0, while bebop_autonomy uses Parrot’s new SDK for its third generation drones. Since these two SDKs and their underlying protocols are totally different and incompatible, we had to develop bebop_autonomy from scrath.

Is bebop_autonomy compatible with ardrone_autonomy?¶

Not completely.

• Topic names, types and coordinate frame conventions for core piloting tasks are identical, however there is no explicit namespacing (i.e. takeoff instead of ardrone/takeoff)
• bebop_autonomy does not expose services for Flight Animations or Flat Trim; topics are used instead.
• Front camera video stream is published on image_raw topic only.
• Parameter names, types and effects are different.
• AR-Drone Navdata is replaced by Bebop States (see States (aka Navdata))

Automatic Code Generation¶

TBA

Threading Model¶

TBA

Publishing the States¶

TBA

Configuring the Drone¶

TBA

Tests¶

$ cd /path/to/bebop_ws
$ catkin clean --cmake-cache
$ catkin build bebop_driver --cmake-args -DRUN_HARDWARE_TESTS=ON

$ cd /path/to/bebop_ws/build/bebop_driver
$ make tests
$ rostest --text bebop_driver bebop_itl_test.test

Upgrading the Bebop SDK¶

1. Update the GIT_TAG of ARDroneSDK3 in bebop_driver/CMakeLists.txt::add_custom_target::./repo init ... -b GIT_TAG to your desired commit hash, branch or tag (release). The official upstream repository is hosted here.
2. Checkout (or browse) the upstream repository at the same hash used in step (1) and open release.xml file. From this file, extract the commit hash of libARCommands from the revision property of this XML tag: <project name="libARCommands" ... revision="" />.
3. Open bebop_driver/scripts/meta/generate.py and update LIBARCOMMANDS_GIT_HASH variable to the hash obtained in step (2).
4. Change the working diretory to bebop_driver/scripts/meta, then execute generate.py from the command line. This will regenerate all automatically generated message definitions, header files and documentations.
5. Copy the generated files to their target locations by calling install.sh.
6. In bebop_driver/include/bebop_driver/autogenerated/ardrone3_setting_callbacks.h change ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_PILOTINGSETTINGSSTATE_MAXDISTANCECHANGED_VALUE to ARCONTROLLER_DICTIONARY_KEY_ARDRONE3_PILOTINGSETTINGSSTATE_MAXDISTANCECHANGED_CURRENT. This is due to a bug in upstream XML definitions.
7. Remove build and devel space of your catkin workspace, then re-build it.

Parrot ARDrone3 SDK¶

Copyright (C) 2014 Parrot SA

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of Parrot nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior writtenpermission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

bebop_autonomy (driver and tools)¶

Copyright (c) 2015, Mani Monajjemi (AutonomyLab, Simon Fraser University) All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of [project] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.