Raspberry Pi Zero power deck

2018-08-20 | Tobias | 7 Comments

Ever since the Raspberry-pi zero was released we wanted to find-out what it would take to fly one with the Crazyflie 2.0. One immediate issue is the size and weight of the R-Pi-Zero. It is just a bit to big and heavy to make it work without modifying the Crazyflie 2.0. Also it requires 5V power which is something the Crazyflie 2.0 doesn’t provide if USB isn’t connected. Actually the R-Pi-Zero works well down to ~3.6V but this is still too high to reliably run directly from a single LiPo cell. So to begin with we created a Raspberry Pi Zero power deck. It is reusing the same step-up/step-down (STBB1) as used on the LED-ring to make things simple and the output is set to 3.8V. Other than that the UART and the I2C interfaced has been connected so that the raspberry pi zero could control the Crazyflie.

The raspberry pi zero would then be soldered to the deck with 0.1″ header pins. The result can be seen below and the power part works well. We chose to solder the deck header pins to the deck, instead of using the female deck connectors, to make it more sturdy. Another thing we did was fitting a Pi-camera using a 3D printed mounting bracket we designed. We think this is one of the interesting use cases, to run computer vision or maybe neural networks :-).

Well unfortunately this only solves the first part, powering the R-Pi-Zero from the Crazyflie 2.0. Next step will be to modify the Crazyflie 2.0 with bigger motors/props so that is can carry it for a decent time. So story to be continued…

Crazyflie RZR control board progress

2018-08-06 | Arnaud | Leave a comment

We have been thinking for a while about making a Crazyflie control board that could be used to make a bigger quadcopter using the Crazyflie firmware and deck. This idea has materialized in the Crazyflie RZR project.

The Crazyflie RZR is a quadcopter controller board based on the Crazyflie design, as pointed if our previous blog post, it is intending to bring the strength of the CF2 but in a little bit bigger package :-). It runs the Crazyflie firmware and feature the Crazyflie 2.0 deck port. It is capable of driving brush-less motor controller and has an uFL port for an external 2.4GHz antenna. It also contains the new quadcopter-optimized Bosch BMI088 IMU. We have made some progress lately on the Crazyflie RZR, we have just got the first initial sample from the manufacturer shown in the picture above.

We are not sure yet when the RZR will be in the shop, but the project is definitely going forward. We will keep posting information about the project as it develop.

Lighthouse prototype deck development

2018-07-30 | Arnaud | 4 Comments

We already wrote in a previous blog post that we where working on a Lighthouse positioning receiver deck for the Crazyflie 2.0. In this post we will describe a bit what has been the development process so far for this deck as it is an example of how to develop with the Crazyflie. Basically, our way of working often is to try to get one things working after another, this is what we have done here: we start from a hack and then we replace hardware and software pieces one after the other to make sure we always have one half (hardware of software) we can relie on.

The lighthouse deck started as a Fun Friday project, and as such we usually want to hack something together to see if the idea can work. So I looked around the web to get some information as of how to receive the lighthouse positioning signals and decode it. I found the vive-diy-position-sensor GitHub project by ashtuchkin. The project describe the schematic and contains the software for a Teensy board to receive a lighthouse 1.0 signal and calculate the position of the receiver. I went forward and cabled the circuit on a Crazyflie prototyping deck and attached a Teensy board to another prototyping deck. The idea is to install these two board above and bellow a Crazyflie:

Discreet-component Lighthouse receiver

Teensy to decode the lighthouse signals

The signal from the lighthouse receiver goes to the Teensy, then the serial port of the Teensy is connected to the serial port of the Crazyflie. As a first approach the Teensy was configured and we could get the position data using the Teensy USB port. When everything was working correctly I could implement a small deck driver in the Crazyflie to receive the position and push it in the Kalman filter. This way I could get a Crazyflie 2.0 flying in lighthouse with minimal firmware work.

The obvious next step was to get rid of the Teensy, this was done by implementing the lighthouse pulse acquisition and interpretation in the Crazyflie. Once that was done, we could make our own deck. Instead of using op-amp we used the official receiving chip available at this time, the TS3633:

First lighthouse receiving deck prototype

This board implements up to two receiver which would allow to get the orientation as well as the Position of Crazyflie. Due to questionable soldering only one receiver has ever worked but the prototype was useful to test the concept anyway, one of the lesson learned is that the receiving angle of the two flat is not big enough to fly very high, with the two lighthouse base station near the ceiling we could only fly up to ~1.5m before loosing the signal. We would need a microcontroller or other chip capable of acquiring the signals on the deck since the Crazyflie 2.0 deck port only has two input capable of acquiring the pulses.

At this point informations about Lighthouse 2.0, the next version of Lighthouse tracking that will allow to cover much bigger area, started appearing on the internet and a new receiver chip was release to receive the signal, the TS4231. One big difference was that Lighthouse 2.0 would transmit data in the laser carrier. The data transmitted are in the range of 1 to 10MHz dixit the TS4231 datasheet so it makes them impractical to acquire with a microcontroller. This gives us a perfect opportunity to play with the iCE40 FPGA and the icestorm open-source toolchain that has just been release.

The result is a deck containing enough receiver to cover a much bigger flying space and an iCE40UP5K FPGA to acquire the signals sent by the lighthouse. There is already two prototype of this design: one without SPI flash, so the Crazyflie would have to embed the FPGA configuration bitstream and program it at startup and the latest one has an SPI flash so the deck can start by itself:

First FPGA-Based lighthouse deck prototype

Partially populated second FPGA-Based lighthouse deck prototype, now with SPI flash

As a first approach the FPGA will acquire the Lighthouse 1 pulses and send the raw timing via a serial port to the Crazyflie. The Crazyflie can then decode and interpret the pulse. I am currently playing with the idea of maybe running a picorv32 Risc-V 32 bits CPU core in the deck, this will allow to acquire and interpret the pulses in the deck and send angles to the Crazyflie, this would greatly lighten the processing load on the Crazyflie 2.0. Eventually this FPGA should be able to acquire and decode the Lighthouse 2.0 signals.

This is very much work in progress and we will write more about the Lighthouse deck when we have further results.

Bitcraze at iROS 2018 in Madrid

2018-07-23 | Arnaud | Leave a comment

Last week we received the visit of Wolfgang from USC, he is the creator of the Crazyswarm project. It was great to have him here at the office. One of the subject of discussion was to prepare a demo for iROS 2018 on October 1-5 2018 in Madrid.

We will be in booth 91, if you are attending iROS 2018 feel free to pass-by and say hello. We are planning a couple of demos:

Crazyswarm with at least 6 Crazyflies flying in a Qualisys mocap system.
Running a fully autonomous Crazyflie with the Loco Positioning System.
Hopefully, some demo of autonomous flight using the lighthouse positioning. This is still not fully working but I have at least 2 full months to get something flying :-).

If you would like to see us demo anything more/else tell us in the comments and we will see if we can setup something.

We used Wolfgang’s visit to finalise the Qualisys support for Crazyswarm. It is now pushed and documented, this means that if you have a Qualisys system and a couple of Crazyflies you can now fly them autonomously using the Crazyswarm framework. It also means that we now have Crazyswarm up and running flawlessly at the office, it will help us testing related pull-request and supporting advanced functionality like the high-level-commander in the Crazyflie python lib.

As a side note, Bitcraze is spread very thin these weeks since most of us are in vacation (I am basically alone). We usually miss one Monday post per year, it was last week and the Wolfgang visit is my excuse :-). Sorry in advance if there is any delay to answer mail, forum or other requests. From next week, the rest of the team will slowly start to come back.

Lighthouse positioning for Crazyflie

2018-06-25 | Arnaud | 3 Comments

A while ago we bought an HTC Vive for the Bitcraze office. This was partly for having fun with VR, but is was mostly because we had hope to use the vive tracking system with the Crazyflie. We are making progress with the idea and we just received our latest prototype:

The Lighthouse tracking system is the hardware component of steamvr tracking, it is used by the HTC vive to get the full position and orientation of the Vive VR head mounted display and game controllers. It has sub-millimeter precision and low latency, which is key to achieve immersive VR experience. The system works by having base-stations installed in the room. The base station sweeps two rotating infrared laser planes. A receiver is basically a photodiode, by detecting when the photodiode is hit by the sweeping lasers, the receiver can measure at which angle it is seen by the base station. With enough receivers and/or base-stations, it is possible to calculate the receiver position and orientation. If you want to read more about how lighthouse works, there has been awesome work of reverse engineering and documentation made by the open-source community.

As far as Crazyflie is concerned the lighthouse system has one major advantage: the position and orientation can be calculate in the tracked object which means that the Crazyflie can be completely autonomous and there is no limit in the number of Crazyflies that can be tracked at the same time.

Lighthouse has been my fun-Friday project for a couple of month and the early results are very encouraging.This is still very much work in progress, so stay tuned for future blog-posts about the subject :-).

A[nother] french in Malmö

2018-06-18 | Benjamin Kuperberg | Leave a comment

Malmö is known to be very beautiful in June. At least that’s what i’ve heard from the Bitcraze team when we talked about having a meet-n-geek in their offices in Sweden.

I’ve been working on the crazyflies and developing artist friendly interface to control them for a year now, and I always was impressed with their philosophy of work and communication. Over the past year, they’ve helped me and my companies a lot to be able to create the shows we want, with our specific needs and constraints, that researchers don’t have, like fast installation time, or confidence in drone take off (you want to make sure that a drone won’t hit the theater’s director’s head at the very beginning of the show !).

For that I created LaMoucheFolle, which is an open-source software with a nice UI to be able to connect, monitor and control multiple drones. LaMoucheFolle is not made to be a flight controller, but acts more as a server that any software will be able to use, like Unity or Chataigne. That way, people and users don’t need to handle all the connection, feedback, warning, calibration process and can concentrate essentially on the flight and interaction.
While the fist version of LaMoucheFolle got me through most of the demos and workshops, I knew that it could be vastly improved if I understood better the drones, so I decided to ask the creators to meet them, and here I am !

As I hoped, being physically there allowed me to understand better what are their practices, and allowed them to better understand mine, so we could find a way to improve both their Crazyflie ecosystem and my contribution to it.

So I refactored, redesigned and improved LaMoucheFolle to a (soon to be released) V2, featuring :
– New drone manager interface with a more intuitive feedback of the drones
– New multi-threaded drone communication mechanism
– New state-safe sequenced initialization and flight control of the drone, with a progressive take-off vastly increasing its stability
– Unity demo app and Chataigne demo session to show how to control from other softwares via OSC

While developping the new version and talking to the team, some key features and improvements for the use Crazyflies in shows were discussed and some of them are now in research/development :
– Health analysis : using the accelerometer’s data and Tobias’ magic brain, it allows to test the motors while the drone is on ground and find out if one or more are problematic (too much or not enough vibration, meaning either the propeller or the motor needs to be repaired/replaced)
– Battery analysis : when the battery is fully charged, this allows to have an automated motor sequence which will find out if the battery has an abnormal discharge behavior
– Steath mode : Shut down all the system leds (the 4 builtin leds on the drone) so it can be invisible, ninja-style
– Normalized battery level and low battery log values : it allows for safe and consistent feedback of the battery level in percent, and an indicator if the drone should land soon. It will also possible to use this value to monitor the charging progression of a drone.
– LedRing fade pattern : This mode allows for easy fading between solid colors on the led ring, so it’s not necessary to stream all the colors from one color to another, but instead having a very beautiful smooth interpolation, using only 2 parameters : the target color and the fade time.

I hope you are as excited as I am about those new features, and if you’re not, please tell us what would make you “vibrate” !

I’ve been spending the last week at their office, and it was a great week : I initially came to improve my software, and discuss about future development of the Crazyflies [which was great], but what i’ll remember the most from this trip is by far the human aspect of the Bitcraze team.
Marcus, Kristoffer, Tobias, Björn and Arnaud are amazing and i’m really happy to have had the chance to see them working, and collaborate with them. I admire their choices of being fully transparent on their work and amongst themselves, and there is a natural kindness mixed to the passion for their project that makes working there feel like everyday’s special. Also, Malmö is very beautiful indeed :)

Thank you very much and I hope to reiterate the experience soon,

Skål

MoCap deck

2018-06-11 | Tobias | 9 Comments

The Crazyflie 2.0 has been flyable in MoCap systems such as Qualisys, Vicon or Optitrack for quite a while thanks to the Crazyswarm project. For the MoCap systems to be able to track the Crazyflie it needs to be fitted with reflective markers. These can be attached on e.g the motor mounts which in some cases might be the best solution, however we also liked the idea of creating a deck where the markers easily can be attached and in many, repeatable configurations, that is why we created the Mocap deck. This deck is now soon to be released but before we start manufacturing it would be great to get some feedback.

The deck has M3 sized holes which is spaced on a 5mm grid. The deck also has footprints for two optional push buttons that can be used to e.g. trigger a take-off or start of a demo. And as the battery holder deck, which has no electronics, so this can be mounted upside down for better fitting of the markers, if the buttons aren’t mounted of course.

We are collaborating with Qualisys, also based in Sweden (in Gothenburg), to make the Crazyflie more moCap friendly and make it easy to use together with the Qualisys system as well as other mocap systems. Qualisys will provide the markers for the moCap deck.

Qualisys and Bitcraze are exhibiting together at IROS in Madrid where we will show some awesome demos with a moCap system as well as other position technologies and we are also hoping to fly a Crazyswarm. We will publish more information when we get closer to the conference.

TDoA 3 progress

2018-05-28 | Kristoffer Richardsson | Leave a comment

We have now worked a few weeks on the new TDoA 3 mode for the Loco Positioning System. We are happy with the results so far and think we managed to do what we aimed for: removing the single point of failure in anchor 0 and supporting many anchors as well as larger spaces.

We finished off last week by setting up a system with 20 anchors covering two rooms down in the lunch area of the office. We managed to fly a scripted autonomous flight between two rooms.

Work so far on the anchors

Messages from the anchors are now transmitted at random times, which removes the dependency on anchor 0 that used to act as a master that all other anchors were synchronized to. The drawback is that we get problems with collisions when two anchors happens to transmit at the same time. Experiments showed that at 400 packets/s (system rate) we ended up at a packet loss of around 15% and 340 TDoA measurements/s sent to the kalman filter for position estimation. We figured that this was acceptable level and added an algorithm in the anchors that reduces the transmission rate based on the number of anchors around them. If more anchors are added to a room they all reduce their transmission rate to target 400 packets/s in total system rate.

The anchors continuously keeps track of the clock drift of all other anchors by listening to the messages that are transmitted. We know that clocks do not change frequency suddenly and can use this fact to filter the clock correction to reduce noise in the data. Outliers are detected and removed and the resulting correction is low pass filtered. We have done some experiments on using this information and compare it to the time stamp of a received message to detect if the time stamp is corrupt or not, but this idea requires more work.

One interesting feature of the anchors is the limited CPU power that is available. The strategy we have chosen to handle this fact has been to create an algorithm that is efficient when handling messages. A timer based maintenance algorithm (@1 Hz) examines the received data and makes demissions on which anchors to include in the messages in the future as well as purges old data.

The Crazyflie

The implementation in the Crazyflie is fairly straight forward. The biggest change to TDoA 2 is that we now can handle a dynamic number of anchors and have to chose what data to store and what to discard. We have also extracted the actual TDoA algorithm into a module to separate it from the TDoA 3 protocol. The clock correction filtering algorithm from the anchors has also been implemented in the Crazyflie.

An experimental module test has been added where the TDoA module is built and run on a PC using data recorded from a sniffer. We get repeatability as well as better tools for debugging and this is something that we should explore further.

Work remaining

The estimated position in the Crazyflie is still more noisy than in TDoA 2 and we would like to improve it to at least the same level. We see that we have outliers in the TDoA measurements that makes the Crazyflie go off in a random direction from time to time, we believe it should be possible to get rid of most of these.

The code is fairly hackish and there are no structured unit or module tests to verify functionality. So far the work has been in an exploratory phase but we are getting closer to a set of algorithms that we are happy with and that are worth testing.

We have not done any work on the client side, that is support for visualizing and configuring the system. This is a substantial amount of work and we will not officially release TDoA 3 until this is finished.

How to try it out

If you are interested in trying TDoA 3 out your self, it is all available on github. There are no hardware changes and if you have a Loco Positioning system it should work just fine. There is a short description on the wiki of how to compile and configure the system. The anchor supports both TDoA 2 and TDoA 3 through configuration while the Crazyflie has to be recompiled to change between the two. The support in the client is limited but will basically handle anchors 0 – 7.

Have fun!

Work on TDoA 3 started

2018-05-07 | Kristoffer Richardsson | 1 Comment

First of all we are happy to announce that (almost) all products have been stocked in the new warehouse and are now shipping! The last orders that were on hold are on their way out and new orders placed in the store will now be shipped again within a few days.

We released the TDoA mode, a.k.a. swarm mode of the Loco Positioning System back in January. TDoA supports positioning of many Crazyflies simultaneously which makes it possible to fly a swarm of Crazyflies with the LPS system. The release in January was actually the second iteration of the TDoA implementation (the first iteration was never publicly released) and it is also known as TDoA 2.

TDoA 2 works well but there are a couple of snags that we would like to fix and we have now started the work on the next iteration, TDoA 3.

Single point of failure

TDoA 2 is based on a fixed transmission schedule with time slots when each anchor transmits its ranging packet. All anchors listen to anchor 0 and use the reception of a packet from anchor 0 to figure out when to transmit. The problem with this solution is that if anchor 0 stops transmitting for some reason the full system will stop transmitting positioning information. This is clearly a property that would be nice to get rid of.

Limited number of anchors

The packets in the TDoA 2 protocol have 8 slots for anchor data that are implicitly addressed through the position in the packet. First slot is anchor 0, second slot anchor 1 and so on. This setup is easy to use but creates an upper limit of 8 anchors in the system.

The maximum radio reach of an anchor depends mainly on the transmitted power and the environment. This distance, in combination with a maximum of 8 anchors and that all anchors must be in range of anchor 0, sets an upper limit of the volume that an LPS system can cover, basically one large room. When we designed TDoA 2 we were happy to be able to support a swarm of Crazyflies and did not really bother too much about the covered volume. We get more and more questions about larger areas and more anchors though and it would be nice to have a positioning system that could be expanded.

The solution – maybe…

What we want to do in TDoA 3 is to transmit packets at random times and add functionality to handle the collisions and packet loss that will happen in a system like this. The idea is that the even if some data is lost, the receiving side will get enough packets to be able to calculate the distance to other anchors or a position as needed. By removing the time slots and synchronization to anchor 0, we get rid of the single point of failure.

In the TDoA 3 protocol, we have added explicit ids to the anchor data, and thus removed the implicit addressing of anchors. We have 8 bits for anchor ids and the system will handle 256 anchors for sure. We do think that it will be possible to design larger systems though by reusing ids and making sure that the radio ranges of anchors with the same ids do not overlap.

The UWB radios have a nice property that makes this a bit easier to handle collisions than one might first think, if they receive two packets at the same time, they will most likely “pick” one of the packets and discard the other. The drawback is that it is likely that the receive time of the packet will be less accurate. We are not completely sure it will be possible to detect and handle the added noise in the time stamps but we have good hope!

The current state of the project

Last week we did a proof of concept hack when we modified the old TDoA 2 implementation to transmit at random times, as well as minor modifications to handle random receive order of packets. It all worked out beautifully and we could fly a short sequence in the office with the new mode. The estimated position was a bit more shaky which is not surprising, considering that the receive times are more noisy.

We have just started with the real deal. We have designed a draft spec of the protocol and have also started to implement the new protocol on top of the old TDoA2 algorithms in the anchors and the Crazyflie to get started. Next steps will be to introduce random transmission times, dynamic anchor management and better error handling. The TDoA 3 implementation will exist in parallel with the current TDoA2 implementation and should not interfere.

If you want to contribute, are interested in what we do or have some input, please comment this blog post or contact us in any other way.

Multi-ranger deck update 2

2018-04-16 | Marcus | 7 Comments

It’s time for an update on the Multi-ranger deck (see previous updates here: 1, 2, 3). Back in February/March we were just about to start the production of the Multi-ranger deck when the new VL51L1 ToF sensor from ST became available. Among the interesting features for the new sensor is increased range and ROI (region of interest) settings. We felt that the improvement was enough to consider using the new sensor for the Multi-ranger so we got some sensors and started testing.

Point cloud

We’ve made a little example where you can control the Crazyflie with a keyboard (using velocity mode) that records estimated position, body attitude and all the distances (down/up, left/right, front/back) from the ToF sensors. We then did some post-processing of the log data and plotted it using pyntcloud, you can see the results in the point cloud. There are still lots of possible improvements (like taking body attitude into consideration) to be made on the script, but once we’ve cleaned it up a bit we’ll publish it on GitHub so others can play around with it. Note that in the plot the blue points are up/down sensors (i.e Crazyflie movement) and the red points are the side sensors (front/back/left/right).

The room that was mapped

So far we’re happy with the results. We feel that the increased range and new features enables users to work on more interesting problems with the deck, so we’ve decided to switch our the sensors and go to production with the new one. Right now we’re running a 0-series of 10 units using the real production manufacturing fixture (for the standing PCBs with sensors) as well as the production test rig. Our best estimate for when the deck will become available for purchase is some time during the summer. Below is a picture of the latest prototype. We’ll make sure to keep you updated on the progress!

Warehouse issues

On an additional note we’re having some issues with our warehouse provider which ships out orders from our E-store. In the beginning of the month the provider hade scheduled a move of the warehouse to a new physical location which would delay handling of orders for max a week. Unfortunately the move, which should have been finished mid last week, is still in progress which means we can’t ship out any orders for the moment. We’re working hard on trying to work this out with the provider.