Working on a new input device architecture

2015-01-19 | Marcus | 4 Comments

Today we were supposed to post the next part of the RPM measurements. But since we are’t finished with the analysis yet we thought that we would post some info on what we are working on. Since Christmas we have been working on and off on a new architecture for the input devices in the Crazyflie Python client. A while back we started discussing the possibility of “hooking in” different backends that could be used for input data like LeapMotion, Gamepads, sockets and so on. It’s something that we have been wanting to do for a while, but other things have always been prioritized. But during Christmas a forum request triggered the work. Users wanted to be able to change the LED-ring effects directly from the controller. We had some code for this lying around, but since the switch from PyGame to PySDL and Linux devices this wouldn’t merge easily. So we thought we might as well take this opportunity to implement what we wanted :-)

Below is a brief overview of the architecture and a description of the different parts:

Crazyflie Python client input device architecture

Each backend is implemented as a single Python file in the directory /lib/cfclient/utils/inputreaders. When the application starts up each of the files are picked up and initialized, so for anyone that wants to create their own backend it’s pretty easy. A list of successfully initialized backends is created. Once the application is started a scan of the input devices will be requested. Each of the backends will do it’s own scanning and together a big list of available devices will be created. Each of these implement a specific API for opening, closing, scanning and reading the device by using their respective backends. The higher layer (Input) now has a list of available devices that it can open and read. But to make sense of the data read from the devices a mapping needs to be created to set which axes/buttons effect what parameters. There’s a number of parameters that can be changed, the main ones being roll/pitch/yaw/thrurst for controlling the Crazyflie. In order to make the mappings as flexible as possible each mapping has a scale and offset. It’s also possible to split axis, so two axis on the device can effect the same parameters (like having yaw on bumper buttons). Normally (for PySDL2 and linuxjsdev) all axis are between -1 and 1 and buttons are either 0 or 1. But using the mappings it’s possible to have other values, like for the LeapMotion. When the LeapMotion is read it return the roll/pitch/yaw/height as read from the device. Using the mappings offset and scaling these values are transformed into usable values for roll/pitch/yaw/thrust. Here’s a step by step walkthough of how a device is read:

Input: Each 10 ms the open device is read
InputDevice: Asks the backend for reading the device
Backend: When read two arrays are updated, one for the buttons and one for the axes. If the device is event based all the events are consumed before updating
InputDevice: Takes the raw values from the backend, iterates though them and updates a list of highlevel parameters accordingly. This returns a dictionary with keys like roll/pitch/yaw/thrust
Input: Pre-processes the values of the parameters, like only calling callbacks when there’s a state shift (button 0->1 or 1->0), slew-rate limiting the thrust, dead-band and trimming
Input: Calls special callbacks (such as alternative functions and emergency stop)
Input: Calls callbacks registered for control data (roll/pitch/yaw/thrust). For this there are two registered callbacks, the UI and the Crazyflie object (crazyflie.commander.send_setpoint(…))

So how does this help the original problem of setting parameters from buttons? In this change we have also included two new buttons, alt1 and alt2. These can be mapped just like any other buttons in the configuration dialog. When these buttons are toggled (0->1 and 1->0) all the registered callbacks are called. The idea is not mapping them graphically to specific parameters, it’s for enabling users to easily (with one line of code) register for these and be able to act on them. For instance setting the LED-ring headlights on/off or changing the effect of the LED-ring.

When we are poking around in the code we are also looking at fixing some other issues, like how to handle when Bluetooth controllers go out of range (see this topic in the forum). We are hoping that everything will be finished and merged when the next release of the client. Also a big thanks to everyone that’s contributed code for the input reading, it’s made things a lot easier!

Today we also released new firmware for the Crazyflie 1.0 and a new Crazyflie Python Client. We have now fixed the client compatibility issues between the Crazyflie 1.0 and 2.0. We are also happy to report that next week the LED-ring and the Crazyradio PA should be back in stock.

Measuring propeller RPM: Part 1

2015-01-12 | Tobias | 1 Comment

We have had numerous request to get a transfer function from the motor PWM output to propeller RPM. The next step would then be to get the propeller RPM to thrust transfer function as well. With that it is easier to do calculations on the system and mathematical models. So this and probably next post will be about how to obtain this function and also give a bit of insight in how one can do development with the Crazyflie 2.0.

First thing how do one do propeller RPM measurement? A quick search on the internet and you will find that using an optical switch is a common method. I also found this guide written for Arduino which was a great start. Since I preferable wanted to measure the RPM while flying the switch needed to be small and lightweight. I found two types that could be useful. A slotted type and a reflective type. The reflective type, QRD1114, is small and promising but would it work? I got some of each type just in case.

[Show as slideshow]

Now the optical switch needs interfacing and power. Sparkfun made a good tutorial using the QRD1114 sensor so I will not go into details. Since we use 3V instead I adjusted the resistor for the LED to 82 ohms instead. This will give me ~20mA emitter current. I also played a bit with the sensor output pull-up resistor. If you go with a to strong pull-up, the sensor will need a lot of light to pull it down and if it is to week, it will rise to slow. 12k pull-up seams like a good compromise in my lighting conditions.

As a first thing I wired it up on a breadboard using the Crazyflie 2.0 breakout board to get a sense if it would work or not. My finding by measuring the output signal with a multimeter is that it is pretty sensitive to surrounding light but that could be solved by flying in a dim room since it is mainly intended to be used for research.

[Show as slideshow]

Now it was time to build a circuit using the prototyping expansion board. I also multiplied the circuit 4 times so I can measure all 4 motors. The inputs I use was TX2, RX2, IO2 and IO3. This because they are all connected to timers so I could use the input capture timer functionality later when I get to the software part. Bending the legs on the QRD1114 was a pretty fiddly job but worth it as it came out so cool in the end. Before I connected it to the Crazyflie 2.0 I measured the current draw and it all seamed OK, ~80mA (4 x 20mA). I also double checked all the connections since it is easy to put a lot of time thinking it is a software fault later if things aren’t working as they should.

[Show as slideshow]

As a first test I just turned on one of the motors at a PWM of 10000 and measuerd the sensor output with a scope. The black color of the propeller wasn’t so good so I searched around in the office and found some reflective paint we used a while ago. I painted the backside of the propeller and it made a big difference. In the pictures below you can find the scope picture using a 12k pull-up and some pictures of the painted props.

[Show as slideshow]

Next part I will start doing the software and analysis so stay tuned!

Crazyflie 2.0 radio communication

2015-01-05 | Arnaud | 1 Comment

The Crazyflie 2.0 supports two types of radio protocols out of the box: ESB (Enhanced ShockBurst) for Crazyradio/Crazyradio PA USB dongle compatibility and Bluetooth LE for mobile devices. All Crazyflie 2.0’s are shipped with a radio bootloader, able to update virtually all the different parts of the firmware running in Crazyflie 2.0. We thought we would do a post to explain a bit further how it all fits together. Even though the Crazyflie 2.0 supports Bluetooth LE, the preferred way is to use the Crazyradio/Crazyradio PA when doing development. Flying via Bluetooth is very practical since there’s no additional hardware needed except for a mobile device, but the Crazyradio/Crazyradio PA has minimal latency, more bandwidth and works easily with computer. This makes it ideal for development and other advanced usage.

(On a side note, some of our products are currently out of stock (like the Crazyradio PA and LED-ring). We have started the next batches, so they should arrive soon. Until then have a look at our distributor page to find our products.)

Crazyflie 2.0 architecture

For the radio of Crazyflie 2.0 we choose the nRF51822. The great thing with this chip is that it integrates a radio compatible with our existing Crazyradio USB dongle as well as with Bluetooth Low Energy. The nRF51 also integrates an ARM Cortex-M0 MCU enabling radio protocols to be implemented directly in the chip. However this MCU is not powerful enough to be used by itself in our quadcopter development platform, so we put a powerful STM32F4 Cortex-M4 168MHz on the side to do the heavy work.

The nRF51 mainly handles radio and power management and the STM32F4 handles all the rest: flight control, expansion port, log, param, etc. As far as the radio is concerned the nRF51 act as a bridge: CRTP packets are received by the nRF51 and sent unmodified to the STM32F4 and the STM32F4 sends raw CRTP packets to the nRF51 that transmit it by the radio. This means that the STM32 firmware is unaware of the physical communication protocol, it can be Bluetooth, Shockburst or something else, it makes no difference it is still CRTP packets. CRTP is the protocol used to control Crazyflie, it encapsulates all commands and messages exchanged between the client and the Crazyflie.

Enhanced Shockburst (ESB)

Enhanced Shockburst is a radio physical protocol implemented in some Nordic Semiconductor 2.4GHz radio chips. In the nRF24 chip, used by Crazyradio (PA) and the original Crazyflie, this protocol is implemented in hardware and we have little control over it. The nRF51 used in Crazyflie 2.0 offers more control on the radio physical packet and ESB since it’s implemented in software instead.

ESB handles ack and retries: The Crazyradio sends a packet on a given channel and waits for an ack. If a Crazyflie receives the packet without error it sends an ack packet. If an ack is received, the Crazyradio can send the next packet. If no ack is received Crazyradio will automatically retry by sending the same packet again. The current implementation will retry to send a packet forever, so all packet are guaranteed to be transmitted as long as a Crazyflie is in range. Packets are sent back by the Crazyflie by adding a data payload to the ack packet. Close to 80 different channel can be used and every packet is sent with an access address, so more than one Crazyflie could share the same channel.

Enhanced Shockburst using the Crazyradio (PA) offers the lowest latency that can be expected. The minimum latency to send a packet is estimated to about 2ms (1ms minimum for USB and 1ms measured latency for the radio at 2Mbps without any retries). With the Crazyflie 2.0 and the Crazyradio PA it also offers the maximum range with 20dBm power output.

For the original Crazyflie there is an implementation of the E-sky RC transmitter protocol. This permits controlling the Crazyflie directly from an RC transmitter. It is technically possible to implement this protocol in the Crazyflie 2.0 nRF51, but it hasn’t been done yet.

Bluetooth Low Energy

In the Crazyflie 2.0 Bluetooth low energy is implemented as a CRTP bridge: CRTP packet are written and read using Bluetooth. This simplifies greatly the implementation, but does not make full use of the Bluetooth LE functionality. It is planned to add more Bluetooth capabilities for things like communicating the battery status and being able to switch ON or OFF the Crazyflie with a mobile devices.

On the nRF51 side the Bluetooth functionality is implemented using the Nordic Semiconductor S110 Bluetooth stack. This stack runs independently of the firmware. Nordic calls this a softdevice and it’s a fitting description of how it works. It almost looks like a hardware device from the firmware point of view as it is not linked into the main firmware.

However we do not currently have the right to distribute the supporting files for the stack, so unfortunately you will have to download them yourself if you want to compile your own nRF51 Bluetooth firmware. To do so you must own a Nordic Semiconductor development kit. Even though some of the kits are pretty cheap, we do not like this situation at all so we are working on solving it. However we made sure that it is possible to compile the nmRF51 firmware without Bluetooth, to avoid the added dependencies. This means that you can still build your own nRF51 firmware to work with a Crazyradio/Crazyradio PA.

Bootloader/firmware upgrade

The Crazyflie 2.0, like the original Crazyflie, is upgradable wirelessly with radio. The radio bootloader has been enhanced to work both with ESB and Bluetooth LE. Both nRF51 and STM32F4 can be upgraded and it is even possible to upgrade the nRF51 Bluetooth stack and bootloader.

Currently the bootloader is working with Crazyradio on ESB. Bluetooth implementation for iPhone and Android is still work in progress. The STM32F4 can also be upgraded via USB and so, for people that does not have a Crazyradio, the first Crazyflie 2.0 firmware upgrade has been released for USB DFU as well as the classical radio bootloader update package.

Looking forward to 2015

2014-12-29 | Tobias | Leave a comment

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.

xmas_2014_cf2

Expansion board Architecture and Bluetooth firmware

2014-12-22 | Arnaud | 3 Comments

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.

New Crazyflie 2.0 firmware and updated Android client

2014-12-16 | Arnaud | Leave a comment

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.

Hectic release week!

2014-12-08 | Tobias | 11 Comments

This week is going to be an exiting week! Crazyflie 2.0 has started to ship and we are pushing out a lot of code during the week. We wish that we would have gotten more time to work on the code before releasing it, but all three of us have been really busy with production. With the first units now shipping we can finally switch focus to software and documentation. Since there’s quite a few source code projects we are releasing, they each get its own bold headline below. As we role out the different releases we will update this post and post the link in social networks.

iOS Client

iOS joystick screen – Download on Appstore

This is our first ever iOS app, and it’s just been released. It got accepted just in time and you can get it from the AppStore, free of course. Currently it is pretty simple, you can connect to a Crazyflie 2.0 and fly it with thumb controls. There is a settings menu where you can adjust sensitivities and configure mapping. The app is all open source and the code can be found here on Github.

Android Client

Android joystick screen – Android app on Google Play

This is more or less the same as the client that has been available for the Crazyflie Nano Quadcopter, but now we have added Bluetooth LE support. Since this app has been manged by our community member Fred for a while it has more functionality then the iOS app, such as tilt control. One cool feature is that you can connect a gamepad with a USB-OTG cable to the phone to get better flight precision with real thumb sticks. The app is all open source and the code can be found here on github. Thanks to Fred Sauer the Crazyflie app has been available for a while now on the market, but now we have taken over the ownership of it. Due to a change in the certificate used to sign the app you will have to re-install the application to get the latest version (market link).

PC Client

The PC client written in Python has got some new features to support the Crazyflie 2.0. E.g. the bootloader in Crazyflie 2.0 is different as it now contains two MCU. It also has a EEPROM which needs new functionality, but other then that we are trying to keep things as common as we can to make things easier. The code is all open source and the code can be found here on Github. Edit: We have made a new tag (2014.12.1), source-code is available here and a windows installer is available here.

Crazyflie 2.0 Firmware – STM32

This firmware is based from the Crazyflie Nano Quadcopter firmware and the aim is to merge the old and new code, but we haven’t had the time to do it yet. Therefore it is now located in its on crazyflie2 branch on Github. We plan to merge them together but more work needs to be done before this is possible, a perfect job for the cold and dark winter months here in Sweden.

Crazyflie 2.0 Bootloader – STM32

This is the code that can flash new code into the STM32F405 MCU. Now the data comes from the nRF51 MCU over the uart, so the booatloader had to be updated. The code is all open source and will be released later this week on Github.

Crazyflie 2.0 Firmware – nRF51

This firmware is completely new and handles the radio communication (Bluetooth LE and Shockburst, compatible with Crazyradio). It also handles the power management and the expansion boards 1-wire memories. The code is all open source and will be released later this week on Github.

Crazyflie 2.0 Bootloader – nRF51

The program to load new code into the nRF51 over the radio link. It also boots the STM32 in bootloader mode and serves as a radio gateway to be able to flash it. The bootloader handles Bluetooth and shockburst so that not only the PC client but also future version of the mobile apps will be able to update the Cazyflie 2.0 firmware. The code is all open source and will be released later this week on Github.

Hardware

We have not yet had time to finalize the hardware files. We are reorganizing the kicad lib and we need to clean things up properly. The hardware projects therefor have to wait, but the schematics has been released if anyone needs to see how things are connected.

Winner of the expansion board naming contest

We have now done a local vote. We are almost hundred percent sure this voting was not tampered with. And the winner is… Flykit. So even though Flykit got a lot of “proxy” votes online it seems the local people liked the same thing. Deck finished second, strange, maybe the voters had read the online vote results… Anyway congratulations to Ramin who will receive a Crazyflie 2.0! We still have not decided if we should go with Flykit or Deck for the real expansion board name. As soon as we have decided we will let you all know.

A week in Shenzhen

2014-12-02 | Marcus | 6 Comments

Starting up production and doing the first batch of a product is always problematic, no matter how well you try to plan it. So just like for the Crazyflie 1.0, we decided to pack our bags and leave for Shenzhen for the production of the first batch of the Crazyflie 2.0. When we launched the first Crazyflie we tried to take things easy and minimize the number of products we launched at once. But for the Crazyflie 2.0 we went all in and launched 13 new products at once. Some of these are just spare parts, but many are more complex products. It’s been a few busy months to say the least :-)

Production

The production timeline that we have been working towards for the Crazyflie 2.0 has been pretty tight. So our main goal with this trip was to help out in any way possible to make sure that everything was going smoothly. Like I wrote above, we are launching a fair amount of boards at the same time. The Crazyflie 2.0 itself is of course the most complex, but also the Crazyradio, the LED-ring and Qi expansion requires a lot of attention. Aside from that there’s also the debug-kit and prototype/breakout boards as well as all the spare parts that should be inspected. Everything started off very well and things was going ahead of schedule, somehow we became the ones slowing things down. We had to work almost around the clock to catch up. In the end though it was all worth it because on Saturday it all came together and everything was following schedule.

Delivery

Since things are running according to the schedule it means the products will start to ship Monday the 8th of December. So if you have chosen Air mail there is a big chance it will reach you before X-mas, but not guaranteed. If you have chosen a faster method, DHL or UPS you will get your pre-order before X-mas.

Getting to Shenzhen

Going from Sweden to Shenzhen is a pretty long journey, but that doesn’t mean it has to be super expensive. Since Shenzhen is very close to Hong Kong, the easiest for us have been to fly to Hong Kong and take the bus/train to the border at Lo Wo (map). The bus ride takes over an hour, but it’s filled with beautiful views of Hong Kong so time passes quickly. Once you are at Lo Wu you can walk across the boarder to mainland China and go directly down into the metro. While entering the metro it’s easy to pick up a Chinese SIM card for your phone and a metro card. The Chinese SIM we got was about 15 USD which also includes 300 MB of data. If you are on your way to Seeedstudio then make sure to check out their guide for getting there.

Huaqiangbei

If you are an electronics enthusiast or just like electronics you need to visit Huaqiangbei in Shenzhen. It is the worlds largest electronics market and things that can’t be found here, I’m not so sure it can be found at all. The prices are extremely low but be aware of fake products and quality problems. E.g if you buy a cheap 32GB SD card you can almost be sure it is a fake and only holds a true 4 – 8GB, so we can’t recommend you to get one there. Many guides has been written about Huaqiangbei so we won’t write yet another one. If you want to read more we can recommend dangerousprototypes guides.

Expansion board naming contest results postponed yet another week

After checking the voting log we could see that most of the naming alternatives had been tampered with. We had some idea that maybe we could filter out the suspicious ones but our attempt failed so we are back on square one. We still want to give away a Crazyflie 2.0 kit to the winning name but we more or less decided to have a local voting process with people aorund our office instead. We will therefore need more time to select the winner. As we won’t be able to ship the award unit before the 8th of December anyway so we decided to postpone it yet another week to be able to gather the local votes, which will be a lot harder to tamper with. So be sure to check back next Monday.

[Show as slideshow]

It’s been Shenzhen frenzy

2014-11-25 | Tobias | 5 Comments

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!

Expansion board naming vote

2014-11-17 | Marcus | 18 Comments

Wow, we are a bit overwhelmed with all the naming suggestions we got for our expansion board last week. It’s fun to see so many people joining in and having an opinion, thanks to everyone that dropped a suggestion. After discussing it we decided to put favorite suggestions into a poll and see what our readers likes the best. Make your voice heard and take part in the voting below! And in case anyone missed it the winning contribution will get a Crazyflie 2.0 developer pack.

What should be name of the Crazyflie 2.0 expansion boards (tampered with)

Flykit (36%, 242 Votes)
Deck (32%, 215 Votes)
Bitboard (11%, 77 Votes)
Crazymod (6%, 39 Votes)
Payload (4%, 26 Votes)
Flieboard (3%, 19 Votes)
Pod (3%, 19 Votes)
Fliekit (2%, 16 Votes)
Companion (1%, 10 Votes)
Avionic (1%, 10 Votes)
Fliemod (1%, 5 Votes)

Total Voters: 678

Loading ...

In other news we are spending the week in Shenzhen in China, visiting Seeedstudio and helping out with the testing of initial production samples. So far everything is on track and today we got to fly the first mass produced Crazyflie 2.0! Here’s a picture of it before we broke it loose and got it into the air. Next week we will post lots of updates and photos from our trip. Until then, don’t forget to vote :-)

first_cf2