The Bitcraze Virtual Machine is designed as a quick and isolated way to start development with Crazyflie and other bitcraze projects.
The current VM is starting to get very old, even though we keep it updated it is based on XUbuntu LTS 14.04. This month Ubuntu LTS 18.04 is being release which is a good reason to upgrade the VM!
The main update will then to switch from XUbuntu 14.04 to XUbuntu 18.04. There is a couple more things that we are looking at updating:
Updating Eclipse and CDT to the latest version Oxygen.3a
Fixing Eclipse code completion and hinting configuration
Pre-configuring eclipse with gnu-mcu-eclipse to make it easier to flash and debug Crazyflie.
Fixing the virtual machine Crazyradio communication bugs
We are writing this blog post as a request for comment:
Is there anything else that you would like to add/remove in the new virtual machine?
Anything we could do to make it easier to start developing for Crazyflie?
The virtual machine is generated automatically using packer and VirtualBox, the code is hosted on GitHub. If you want to help making the VM or want functionality to be added to it do not hesitate to open a ticket in the bug tracker.
Here at the USC ACT Lab we conduct research on coordinated multi-robot systems. One topic we are particularly interested in is coordinating teams consisting of multiple types of robots with different physical capabilities.
A team of three quadrotors all controlled with Crazyflie 2.0 and a Clearpath Turtlebot
Applications such as search and rescue or mapping could benefit from such heterogeneous teams because they allow for more flexibility in the choice of sensors and locomotive capability. A core challenge for any multi-robot application is motion planning – all of the robots in the team need to make it to their target locations efficiently while avoiding collisions with each other and the environment. We have recently demonstrated a scalable method for trajectory planning for heterogeneous robot teams utilizing the Crazyflie 2.0 as the flight controller for our aerial robots.
A Crazier Swarm
To test our trajectory planning research we wanted to assemble a team with both ground robots and multiple sizes of aerial robots. We additionally wanted to leverage our existing Crazyswarm software and experience with Crazyflie firmware to avoid some of the challenges of working with new hardware. Luckily for us the BigQuad deck offered a straightforward way to super-size the Crazyflie 2.0 and gave us the utility we needed.
With the BigQuad deck and off-the-shelf components from the hobbyist drone community we built three super-sized Crazyflie 2.0s. Two of them weigh 120g (incl. battery) with a motor-to-motor size of 130mm, and the other is 490g (incl. battery and camera) with a size of 210mm.
120g, 130mm
490g, 210mm
We wanted to pick components that would be resistant to crashing while still offering high performance. To meet these requirements we ended up picking components inspired by the FPV drone racing community where both reliable performance and high-impact crashes are expected. Full parts lists for both platforms are available here
Integrating the new platforms into the Crazyswarm was fairly easy. We first had to re-tune the PID controller gains to account for the different dynamics of the larger platforms. This didn’t take too long, but we did crash a few times — luckily the components we chose were able to handle the crashes without any breakages. After tuning the platforms behave very well and are just as easy to work with as the original Crazyflie 2.0. We additionally updated the Crazyswarm package to be able to differentiate between BigQuad and regular Crazyflie types and those updates are now available for use by anyone!
In future work, we are excited to do hands-on experiments with a prototype of the CF-RZR. This new board seems like a promising upgrade to the CF 2.0 + BQD combination as it has upgraded components, an external antenna, and a standardized form factor. Hopefully we will see the CF-RZR as part of the Crazyswarm in the near future!
We though we could use this Monday blog post to do a small state of the Crazyflie clients. What we call a Crazyflie client is a piece of software that connects a Crazyflie and allows to control it and get telemetry back from it. In this post we will concentrate on single-crazyflie client we have on our GitHub page, there exists a lot of libraries and software to control one or many Crazyflies, we will write another blog post about them.
Crazyflie PC client
The Crazyflie PC client, is what we consider the reference client. It supports connecting one Crazyflie using the Crazyradio (PA) dongle or direct USB connection to Crazyflie 2.0. It supports the full Crazyflie telemetry (ie. log), parameters (ie. params) and firmware update. It has support for all the Crazyflie 2.0 deck that can use client support. It is updated each time it is needed when new functionalities are added in the Crazyflie which makes it actively developed and maintained by the community and Bitcraze. A bluetooth link has not been prioritize so far since its multi-platform implementation is non-obvious and bluetooth will introduce some latency and lower the radio bandwidth compared to Crazyradio. However, if anyone would want bluetooth support for the Crazyflie PC client, we welcome contributions :-). The Crazyflie PC client is using the crazyflie-lib-python to communicate with the Crazyflie.
We have three mobile clients on our Github. They have various level of functionality depending on community involvement. Our philosophy is to have the mobile clients at least able to control a Crazyflie, this allows to use them to test Crazyflies without requiring to setup a computer. We will help and support anyone that is interested in adding functionalities to the mobile clients but we generally do not have time to add much functionalities by ourselves.
The Andoid crazyflie client is currently maintained by Fred from the community. It is mobile Crazyflie client with the most feature. It supports both Crazyradio and Bluetooth link. Using Crazyradio it currently supports the part of telemetry and parameter required to support a couple of deck like the led-ring and buzzer deck and supports updating the firmware. Using bluetooth there is currently no telemetry, parameter or firmware update functionality so no deck support. Development is in progress to support more decks and to bring the bluetooth link to the same functionality as the Crazyradio link. The Android client is written in Java and Fred has developed a Crazyflie Java library that is used in the Android client but that can also be used in any other Java program.
Crazyflie Android client
The iOS Crazyflie client, works on iPhone and iPad. It supports bluetooth link. It does not have any telemetry or parameter support, so no deck control support. It has firmware update support over bluetooth. It has mainly been developed by me with great contributions from the community for, among others, the port to swift. The iOS client is written in swift. The Crazyflie and Bluetooth part of the code could be a good starting point if anyone wanted to make a native mac Crazyflie client.
Crazyflie iOS client
Finally we have a prototype of a Windows UWP client developed by theseankelly. It supports Bluetooth low energy. It currently does not supports any telemetry or parameters. It is working both on Windows phone and on Windows 10 on computer, it is currently the only way to connect a Crazyflie using Bluetooth from a laptop. The windows client supports manual control of the Crazyflie using a gamepad or with gesture using HoloLens. This original set of functionality makes it both the most simple and the most advanced Crazyflie client :-).
If you are interested in developing for any of these client, of by making your own, feel free to make a ticket on the relevant github repo or open a thread in the forum. We migh not have much time to develop for the mobile clients, but we will always be glad to help and guide anyone that wants to implement software in relation with the Crazyflie. The Crazyflie clients (running in a computer or phone) and the Crazyflie firmwares (running in the Crazyflie itself) are open source and in active development, it means that is possible to modify both side, this makes it a great target to experiments and to play around with new ideas :-).
We have seen a big interest in flying swarms of Crazyflies and there are many challenges in doing so. The USC ACT Lab has developed Crazyswarm, a collection of software and firmware that allows to fly big swarms of Crazyflie using a motion capture system. This project has been used by USC and other universities to fly the most impressive swarms of Crazyflie 2.0 to date.
We are very happy that we together with Wolfgang and James, the main developer of Crazyswarm, have started to merge the firmware part into the official Crazyflie firmware. Merging the code will have two great consequences: people will be able to use Crazyswarm with a Crazyflie 2.0 running the stock firmware and everybody else will be able to use functionalities that has been developed for Crazyswarm.
There is currently a couple of parts that are in the works. The state controller has been merged already. There is currently some discussion on Github on how to merge the high-level commander, a commander that would allow the Crazyflie to autonomously follow trajectories as well as other high level commands. Finally there will be some work required to adapt the Kalman filter to make it more suited to accepts measurements from a motion capture system. The Crazyflie was not developed as an autonomous platform from the beginning but it is becoming one in big part thanks to the great contributions from the community.
A great thanks to James and Wolfgang for their effort in merging CrazySwarm in the Crazyflie code-base!
Out of stock
Unfortunately we miscalculated how much China slows down during Chinese new year which has caused some products to become out of stock. One of them is the Crazyradio PA which is also causing some bundles to become out of stock as well. The good news is that the products are in transit to the warehouse and will hopefully be back in stock any day now. Until then you can use the “Item out of stock – notify me!” functionality to get notified as soon as the product is back in stock.
During the fall we did two blog-posts (1, 2) about a new prototype named Obstacle Avoidance/SLAM deck, but since then it’s been a bit quiet about it. So we thought it was due for an update! First of all, after a lot of discussions, we decided to rename the deck to Multi-ranger. It better describes what the board does and matches the naming of the Z-ranger. We’ve sent out some samples to customers and so far the response has been great. So we’re pushing forward and preparing for production that’s estimated to begin in March. Below is a picture of the latest prototype.
The biggest change for the final prototype is adding a LDO regulator to power the sensors. We’ve seen that depending on the settings for the sensors they might consume a lot more than when we initially tested. Using the same settings as for the Z-ranger brings the consumption to 90 mA, which together with the Crazyflie 2.0 electronics, comes close to filling the power budget for the Crazyflie 2.0 VCC LDO regulator. Aside from that we’re making some minor changes to simplify production and testing.
We just released a new version of the Bitcraze VM, version 2018.01. Nothing very new in this version, the VM has been rebuilt so that all the projects included in it are now up-to-date. This solves an issue where the Crazyflie client was blocked in the previous revision.
The current VM is running a quite old version of Ubuntu, the 14.04 LTS version. We are planning at refreshing the VM by making a new one when Ubuntu 18.04 LTS is released.
Since the Crazyflie 1 time we have been documenting the VM as a standard development environment. This has a couple of advantages:
We can distribute a fully setup development environment that has minimal dependencies with the host system
If someone has a problem with the VM, there is a bit chance we can reproduce and fix it, everyone is running the same system
Everything is pre-setup so it should be fairly quick to get started with the actual firmware or software development
However the VM solution also has drawbacks:
It requires to install and somewhat configure VirtualBox or other virtual machine software
It has some cost in performance, mostly for USB as it slows down the communication with the Crazyflie
The USB implementation seems to have bugs on Windows, which makes the communication with the Crazyflie buggy. This is currently the biggest problem!
So, the situation is not ideal, and we would love to get some feedback from the community.
There are two very different parts in the system: the lib and client in Python, and the firmwares in C.
Starting development of the python parts, on Windows/Mac/Linux, is fairly straightforward. Basically one has to install python and git, clone the projects, install dependencies and it runs. Different python IDEs can be used and work pretty much out of the box.
Starting development for the embedded C part can be a bit more challenging. On Linux and Mac it is pretty easy since it only requires to download the arm-embedded-gcc compiler and adding it to the path. On windows things are a bit more complex because you also need Make and I haven’t yet figured-out the best way to install that. Having an IDE requires to configure Eclipse CDT.
What do you think about the VM as a development environment and would you prefer other solutions like documentation for each operating system on how to install a development environment?
We have been writing a couple of times already about the new TDoA2 algorithm for the Loco Positioning System. A TDoA mode has been experimental from the day we released the LPS but we are now proud to announce that TDoA is an official positioning mode for the Loco Positioning System and the Crazyflie.
Practically it means that the Loco Positioning System now has an officially supported mode to locate and fly a swarm of Crazyflie 2.0.
We have worked these last weeks at updating documentation, the “Getting started” tutorial and releasing all the affected firmware and software. One of our goals was to make the new TDoA mode as seamless and as easy as possible to work with, this meant having everything working without having to recompile the Crazyflie or any other part of the system. The Crazyflie is now detecting the LPS mode automatically and it is possible to configure the anchors position and ranging mode remotely from the within Crazyflie client LPS tab.
If you have 8 anchors and want to convert your local positioning system to TDoA, this can be done very easily by following the new version of the getting started with loco positioning system guide.
If you want more information about the different positioning modes, we have also updated the system description.
We have been lucky get the opportunity to use a motion capture system from Qualisys in our flight lab. The Qualisys system is a camera based system that is using IR-cameras to track objects with sub-millimeter precision! The cameras are designed to measure the position and track small reflective marker balls that are fixed to the object to be tracked with high accuracy. By using multiple cameras shooting from different angles it is possible for the system to calculate the 3D position of a marker in space. By mounting multiple markers on an object the system can also identify the object as well as its orientation in space. Very cool!
We have started to look at how to add support in our ecosystem for the Qualisys system as well as other “external” positioning systems, external in this context is systems that calculate the position outside the Crazyflie. There is already great support for external positioning in the CrazySwarm project by the USC-ACTLab, but we are now looking at light weight support in the python client. We are not sure what we will add but ideas are on the lines of viewing an external position in the client, feed an external position into the Crazyflie for autonomous flight and maybe a simple trajectory sequencer.
MoCap Deck
We have also started to design a MoCap Deck to make it easy to mount reflective markers on the Crazyflie. Our design goals include:
* light weight
* easy to use
* support for multiple configurations to enable identification of individuals
* the possibility to add a button for human interaction
The suggested design of the MoCap Deck
Any feedback on the MoCap Deck and ideas for functionality to add to the client is welcome! Please add a comment to this blog post or send us an email.
We will write more about the Qualisys system later on, stay tuned!
This week we have a guest blog post by Ben, enjoy!
I’m Ben Kuperberg and i’m a digital artist, artist-friendly software developer and orchestra conductor. Being a juggler, I’ve decided to focus some of my work on the intersection between juggling and technology, and i’ve since been working more and more with jugglers, my last project being “Sphères Curieuses” from Le Cirque Inachevé, created by Antoine Clée. While the whole project is not focused on drones, a part of it involves synchronized flight of multiple drones and precise human interaction with those drones. Swarm flight is something already out there and some solutions already exist but the context of this project added some challenges to it.
Most work on drone swarms have been done by research group or school. They use high-grade expensive motion-capture system able to track precisely the drones and able to assign their absolute positions. While the quality of the result is undeniable, it’s not fit for stage shows : the setup is taking a lot of time which we can’t always have when the show is on the road. Moreover, the mocap system is too invasive for the stage if you want to be able to “hide” a bit the technology and let the spectator focus on what the artist wants you to see. Not to mention it costs an arm and a leg and Antoine needs both to juggle.
So we had to find other ways to be able to track multiple drones. That’s when we found out the [amazing] team at Bitcraze was working on the TDoA technology, which allows precise-enough tracking of a virtually unlimited amount drones, at reduced cost and with a fast and clean setup.
After some work we managed to have a first rough version of our swarm server made by Maxime Agor that allowed to connect and move multiple drones using the TDoA system, controlled from a Unity application.
While we were able to present a decent demo with this system, we were facing a major problem of reactivity. When working with artists and technology, reactivity is a key component to creativity. Because it can be frustrating and tense to stop each 2 minutes to make changes or fix problems. My first priority was therefore to prepare and design softwares that will allow me to spend most of the “creation time” on the actual creation aspect and not on technical parts. It is also essential that the artist performing in front of the audience can entirely focus on the performance and by fully confident in this technology. The last challenge is that as I focus my work on the creation and not touring, all my work needs to be easily understood and modified by both the artists and the technicians who will take over my work for the tour.
With all of that in mind, I decided to create a software with a high-end user interface called “La Mouche Folle” (« The Crazy Flie » in french) that allows to control multiple drones and have an overview of all the drones, their battery/charging/alert states, auto-connect / auto-reboot features, external control via OSC, and a Unity client to view and actually decide how to move the drones. All my work is open-source, so you can find the software on github.
There only is a Windows release for now but it should compile just fine on OSX and Linux, the software is made with JUCE, depends on OrganicUI and lib-usb. Feel free to contact me if you want more information on the software. Many thanks Wolfgang Hoenig for the support and the great work on the crazyflie cpp library i’m relying on.
So this is the basic setup of our project, but we needed more than that to control the drone. We wanted to be able to control them in the most natural way possible. We quickly decided to go with glove-base solutions, and have been working with Specktr to get our hands – pun intended – on developer versions of the glove. The glove is good but can’t give us absolute position of the hand, so we added HTC Vive trackers with the lighthouse technology and then were able to get both natural hand control and sub-millimeter precision of the tracked hand.
Then it was a matter of connecting everything together : for other projects for Theoriz Studio, I already developed MrTracker (used in the MixedReality project) that acts as a middleware between the Vive trackers and Unity.
I used Chataigne to easily connect and route the Specktr Glove data to Unity as well so we would have maximum flexibility to switch hardware or technology without breaking whole setup if we needed to.
A video of the final result
In the past years, i’ve come to work on a lot of different projects, with different teams, which i like very much, because each project leads to discover new people, new ways of working and new challenges to overcome. I’m having a great time working on this project and especially sharing everything with the guys at Bitcraze and the community, everyone has been so cool and nice. I’ve planned to go at the Bitcraze studios to work for few weeks with them and i’m sure it’ll be a great experience !
