Guest blogging

2015-04-20 | Marcus | Leave a comment

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!

“Monday post” on a Tuesday?

2015-04-07 | Marcus | Leave a comment

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.

Crazyflie 2.0: Building a buzzer deck

2015-03-16 | Marcus | 3 Comments

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 :-)

[Show as slideshow]

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.

Input-device MUX

2015-02-23 | Marcus | Leave a comment

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

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!

Refocusing for 2015

2015-01-26 | Marcus | 5 Comments

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

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.

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]

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

Suggest a name for our expansion boards and win a Crazyflie 2.0

2014-11-10 | Marcus | 126 Comments

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

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.

Crazyflie 2.0 bootloader and USB

2014-11-04 | Marcus | 2 Comments

The production of the first Crazyflie 2.0 batch is still on track. Currently all the components are being purchased and when they are all in, the assembly will start. We are still busy preparing things for the production, but we have now slowly shifted over to software and firmware development. The last week has been spent implementing the bootloader and implementing our communication protocol (CRTP) over USB support.

The bootloader has gone from a simple piece of firmware to something that’s more complex. For the Crazyflie 2.0 we have a dual-MCU architecture, which means that we have to flash two MCUs instead of one. Aside from that we now also support bootloading via Bluetooth LE as well as the enhanced shockburst protocol. Another fact that complicates things is that the nRF51 uses a closed binary for it’s Bluetooth LE support, which means we have to take special care when upgrading it. But the trickiest part of all this is to make it safe so that it’s always possible to rescue the system without needing a JTAG/SWD dongle if something goes wrong. It’s important to get it right, since the bootloader is flashed during production it can’t be updated at a later stage without using JTAG/SWD.

The Crazyflie 2.0 only has one button and it’s connected to the nRF51. Instead of directly switching on/off the power to the platform like on the Crazyflie 1.0, the button is now multi-functional. Pressing it will turn on/off the power and put the nRF51 to sleep, but holding it down when powering on the Crazyflie 2.0 will affect the start-up behavior. By holding it down 1.5 seconds the bootloader will launch and by holding it down 5s the STM32F4 will start in DFU mode (Device Firmware Upgrade). One of the reasons for designing in the DFU functionality was to use it as a last resort to rescue the system in case we couldn’t make the nRF51 bootloader secure. Another reason for it is that we always try to design in lots of possibilities, even if we can’t find a use for it we are hoping someone else will.

CRTP over USB is something that’s been on our TODO list for at least 2 years, but we have never gotten around to it. One idea we had was for building a bigger quadcopter using a Raspberry Pi and a Crazyflie connected to it via USB. The Crazyflie would still be used as the real-time control board, but would receive commands on the USB. This would allow the Crazyflie to become a quadcopter control board using our normal Python API for commands from Linux. This way we could for instance create a higher level autonomous system. But now we needed it for one of our test-rigs, so we had to sit down and get it done. For the implementation we use a raw USB device (i.e class 0) where we use the end-points to send CRTP packets back and forth from the PC. Since a CRTP packet is smaller than a USB packet, there’s no need for flow control or any extra protocols, we just receive new packets on the OUT requests and send a new packets back on the IN requests (if there’s any available). This fits nicely into the current architecture of the Crazyflie Python Lib and the firmware, but it still needs some cleaning up. Once everything is done it will be merged into the main firmware as well.