As we have written about before we moved to a new office last month. One of the major reasons was the need for a bigger flight lab. This will enable us to do better testing and improve how we can develop things, especially our positioning solutions. Even though it is not a huge place, going from 4x4x3m to 8x8x3.5m and possibly 13x9x3.5m, is a great improvement for us. We call this great playground for the Arena as this is what it feels like for us :-). Very soon we hope to have our Qualisys MoCap system, Lighthouse and the Loco positioning running, maybe even at the same time.
The Arena
As a bonus this is a great pace to play HTC Vive VR games, we just need to get the wireless transmitter so we can make full use of the space!
Today we received a bunch of MoCap marker decks which means they are now available in our shop. This is a handy deck for those that flies in a motion capture system as it is easy to create different configurations and move between Crazyflies.
The deck is designed in collaboration with Qualisys. We suggest using 6.5mm, 8mm or 9.5mm diameter reflective motion capture markers. Currently we don’t offer the markers but soon we will also offer a bundle together with markers.
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!
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!
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.
The post this week is going to be a bit more about ‘how we work’. In our daily work we often have to solve problems that are not directly technical, though we tend to solve them in a technical way. Our new automated printing system is an example of that.
Last year we have started our own e-shop to be able to sell our products by ourselves. At first we used an external warehouse which ended up causing a lot of problem so we decided to have all stock for our e-shop in our office and started shipping from Sweden. Part of the plan was to make the shipping process as efficient as possible to understand what it takes to handle stock and shipping worldwide. The latest addition is an automated printing system.
When you order in the Bitcraze store, the order is sent to a system we made to handle stock and production. In the morning, one of us will log-in in this system and start handling the orders of the night. The system is generating all documents and ordering shipping for the order, this means that all we have to do is to print the picking list and all required documentation, put the products in a box and stick all the document on the box. This level of automation was already saving us a lot of time but we still had to print manually the right amount of every required document.
We now have a Raspberry-pi connected to all the printers. A program (written in Rust, because I want to experiment with the language :) connects the management system using WebSocket and waits for a print order. When we connect to the management system we just have to click ‘print’ on the next order to get all the required instructions and documents printed, ready to use.
We are still not sure we will keep shipping from the office in the long run, but making it as efficient as possible allows us to ensure good quality and high flexibility. This kind of project is also a good excuse to play with various technologies.
