Last week we posted about painting with the Lighthouse deck. This week we continue on the same track but add a new dimension, all in our “let’s try this crazy idea” spirit. So last Friday, after having a lot of fun painting with the Crazyflie led-ring using long exposure photo and the Lightouse deck for positioning, we had one extra crazy idea. Can we use the Crazyflie to show a raster image, very much like the way a CRT monitor works by sweeping line by line and displaying the pixel color one by one, using the led-ring? Unfortunate we did not have enough time that day…
However the idea was so intriguing that Kristoffer couldn’t stop himself from writing a prototype script during the week-end. So last Monday, just after publishing the blog post, we went to the flight arena and tried it. After a couple of trial and error we found a display algorithm that showed a pretty good result:
Crazy-Lisa
The source for this image is this very low resolution Mona Lisa:
It was a very fun experiment, it is magic to see the Crazyflie going back and forth blinking for ~3 minutes, click on the camera and see the resulting picture. It is also a really nice way to observe the current state of the lighthouse positioning. The lines are spaced by about 3 cm and the Crazyflie is controlled using the PID controller. The controller do a decent job of keeping the Crazyflie in lines and the space seems a little bit ’tilted’.
As a side note, we will be exhibiting at the ICRA 2019 conference May 20-24, 2019 in Montreal, Canada. We will running demo of the LPS and Lighthouse (though I am not sure we can print long exposure picture, this is not so exciting to look in real-time :). We hope you would like to come and meet us there!
Last week we blogged about the early release version of the lighthouse deck and showed a nice push-around demo of the Crazyflies using the Vive controller. Now we wanted to push the system even further, by making a Lighthouse Painting!
We started by adding a LED-ring deck on the bottom of the CrazyFlie 2.1 with the lighthouse deck attached to the top. We were able to access the input of the track pad of the Vive controller and link it to a specific color / hue value. The LED ring can display any color possible in the RGB range, so in theory, you could paint in whatever color you like. For now, the brightness was fixed, but this could be easily added to the demo script as well.
To capture the light trace, we needed to make a long-exposure image, therefore, the flight arena need to stay completely dark. Luckily, this was easy to do for us since we do not have any windows in our new testing arena. Our camera is the Canon D5600 with a manually controlled shutter time setting selected (press to open the shutter and press again to close the shutter). The aperture setting was set at F-22. Nevertheless, this is very depended on the environment, so we had to do some trial-and-error in order to get this parameter right.
Aperture too wide… perfect!
Once we had the set-up finished, we made several long exposure photo paintings with one person controlling the camera and another painting the picture into thin air. Of course, the artist would need to imagine its creation, as we were not able to see the result until after the picture was taken. Also, big gestures were required in order to complete the painting, as the Crazyflie’s and the Vive controller’s movements were synced 1:1, so adding some multiplication factor would come in handy. Nonetheless, the results were amazing.
Some nice examples of a single crazyflie flying based on the Vive’s position, changing color based on the trackpad
We took it even further, by making the Crazyflie fly a predefined trajectory and planned color scheme without the Vive controller. First, it flew three concentric circles in green, red and blue with the high level commander with the PID controller setting. But, the circles would probably be closed-off more properly with the Mellinger controller setting. We also were able to reproduce the Bitcraze logo in the same fashion. In both long-exposure photos, it still possible to see the Crazyflie, as it is still traceable due to its routine LED functionality, so you can easily observe where it took off, and where it flew in between shapes.
The Crazyflie flying a predefined trajectory in several shapes
The demo python scripts of the above flights can be found here:
An we also took a video of the Bitcraze logo being drawn. The mobile phone camera had some problems focusing in the dark, but it gives a good idea of how things works:
The lighthouse deck allows the Crazyflie to estimate its position using the HTC Vive tracking base-station normally used for Virtual Reality. The positioning is done by tracking the timing of rotating infra-red laser beams emitted from the base-stations. This system has the advantages of having a very good precision and of allowing the Crazyflie to acquire its position autonomously: once the Crazyflie knows the position and orientation of the base-station, it can calculate its own position without the help of any external systems.
The release as Early Access means that we have finished the hardware and we are confident that the hardware is working properly. Though we have not yet finished all the software and firmware, by releasing the hardware early we can get the hardware into the hands of users quickly to try it out. In return we hope we can get some help making the software better.
Current state
The Crazyflie can calculate its position from the received Vive Base-Station V1 signals.
Direct line of sight should be kept to both base-stations. The Lighthouse deck has 4 receivers so in the future it will be possible to get a position from seeing only one base station.
Base-Station V2 support is still being worked-on, it will only require a software update.
The Base-station position is hard-coded in the Crazyflie and found using SteamVR. Ideally this should be sent from the ground and the Crazyflie should calculate the positions of the Base-Stations automatically.
The previous point means that a full VR system or at least two base stations and a controller or tracker is required to setup the system. In the future we hope to setup the system with only a Crazyflie and two base stations.
Since this version of the deck only has horizontal sensors, it is important that the base-stations are placed above the flight space and the Crazyflies should fly ~40cm bellow the base-stations
As long as the deck is in early access, the main documentation will be the lighthouse positioning page in the wiki. This page is going to be updated a lot in the near future and will track the progress in development.
Demo
We have written a small demo script that allows to set the position of the Crazyflie using a Vive controller. It is a good demo to experiment with the precision of the system and the ability to mix VR and Crazyflie since they are in the same tracking space:
In this demo, a python script connects to two Crazyflies and acquire the controller position using OpenVR and makes the Crazyflies take-off above the controller. Then, when the controller trigger is pushed, the setpoint to the closest Crazyflie is changed to follow the controller movement, the Crazyflies are flying autonomously only getting position setpoints from the python script. The position estimation and control is handled onboard.
We are pretty excited by this release since we think this positioning technology will be very useful for a lot of use-case. Let us know what you think and do not hesitate to contribute if you want to improve the system :).
Last week was busy at Bitcraze as we moved to our new office. We packed all our tools, equipment, toys, components, stock and other bits and pieces into boxes and on Tuesday the moving truck came to pick it all up. Everything was very smooth and by lunch all the stuff had been unloaded in the new office.
Office work
Until now we have had our offices at various co-working spaces, but this time we rent a “real” office. We get a lot of more space that fits our needs better (a flight lab!) but the drawback is that we have to buy a lot of stuff that was part of the package earlier, such as furniture, printer, network, fire extinguishers, coffee brewer and lots of other things.
Painting Bitcraze green wall
We spent most of last week unpacking, buying stuff, painting and installing and we are in pretty good shape now. There are still a lot to do but the most important functionality is up and running. We even managed to ship orders in the store every day except Tuesday when we moved.
This week we have a guest blog post from Javier Burgués. Enjoy!
I would like to introduce you a rather unknown application of the CrazyFlie 2.0 (CF2): chemical sensing. Due to its small form-factor, the CF2 is an ideal platform for carrying out gas sensing missions in hazardous environments inaccessible to terrestrial robots and bigger drones. For example, searching for victims and hazardous gas leaks inside pockets that form within the wreckage of collapsed buildings in the aftermath of an earthquake or explosion.
To evaluate the suitability of the CF2 for these tasks, I developed a custom deck, named the MOX deck, to interface two metal oxide semiconductor (MOX) gas sensors to the CF2. Then, I performed experiments in a large indoor environment (160 m2) with a gas source placed in challenging positions for the drone, for example hidden in the ceiling of the room or inside a power outlet box. From the measurements collected in motion (i.e. without stopping) along a predefined 3D sweeping path that takes around 3 minutes, the CF2 builds a map of the gas distribution and identifies the most likely source location with high accuracy.
1. MOX deck
The MOX deck (Fig. 1a) contains two sockets for 4-pin Taguchi-type (TGS) gas sensors, a temperature/humidity sensor (SHT25, Sensirion AG), a dual-channel digital potentiometer (AD5242BRUZ1M, Analog Devices, and two MOSFET p-type transistors (NX2301P, NEXPERIA). I used TGS 8100 sensors (Figaro Engineering) due to its compatibility with 3.0 V logic, power consumption of only 15 mW (the lowest in the market as of June 2016) and miniaturized form factor (MEMS). Since the sensor heater uses 1.8V, two transistors (one per sensor) reduce the applied power by means of pulse width modulation (PWM). The MOX read-out circuit (Fig. 1b) is a voltage divider connected to the μC’s analog-to-digital converter (ADC). The voltage divider is powered at 3.0 V and the load resistor (RL) can be set dynamically by the potentiometer (from 60 Ω to 1 MΩ in steps of 3.9 kΩ). Dynamic configuration of the load resistor is important in MOX gas sensors due to the large dynamic range of the sensor resistance (several orders of magnitude) when exposed to different gas concentrations. The sensors were calibrated (by exposing them to several known concentrations) to convert the raw output into parts-per-million (ppm) concentration units.
Figure 1. (a) MOX deck (without gas sensors); (b) Schematic of the conditioning electronics for each MOX sensor.
The initialization task of the deck driver configures the PWM, initializes the SHT25 sensor, sets the wiper position of both channels of the potentiometer and adds the MOX readout registers to the list of variables that are continuously logged and transmitted to the base station. The main task of the deck driver reads the MOX sensor output voltage and the temperature/humidity values from the SHT25 and sends them to the ground station at 10 Hz.
2. Experimental Arena, External Localization System and Gas Source
Experiments were performed in a large robotics laboratory (160 m2 × 2.7 m height) at Örebro University (Sweden). The laboratory is divided into three connected areas (R1–R3) of 132 m2 and a contiguous room (R4) of 28 m2 (Fig. 2). To obtain the 3D position of the drone, I used the Loco positioning system (LPS) from Bitcraze, based on ultra-wide band (UWB) radio transmitters. Six LPS anchors were positioned in known locations of the experimental arena and one LPS tag was fixed to the drone. The six LPS anchors were placed in the central area of the laboratory, shaped in two inverted triangles (below and above the flight area).
Figure 2. Experimental arena. The green squares indicate the position of the UWB anchors, which are positioned along two inverted triangles (green lines).
Figure 3. The CrazyFlie 2.0 equipped with the MOX deck and the UWB tag (center) gets its 3D position from the LPS system (left). The location and sensor data are communicated to the ground station (right) over the 2.4 GHz ISM band.
A gas leak was emulated by placing a small beaker filled with 200 mL of ethanol 96% in different locations of the arena (Fig. 4). Ethanol was used because it is non-toxic and easily detectable by MOX sensors. Two experiments were carried out to check the viability of the proposed system for gas source localization and mapping in complex environments. In the first experiment, the gas source was placed on top of a table (height = 1 m) in the small room (R4). In the second experiment, the source was placed inside the suspended ceiling (height = 2.7 m) near the entrance to the lab (R1). Since the piping system of the lab runs through the suspended ceiling, the gas source could represent a leak in one of the pipes. A 12 V DC fan (Model: AD0612HB-A70GL, ADDA Corp., Taiwan) was placed behind the beaker to facilitate dispersion of the chemicals in the environment, creating a plume. The experiments started five minutes after setting up the source and turning on the DC fan.
Figure 4. Gas source location in two experiments. (left) Experiment 1: inside small room; (right) Experiment 2: hidden in suspended ceiling.
3. Navigation strategy
The drone was sent to fly along a predefined sweeping path consisting of two 2D rectangular sweepings at different heights (0.9 m and 1.8 m), collecting measurements in motion (Fig. 5). These two heights divide the vertical space of the lab in three parts of equal size. Flying first at a lower altitude minimizes the impact of the propellers’ downwash in the gas distribution. For safety reasons, the trajectory was designed to ensure enough clearance around obstacles and walls, and people working inside the laboratory were told to remain in their seats during the experiments. The ground station communicates the flight path to the drone as a sequence of (x,y,z) waypoints, with a target flight speed of 1.0 m/s. The CF2 reports the measured concentration and its location to the ground station every 100 ms.
Figure 5. Predefined navigation strategy based on zig-zag sweeping at two heights (0.9 and 1.8 m).
At the end of the exploration, the ground station uses all the received information to compute a 3D map of the instantaneous concentration and the ’bouts’. A ’bout’ is declared when the derivative of the sensor response exceeds a certain threshold. Bouts are produced by contact with individual gas patches and some authors use them instead of the instantaneous response (which is more affected by the slow response time of chemical sensors). For gas source localization, we compare two approaches: using the cell with maximum value in the concentration map or using the cell with maximum bout frequency. The bout frequency (bouts/min) is computed as the bout count in a 5 second sliding window multiplied by 12 (to convert it to bouts/min).
4. Results
In the first experiment, the drone took off near the entrance of the lab (R1), 17 meters downwind of a gas source located in the other end of the laboratory (R4). From the gas distribution map (Fig. 6a) it is evident that the gas source must be in R4, because the maximum concentration (35 ppm) was found there while concentrations below 5 ppm were measured in the rest of the lab. The gas plume can be outlined from the location of odor hits. The highest odor hit density (25 hits/min) was found also in R4. The cells corresponding to the maximum concentration (green start) and maximum odor hit frequency (blue triangle) were found at 0.94 and 1.16 m of the true source location, respectively.
Figure 6a. 2D map of the instantaneous concentration (ppm) measured in Experiment 1 (in log scale). The odor hits are represented by blue circles. A hand-drawn ellipse outlines the approximate plume shape based on the location of odor hits.
Figure 6b. (top) Trajectory of the CF2 along the z-axis. (bottom) Temporal evolution of the measured concentration (ppm) on a log scale, with odor hits highlighted in red (the black star indicates the start of an odor hit). The identifiers R1–R4 indicate the area of the map in which the drone is flying at each moment. The maximum instantaneous concentration and the maximum odor hit frequency are indicated by a green star and a blue triangle, respectively.
In the second experiment, the gas source was located just above the starting point of the exploration, hidden in the suspended ceiling (Fig. 7). The resulting maximum concentration in the test room was measured when the drone flew at h=1.8 m, highlighting the importance of sampling in 3D for localization and mapping of elevated gas sources. However, since the source is presumably not directly exposed to the environment, concentrations below 3 ppm were found in most locations of the room, which complicates the gas source localization task. The concentration and odor hit maps suggest that the gas source is located in the division between R1 and R2, which represents a localization error of 4.0 and 3.31 m, respectively.
Figure 7. 3D map of the instantaneous concentration (ppm) in Experiment 2. The black square indicates the gas source location (x,y,z) = (14.0, 5.2, 2.7) m, the black arrow the wind direction (positive x-axis) and the letter ‘S’ the starting point of the drone (x,y,z) = (13.5, 5.2, 0.0) m.
5. Conclusions
These results suggest that the CF2 can be used for gas source localization and mapping in large indoor environments. In contrast to previous works in which long measurement times were taken at predefined or adaptively chosen sampling locations, a rough approximation of such maps can be obtained in very short time with concentration measurements acquired in motion. The obtained gas distribution maps seem coherent with respect to the true source location and wind direction, and not only enable the detection of the source with relatively small localization errors but also provide a rich visual interpretation of the gas distribution.
If you are interested in more details about this work, take a look at the journal paper or drop me an email at <jburgues8 at gmail dot com> or leave a comment on the blog!
The Crazyflie 2.0 was released almost 4 years ago now. When we released it we wanted to avoid limiting our users in hardware. We over-designed it with lots of features and power we weren’t using at the time of release. We also put in the deck connector so we could keep users updated with new hardware without having to replace their Crazyflies.
Over the years there’s been thousands of users and lots of feedback on the product. Most of it great, but there’s of course also been issues that needed to be addressed. The original design concept is still working with new decks coming out and still free CPU cycles, flash and RAM. So instead of major updates we decided to focus on fixing the issues we’ve seen while keeping backwards compatibility for our users.
So today we’re really excited to announce we’ve released the Crazyflie 2.1! The updated version of the Crazyflie brings improved flight performance, better durability and improved radio stability.
Here’s a list of the updates:
Better radio performance and external antenna support: With a new radio power amplifier we’ve improved the link quality and added support for dual antennas (on-board chip antenna and external antenna via u.FL connector)
Better power button: We’ve gotten feedback that the power button breaks too easily, so now we’ve replaced with a more sturdy alternative.
Improved battery cable fastening: To avoid weakening of the cables over time they now run through a cable relief.
Improved sensors: To make the flight performance better we’ve upgrade the IMU and pressure sensor. The new Crazyflie uses the drone specialized sensor combo BMI088 and BMP388 by Bosch Sensortech. It lowers drift and avoids accelerometer saturation which makes the IMU more “trustable”.
It’s important to note that the Crazyflie 2.1 is a drop-in replacement for the Crazyflie 2.0. All spare parts and decks are compatible with both the Crazyflie 2.0 and the 2.1.
We even took it so far that the same binary can be flashed on the Crazyflie 2.0 and 2.1 without any special care. The binary will automatically activate the right drivers which means working with mixed groups of 2.0 and 2.1 isn’t a hassle.
When releasing the Crazyflie 2.1 we’ve also updated all the bundles to contain the new version. But even though you can’t get the bundles with the Crazyflie 2.0, there’s still some Crazyflie 2.0 units left from the last batch that can be purchased in the E-store.
We are glad to announce that we have manufactured the fist batch of Lightouse positioning decks and hopefully it will be ready to ship by the end of the month!
The Lighthouse positioning deck is a Crazyflie 2 deck capable of receiving IR signals from HTC Vive tracking base station (ie. Lighthouses). The basestations works by spinning IR laser beams that are received by the deck to measure the angle at which the base station sees the receiver. This allows the Crazyflie to estimate its position with great accuracy and so to fly autonomously.
The board we produced is very similar architecture-wise to the prototype we showed in previous blog posts. The main physical difference is that we now only have horizontal receivers. This change was made because we do not yet have a satisfactory mechanical solution to mount vertical IR receivers and we arbitrated that horizontal-only sensor already provides great performance for autonomous flight. Functionally it means that the Crazyflie should fly bellow the base stations to be able to position itself, we found that flying ~40cm bellow the base station gave good flying performance. We will continue looking at solution to make a deck with more receiver to increase the flight space in the future.
The lighthouse deck acquires the IR pulses transmitted by the lighthouses, the Crazyflie can then interpret these pulses to estimate its position. We also added soldering pads for a 2.54mm pin header which would allow to interface other microcontroller boards to the deck:
Lighthouse deck architecture
HTC has released 2 versions of the base stations that are incompatible with each other. Version 1 supports 2 base stations per system, and version 2 can support more than 2. We have good initial support for version 1 both in the deck and in the Crazyflie. Version 2 is currently being worked-on but early work shows that the deck should be compatible with version 2 with only a firmware update.
This leads to the current state of the product. The boards have been manufactured and we have received them but they are currently programmed with a test firmware. As previously stated the basic functionality is there but we still don’t have any finished bootloader. As soon as this is finished and tested we will start flashing all the boards. After that is is just a matter of adding them to the web-store stock and they will be ready to ship!
For now we consider this deck as early access, which means that we will document it in the wiki and that the software will still be heavily developed. For example an early limitation that will be worked-on is that it is currently required to run SteamVR on a computer to setup the system, this means that you need to have a full Vive VR setup or at least a vive gamepad or tracker to setup your flight space. Eventually we want to make it possible to setup the system with only base stations and a Crazyflie, without using steamVR.
We have added the deck to our web store so that you can subscribe to get notified as soon as it is in stock, we will of course post on the blog with more informations when this happens. In the mean time we can share again the video we did for the holidays that was made with 3 Crazyflie 2.1 equipped with the lighthouse deck using 2 V1 base stations:
We currently have our office at The Ground, a co-working space for startups. It has been three fantastic years at The Ground, with lots of awesome people around and we have had a great time, but space is limited and we are now moving on to our own office. We have found a great place where we will not only get more office space, we will also finally have our own dedicated flight lab!
The flight lab
We hope the flight lab will be a useful tool for future quad copters and positioning systems, and we think it will speed up the development process and help us create even better products.
We will move to the new office February 25, stay tuned for more information.
Björn is leaving Bitcraze
We are sad to announce that Björn is leaving the company. Björn has been involved in film making on his spare time and has now decided to explore this world full time. He has been a much valued colleague and he will be missed, but we are at the same time excited on behalf of him and hope for a bright film future!
While Crazyflie is nowaday mostly used connected to a computer, we have mobile clients that can be used to fly a Crazyflie using either Bluetooth Low Energy or a Crazyradio with an Android device or an iphone.
The Android client is currently the most advanced one with support for some decks. The goal of these mobile clients is to at least allow to fly a Crazyflie manually, though a lot more could be done by supporting the various decks of the Crazyflie (for example using the flow deck, one might imagine drawing a trajectory on the phone and having the Crazyflie following it :-).
As for development, we have not been very active in the development of the mobile clients and are relying mostly on contributions. So if you are interested into adding functionalities do not hesitate to drop by the Github page of the Android or iOS clients and to propose functionalities and pull requests.
Android client
In 2018, Fred the maintainer of the Android client, has worked hard to stabilize the current app and solve the last few bugs and problem in the current app. A new version was released last week that incorporate all the fixes.
Last years the Android client has seen big internal changes including separating all Crazyflie protocol handling in a separate java library. All these changes will make it easier to implement new functionality in the future and to make the functionality available to android as well as, to any Java program using the Crazyflie java lib.
Iphone client
The iPhone client has seen much less activity in 2018. It has been kept updated with the new versionsd of the Swift language and have seen some bugfixes, all thanks to Github contributors.
There have been reports of a couple of pretty bad bugs that have appeared in the latest release, as soon as these bugs are fixed we plan to release a new version of the iPhone client. The new version will also include the possibility to control the Crazyflie by tilting the phone, and with the bug fixes in place we should be off for a good start of 2019.
Windows client
The Windows UAP Crazyflie client is the least advance of all the mobile Clients. It has the particularity to work on Windows 10 for computers as well as for Phones. This makes it the only implementation of a Bluetooth low energy Crazyflie client for computers. However, Windows 10 for phones being pretty much dead now, the future of this client might be more on the Computer side if any.
Anyway, if anyone is interested in improving the Windows client, we will gladly test and merge pull requests when they come.
We are happy to announce that the Roadrunner soon will be available in our store. The Roadrunner is an Ultra Wide Band (UWB) tag that can be used to acquire the position of any robot or object in a Loco Positioning System, which makes the LPS work with more than the Crazyflie.
The Roadrunner
The Roadrunner started out as a joint project with a customer that wanted to track go-karts on a track, but we think it should be equally useful for tracking any robot or vehicle indoors. It is essentially a Crazyflie 2.1 with an integrated LPS deck, but stripped of all quadcopter stuff, all in a nice package. It can be interfaced through the Crazyradio and USB, but also through a UART if needed. It can be powered with anything between 4 – 17V. Since it is based on the Crazyflie 2.1 platform, all tools, libraries and clients are compatible. It also has the same expansion port which makes it compatible with existing decks and can be extended with custom hardware.
You might be curious about the name we choose? We usually name internal projects after birds and what could be a better name for tracking a car than the Roadrunner? We liked the name and decided to stick to it when releasing it as a product.
We release the Roadrunner as an Early access product since we are a bit uncertain of how it will be used. We hope to get feedback from anyone using it and improve the design if needed.
This is also the first product to be released based on our new platform concept. We will release a number of new hardware designs in the near future and the platform concept is intended to simplify managing and building firmware binaries for the different hardware configurations.
On a side note, Arnaud from Bitcraze and Fred, the maintainer of the Crazyflie android client, will be visiting FOSDEM 2019 in Brussels at the end of the month. If you want to meet us there just ping us in the comment, by mail, on twitter or on the forum.
