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 !
A couple of weeks ago, I was visiting 34C3, the Chaos Communication Congress, with Fred. The trip was not ‘official’ business for Bitcraze but more of a personal interest, the Congress is a great place to be and I hope to be able to go next year. While there, we found out that Foosel was there too, she is the developer and maintainer of the Octoprint project (Our 3D printer would be much less useful without Octoprint …). It was awesome to finally meet her in real life, she has been in the Crazyflie comunity since the beginning and we have never been able to meet even though we did a couple of maker faire in Germany.
Meeting the community in person is always awesome, this is one of the best part of going to conferences.
At the end of the month we will be at FOSDEM in Belgium, Fred will be there too, he is planning to demo Crazyflie at the Eclipse booth. If anyone else is coming please let us know, we can improvise a Crazyflie meetup there.
Later in the year, in good Bitcraze style, we have not planned anything yet. Last year we went to ICRA which was a very good experience and we might be leaning for IROS this year. Let us know if there is any conference at which you would like to meet us and we will consider going.
It is now the first day in 2018 and a good day to look back at 2017. Its been a busy year as always and we have had a lot of fun during the year. One of the first things popping up is that things takes so much longer then we think. Luckily we are working with open source and the progression is not only dependent on us as we have awesome help from the community. We are already really excited about what’s coming in 2018, looking forward to working together with so many great people!
Community
The Crazyflie 2.0 is still gaining attention and are becoming more and more popular among universities around the world. We see interest from researchers working with autonomous systems, control theory, multi-agent systems, swarm flight, robotics and all kinds of research fields, which is really great. This means that a lot of exciting work have been contributed by the community, so here is a small summary of what has happened in the community during the year.
In the beginning of the year the Multi-Agent Autonomous Systems Lab at Intel Labs shared how the Crazyflie 2.0 is used in their research for trajectory planning in cluttered environments. We wrote a blog post about this if you want learn more about their work. The Crazyflie showed up on the catwalk of Berlin Fashion week being part of fashion designer Maartje Dijkstras futuristic creation TranSwarm Entities”, a dress made out of 3D prints accompanied by autonomously flying Crazyflies.
For the third year Bitcraze visited Fosdem. We had a good time and got to hang out with community members like Fred how did a great presentation about what’s new in the Crazyflie galaxy. During the conference we took the opportunity to present the Loco positioning system and demo autonomous flight with the Crazyflie controlled by the Loco positioning system. In the demo we flew with the non-linear controller from Mike Hammer using trajectory generation from Marcus Greiff.
We have had a few interesting blog post contributions during the year from major universities. Including a guest post written by researchers at Carnegie Mellon University. The researchers are using the Crazyflie 2.0 drone to create an adaptive multi-robot system. Similar work has been done by the researchers at the Computer Science and Artificial Intelligence Lab at MIT were they have been studying coordination of multiple robots, developing multi-robot path planning for a swarm of robots that can both fly and drive.
We have also had two interesting guest blog post from the GRASP Laboratory at University of Pennsylvania, the “A Flying Gripper based on Modular Robots” and “ModQuad – Self-Assemble Flying Structures“. Inspired by swarm behavior in nature, for instance how ants solve collective tasks, both projects explore the possibilities of how multiple Crazyflies can work together to perform different missions.
During the fall Fred took the time to pay us a visit at the office in Sweden and worked together with us. He is making great progress on the Java Crazyflie lib that is going to be used in the Android client as well as in PC clients. It will allow to connect and use a Crazyflie from any Java program, there has already been some successful experimentation done using it from Processing.
Some other great news is that thanks to Sean Kelly the Crazyflie 2.0 is now officially supported by the Betaflight flight controller firmware. Betaflight is a flight controller firmware used a lot in the FPV and drone racing community.
Finally The Crazyswarm project, by Wolfgang Hoenig and James A. Preiss from USC ACTlab has been presented at ICRA 2017. It is a framework that allows to fly swarms of Crazyflie 2.0 using a motion capture system. There is currently some work done on merging the Crazyswarm project into the Crazyflie master branch, this will make it even easier to fly a swarm of Crazyflie. In the meantime the project is well documented and can be used by anyone that has a couple of Crazyflies and a motion capture system.
Hardware
During 2017 we released four new products. Beginning with the Micro SD-card deck which e.g. makes high speed logging possible. Then the Z-ranger that enables a height hold flight mode up to 1m above ground. We like to call it drone surfing as that is very much what it feels like when flying. We ended by releasing two boards, Flow deck and Flow breakout, in collaboration with Pixart containing their new PMW3901 optical flow sensor. The Flow deck enables scriptable flight which is very exiting. That lead us to release the STEM drone bundle which we hope will inspire people to learn more about flying robotics.
Hardware prototypes, our favorite sub-category, are something we have plenty of lying around here at the office. To name a few, a possible Crazyradio 2, the Loco positioning tag, the Crazyflie RZR, the Glow deck or Obstacle avoidance/SLAM deck. It takes a long time making a finished product… Hopefully we will see more of these during 2018!
Software
At the same time we released the Flow deck we also released the latest official Crazyflie 2.0 FW and client (2017.06). This enables autonomous capabilities as soon as the Flow deck is inserted by automatically turning on the corresponding functionality. Just before that, the loco positioning was brought out of early access with improved documentation and simplified setup. Since then a lot of work has been put into making a release of TDoA and improving overall easy of use. With the TDoA2 and automatic anchor estimation starting to work pretty well we should not be far from a new official release!
We would like to end 2017 with a big thank you to our users and community with this compilation video. Make sure to pump up the volume!
This year we decided to celebrate the holiday by painting a Christmas tree, rather than dressing one like last year. What better way to do this that with the flow deck, a LED-ring and a long exposure photo. To check out all the yummy details and how to DIY check out this hackster project we made. Also as an Christmas extra we made this light painting video with the LED-ring mounted on top of the Crazyflie 2.0 and a bit of video editing. To be able to mount the LED-ring on top we hacked together an inverting deck. Not a bad idea and something we aim to release in the future!
Getting started
For those of you that was lucky and got a Crazyflie 2.0 under the Christmas tree, here is a short intro to get you started.
When you are comfortable flying the Crazyflie you might feel that it is time for the next step, to make use of the flexibility of the platform. After all it is designed to be modified!
Check out the “Getting started with development” tutorial to set up your development environment, build your first custom firmware and download it to the copter.
Maybe you want to add a sensor or some other hardware? Heat up your soldering iron and dive in to it! Find more information about the expansion bus on the wiki. The wiki is the place to look for all product and project documentation.
All source code is hosted on github.com/bitcraze and this is also where you will find documentation related to each repository.
Open source is about sharing, creating something awesome together and contribute to the greater good! Whenever you do something that you think someone else could benefit from, please contribute it! If you were curious or confused about something, someone else probably will too. Help them by sharing your thoughts, insights and discoveries.
Can not find the solution to a problem? Don’t understand how or what to do? Have you read all documentation and are still confused? Don’t worry, head over to the forum and check if someone else had the same problem. If not, ask a new question on the forum and get help from the community.
We’ve been seeing an increase in the demand for a “programmable drone”, where users can easily give simple commands though scripting and the Crazyflie 2.0 following them. In order for this to work well you need a closed-loop control, i.e you need a reference system to see how you’re moving. Previously this was only possible using external camera systems or bulky on-board cameras. But a while ago we released the Flow deck which solves this problem. Thanks to the mouse-like sensor the deck contains it enables the Crazyflie 2.0 to see how it’s moving along the floor. Suddenly it’s possible to give commands like “move 1 m forward” or “fly in a clock wise circle with the radius of 1 m”.
To make it easier for users to pick out the parts needed we’ve put together a discounted STEM drone bundle. It contains all the parts needed for scripting the flight. If you have a gamed-pad or a Bluetooth LE enabled phone you can of course fly it manually as well :-)
The Loco Positioning System (LPS) default working mode is currently Two Way Ranging (TWR), it is a location mode that has the advantage of being pretty easy to implement and gives good positioning performance for most use cases and anchor setups. This was a very good reason for us to start with it. Though, TWR only supports positioning and flying of one or maybe a couple of Crazyflies, while it is not a solution to fly a swarm.
One solution to fly a swarm is an algorithm called Time Difference of Arrival (TDoA). We have had a prototype implementation for a while but we experienced problems with outliers, most of them where due to the fact that we where loosing a lot of packets and thus using bad data.
To solve these issues, TDoA2 makes two changes:
Each packet has a sequence number and each timestamps is associated with the sequence number of the packet it has been created from
The distances between anchors are calculated and transmitted by the anchors
A slightly simplified explanation follows to outline why this helps (a more detailed explanation of how TDoA works is available in the wiki).
We start by assuming that all timestamps are available to the tag, this is done by transmitting them in the packets from the anchors to the copter.
The end goal is to calculate the difference of time of arrival between two packets from two different anchors. Assuming we have the transmission time of the packets in the same clock, all we need to do is to subtract the time between the two transmissions with the time between the two receptions:
0 – anchor 0, 1 – anchor 1, T – Tag (that is the LPS deck on the Crazyflie)
To do so we need to have the time it took for the packet to travel between the two anchors, this will enable us to calculate the transmit time of P2 in anchor 1, this can be done by calculating the TWR time of flight between the two anchors, this would require the tag to receive 3 packets in sequence:
So now for the part where TDoA2 helps: previously we had to have the 3 packets in sequence in order to calculate a TDoA, if any one of these where missing the measurement would fail or worse, it could give the wrong result. Since we did not have sequence numbers, it was hard to detect packet loss. Now that we have sequence numbers, we can understand when a packet is missing and discard the faulty data. We also do not have to calculate the distance between anchors in the tag anymore, it is calculated by the anchors themselves. This means that we can calculate a TDoA with only two consecutive packets which increases the probability of a successful calculation substantially.
To reduce packet loss even more, we have also added functionality to automatically reduce the transmission power of the NRF radio (the one talking to the Crazyradio dongle) when the LPS deck is detected. It has turned out that the NRF radio transmissions are interfering with UWB radio reception, and since most indoor use cases does not require full output power we figured that this was a good trade-off.
The results we have seen with the new protocol is quite impressive: TDoA is usually very sensitive to the tag being inside the convex hull, so much so that with the first TDoA protocol we had to start the Crazyflie from about 30cm up to be well within the convex hull. This is not required anymore and the position is still good enough to fly even a bit outside of the convex hull. The outliers are also greatly reduced which makes this new TDoA mode behave very close to the current TWR mode, but with the capability to locate as many Crazyflies as you want:
Added to that, we have also implemented anchor position handling in the TDoA2 protocol and this means that it is now as easy to setup a system with TDoA2 as with TWR:
We are now working on finishing the last functionality, like switching between algorithms (TWR and TDoA) and on writing a “getting started guide”. When that is done TDoA will become an official mode for the LPS.
In the mean time, if you are adventurous, you can try it yourself. It has been pushed in the master branch of the Crazyflie firmware and the LPS node firmware. You should re-flash the Crazyflie firmware, both STM32 and nRF51, from master and the anchors from master too.
As I wrote about in a previous blog post, I have been working on an anchor position estimation algorithm in the Crazyflie Client. The algoritm uses ranging data from the Loco Positioning system to estimate where the anchors are located, and thus remove the need to measure their positions in the room. I have finally reached a point where I think it is good enough to let it out from the lab and it has been pushed to the client repository.
A button has been added to the Loco Positioning tab that opens a wizard. In the wizard the user is asked to place the Crazyflie in certain positions to record ranges and define the coordinate system. If all goes well, the estimated anchor positions are transfered to the anchor position fields in the Loco Positioning tab. If the user is happy with the result the next step is to write the positions to the anchors and start flying!
Now to the disclaimer: the results may not always be perfect – surprise! We have not tested the algorithm a lot but it seems to give decent results, at least it can be useful as a base for manual corrections and sanity checks. Some of the estimated positions are pretty good, while others might be a meter or so off. The conclusion is that you should not trust it blindly, check that the estimated positions seem reasonable before flying.
Currently the system only supports Two way ranging, but extending it to TDoA should not be too complicated. There are probably many possible improvements that can be done, and we hope that everyone that finds this interesting and have ideas of how to do it will give it a go. After all, it is open source and we would love to see contributions refining the functionality, now that there is a base to build from.
Any feed back is welcome, let us know if it works or not in your setup!
