Artoo Adaptor For Crazyflie

This repository contains the Artoo ( adaptor for the Crazyflie micro-quadcopter (

Artoo is a open source micro-framework for robotics using Ruby.

For more information abut Artoo, check out our repo at

The artoo-crazyflie adaptor is based on the crubyflie gem (

Code Climate Build Status


gem install artoo-crazyflie


require 'artoo'

connection :crazyflie, :adaptor => :crazyflie
device :drone, :driver => :crazyflie, :connection => :crazyflie, :interval => 0.1

work do
  after(1.seconds) {drone.stop}

Connecting to Crazyflie

The Crazyflie uses a 2.4 GHz radio to communicate. There is a USB dongle called the Crazyradio that is required to control the Crazyflie quadcopter.

If you are have a USB 3.0 port, you might run into this issue

Crazyflie Hover

To use the Crazyflie beta 'hover' mode, you will need to install the latest beta of firmware to the Crazyflie itself from

Once you have updated the Crazyflie firmware, to trigger the hover mode on, use the flightmode.althold param on the Crazyflie like this:

  @crazyflie.param.set_value('flightmode.althold', true)

Please note that the Crazyflie's interprets hover to mean "maintain altitude", not "stay in one place", so you will need to control horizontal positioning yourself.

To turn hover mode off:

  @crazyflie.param.set_value('flightmode.althold', false)

Once you turn hover mode off, the Crazyflie requires that you immediately apply thrust, or it will just drop like an unpowered PCB from the air. You have been warned...


Check out our documentation for lots of information about how to use Artoo.


Need more help? Just want to say "Hello"? Come visit us on IRC freenode #artoo


  • All patches must be provided under the Apache 2.0 License
  • Please use the -s option in git to "sign off" that the commit is your work and you are providing it under the Apache 2.0 License
  • Submit a Github Pull Request to the appropriate branch and ideally discuss the changes with us in IRC.
  • We will look at the patch, test it out, and give you feedback.
  • Avoid doing minor whitespace changes, renamings, etc. along with merged content. These will be done by the maintainers from time to time but they can complicate merges and should be done seperately.
  • Take care to maintain the existing coding style.
  • Add unit tests for any new or changed functionality.
  • All pull requests should be "fast forward"
    • If there are commits after yours use “git rebase -i
    • If you have local changes you may need to use “git stash”
    • For git help see progit which is an awesome (and free) book on git

(c) 2012-2014 The Hybrid Group