Author: Marcus

During the design-phase of the Crazyflie 2.0 products last year, we sat down and had a long discussion about testing. In order to make sure things runs smoothly, it’s best to make sure that the hardware you’re designing can be tested properly in manufacturing. It could be as simple as adding a few test-points or a bit more complicated like making sure the product can run self-tests to cover some of the testing. There’s also other factors that count, such as the time it takes to test one unit. The better the tests are the less hassle you will get down the line and the happier your customers will be. The cost of finding a faulty board during production is very low, while finding faulty units in the field can be a costly process.

When it comes to the Crazyflie 2.0 we tried to think all of this though during the design-phase, walking though the schematic and making sure that everything could be tested properly in manufacturing. Since the new design is more complex then the old one, we also ended up with a test procedure with more steps and more things that could potentially go wrong. So we felt we needed some way to keep track of the products all the way from the production, to faulty units we might get from customers. Figuring out how faulty units might get passed the testing is crucial for improving it. But in order to acheieve this you need some way to track each board, thankfully for us this was already solved.

Both the Crazyflie 2.0 and all the decks fitted with a 1-wire memory have a unique identifier, a serial number. So these can easily be used for tractability. But without any information to trace it not very useful. So we built a simple framework for reporting as all of the test data back to our servers where we could easily look up what was happening. Here’s a screenshot of what it looks like for a tested Crazyflie 2.0 (1-wire memory products look similar):

cf2_testing

So what’s all the information? Well, here’s a quick rundown:

  • Run list: Each test that involves the serial is listed, so it’s easy to select which one you want information about
  • golden_sample: Serial of the golden sample unit
  • power and power_d: The measured power and power deviation from the golden sample
  • freq and freq_d: The measured frequency and frequency deviation from the golden sample
  • Tests: The framework allows for a number of tests to be defined, the result of each test is reported and if the test fails it’s possible to see in which step this happened
  • Console output: For the Crazyflie 2.0 there’s a special case of being able to see the console output when the unit is started

There’s of course a lot of other nifty features with having this setup, like getting production updates in real-time and being able to look at lots of statistics. All in all we’re pretty happy with the system, but there’s still lots of things to be added. Oh, and if anyone is wondering what happens if the internet connection is lost: It’s all saved locally as well (and uploaded when the connection is recovered). Plan for the worst and hope for the best :-)

If you’re interested in seeing what some of the rigs looks like, then have a look at this old post with some pictures from when we started up the Crazyflie 2.0 manufacturing.

 

If you haven’t already noticed, you’re not on bitcraze.se. You’re actually on bitcraze.io (and on HTTPS). After a long week of researching, testing and holding our breaths, we’re finally on our new domain. You would think that it’s not very complicated, but as always the hole is deeper than you think… We will keep our old bitcraze.se address for a long time to come, but it will be redirecting to the io domain (this includes email). The only thing we have left to move is the forum, and it’s on it way.

A couple of weeks ago we wrote about our Monday post tradition where we post a blog-post every Monday. Sometimes we spend lots of time testing and documenting to come up with something to write, and sometimes it’s just a quick note. And that’s the way it’s been for years. But last week one of our community members (Wolfgang) offered to write a post about what he’s been up to in the USC ACT-lab. We were really excited about the offer and it spawned the idea of letting more people write guest posts. We’re really happy to see that there’s lots of interesting things happening in the community and we would really like people to get a chance to show off what they have been working on.

So if you’re working on something with your Crazyflie and would like to write a blogpost about it, drop us an email and we can see if we can fit it in!

When we were developing the Crazyflie, going from our hackish prototype to a production version, we decided to start posting a blog-post every week. Back then we always used to meet after work on Mondays to work on our project, so we named our “once-a-week” update “Monday posts”. The purpose of the posts was to show that things were happening behind the scenes, even if things looked pretty quiet. Developing something from scratch takes a lot of time and there’s not always something interesting happening, so the Monday-posts covered all sorts of things related to the project. We’ve written about the good times, the bad times and everything in between; covering tech, manufacturing, our community and trips that we’ve done.

It’s not always easy to come up with something to write about every week. Sometimes we spend lot’s of time investigating and writing about something (like RPM measurements part 1, 2 and 3) and sometimes it’s just a quick note about what’s happening. But we’ve made a point of always posting something (even on Christmas eve), and have been doing so every Monday since January 2012. So we were a bit shocked this week when we realized that it was Tuesday and we have missed posting something yesterday. But don’t worry, we’re still here and things are still happening :-)

Next month we will be attending the Bay Area Maker Faire. Last fall we visited the Maker Faire in Rome and really liked it! While there we met people from Make that invited us to the Bay Area for the next Maker Faire. It’s an awesome event with lots of technology and geeks around, so we’re really looking forward to it!

In other news we will be switching domain shortly to our bitcraze.io domain and also switching on SSL for the blog/wiki/forum. Our old bitcraze.se will still be around linking to the same site. The move is planned for this week, but like always there might be something else happening that postpones it.

Don’t forget that we still have the CCW-propeller replacement running. So if you have a Crazyflie 2.0 from the first batch and you are having issues with your propellers, then fill in the form and we will ship you a set of replacement propellers.

While digging around in our office looking for a board we found a piezo buzzer we bought a while back. The reason for buying it was to test some buzzer functionality to the Crazyflie 2.0, but we forgot about it. But now that we found it again we got to work :-) We documented the build in our hacks section on the wiki, but here’s a quick run down.

  • Get a piezo buzzer and a Crazyflie 2.0 prototype deck
  • Solder it to the RX2/TX2 pins (pinout)
  • Clone and build custom firmware (dev-buzzer branch)
  • Play around with the parameters in the buzzer group
    • Set buzzer.effect for different effects
    • Set buzzer.melody for different melodies (with buzzer.effect = 2)

If you want to add new melodies or effects, have a look in the modules/src/buzzer.c file :-)

Here’s a Vine with the result (enabling sound is a good idea :-) )

On a side note Seeedstudio will start shipping out the CCW propeller replacements this week. If you still haven’t filled in the replacement form it’s not too late, here’s the form.

When the schools closed for vacation last week Minc (the company accelerator where we have our office) hosted a “bring-your-children-to-work” day. The original idea came from Fredrik who works at the Swedish Arduino office (in the same building as us). One of the goals whas to let children see cool technology and to get a chance to try it out. We quickly jumped on this since we thought it would be fun for the children to fly. But we realized there was a bit of a safety problem letting Crazyflies go wild all around the place. So we dug up an old idea we had been discussing (yes, there’s lots of those..), the input-device MUX.

The idea is to allow combinations of input-devices to work together at the same time. There’s a couple of use-cases for this that we have been discussing in the past, like combining Kinect with a controller so you can take control if you loose tracking. But the most obvious one is a “learning” mode, where you could control roll/pitch from one device and thrust/yaw from another. Or having the possibility to take over control “on-the-fly” (no pun intended…) from one device to another. For us it makes it a lot easier to give a controller to people and say “Try it out!” if we can take over control just in case things start going bad.

So we started hacking around a bit and got it working, but there’s still lots of work to be done. We revised the architecture a bit for the input-device layer in the Crazyflie Python client from what we posted before. The main change is the multiplexer, which enables the user to open multiple input-devices at the same time and combine them. The other change is to connect other devices “higher-up” in the architecture, like the Leapmotion. Instead of connecting it as an input-device with a mapping, it is connected directly to the MUX and will give well scaled values for controlling. The same goes for other devices such as the Kinect and network connections (which would allow to control Crazyflie throw the client from any other software).

input-arch-mux

 

The hardest part will not be to code this, it will be to design the UI and configuration of this functionality. We have some sketches, but any ideas are welcome! In its current state you just select a MUX, then the devices that you want to use (master first, then slave). But there’s no way of configuring what values are taken from what device.

Check out this album to see a few photos from the “bring-your-children-to-work” day!

During the last week there’s been lots of work, but we don’t have that much to show for it. We’ve spent a lot of time discussing what we should do during 2015. Last year there was a clear focus: develop, release and ship the Crazyflie 2.0. But up until now we haven’t really discussed what the goals for 2015 are. It’s not that we don’t have ideas, there’s always lots of ideas. It’s more about finding a common focus to work towards. It’s still ongoing, but there’s a few points that we know. We will of course continue the development (firmware, software, clients) of the Crazyflie as well as creating more expansions for the Crazyflie 2.0. For the expansion boards we’ve already talked a bit about it before, but for the firmware/software side we haven’t communicated our plan. The reason for this is simple, there’s not really been a plan for this. The main focus has been stabilization and creating clients for iPhone and Android. But now that it’s done we need to move forward with new features. If you have any feedback on this please let us know. Something that we are hoping to work on is ROS integration. (Edit: well, what do you know, this has already been started by Wolfgang Hoenig, the power of open source! Here’s a link) Once we figure out the plan we will let you now :-)

Fred, the main developer of the Crazyflie Android client, is doing a presentation about the Crazyflie at FOSDEM next weekend. Arnaud will be attending as well so if you would like to meet up, let us know!

But a few things happened during last week:

  • There’s a new release of the Android Client (thanks Fred!), so make sure to upgrade your apps!
  • We’ve added LED-ring settings to the FlighTab in the latest version on the develop branch of the client.
  • We released a bug-fix version of the python client. This new version fixes Crazyflie 2.0 configuration.
  • We added a some guideline for contributing to the client. We hope to streamline the contribution process to be more efficient at it. Tell us if you have any comments.

As for the RPM measurements and analysis we’re working on it, but it’s not ready yet… We are however making progress and it’s been very interesting, have a look at the thrust fixture we made :-).

cf2 thrust fixture

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.

 

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.

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 ... 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

As everyone probably knows by now, one of the new features of the Crazyflie 2.0 is the improved expansion port. It’s something that we’ve been putting a lot of effort in and we’re really looking forward to see what you will do with it. However a couple of weeks ago we realized something: We don’t have a good name for the expansion boards. Arduino calls them sheilds, the Beaglebone capes, but what should the Crazyflie’s boards be called? Up until now we have just been calling them “expansion board”, like “LED-ring expansion board”.  As far as we know this is the first flying platform that has this type of expansion port, and we think it deserves a cool name. Don’t you? We have been trying to come up with something ourselves and our current best idea is “deck”, as in the different levels on an airplane. But we’re a bit stuck there, we haven’t come up with something else and we think there must be a better name then “deck”.

So we thought that we would turn to our readers and community for help. In order to find a name to call our expansion boards we thought we would organize a little competition this and next week. For this week we would love to get some ideas in the comments for naming and then next week we will do a poll to vote for a winning contribution. To sweeten the deal we thought that we would  throw in a Crazyflie 2.0 developer edition (which includes debug-adapter, proto- and breakout board and a Crazyradio PA) to the first comment that holds the winning contribution. But before everyone beings posting ideas, here’s a few rules:

  • Only one idea per comment, if you have more then post more comments. By posting an idea of the name you give us the right to use it, otherwise there wouldn’t be much point in posting it ;-)
  • Our WordPress is set-up for reviewing posts before they are accepted, but once you are accepted as poster you can freely post. This means that some comments will appear directly and some won’t. But to judge whoever is first we will use the timestamp of the comment.
  • The best ideas will be collected in a poll next week. Then everyone will get a chance to vote for the name they think is best during the week and then a winner is selected
  • The winner of the poll is the one with the highest number of votes and this user will receive a Crazyflie 2.0 developer edition. But even if everyone likes the name we still reserve the right to use something else, but you will still get the price :-)

So start brainstorming and get the chance to be the inventor of the Crazyflie expansion boards name! Also the winner of a Crazyflie 2.0.. :-)

cf2 front rosette

At the moment we are just overloaded with work and we haven’t had time to be so active in the forum lately. We feel really bad about this and hope things will change as soon as the Crazyflie 2.0 is starting to ship. Until then we hope our community can step in and help us out, it would mean a lot to us. We have already got a lot of help from Chad, thanks a lot for that Chad and others! For urgent matters you can still reach us at our contact address found in the about page.

Oh, one last thing. The manufacturing of the first batch of Crazyflie 2.0 it’s still on track and no delays to report. When we have any updates on a final estimated shipping date we will let you know.