New Crazyradio PA

2014-08-11 | Arnaud | 2 Comments

As we said in previous post, with Crazyflie 2.0 one of the focus has been on enhancing the current Crazyflie platform. The radio range and power is one of these things that is good enough on the current Crazyflie but that could be made much better. So on Crazyflie 2.0 we added a +20dB power amplifier that increase the output power up to +20dBm.

The logical move was to add a similar amplifier on the Crazyradio dongle and that is what we did. We made Crazyradio PA (power amplifier) and we intend to release it with Crazyflie 2.0

[Show as slideshow]

The output power is now of 20dBm for Crazyradio PA, which will dramatically increase the control range. Even though Crazyflie was originally intended for indoor use, Crazyflie 2.0 is pretty capable outside, mostly with the expansion capability that could allow to add things like GPS, so the extra range could be put to use. But maybe the biggest advantage is indoor where Crazyradio is now playing equal with Wifi in term of TX power. This increases the link robustness and allows for flying in other rooms (could be useful with a powerful FPV for example).

Preliminary tests show much better performance compared to the first Crazyradio and Crazyflie both indoor and outdoor. So far, we mesured a stable link two floors down about 20m away indoor and about 150m outside range (the uplink has been tested up to 450m). Of course we are continuing to work on it and final specs will come later.

As for the radio dongle mechanic we have changed nothing: the connectors and LEDs are still at the same place. This was made possible by using smaller SMD components and so existing 3D-printed cases for Crazyradio still work for Crazyradio PA.

Crazyflie 2.0 expansion port

2014-08-04 | Marcus | 4 Comments

One feature of the new Crazyflie 2.0 that we are especially happy about is the new expansion port. We have attached a lot of hardware to the current Crazyflie and we have also seen lots of users attaching their hardware, but it’s not very easy. The current connector is small, you will need to solder and it’s not mechanically stable once you attach something. For the Crazyflie 2.0 we wanted to improve this, making it easier to attach new hardware and to expand the functionality of the platform. When we started looking at this we quickly realized that the small size of our platform limits what kind of interface we can have. We wanted something very small and light, but still it couldn’t be too expensive. While looking for a solution we found some of good alternatives, until you start measuring them and bringing them into our design in KiCad (again, it’s like parking a minivan in your bedroom). Something that didn’t make the selection easier was that we wanted lots of flexibility. We wanted users to be able to add multiple boards, both on the bottom and on the top of the platform. This might sound crazy for a small platform like the Crazyflie, but with the new motors we are able to carry more weight than before. Adding expansion boards will of course effect performance (like flight time) but to the extent that it’s possible, we want to give users the possibility to do as much crazy things as possible with their Crazyflies :-)

After months of searching (it’s pretty hard finding connectors…) we finally found a solutions that fulfilled all of our requirements. The connectors we found allows users to place multiple boards on the Crazyflie, both on the top and the bottom, and without pre-defined vertical spacing. We only place female connectors on the expansion boards, which means that if you crash and bend the male pins, you just have to exchange them and not any expansion boards. Below are some images showing the expansion connector, the pins and some examples on how you can connect boards. It also shows two of the expansion boards that we have designed, a prototype board and a breakout board for breadboards. In the images we use the breadboard and the breakout board to connect to a pressure sensor from ST and the prototype board to build a flying traffic light :-) The idea of the pattern for the prototype board is taken from ElecFreaks. It allows for easily using both though-hole components and SMD components.

All the boards and the Crazyflie 2.0 with the 3D printed motor mounts are still just prototypes.

[Show as slideshow]

Detecting boards

We think that being able to attach different boards is great, but how do we use them in the firmware/software? Well, there are two different use-cases for that. The first one is “pre-made” boards. Aside from the two boards above (prototype and breakout) we have a bunch of ideas and also a few working prototypes that we will write a bit more about later. Let’s use the GPS-expansion that we are working on as an example. When you attach this board you want extra functionality to be available without re-compiling and configuring things. You still want the possibility to hack around in the firmware/software, but you want the hardware to be initialized properly so you don’t have to worry about that. To accomplish this we needed some way to identify the different boards. Again, this needed to be done is a cost-efficient way and without using up too many of the pins in the expansion port. The solution we found is 1-wire memories. So what’s so great about them? Well, they have some nifty features. First of all each produced IC has an unique address, so placing multiple memories on the same buss is no issue. Using a search algorithm you are able to find and identify all the connected memories so that you can address them individually. Secondly they only use, like the name suggest, one wire for communication. This wire is also used for parasitically powering the memory. That means all you need to connect is the one wire and ground. Last, but not least, they are fairly small. The ones we use are in a SOT23 package.

So how are we using these memories? We are placing a memory on every board we design (except for boards like the prototype and breakout boards). The memory is very small, but it’s enough to contain some information about the board. So during production each memory will be programmed with things like what board it is, which revision and what resources (i.e what pins in the expansion port) the board uses. At start-up the 1-wire bus will be scanned and all the memories will be read to detect what boards are attached. Why store what pins the expansion boards use? Well, the nice thing is that the 1-wire bus is connected to the nRF51 (here’s some info on the system architecture). Since the nRF51 is responsible for power management (i.e switching on power for the STM32F4) it’s possible to scan all the memories and detect conflicts in resources before powering on the main system and the expansion boards. Let’s say you attach two boards that use the same UART. This will result in issues when the systems starts running. To protect against this the nRF51 will check if there are any conflicts and won’t power on the system if there is.

The second use-case for expansion boards are the ones you make yourself. Then you might not be interested in using the 1-wire to detect your board. Therefore it’s in no way mandatory to use that feature, it’s just something that we think will make working with our platform easier for our users. But in case you are interested in detecting your own boards, the firmware will support programming the memory and we will link to the correct parts at suppliers.

The pinout of the expansion port

The expansion connector consists of 2 rows of 10 pins each with the spacing of 2mm and has the following pinout:

Crazyflie 2.0 expansion port

VCC – 3V0 regulated supply (max ~50 mA consumption). Only powered when the STM32F4 is powered.
STM32F4 UART 1 (RX/TX)
STM32F4 I2C bus (400kHz)
STM32F4 4xGPIO (can be used as chip select for SPI)
GND – platform signal ground

STM32F4 UART 2 (RX/TX)
STM32F4 SPI (SCK, MISO, MOSI)
nRF51 2xGPIO that could be used for GPIO but will have the following reserved:
- nRF51 wakeup – allows waking up from an expansion board
- nRF51 external power indication – will indicate if an expansion board is powering the system or not
- nRF51 1-wire memory access
VCOM – unregulated direct access to power after charger (max 1 A consumption). The voltage is VUSB if a charger is connected and VBAT otherwise. Currently this power supply is always on (even when the system is powered off) witch allow for making always-on expansion board. However we are looking at inserting a high-side switch which would allow also switching this supply off if needed, making prototyping and design of expansion boards a bit simpler.
VUSB – unregulated direct access to uUSB power. This can either be used to get uUSB power or to supply uUSB power to the platform (like an external charging board that powers and charges the system).

The pins that are connected to the STM32F4 can be used as GPIO or for other functionality that they are multiplexed with, like timers.

Making expansion boards

As many of you probably know, we strive after using open source tool for our development. So for electronics design we use KiCad, an open source EDA suite that works on Linux/Windows/Mac. To make it easier for users to design and make their own expansion boards we have created a template for the design. It contains the initial schematics as well as layout. The connectors are added in the correct positions and the memory is also in. To make things even easier, the layout contains drawings of the Crazyflie 2.0 board outline and connectors, to easily see how the board will fit. As with everything else this needs some cleanup when the final design is in place, but then it will be released under the CC-BY-SA 4.0 license. Looping back to the 1-wire memories, if you make your own board will it be possible to get in on the automatic detection? Sure, the more the merrier. But we still haven’t specified exactly how this will work technically, so we will have to get back on the specifics. If you are interested in hacking something together a great way to go is first to try out the design on a breadboard, then solder it together on the prototype board and finally do the layout in KiCad and order it at a batch-PCB service.

Crazyflie 2.0 debug-adapter board

2014-07-28 | Arnaud | 8 Comments

While designing the Crazyflie 2.0 one of our focuses has been enhancing the current Crazyflie functionality. As a flying development kit the current Crazyflie already has a JTAG debug port that allows to flash and debug the STM32F1 microcontroller. The design uses a standard ARM 10-pins cortex debug connector. The connector is shipped with the Crazyflie control board, but it is not soldered. So before doing any advanced debugging with the Crazyflie the user will have to solder the debug connector (it is always possible to flash new firmware using the radio bootloader).

With Crazyflie 2.0 we wanted to make it easier to debug it out-of-the-box, without needing to solder. But the issue is that standard debug-connectors tend to be fairly large, so to fit the connector on the board we used a different connector that connects to an adapter board.

[Show as slideshow]

Aside from having a reset button, the adapter board will have 3 JTAG/SWD connectors:

20-Pins HE10 ARM JTAG with 2.54mm spacing: The most commonly used connector
10-Pins ARM Cortex with 1.27mm spacing: Used in some modern ARM board, the same as the current Crazyflie
6-Pins SWV with 2.54mm spacing: Compatible with the connector present on ST Discovery boards

The smaller 6-pin connector connects to the Crazyflie 2.0 for flashing and debugging of its 2 MCUs: The STM32F405 and nRF51822. The connector for debugging the STM32F4 is mounted on the Crazyflie 2.0. For the nRF51 we are still working to get a solder-free solution using the same cable/connector on the debug-adapter. Why not just put two connectors, or one big with all the signals on the Crazyflie? There’s just no more space on the board. The connector looks very small, but when you bring the footprint into KiCad it’s like parking a minivan in your bedroom :-)

Since all the connectors are wired together the board can also be used in a number of other combinations, like using it as a 20-pin to 10-pin Cortex JTAG adapter or any other combination of its connectors.

Crazyflie 2.0 photos and video

2014-07-21 | Marcus | 2 Comments

With the help of our new intern Mattias we finally got around to shooting a short video and taking photos of the Crazyflie 2.0 prototypes. We are really excited to finally show the new version and we are looking forward to getting some feedback from our readers. We are currently finalizing the design of the motor mounts, so for the video and photos we are using 3D printed prototypes printed in our Ultimaker. The design used in the photos is pretty close to the final design, which will also be transparent. The Crazyflies shown doesn’t have any expansion boards attached, instead there’s just a PCB that holds the battery.

[pe2-gallery album=”http://picasaweb.google.com/data/feed/base/user/115721472821530986219/albumid/6038515743776561441?alt=rss&hl=en_US&kind=photo” ]

Crazyflie 2.0 prototype: From package to flying in 8 hours

2014-07-14 | Marcus | Leave a comment

When working with hardware there’s always a very intensive phase when you do the initial design, find the correct parts and finally order your prototype. Then you sit around waiting for a month or two until the board shows up with the mail. For a first prototype there are always errors, so you want to minimize the time before you do another round of prototypes. Already during the work with the initial hardware design we use various development boards to check that we won’t run into any problems. Normally there’s something you didn’t think about and there’s always something ugly that shows up in the errata. To test some of the hardware you might need a lot of firmware, like how well do the sensors work when flying. To speed things up we normally continue the development using our hackish set-up of development boards even after the prototype is ordered. This way we have made lots of progress with the firmware until the first prototypes show up.

Since we did a lot of changes for the Crazyflie 2.0 we verified many things already before ordering the fist prototype, but for others we needed more firmware and we didn’t have the time do finish it all. So after ordering we continued the development using our initial set-up. It contains roughly the same sensors we use in the final design and also the two MCUs (STM32F405/7 and nRF51822), everything is wired up using roughly the same pins and buses we have in our design. While we were doing more work on the firmware we found a couple of errors we made in the hardware that we needed to fix when the prototype arrived. Finally we had the old firmware ported and running on the STM32F4 and some new firmware for the nRF51. Together this built up almost a complete system which we could connect the client to and log data from the sensors. Obviously there was one thing we couldn’t really test, the actual flying :-)

Prototyping the Crazyflie 2.0

Finally the new prototypes arrive. If you have been in this situation before you recognize the feeling, it’s great! Even though we had the firmware working we didn’t want to start trying to flash it, there was probably other issues we haven’t found. So we had also prepared a blinky program which just starts the oscillator and blinks the LEDs. While taking small steps it’s a lot easier to find out what went wrong. After successfully blinking the LEDs we got a bit more confident and flashed the full firmware, and it was working! But then we already knew about the error that kept the STM32F4 in reset and had patched it :-) After attaching the 3D printed motor-mounts for the new 7mm motors and fixing the PWM we gave it a try. Crash! A bit too optimistic.. we fixed the sensor orientation and it was finally in the air. After a quick glance at the clock we realized that it had only taken 8 hours from ripping the package open (yes, ripping) until we had the first prototype of the Crazyflie 2.0 in the air. After a couple of days all the hardware was tested, the changes were made and a new prototype was ordered (which coincidentally showed up today).

So where’s the video of it flying? It’s still in the making. This fall we are very happy to have the help of Mattias that is doing an internship at Bitcraze. He’s worked with media and graphical design before, so you can expect images and video with better quality than we normally manage to produce :-)

Crazyflie 2.0 based Master thesis for flying meshed sensor array

2014-06-30 | Marcus | 2 Comments

At Bitcraze we often get into discussions about crazy ideas that we would like to test out. Most of them are just that, crazy ideas, that are hard to realize or that we never have time for and the discussion ends (and a new one begins). But one of these discussions have been popping up time and time again, the idea of a flying sensor array based on the Crazyflie. Imagine a situation where you would need to distribute a large number of sensors over an area that you don’t have access to. You could also imagine a situation where you would like the measurement points to move over time. In these cases manually placing sensors at different points might not be a feasible solution.

During the initial design of the new Crazyflie we tried coming up with different use-cases for the new platform. We are not designing a “end-user” product that is intended for a specific end-use, instead we are designing a platform that is aimed at giving us and other users as much flexibility as possible to define the end-use themselves. But we still needed something to aim for, to try out our design on, and see if it could be done. One of these use-cases ended up being a flying sensor node. This might seem like a very specific usage, but we thought that if we come up with a design that would fulfill our basic idea and also a few far fetched ideas, then we would have something good. Hopefully this will be the case :-)

But we don’t only want to use the sensor array as a use-case, we want to build it! But as always time is in short supply. What’s the second best thing after doing something yourself? Seeing someone else do it! So we thought that this would be a great opportunity for a master thesis, where there would be room for both a theoretical part and a practical implementation part. Therefore we are hosting a thesis together with the consultant-company DevPort and the faculty of engineering at Lund University this fall semester. The theoretical part of the thesis includes investigating mesh-algorithms that could be used for a flying sensor array to relay commands to the nodes and to relay back sensor data. The goal is not to relay direct control commands though the mesh, but instead relay target positions for sensors or area that the array should cover. The goal of the practical part of the thesis is to implement basic functionality of the selected design using our new Crazyflie. The radio used in our new design is the nRF51822 from Nordic Semiconductor, we will go into more detail on the new radio in upcoming posts. We realize that this is a huge task, but we will do our best to help out. Between the three of us we cover mesh, radio, embedded systems and of course lots of knowledge about of the new Crazyflie and the nRF51822.

The thesis will be based on location in Lund/Malmö in Sweden, but we will of course share the progress and results on our blog. If this sounds like something that is interesting and you are looking for a thesis, then check out the description here (PDF here). Contact information for questions and applications can be found in the description.

So how did using this use-case when designing the Crazyflie effect the result? Well, one thing is that one of the pins in the expansion connector can be used for charging and powering the system. Think solar-cell, inductive charging or any other alternative source of power. It also sparked lots of discussions that effected the complexity of the power-management system, something that is now handled by the new radio MCU.

The next generation – Crazyflie 2.0

2014-06-23 | Marcus | 42 Comments

It’s been more than a year now since the Crazyflie Nano Quadcopter was released and it’s been a great journey! It’s been great to see users all over the world assembling their Crazyflies and doing all kinds of things with them. The list of cool things that have been done is long! During this time we have gotten feedback on what we can improve. We have also had time to reflect on what we think we could do better. So since some time now we have been discussing what we should change if we had the chance to make a second version of the Crazyflie. We think the time has come for an upgrade, so during the last 6 months we have been trying to sort out what we can do (and what is just too crazy..) and we have finally landed on a design that we hope you will like.

So it’s finally time to announce our new Crazyflie, the Crazyflie 2.0! Honestly we tried coming up with a cool name, but 2.0 just felt so geeky we couldn’t resist :-) During the upcoming months we will write lots of post detailing the features and design of the new version, but here’s a quick overview. First some of the things that we have seen users requesting:

No more soldering: The new design features connectors for the motors so you will not need to do any soldering.
More robust shape: We redesigned the PCB shape to withstand more punishment by changing the + shape to an X shape and also making the “wings” thicker.
Bluetooth Low Energy: Lots of users would like to fly the Crazyflie directly from their phone. To accomplish this we decided on adding Bluetooth Low Energy support while keeping compatibility with the current Crazyradio.
More payload: Lot’s of users would like to lift more payload than the current Crazyflie can handle. To accomplish this we have upgraded the motors from 6 mm to 7 mm, which increases the payload with about 2-4 times. It also makes it a lot more aggressive and fun to fly ;-)

Aside from user requests, we also have a couple of things that we wanted to improve and would give users much more possibilities to experiment and explore flying robotics:

Improved expansion-port: We have removed the old 2×10 header and instead added an expansion interface that has better mechanical stability and is easier to use. The interface is two 1×10 2.0 mm pitch connectors, spaced 22.0 mm apart. To maximize the flexibility users are able to stack boards on top of each other, both on the bottom and on the top. This will of course affect aerodynamics and flight time, but gives users lots of exciting possibilities.
Improved radio range: To be able to do more experiments using the Crazyflies outside we wanted to improve the range of the radio. This has been done by adding a radio power amplifier to the Crazyflie and also to the Crazyradio.
Dual-MCU architecture: Dedicated MCU for power-management/radio-communication and updated main MCU for control and application.

When moving to the new platform we don’t want to have two different firmwares for the new and current Crazyflie. Therefore we are doing major changes to the firmware in order to support multi-platform. Our goal is to keep full compatibility with the current Crazyflie as far as the hardware will permit, so any improvements done on the new Crazyflie will also be available on the current Crazyflie. We are still hashing out the details of what this will look like, but we are looking at abstracting all hardware-related code from the core platform.

Much of the design is in place for the Crazyflie 2.0, but there still some things we don’t know yet. Here’s a list of things we will haven’t decided on or tested, that we think you might be interested in:

Flight time: We still haven’t decided exactly on the battery so we have no measurements for this yet, but we are aiming for something similar to the current Crazyflie.
Weight: The size of the bounding box of platform will be the same (i.e. length and height) but the board is packed with more things, the PCB is a tiny bit larger, the motors are heavier and the motor mounts are different. Due to these things not being finalized we don’t have a final weight yet.
Radio performance: We are still tweaking and measuring the radio performance, so we don’t have any exact measurements that we can share.
Release date: We are always careful when promising specific dates, since we know it’s hard to keep them. At this point we could still hit some major roadblocks, but so far things are going according to plan. That being said, our aim is doing a pre-order of the new version at some time during the late fall.

We think that all of this sounds great (of course :-) ), but we are very eager to hear what you think about it. Does the Crazyflie 2.0 sound interesting? Is there something you would like to add or remove? Leave a comment below and let us know what you think!

Last week at Devoxx UK

2014-06-16 | Marcus | Leave a comment

Like we mentioned a couple of weeks ago we went to Devoxx UK last week exhibiting the Crazyflie. We got a chance to do lots of fun things, like flying the FPV quad in the keynote and also over the exhibition floor. The image is a bit faded, but we had the luck of having a projector next to us that we hooked up the FPV receiver to so the video feed was projected on the wall behind our booth. Our booth was next to the NFC ring exhibition which had a nerf gun that was unlocked when wearing their NFC ring. We quickly came to the conclusion that trying to shoot the Crazyflie down with the nerf-gun was the way to go :-) It can actually take a couple of direct hits before going down!

On Thursday night we jointed the IoT hackathon hosted by IBM. We got an Arduino with lots of sensors that we were supposed to interface from Java. Unfortunately we didn’t do too well on the Java front, but we managed better with the Arduino. We decided to use on the thumb-joysticks for controlling roll/pitch and a light sensor for controlling the thrust. Our first plan was to use a microphone for controlling the trust with the sound-level, but we realized that might be a bit too tight with time. The joystick and light values are sent via the UART to the PC and picked up in the Crazyflie Python Client using a modified version of the joystick drivers. Instead of reading events from PyGame we read data from the serial port. This makes it alot easier to debug since we get feedback from the input-device directly in the UI. In the end we got it working (kind of..) so we could fly and actually won the hackaton! So now we have a box of sensors that we can play around with. Below is an image of the sensors connected to the Arduino.

Things happening in the community

2014-05-12 | Marcus | Leave a comment

It’s been a while since we summed up things happening in the community so here’s some of the things that are happening. There’s lots of more things, so if you think we are missing something, then post it in the comments below.

Ralph has been doing some work on an semi-automatic flip feature in the client. There’s more info on the forum and video below.

Last week we tested some modifications made by otto for a headfree mode (i.e yaw only rotates the platform, not the referance direction). It’s a really nice feeling just rotating without taking care of the direction you are going in :-) There’s more information and links to code on the forum.

The SHERPA project have been working on swarm algorithms using a vision system and the Crazyflie.

Geof from Centeye have been working on optical flow stabilization using the Crazyflie. He has a prototype board working and there’s lots of information in the forum about this build. To see the results have a look at the video below.

Thanks to Victor the Deviation firmware for Devo-7e (custom firmware for Devo RC-controllers) now has support for the Crazyflie (needs hardware hack). If you would like to give it a try have a look at the code or grab one of the nightlies.

Researchers at the University of Tokyo have been testing a new concept for a HoverBall using the Crazyflie. Imagine throwing a ball into the air that doesn’t come down (well not right away at least..). Here’s some more info and a picture.

We have also seen some nice stand alone controllers for the Crazyflie, one by MidLifeCrisis (more info here) and one by ivandevel (video below) . There’s also more info in the forum.

There also some updates on the work done by Oliver on the Kinect tracking of the Crazyflie. A demo video is shown below (it looks great!) and there’s more information on the forum.

And finally here’s a nice video we found on Youtube showing position control of the Crazyflie using a VICON system.

Crazyflie and NeoPixel ring continued

2014-05-05 | Marcus | 3 Comments

Continuing our post last week here’s a video showing the Adafruit NeoPixel ring and some of the effects that we did. The client code still needs some cleaning up, but the firmware is pushed here.

The firmware implementation includes two parameters, ring.neffect and ring.effect. The first parameter is used to know how many effects are implemented and the second one is used to set the index of the effect that should be used. For our current implementation we just loop though all the effects with either a joystick button or using the thumb together with the Leap Motion. It’s also possible to use these parameters directly from the UI as seen in this blog post.

Some of the effects we implemented are just blinking patterns, but we also wanted the ability to show feedback from the firmware using the ring. This has been enabled by adding an API in the firmware to access variables exposed though the logging framework. Using this API the firmware can access the same variables in the logging as the client. This enables all kinds of fun possibilities. In the video you can see (blurred) our implementation showing which direction the Crazyflie is tilting, but we have also been working on showing thrust (think rocket :-) ) as well as other things. We have done our best to implement a couple of effects, but there is so much more cool effects that could be done. So the firmware allows for custom effects and also for mixing multiple effects together (see this code).