Well its hard to believe that yet another year has passed. Maybe because it’s been such an hectic year for us at Bitcraze things has been moving so fast. It has not only been hectic but very exiting as well, we managed to release the Crazyflie 2.0 platform just in time for Christmas. That was our goal when we started working on it in March and we can’t really believe we made it. Sure, there are still lot’s of things to be done but now we can all unleash our creativity and start having fun while creating the future for small drones. So what does that mean? Well we don’t know what you have planned but we can at least share some of our ideas for 2015

• Improve documentation and instructions
• Develop new expansion boards where GPS and Camera are on top of the wish list
• Improve the smartphone apps
• Master thesis in dynamic mesh networks
• Improve firmware and merge it with Crazyflie 1.0
• Support for on-board scripting languages such as micro-python and Lua.
• Improved ROS support
• And much more!

With that said we thank you all for your support and wish you all a great 2015.

It seems that many have received their Crazyflie 2.0 now. It is a very exciting time for us, tell us what you think about your Crazylie 2.0 and if you have any problems. We wish you Merry Christmas, a Happy New Year, and a lot of fun with your new Crazyflie 2.0!

Getting started

The instructions and documentation are not really as finished as we would like them to be but we hope it is good enough for everyone to get started. For convenience we have put together a sets of links to find the information easier.

Crazyflie 2.0 – Getting started
Crazyflie 2.0 – Wiki
Crazyflie 2.0 – FAQ
Crazyradio/Crazyradio PA – Wiki
Crazyradio/Crazyradio PA – Windows driver installation
Android App
iOS App

Expansion port

The expansion port is a core functionality and it is important that it is easy to work with. The hardware part of the expansion port allows to easily attach custom electronic to the Crazyflie 2.0, making it a very versatile platform. We want to bring this convenience to the firmware and software development as well. We are not really there yet but would like to share our ideas of how we think, but also as an inspiration and to get valuable feedback.

As you might know we have added One-Wire memories on all our expansion board so that CF2 is able to detect which expansion board is connected. The intent is to automatically initialize the expansion board driver when a board is detected so that the firmware can contain all the expansion board drivers. Other benefits are that the resources easier can be shared but also blocked if there are conflicts between boards.

Currently we are in a state where we have made a prototype of how we want the driver to look like and work. The example/mock-up driver we have put together is for the traffic light hack we have written about earlier. The driver would just declare which expansion board it is supporting and it would be loaded automatically. Also some enhancement to the parameter API would allow for more declarative and short code.

Things will be a little bit slow here at Bitcraze during Christmas period as we are focusing on support and on our families. This is however definitely one or our focus when we start 2015. We will create issues to track this work in the Crazyflie firmware bug tracker, contributions are welcome :).

Bluetooth support

We have also published the rest of the Crazyflie firmware, the nRF51 has firmware, bootloader and a ‘Master Boot Switch’. The STM32F4 has bootloader and firmware. The nRF51 bootloader and firmware supports bluetooth low energy using a proprietary stack from Nordic Semiconductor. This stack architecture should play well with open source software as it is completly isolated from the firmware, it runs on the background and is interfaced with syscall (ie. the same way a program communicates with an OS in computers), Nordic call that a Softdevice. The problem is that the supporting libs that allows to access the softdevice is currently proprietary and we do not have the right to publish it.

Currently you can compile the nRF51 firmware in ESB (Enhanced Shock Burst) mode (ie. to communicate with Crazyradio) out of the box. To compile with BLE support you should download the S110 Softdevice and nrf51_sdk from Nordic Semiconductor and this requires you to have one of the Nordic kit. We are in communication with Nordic to fix this situation and will keep you updated. One nice thing about the nRF51 is that the radio is well documented so one way or another this is going to be solved: either we can distribute supporting files for the Nordic stack, or we make our own stack ;-).

Virtual machine

The virtual machine for the Crazyflie 2.0 is on its way, but as we have run into some problems, it has been delayed a bit. Now most of the problems has been fixed and we hope to release it any day now.

The workload is still huge and now it is starting to take its toll, we are really looking forward to a short vacation around Christmas! But even though we will be off, we will still be checking the support forum. Meanwhile we are doing our best to continue to march on and we managed to write some new documentation and also pushed some new releases. Please have a look at last week post which we have updated and will continue to update as we push them out.

Unbalanced CCW propellers

After receiving the final production version we have found that many of the CCW propellers (not marked with an A) shipped with Crazyflie 2.0 are a bit too unbalanced. This might cause vibration that will affects the flight performance. To get the best flight performance the propellers, especially CCW, might need to be balanced. Balancing the propellers is pretty easy, all you need is a needle and some office tape. We have put together a step by step guide on how to balance them and also updated the general assembly instructions to include balancing. We are currently investigating this with the propeller manufacturer and we will keep updating about it. If you have any questions or concerns drop by our support forum.

Firmware update

Yesterday we released a new version of the Crazyflie 2.0 firmware. This version fixes an issue that was triggered by the motor PWM frequency interfering with the one of the voltage regulators causing the Crazyflie 2.0 to shut-off if the thrust increased too fast. Doubling the PWM frequency fixed this issue completely. We also adjusted the gyro and accelerometer low pass filters a bit to handle vibrations from unbalanced propellers a bit better.

Crazyflie 2.0 can be updated with Crazyradio using the latest version of the Crazyflie client, with the update zip. Documentation of the update process is on the wiki. We also made a USB dfu update zip for people that do not have the Crazyradio. Instruction for the DFU is in the README.txt file in the zip file. In the future it will be possible to update Crazyflie 2.0 with the Android and iPhone client as well. This time around the update is for Crazyflie 2.0 only but the plan is to merge both Crazyflie firmware together in order to release everything at the same time.

New Android release

The Android client is also going forward thanks to Fred. This evening we are releasing an update that enhance the GUI and allow the app to run full screen on Android 4.4+. The update is going to be released on the play store.

Feedback

We are really eager to hear what you think about the new Crazyflie 2.0, the instructions and everything else around it. So please drop by our feedback topic in the forum, or post your feedback here, to let us know what you think.

We are sitting here at Doha airport in Qatar writing our Monday post after a very hectic week visiting Seeedstudio in Shenzhen, China. And it’s been really hectic week, I can honestly say I don’t think any of us has worked this many hours in 7 days in whole our lives. It’s been worth it though, because we did it! We got everything working and ready in time and production is up and running and it’s all on schedule. We have just seen to many kickstarters and pre-order campaigns deliver to late and we do not want to be one of them, and If nothing unexpectedly happens, we will deliver as scheduled.

As we think many of you know of, using internet in China can be a bit difficult. It is often refereed to as the “Great Fire Wall”. We had some clues about it before our visit and tried to take some measures but without much success. We are heavy users of Google services and most of them are either extremely slow or blocked. So is Twitter, Facebook, Youtube and similar social medias so our plan of posting frequent updates failed miserably. Next Monday post we plan on making a summery post of the trip when we organized all photos and when we are a bit more clear in our heads (sleeping on an airplane is not our specialty). Until then here is one photo of us in the Seeedstudio production floor and the new Crazyflie 2.0 box.

Another very interesting thing we have tired to follow (yes Bitcraze website has been blocked by the GTW as well) is the expansion board voting process. We’ve seen now that it has been a bit to easy to manipulate and we will use the following week to figure out what to do about it. You guys are just to clever and we see now that we should have done an investigation of good voting processes before we launched it. Well, it’s been exiting to follow and we are pretty happy to see it got people involved!

On Thursday this week we are ending the pre-order of the Crazyflie 2.0 and related products. A huge thanks to everyone that has supported us by taking part in the pre-order! If you are thinking about getting a Crazyflie 2.0, then remember to order before Thursday to get 15% off.  This time next week we are starting the production and will keep you updated of the progress.

During the pre-order we have been busy working on production tests, marketing and planning. Now we are preparing for the next big push, the firmware and software. This year we haven’t been very active when it comes to software development. It’s not that we have forgotten about it, there just hasn’t been any time for it. But with the hardware finished and the pre-order almost over, it’s time to refocus. The first thing we are publishing is the Crazyflie iOS client. It’s still very much a work-in-progress, but it works for flying the Crazyflie 2.0.

We also got a chance to visit the Maker Faire in Rome two weekends ago. It was a really great event with lots of things to see and lots of interesting discussions. Below are some of the photos we took.

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

One of the nice new functionality of Crazyflie 2.0 is the Bluetooth 4.0 low energy (BLE) connectivity. In Crazyflie 2.0 we are using a radio microcontroller chip from Nordic semiconductor, the nRF51822. This radio chip allows us to keep compatibility with the existing Crayradio (and future Crazyradio PA), and to support BLE connectivity as well. The radio chip is a bit bigger that the one we used so far, and with the Power amplifier, we end up having the radio taking more space on the PCB:

The extra footprint is offset by the fact that we are now using smaller sensors and that the nRF51 is also handling the power management thus freeing pins on the main CPU.

The main usage of BLE will be to fly Crazyflie from a compatible mobile device like an Android phone or an Iphone. This could be used both to ‘just fly’ or to develop crazyflie control apps using the mobile phones capabilities. For example the phone camera could be used to detect and control Crazyflie autonomously. We have prototyped the BLE communication both on the existing Android client and for IPhone. The plan is to provide basic apps for the Crazyflie 2.0 release so that the copter can be flown from a mobile device out of the box. So far we have got the copter to fly from both Android and IOS:

[Show as slideshow]

We are not planning on implementing any BLE support for the PC client, so Crazyradio is still the main way to communicate with Crazyfle. It is possible to have BLE on PC but it would require a major effort to get it to work for Linux, Windows and Mac (there is no cross-platorm Python BLE lib as far as I know. If there is some please tell me in the comments!). Also Crazyradio is lower latency and has an higher datarate which makes it better for flying and communicating with one or many Crazyflie 2.0 from a PC.

We are also implementing BLE in the bootloader. This means that it will be possible update the Crazyflie 2.0 firmware from both a PC or a mobile device.

Technically we are using the Nordic Semiconductor soft device BLE stack. The stack runs a little bit like an operating system, behind and independently of the firmware: the firmware is not linked to the stack. This will make things a little bit easier to have an open-source firmware even though the nordic bluetooth stack is closed. Another nice thing about the nordic chip is that the radio peripheral is well documented so implementing open source stacks in the future is potentially possible.

Practically we where originally planning to have two modes for the firmware: one Crazyradio and one bluetooth mode. However the new release of the Nordic BLE stack allow to mix BLE and Crazyradio at the same time. So we are working on having a seamless connection procedure between Crazyradio and BLE: when starting Crazyflie 2.0 it will be accessible both via BLE and with the Crazyradio. When connected the unused mode will be disabled until disconnection. Also the name of the copter will be communicated both in BLE and Crazyradio mode and can be changed by the user. This will help a lot people having more than one Crazyflie (us first!) to differentiate them.

Early on in the Crazyflie 2.0 design we decided on using a double-MCU architecture. The main reason for this was to add Bluetooth low energy (BLE) to the platform to permit new use-cases like controlling the Crazyflie 2.0 directly from a mobile device. It just so happens that Nordic semiconductor some time ago released a chip that perfectly matched our requirement: the nRF51822 can run a BLE stack and is still compatible with the nRF24Lx1 that we are using in the current Crazyflie and Crazyradio. This nRF51 chip contains an ARM Cortex-M0 microcontroller, powerful enough to implement the radio functionality and power management, but not powerful enough to run a fully featured Crazyflie. The resulting system architecture can be seen here:

The nRF51822

The two main tasks for the nRF51 is to handle the radio communication and the power management. We use the radio for both CRTP and BLE, but the hardware also supports other protocols like ANT. The CRTP mode is compatible with the Crazyradio USB dongle and it provides a 2Mbit/seconds data link with low latency. Our initial tests of the Crazyflie 2.0 implementation shows that the latency of the radio link is between 360us and 1.26ms, at 2Mbps without retry and a packet size of respectively 1 and 32 bytes. The main benefit of the CRTP link with the Crazyradio is that it’s easily implemented on any system that supports USB host which, makes it the first choice to hack and experiment with the Crazyflie. To that we have added BLE, mostly with the use case of controlling the Crazyflie 2.0 from a mobile device. The idea is of course to be able to fly easily and on the go with BLE, but we also see lots of opportunities for fun hacks and experimentation with mobile devices. One idea we came up with is to be able to place the mobile device up-side-down on a table and to autonomously hover the Crazyflie above it using the camera on the back.

One of the other particularities of the nRF51 chip is that it was designed to run from a coin battery, which means that it is pretty well suited for low energy operation. So we decided to give the nRF51 the responsibility for power management as well. In the current version of the Crazyflie we have a small chip handling the ON/OFF button and cutting power to the complete board. On Crazyflie 2.0 the button is connected to one GPIO pin on the nRF51 and power to it will never be cut, it just goes in “power down” mode. This permits to reproduce the current ON/OFF functionality and the button can be used for more function like long press and double click. We have also added the possibility to wake up the system from one of the pins in the expansion connector, which allows wake-up by an external source. It also adds more possibilities like waking up the system at regular time-intervals to perform some function.

The STM32F405

We also updated the main MCU to a fast Cortex-M4 with a lot of memory. The CPU power is not a big limitation in the current Crazyflie, but the memory could become a limitation if users would like to implement new functionality that needs a lot more memory. We ran into this problem when we were trying to implement SD-card support for logging, as this required too big buffers. The new MCU has 196kB of RAM which should be enough for anyone (famous last words…). The MCU power will also allow for more computationally intensive algorithms, the first that comes in mind is sensor fusion between inertial sensors and the GPS data.

This amount of memory and computational power also open the doors for new things: the STM32F4 has a Memory Protection Unit, which allow to run tasks in a protected environment and intercept bugs before they can crash the full Crazyflie control firmware (like what  happens on PC operating system). One use of this could be to to allow for “user code” that runs in a protected environment to allow easier development of advanced behavior. As always this kind of functionality spawns lots of crazy ideas :-) The leading one is to run a Lua interpreter in such a protected task. If there was a good API that could be used from Lua you could imagine lots of fun stuff to do. Like adding a new board with sensors, reading them and then controlling the Crazyflie from that, without having to go into the actual control algorithms or risking to crash the firmware. This is of course still a dream but at some point in the future we will definitely give it a try (when we have the time for it that is :-) ).

Inter-MCU communication

Working with a system with multiple MPU is hard. As embedded system developer we know that, so we designed the Crazyflie 2.0 with at least some idea of how to limit the problems related to debugging two inter-dependent MCUs. We have defined as precisely as possible the responsibility of each MCU, which permits to develop and test things independently:

• The nRF51 is responsible for
  • ON/OFF logic
  • Enabling power to the rest of the system (STM32, sensors and expansion board)
  • Battery charging management and voltage measurement
  • Master radio bootloader
  • Radio and BLE communication
  • Detect and check installed expansion boards
• The STM32 is responsible for all the rest, among other things:
  • Sensor reading and motor control
  • Flight control
  • Telemetry (including the battery voltage)
  • Additional user development

The nRF51 will act as slave and the STM32 as master. Using a radio bootloader it will be possible to wirelessly update the firmware for both MCUs.

We will write more details and post photos in the following weeks. Do not hesitate to tell us what you think about it, we appreciate all the feedback we get and we already have a couple of verification that we made after previous feedback (ie. radio latency and magnetometer usability).

We are glad to announce that we got a reinforcement to our team. His name is Miguel Piteira Gomes and just got out of school where he studied mechanics. Now we can finally do other stuff then electronics and software! Miguel comes from Portugal and will help us out during the summer. We wish him a big welcome!