The next generation – Crazyflie 2.0

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!

42 comments on “The next generation – Crazyflie 2.0

  • Excuse the rant, but serously, why, with the global internet do people still use localized timeframes such as “during the late fall”
    can’t we all just use first, second, third, or fourth quarters?
    now that’s out of the way:

    Cool! can’t wait to hear more! maybe by then my financial situation will be such that I feel like I can splash out on such a toy.

  • But, the Crazyflie 1.0 I bought only just arrived the day before this announcement…
    +1 for progress though, BLE should make for some fun applications!

  • I hope BT4 LE wont be the only option radio-wise. 7 minutes with “mother” quadcopters providing inductive charging stations nearby when the battery is about to die could really make things interesting, but only if I’m not limited by the range of my radio. The “mother” quadcopters could be set up to act as signal repeaters but I’d prefer direct communication.

    • Interesting idea! The radio will be backwards compatible with our current radio dongle, so BLE is not the only option.

  • Thanks a lot for sharing that, Marcus!

    Things I really like:
    * No more soldering: I actually didn’t mind the soldering, but having connectors makes replacement of broken motors much easier.
    * More payload: One great thing about the crazyflie are the possible add-ons. The current payload limits that quite a lot allowing only one additional sensor (sonar, GPS, or camera).

    Things which are nice, but I wouldn’t need:
    * More robust shape: That might be something I would really like. However, I had quite many crashes with my flie and never had an issue with the old design. If it gets even better – great!
    * Improved radio range: I use the flie indoors only – the current range is sufficient for that!
    * Improved extension port

    Things I am skeptical:
    * Bluetooth Low Energy: I actually don’t think that Bluetooth is such a good technology for that. I believe it has longer latencies and shorter range compared to the crazyradio.
    * Dual MCU: I believe the current MCU was only used at about 60% with the official firmware. If you upgrade this MCU and add a second one, what is the benefit? I would be scared that the added resources are just used to compensate for the overhead introduced just for the communication between the two. Additionally, it makes the development much harder to program two MCUs.
    * Compatible firmware for both flies: It is a noble goal, but might not be worth the pain. It might be better to start with a clean sheet of paper and at the end see if you can backport the changes to the old flie. As end-user I wouldn’t mind dealing with a new firmware. I touched all pieces of the current code (python, firmware for the copter, firmware for crazyradio) already and had not much trouble with it (meaning your code is well written). I would be up learning something new if that makes it easier for you!

    Other ideas:
    * One issue is that the barometer and magnetometer are not very stable on the current flie. Oliver used a neat trick of having two flies, keeping one on the floor while the other one is actually flying. He than used the one on the floor as reference for sudden barometer changes etc. I wonder if it would be possible to integrate a barometer into the crazyradio instead? An ultrasonic sensor on the flie would be even better (for indoors usage at least), but they just seem to be too big to integrate on the flie. I don’t really know how to improve the magnetometer. With the new motors it will most likely get worse on the new flie…
    * Did you look into alternatives transceiver modules? It would be very useful if a crazycam without separate sender module would be possible in the future. As far as I remember the current chip does not achieve a high enough bandwidth (but it does have a very good latency).

    Btw.: The Crazyflie is a really amazing product. I mainly use it to learn more about UAVs (algorithms, sensors, programming) and it helped me a lot already (and more to come!). That being said, I would be definitely up for buying the new version. Thank you very much for all the good work!

    • Hi Wolfgang,

      Thanks for the great comments! I will try to address skeptical things and other ideas in order:

      * BLE is actually pretty low latency, the radio part has 7.5ms latency. Though I share your skepticism about having a huge stack that we do not control. That is why we keep compatibility with the current Crazyradio and make a new Crazyradio with Power Amplifier: this is still the main communication link for PC and anything else than a phone. Though BLE may enable some fun new use case (like waking up the copter with a phone).
      * The benefit of 2 MCUs is that we use an MCU that has radio integrated. So we can unload the radio communication and have Bluetooth without affecting the main CPU. The plan is to have all ‘interesting’ parts in the main CPU and only radio and power managment in the radio CPU. This way the majority of the people will actually never have to look in the radio CPU, but being PM and radio allows for new exiting use case like powering up on radio events. As for upgrading the main CPU the current Crazyflie is fairly limited in RAM and that is the main thing that changing CPU solves, the extra CPU power is just a nice bonus and could allow for some firmware craze (I am thinking isolated user code to ease development of hacks …. :).
      * Compatibility is not only for the past but also for the future, we really want to get good at that so that we are free to develop quickly new and different hardware in the future.

      * Barometer in the radio, I would really like that! but the current design would not allow for it so we skipped it. There should be ways to filter a lot more the barometer to get a better stabilization already. As for the magnetometer we are looking at it but it is not an easy one either. At the very least it could be made better with an expansion board.
      * We have been looking at radio chips, getting over 2MBit per second would require a wifi chip and until now it is really too big (and adds latency and uncertainty of a big stack). Anyway to me it feel that keeping an independent radio link for the control is not a bad idea, it makes things simpler thus safer.

      Thanks again for the great comments.

      • Hi Arnaud,

        interesting point on separating the BT code – I was expecting that to be on some kind of Bluetooth chip anyways. I am still concerned about the latency. Just to be clear about what I understood so far (arrow denote some kind of communication):

        MCU_controlling -> Motors (GPIO)
        MCU_controlling <- All sensors (I2C etc)
        MCU_controlling MCU_communication (how do they communicate?)
        MCU_communication BlueTooth
        MCU_?????????? nRF24L01+

        One project I had was running all the controlling code on the PC. For that, I had to tune the whole communication for latency. There were actually two bottlenecks I couldn’t remove: USB and SPI between the MCU and the nRF24L01+. USB adds a latency of about 1ms (polling frequency), the SPI clock can run at 10 Mhz max (even though it was possible on my flie to overclock to achieve better performance). At the end I got about 3ms latency total, which somewhat keeps the flie in the air.
        If you guys would end up connecting the nRF24L01+ to the second MCU, this would add another non-negligible latency.
        Even though my particular project has rarely practical relevance, streaming data with low latency in general can be quite useful. Or even if that is not possible, streaming with a fixed (but well known) latency is the next good thing. This would help all kinds of machine learning and filter algorithms to correlate the data correctly. For those reasons I would really like to keep the radio chip directly connected to the controlling MCU.
        Btw.: I believe that this is currently also a huge benefit of the Crazyflie to the AR.Drone. The WiFi-chip there gives you 20ms +- ? of latency, which makes looking at raw data less useful.

        Thanks a lot for responding to the other questions/ideas so thoroughly!

        Wolfgang

        • Hi,

          We are using an nRF81522 as radio chip, it has a cortex-M0 that we will use for radio (CRTP and BLE) and also power management. This chip is compatible with both Crazyradio and BLE and its radio is internally connected to the main bus with DMA and direct interrupt (ie. not like the NRF24LU1 that has a 8051 internally connected to an SPI nRF24L01….).

          The main MCU handles everything the current STM32 handles minus power management (battery charging/voltage and ON/OFF). The radio MCU, the NRF, handles radio comm and power management. So when a packet is sent from the PC it is received by the NRF Cortex-M0 and sent via serial port to the main MCU. In theory the added latency should be minimal (the time required for 1Mbaud serial comm plus handling time by the CM0).

          Thanks for bringing latency and jitter up, actually I am currently working on the NRF code and I did not really think about latency but now I have an oscilloscope cabled to the setup so that I can take care of it. So far I have measured that from Crazyradio to main MCU I get between 2 and 3.5ms (this does not include USB). I still have a weird 1ms jitter in the NRF interrupt handling which I am tracking down. So far it seems that the latency can still be around 3ms.

          How did you measure the full latency including USB? This is something I would like to do as well.

          /Arnaud

          • Hi Arnaud,

            that sounds actually really cool! I would hope that you would essentially replace the SPI latency by the serial latency between the chips (and therefore no additional latency is added).

            I measured the latency purely in software with a simple trick: A custom python script sends a packet and waits for the respond. The custom flie firmware just echos received data. This is done in a loop and averaged. The latency is half of the measured average roundtrip time (and time is measured on the PC side only).
            I think this measurement should be sophisticated for your purpose. In practice, the radio chip has the issue that every communication partner either acts as primary sender or primary receiver. So what you measure is “a” latency, but not the latency to actually receive the echoed message. I have a custom firmware for the crazyflie and crazyradio avoiding this issue by adding another protocol which switches between primary sender/receiver mode on both sides. However, this is just for correctness but doesn’t really affect the measured latency.

            One important point is that the latency highly depends on the payload size of the packets you exchange (on the old flie because of the SPI). I got the 3ms with a payload of 16 Bytes rather than the full 32 possible Bytes. Additionally, you should test on a locally installed system (not a VM). VirtualBox added about 5ms latency just for USB. Windows vs. Linux did not make any difference for me as long as they are installed directly on the box. I can provide you the source code I have if that is of interest.

            Thanks,

            Wolfgang

  • I think Wolfgang did a good analysis :)
    Increasing the payload by 4x is better than 2x. Is 10x out of the question? How about using Li-S batteries? (I can dream…)

    I haven’t used the magnetometer raw outputs myself, but if the motor interference is like people say, some kind of remote mounting option would be nice. I can’t do this mod at home unless you put the sensor on a separate pcb for me…

    When I try to fly in ‘challenging wireless environments’, just about anywhere indoors, I get a lot of dropped connections, so I’d like to see a wireless link that gets dropped less.

    Are you looking at vibration isolation at all or is this just not an issue? Maybe you could put some heat shrink tubing between the pcb arms and the motor holders.

    Thanks for a great v1.0!

    • Hi Miles,

      Thanks for your comment!

      Li-S battery sounds really exciting, though this does not seems available to buy yet…
      We are still in the process of testing the payload. 10x at this form-factor is not realistic though (maybe later ;-).

      We are looking at the magnetometer, and making an expansion board is an option we are considering. We will certainly post about that later.

      The radio Power Amplifier adds a lot of radio robustness, for indoor use our first tests are very promising. Also the bluetooth is channel hopping in a pretty clever way which gives ideas future improvement of the Crazyradio protocol (this might be a lot of work but will benefits both 1.0 and 2.0).

      We are looking at vibration, we are designing new motor mounts and this is part of it. This is indeed something we have to be careful with considering that the new PCB is more stiff.

      • I did just buy a crazyflie 1.0 recently, but I think you guys are going find it a lot easier if you just switch to supporting only v 2.0 …
        HW improvements like magnetometer mountings and more payload just won’t be available for v1.0, unless the user adds them. Or are you going to offer trade-in / retro-fitting? I would pay for that.

        By supporting both platforms, you will have some unavoidable abstractions enforced, but is the additional time cost worth it?

  • may i suggest, it is better to have an option of having multiple quads controlled by a single pc or a single application. thanks

    • Hi Argel,

      We already have code on a development branch that supports connections to multiple Crazyflies from the same application/Crazyradio. It was implemented on request for a University using external vision-systems to control multiple Crazyflies. But it needs to be cleaned, stabilized and merged to the main branch.

  • Hi Marcus,

    With the stability issues concerning the barometer and magnetometer, please consider making a version of the Crazyflie that replaces the barometer and magnetometer with a GPS chip on the main board, which would also allow horizontal stability and pre-routed flights.

    • Hi,

      The area used by the barometer/magnetometer is much smaller than the area used by a GPS module with antenna and required groundplane, so having a GPS module on the board would not be possible to combine with the reset of the design. But using the expansion connector it will be possible to connect a GPS module expansion board.

  • Parrot is introducing a new quadcopter with two features that would be cool to see in Crazyflie 2.0:

    1. Ultrasonic sensor for precision flying near the ground
    2. Vertical camera at 60 fps measures speed by comparing previous image

    • Yeah, that would be really cool. The vertical camera is hard to implement, but the precision flying near the ground might be possible. We have been looking for a small ultrasonic sensor, but we haven’t been able to find any. If anyone has any tips please let us know :-) When it comes to size then other technologies might be better (like time-of-flight sensors) but you will not get the same range.

      The expansion connector gives the possibility to add more functionality in the future and also to try different technologies for ground detection.

    • Adding WiFi is a bit hard since things are very tight. But we have been looking into designing an expansion-board with WiFi. Do you have any ideas for uses-cases that we should keep in mind when we look into it?

      • Hi,
        I specialize in Wifi and Bluetooth development. I’m very familiar with the NRF from Nordic. If you are looking for Wifi take a look at the WICED from Broadcom, it is based on BCM chip and a STM32F103 for the baseband. This would be an advantage since the Crazyflie is based on the M4 from ST also.

        I think that Broadcom made the WICED open source also. WiFi will have several advantages over BLE.

        Cheers,
        Gil

  • I really like More Payload capacity for using a FPV setup. :) How about a voltage regulator to power 3.3v FPV Tx?

    Wish it could have an onboard GPS, too!

    • It will have more payload capacity, so it will be able to carry a small FPV. It’s hard to make the voltage stable/low noise enough not to effect the camera. We are looking into adding a step-up and/or filter on an expansion-board for this.

      Things are a bit tight on the board and we would like to have the antenna included with the GPS so that won’t be possible. But we have been looking into making a GPS expansion board with integrated antenna.

  • Was just about to place an order for the current version, then I saw this post. :-/
    Will version 2.0 be more expensive? I don’t need any of the features listed, except maybe for a more robust shape (never hurts) and maybe better motors for more acrobatic maneuvers. If 2.0 would be more expensive however, I’d just stick to the current version and order right away.

    • We still haven’t finalized the price, but it will probably be around the same price the current 10-DOF Crazyflie.

  • Very nice work! but is it possible to implement (on a pc) a sofware which can fly autonomously a quadcopter? or maybe some of them for do some automatic fly?? thanks

    • Yes it is possible and it is already possible with the current Crazyflie. We have Python API that allows to control programmatically the Crazyflie from the PC. Though to have real autonomous behavior (ie. like following a path) you would need sensor to get the position of the copter. We are looking at things like GPS expansion board that would make that possible outdoor. For indoor, having a camera locating where the coper still seems to be the easiest.

  • Hi,

    it sounds interesting.

    have you considered using the ST LSM9DS1 (integrated 3D accelerometer, 3D gyroscope, 3D magnetometer) or similar?

    Greetings,

    Alex

    • Yes we did some tests with the LSM9DS0 and it performs well but we believe the MPU9250 performs better and chose that one instead. It is still possible to make an expansion board with a secondary IMU if required :)

  • Hi Markus:

    Just now I got to know about the 2.0 pre-release, and I guess we missed the date. Is there a possibility that I can still order Crazyflie 2.0 kit and all parts (need 2 of everything) for some prototyping work and possible other options down the line?

    Can we be extended the discounted rate, and save some money, since this is our first foray into experimental drone technology. We are in the US and would appreciate any help you could extend on price and any issues with shipping. If you can respond soon, we’re ready to place an order immediately. One other question is we have seen some videos where you have training wheels around the propellers. How can we order a kit that includes the training wheels around the propellers. Since we’re amateurs at this, we think it might make sense for us to get something that is more collision proof.

    Really liked the videos that you put out and the enhancements in the 2.0 version. Seems lot less hassle now.

    Regards,
    Sri

    • Hi Sri,

      Sorry to hear that you missed the discounted pre-order. Unfortunately we can’t do anything about the discounted price now, since we have already decided to change the price.

      The training wheels are not available for sale, it was a hack that we did. Maybe we will do a product of it down the line. But the Crazyflie 2.0 is a lot more robust than it might look, so it will take a some touch crashes. But if you order then include some spare motor mounts.

      Best regards,
      Marcus

      • Hi Marcus:

        Thank you for the response. I’ll go ahead and order it now. And as you suggested, I will include some spare motor mounts in my order. Will keep in touch for plans down the line…

        If I have some specific requirements for custom work, what would you suggest are the next steps? How can we discuss pricing, feasibility etc. Skype/Email or other contact info would help.

        Thanks again,
        Sri

        • The beast way to get in contact with us is to drop us an email at contact at bitcraze dot se.

  • I am considering getting one of these as a Christmas gift for my 17 year old son who is an aspiring engineer with an interest in drones. Is this feasible? The site says they will ship in mid-December, but I was curious if a better date is available.

    • Hi Todd,
      Everything is running according to schedule and as things are looking now the units will start shipping in the second week of December. The shipping time will be the deciding factor so it might be worth paying for a faster shipping.

Leave a Reply

Your email address will not be published. Required fields are marked *