Category: Electronic

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…

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. 

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.

 

During the fall we did two blog-posts (12) about a new prototype named Obstacle Avoidance/SLAM deck, but since then it’s been a bit quiet about it. So we thought it was due for an update! First of all, after a lot of discussions, we decided to rename the deck to Multi-ranger. It better describes what the board does and matches the naming of the Z-ranger. We’ve sent out some samples to customers and so far the response has been great. So we’re pushing forward and preparing for production that’s estimated to begin in March. Below is a picture of the latest prototype.

The biggest change for the final prototype is adding a LDO regulator to power the sensors. We’ve seen that depending on the settings for the sensors they might consume a lot more than when we initially tested. Using the same settings as for the Z-ranger brings the consumption to 90 mA, which together with the Crazyflie 2.0 electronics, comes close to filling the power budget for the Crazyflie 2.0 VCC LDO regulator. Aside from that we’re making some minor changes to simplify production and testing.

We’ll keep you updated on the progress!

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.

Thanks to denis on the forum, there is now support for Crazyflie 2.0 in the PX4 flight controller firmware. PX4 is a comprehensive flight controller firmware used in research and by the industry.

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!

video link

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 :-)

To quickly get up and running, we have written a getting started guide. There is also a great hackster project, Beginner’s Guide to Autonomous Quadcopters by community member Chathuranga Liyanage, containing more details.

So we are now back in the cold and dark Sweden after about a weeks visit to a warm and nice Shenzhen, China. Every time we go there something major has happened. When we visited last time, about a year ago, cash was king. Now apparently payments are done with QR codes, even in small lunch restaurants. And I was kind of proud about the BankID and Swish payments we have here is Sweden, until now… Another observation we did was that there are now a lot of colorful rental bikes which can be found about everywhere and which can be rented for around 1 RMB/hour. A great way of resource sharing and pushing Eco-friendly transportation. It has it downside though as piles of bikes could be commonly found and e.g. written about by theguardian.

Aside from the above observations the Maker Faire Shenzhen was one of the reasons we came to visit. As Shenzhen is called the “the silicon valley for hardware” we had pretty high expectations when coming to the Maker Faire. Even though it was a great Faire it did not really reach our high expectations but it is growing fast and I’m pretty sure in a couple of years it is the Maker Faire to be at. A quick summarize, robotics was one of the top categories of products on the faire. 3D printers which are popular on European and US faires was not that common which surprised us. Now let the pictures do the talking:

 

We exhibited on the faire sharing booth with Seeedstudio where we showed an autonomous sequence on top of a table using the flow deck. By pressing a button, the Crazyflie 2.0 would take of, fly in a circle, come back and land roughly in the same spot. It was a very engaging demo catching many peoples attention and especially the kids. The kids constantly wanted to press the button and interact with the Crazyflie.

All the interaction made us very happy and next time we will try to add the obstacle avoidance deck to make it even more engaging.

 

Unfortunately the Crazyradio PA is out of stock in our store and is estimated back around December 1. Until then please checkout our distributors for availability.

 

A few weeks ago we wrote about a new prototype that we call “the obstacle avoidance deck”. Basically it’s a deck fitted with multiple VL53L0x ToF distance sensors that measures the distance front/back, right/left and up of the Crazyflie 2.0. Combined with the Flow deck this gives you an X/Y/Z robot that you can program fly around avoiding obstacles which doesn’t need any external positioning system.

After implementing firmware support for the deck (see #253 and #254) we’ve finally had a chance to do some initial testing, see the video below. In the current implementation we’re doing the measurements in the firmware but using the logging framework to get all the distances into a Python script which does the movement control. Since we have the Flow deck attached we can control the Crazyflie 2.0 in velocity mode, which means we can say things like “Go forward with 0.5 m/s until the forward sensor shows a distance lower than 50cm” or “Go forward 1 m/s for 1s and rotate to measure the distance to all objects”. Since there’s no real-time requirements we can move the complexity of the algorithm from the firmware into external scripting which makes it a lot easier to develop. Now we’re really eager to start setting up obstacle courses and time how fast we can move though them :-)

The results from the testing shows that our two main concerns aren’t an issue: The sensors doesn’t seem to interfere with each other and we can sample them all at high-enough frequency without occupying the bus too heavily (currently we’re doing 20Hz). The next step is figuring out the requirements (i.e how many VL53L0x sensors are needed, do we really need the back one?) and a mechanical solution for attaching the sensors in production. If there’s any feedback let us know now and we’ll try to get it into the design. Also, we really need a new name for the board. Any suggestions?

A long time ago we got a request for a bright LED deck from a community member. When working with high powered leds heat becomes a problem that needs to be taken into account. From the community member we got suggestions of using one of the luxeon rebel leds and so we did. We designed a prototype pretty quickly but also realized that it is a bit harder than we first thought. If using a simple control scheme such as PWM and a mosfet the circuit is simple but brightness will be effected by battery voltage. Using a dedicated LED driver the brightness would be stable but the circuit more complicated and expensive. Trying to list the pros and cons:

MOSFET
+ Low complexity
+ Low cost
+ High efficiency
– varying brightness depending on battery voltage
– Might stress LED (could be solved with low ohm resistor)

LED driver
+ Stable brightness
+ Not as high efficiency (~80%)
– Higher cost
– Higher complexity

We ended up trying booth. The LED driver design failed due to that the battery voltage needed to be lower than the LED voltage + schottky and it is just in the middle. The PWM design half failed since the LED anode and cathode was swapped in the design but was possible to patch afterward. So at least we got something up and running.

The effect is very nice and it is what we used for the wedding show. The question now is, is this something we should finish and put in the store?

At any given time we have a bunch of deck ideas floating around. Some of them might not be doable (or very hard), but still fun to discuss. Other we just never get around to since we’re always pressed for time. The “obstacle avoidance” deck is one of the latter ones.

The idea with the “obstacle avoidance” deck (current working name in lack of imagination) is to mount one of the VL53L0x ToF distance sensors, the same we have on the Z-ranger and the Flow deck, in each direction. This would allow you to keep a distance to the ground, avoid the walls (or any other obstacles you might fly into) and also keep away from the ceiling. Basically you could do a “turtle bot” that just flies around randomly without crashing. Another fun idea we’ve been discussing is being able to SLAM the room you’re flying in. If you can keep track of how you are moving around (with the Flow deck, Loco positioning system or any other means) while you’re measuring the distance on all sides you could make a map of the room.

After discussing this on and off for a some time, mainly focusing on mechanical and production issues of the design, we decided to just try out the concept with a simple prototype. The prototype, named “OA”, has daughter boards with VL53L0x sensors mounted front/back, left/right as well as one sensor facing up. It’s designed to be mounted on the top of the Crazyflie 2.0 and combined with the Flow deck which will give relative movement and also the sixth direction, distance to the floor. One of the issues with the design is that all the VL53L0x sensors are on the same I2C bus with the same address. To work around this the sensor has a nifty feature where you can re-program the I2C address. For this to work you need to release the reset of the sensors one by one: release the first reset, reprogram the address and then release the reset of the next sensor. The reset for the VL53L0x is not cabled on the Flow deck, so this is the first to be re-programmed. Then the reset will be released one-by-one for the sensors on the OA deck. In order to control the reset pins on the deck there’s a 8bit I2C GPIO expander. The reason for the GPIO expander is to use as few GPIOs on the deck connector as possible to keep the compatibility with other decks high. For instance the deck will work fine with the Loco positioning deck.

 

The goal with the prototype is to try out the concept of the deck and to see if it’s feasible. A few of the things we need to sort out is:

  • Mechanical solution for side senors (front, back, left and right)
  • Interference between sensors
  • Update rate when we have 6 sensors on the same bus which we might have to run one-by-one to avoid interference

The current status is that we’ve verified the electronics and written the I2C GPIO expander drivers to test all the sensors. The next step is to work on a new VL53L0x driver to allow multiple sensors running at the same time, which will force some refactoring of the firmware.  Once we’ve made some more progress we’ll do another post and report the results. If you have any feedback on the design/concept or have any ideas of what the deck could be useful for, don’t hesitate to drop a comment below.