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.

Crazyflie 2.0 expansion board template

2014-10-20 | Marcus | 1 Comment

First of all, thanks to everyone that helped us out during the pre-order. Today we are finishing the last details and tomorrow Seeedstudio will launch the production of the first Crazyflie 2.0 batch! It’s been a hectic couple of months here at Bitcraze and it feels great to finally have reached this point. For the first batch we will manufacture more units than were pre-ordered. So from now up until the units are ready we will continue the pre-order, but without the discounted prices. The first batch is planing to start shipping mid-December. We are prioritizing the discounted pre-order but will ship everything as soon as possible.

Last week we published the iOS prototype code for controlling the Crazyflie 2.0. This week we are publishing the Crazyflie 2.0 expansion board template project. The project is done using KiCad and includes the schematics, the footprint mapping and an initial layout with the connectors in the correct place. The license of the template project is CC-BY 4.0. In order for users to more easily see what their expansion board will look like and how it will fit, we have included the Crazyflie 2.0 board outline as well as some key components that might interfere.

We are really excited to see if any cool expansion board projects will come out of this template. So if you feel like giving it a try then head over to GitHub, clone the repository and add some cool stuff. Any ideas of what to do?

Crazyflie 2.0 exp template

Last week of the Crazyflie 2.0 pre-order

2014-10-13 | Marcus | 1 Comment

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

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

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

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

Crazyflie 2.0: The tiny modular quadcopter

2014-10-07 | Marcus | 15 Comments

This weekend we spent at the Maker Faire in Rome and got to meet lots of fellow geeks and makers. Even though it was busy times at the Bitcraze booth, we got a chance to walk around a bit and see other projects. It’s really inspiring to see what people come up with! It was also the first time we got the chance to show off the new Crazyflie 2.0 to the public and the feedback was really positive. We have realized that we might be a bit wide in our description of the new platform. There’s lots of new features that we are very eager to talk about, but maybe we should focus a bit more on the biggest improvements. With two weeks left on the pre-order we have been trying really hard to get some extra attention for the new platform, but haven’t really succeeded yet. This might be one of the reasons.

So even though there’s lots of new features we would really like to highlight the new expansion port. It’s been something that we have been talking about internally for a while now and we are really excited that we managed to fit it in. Like we wrote in an earlier post we used some exotic use-cases to figure out what to include in the expansion header. For example this resulted in the ability to charge the battery from the expansion board, like we are doing with the Qi wireless charging expansion board. Since the Crazyflie 2.0 has the ability to connect multiple expansion boards (both on top and bottom) we also needed some way to determine what boards are added. So one of the pins in the port is used as a 1-wire memory buss. Each expansion board has a 1-wire memory that allows identification of the board, it’s revision and what resources it uses. This way we can adapt the features available from the computer client or mobile device when the platform is connected.

Below is an overview of what’s available in the expansion port:

For the pre-order we have managed to include 4 expansion boards: the LED-expansion, the Qi wireless charging expansion, the breakout expansion and the prototyping expansion. Aside from these boards we also have some prototypes of more expansions. Before the pre-order we were working really hard on a GPS expansion board, but in the end we didn’t think the current prototype had enough precision to launch. We reached about 10-20 meters accuracy with locking times of about 2-3 minutes and didn’t have time to spin another prototype. During the fall we will work on perfecting the design so we reach a level of performance that we feel is good enough.

We also have a prototype for a distance sensor to be used for precision landing. After looking for a solution for a while we finally found the VL6180, a time of flight sensor from ST. The range is not very long, but combined with the high precision pressure sensor mounted on the Crazyflie 2.0 we think the result can be very good. We also have an uSD expansion that we are currently testing.

After getting feedback from the visitors we met at the Maker Faire we have also decided that we will be designing an Edison adapter expansion for the Crazyflie 2.0. The Edison board is fairly small and light, so it should be possible to design an expansion board that has the 70-pin expansion connector featured on the Edison. Our plan is to use some of the interfaces in our expansion board to connect to the Edison, like I2C, UART and SPI.

Last but not least we are also working on an analog FPV expansion board. It’s still just an early prototype, but we think it’s something that a lot of users might be interested in.

[Show as slideshow]

As we will continue making more and more boards we also hope the community will take the opportunity to do so as well. We will soon release templates for KiCad making it really quick to get started. What board would you like to make? Let us know what you think about the new expansion port. Do you have any ideas for boards or any comments about our planned ones? We would love to get some feedback!

We would also like to say congratulations to Mihir Garimella on being one of the winners of the Google Science Faire 2014 with his project the Flybot! He used the Crazyflie to work on escape maneuvers similar to those of fruit flies. Really great work!