Blog

For a background on the “How we work” category, see Self organizing

We have done a session in the company on group development. We based our discussions on the IMGD model by Susan Wheelan (https://en.wikipedia.org/wiki/Group_development#Wheelan.E2.80.99s_Integrated_Model_of_Group_Development).

We wanted to understand more about the structures and forces in the team, what to expect and gain a better understanding of our everyday experiences.

According to the IMGD model a team evolves through a number of phases as it achieve maturity when it works together. The phases are

  1. Dependency and Inclusion
  2. Counterdependency and Fight
  3. Trust / Structure
  4. Work / Productivity
  5. Final (if there is a distinct final point)

We had some good discussions that we think will help us in the future.

This weekend we went to the maker weekend at Hx in Helsingborg and showed off the Crazyflie 2.0 flying with the Kinect. It’s an awesome demo for fairs since it flies by itself and looks pretty good. Below is a few photos from the event.

But this time we ran into some issues with the set-up. When we first developed this we were running the image acquisition and processing on Linux using libfreenect2, but we later switched to Windows. The reason is these three lines. These lines map the depth measurement to the camera measurements and gives a set of “world-coordinates”. This is needed, since the distances left/right wouldn’t be correct without taking the distance away from the camera into consideration. Without it a left/right movement close to the camera would give a much larger response than one further away from the camera.

So to solve the issue above we moved everything to Windows, which would kind of solve the issue. But we started experiencing lag in the regulation, which originated from lag in the image processing. After doing some more digging we drew the conclusion that there was a USB issue when using the Crazyradio at the same time as the Kinect v2. Once every couple of minutes the FPS for the video will drop really low (which results in CPU usage going down as well). But disconnecting the Crazyflie (i.e not using the Crazyradio) seems to solve this issue. To work around this problem we currently have a set-up where we use two laptops. Since we’re running ZMQ to communicate between the applications it’s a quick operation to split it up on multiple hosts. So the Windows laptop runs image acquisition and processing and the Linux laptop runs the control-loop and Crazyflie client for sending the commands to the Crazyflie.

When we were first developing this there was lost of things happening in the libfrenect2 repo, so this might be implemented now. Does anyone have any tips for this? We would love to be able to run the system fully on Linux with only one laptop :-)

During the upcoming months we will be attending both the New York Maker Faire and the Berlin Maker Faire, hanging around the Seeedstudio booth. So if you want to see the Crazyflie/Kinect demo live or just to hang out and talk to us then drop by!

MF15NY_Badge1 icon_Berlin

A new version of the Crazyflie PC Python client has been released, version 2015.08. It’s been a while since the last release of the client so there’s a long list of changes, including lots of fixed bugs. The main new features are:

  • Student/Teacher mode:  It’s possible to use two input devices, where one can take over control from the other. This can be used for teaching or for working with a computer auto-pilot (doc)
  • Control the LED-ring from the Flight Tab:  Now it’s possible to turn on/off the headlights directly with a click and to select the LED-ring effect from a drop-down (doc)
  • New LED-tab to set custom patterns and intensity: Enables the user to individually set the color of each LED as well as the intensity of the LED-ring
  • ZMQ access to LED-ring memory and parameters: Write patterns for the LED-ring or set/get parameter values from an external application using JSON and ZMQ (doc)
  • ZMQ input device: Simulate a joystick by sending axis values in JSON via ZMQ. This can be used to implement a computer auto-pilot using for instance the Kinect (doc)
  • Switched from PyGame to PySDL2 on Mac OSX/Windows and native input device on Linux
  • WiiMote support

The next step after the release is to shape up the code a bit, so we’ve started using Travis for building and continuous integration. The long term goal is to run Flake8 and unit-tests on the code, but we still have a bit to go. The way we’re working towards this is by slowly enabling more and more checking in Travis, fixing one type of errors at a time.

 

This is the first post in the new category “How we work”. The intention is to write about how we work and evolve our company, as opposed to most of our other posts that are about the cool stuff we build.

First we need to take a look at the the history. Bitcraze was started by Arnaud, Marcus and Tobias in 2011 when they created the first Crazyflie. They all had day time jobs at the time and were working on the project on their spare time. Forming the company and taking the step to work full time with Bitcraze was the logical continuation of the success of the first Crazyflie.

They are all passionate about technology, innovation and creating cool things, but the possibility of working with interesting stuff was not the only reason to leave the safety of employment, an important driver to form the company was that none of them really felt comfortable in the companies were they were employed. They all have worked in multiple companies where they had more or less the same bad experiences and they wanted something else, something better. To understand the problem, take a look at Dilbert about shipping and managers :-)

During the years there have been interns in the company from time to time. One of founders donned the role of the “boss” to manage the intern and tell him what to do and to make sure the expected result was achieved. The problem was that they did not felt very comfortable with this, after all they were becoming the type of boss they disliked in their previous jobs, they were moving in the direction they had been running away from.

What to do? The three of them had equal relationships, no one was managing anyone else, so maybe one solution was to not employ any more people and continue the way it was? No, more people can do more fun stuff and they wanted to expand. During this spring Kristoffer started to hangout on Minc (the incubator where we are located) and we stared to talked about this problem. We talked about values, drivers, what we want to get out of work and life. Kristoffer has a similar background with similar experiences from the companies he has worked at and they all realised they were looking for the same thing.

I (Kristoffer) became the first employee in Bitcraze, in June, and we have taken an important step in building the company we want want to work in. We don’t really know where we will end up, but know that it is a continuous journey and that we will change over time.

There is a book full of inspiration and clever insights that everyone, interested in this type of problems, should read,  it is called “Reinventing organizations” and is written by Frederic Laloux, read it!

We have taken one super-important decision that will be the basis for all future work:

No one in the company can decide what someone else should do

Yes, that’s right, no one is the boss and no one is a manger – we are self organising. We’re in this together and will evolve together.

DWM1000 nodes
Last hacking-Friday we have had some time to put together the DWM1000 boards we ordered during the summer. The DWM1000 from Decawave is an ultra-wide-band ieee802.15.4 radio transceiver that can very precisely timestamp packets arrival and departure. More simply it means that it is a standard and it can be used to implement a real time local positioning system: this could be really handy for the Crazyflie. We soldered all the boards and we got some basic ranging working on the nodes. The next step is to implement an opensource driver to be able to implement the ranging in the Crazyflie. We will keep you updated on the progress but in the mean time here is a photo of the prototypes:

DWM1000 nodes and deck

 

Things happening on the firmware side
Recently the commit rate for the Crazyflie 1.0/2.0 firmware has increased a lot. Some of it because of pull requests, great work, and some because we are starting to move in hacks and such on feature branches into the master branch. Our new college Kristoffer has taught us that having stuff on feature branches can be a bad idea, they tend to stay there. It is then better to have them compile switched and in the master branch as it is more visible and get a better chance of getting in for real.

Github crazyflie firmware contributions

 

Here are some of the recent thing going on:

  • A situation awareness framework originating from this pull request by fredgrat. It allows the Crazyflie 1.0/2.0 to react to triggers. Currently there is a free-fall, tumbled and at-rest detection. He recently also submitted an auto-takeoff functionality. Enable the functionality with the define here.
  • The beginning of a Arduino like API for the deck port. Currently GPIO and ADC are the only functions there but more will come.
  • Possibility to fly in rate (acrobatic) mode committed here. Support in the cfclient for this is being developed so currently one have to change the parameters to activate it manually.
  • Carefree, plus and X-mode implemented in firmware. There is also support for this being added to the cfclient.
  • Automatically switch to brushless driver. Motor driver being rewritten so it can be dynamically configured. This means that if the Crazylfie 2.0 is attached to the big-quad-deck it can automatically switch over to the brushless driver during power on.

Summertime are good times, less administration and more time to develop! As soon as things has been integrated and fully tested we will do a new release of the firmware and the cfclient :).

Starting this week we’re all back at our desks and after getting some time off, recharging our batteries, we’re slowly getting up to speed again. The summer has been spent on everything from improving our server environment to cleaning up both the firmware and the client. We’ve also been working on some new things, like the iOS bootloader and prototyping new decks for the Crazyflie 2.0.

Now it’s full speed ahead into an exiting fall with lots of things happening!

As a side note we are going to Maker Faire Berlin the 3&4th of October and we are planing to do a Bitcraze meet-up in Berlin while we are there. We started a thread in the forum to talk about it.

Big Quad Deck
Today we received the revised big-quad-deck PCBs. We made the connectors fit a bit better, and fixed the deck port connectors being mirrored,  and it is starting to look quite good. Next up is to implement the firmware functionality, which is the biggest work. If you have any ideas or suggestions on the design please let us know!

Big-quad-deck v2

Big-quad-deck v2 mounted

 

Big Quad Deck

So last week we received the first prototypes of the Big-quad-deck. With this deck it will be possible to transform the small Crazyflie 2.0 into a flight controller of a bigger quad. It does this by using some of the deck port pins to drive brushless motorcontrollers. This has been explained how to do using a prototype board in a previous post. For those that like it to be more convenient the Big-quad-deck will be a good choice. This will also use the one wire memory so that it will automatically detect the big-quad-deck board and configure it, that is the idea at least :-). So currently the dynamic motor driver is one of the things we are working with. Well that and fixing the layout of the board as there was a major mistake of mirroring the deck port connectors… no blaming :-)

big-quad-deck
Big-quad-deck with cf2

 

iPhone bootloader

The bootloader is finally implemented on iPhone. The change have been pushed to github and will be released before the next firmware release. The GUI is simple and hopefully clear enough:

bootloader-flashing bootloader-idle

The iOS app fetches the latest firmware directly from GitHub and the flashing operation takes about 10 minutes. All new code written for the app is written in Swift, there is an ongoing work to cleanup the app architecture to make it easier to implement more advanced functionality like log/param. We are actually thinking of converting the full app in Swift to make it easier to work with.

The next step is to implement the bootloader in the Android client, this will be one of our main tasks for next week.

The summer here in Sweden is what it is, barely warm enough to earning the name summer. Every year you hope that this year will be the good year and most often you get disappointed. It however encourage productivity instead of  lying on a beach which is a good thing. So as we are currently closing open tasks that never really got finished it doesn’t feel so bad :-). The list is however big with about 130 items so we will have to see how far we get.

One of the items to close was to merge the Crazyflie 1.0/2.0 firmwares. As the two systems are quite different it took a while to get them to compile after they were merged and even longer before they both worked. Now it has been tested for a while and we feel confident there are no major bugs. Therefore the merged software are now moved to the master branch and this is from now on where we will accept pull requests. So if you are developing for Crazyflie 2.0 please move to the master branch!

When it comes to differences on the firmware for 1.0/2.0 it is working similar as before. The new thing is that when you run make it will default to building the Crazyflie 2.0 firmware and to build the Crazyflie 1.0 firmware one needs to run “make PLATFORM=CF1”. The binaries produced will have naming cf1.bin and cf2.bin for Crazyflie 1.0 and Crazyflie 2.0 respectively.

cf2 build in VM

 

Arduino inspired deck API
At the same time as the merging work has been going on a Arduino inspired deck API is starting to develop. Arnaud put together the GPIO base and fredgrat from the community was quick at developing the analog part and sent us a pull request, thanks! If anyone else feels like contributing it would make us really happy. And who knows, another part of the world might also experience a shitty summer encouraging productivity (or shitty winter for that sake) :-).

We have had a lot of deck ideas for the Crazyflie 2.0 but not much time to finish anything, now we finally took the time to order batch PCBs at seeeds so we though we could show a bit what we are working on. Our idea is to order during the summer while some of us are in vacation so that we have all the hardware available when everyone comes back.

One deck that we are working on for a long time is the GPS deck:

ublox GPS deck

We had a prototype last summer but we never managed to get it to work properly: the antenna of the module we used relied too much on the ground plane and was disturbed by the proximity of the Crazyflie. Now we are using a more traditional chip-antenna which, we think, might work better in our design. We also added a u.fl connector to add an external patch-antenna in case the chip antenna is not good enough.

Lately we posted about connecting Crazyflie to a bigger quad frame to use it as a flight controller. We made an adapter deck for this purpose:

Big quad addapter deck

 

The deck can be on top or bottom of the Crazyflie and has output for 4 motor controller, a SPPM input for RC receiver, monitoring input for battery current and voltage, I2C connector and finally a GPS connector. We tried as much as possible to use standard pinout for the connector. Finally this board has holes spaced at 30.5mm, which is common for attaching controller boards.

Some time ago we have seen an interesting kickstarter that implemented local positioning, the pozyx project. While looking at it we found that the transceiver they are using is available, it is the DWM1000. We are really interested about this technology so we made a deck out of it:

dwm1000 deck

 

The DWM1000 tranceiver allows for time-of-flight measurement which would allow to make a local positioning system. This is something we have been looking at for a long time. Of all the prototype board this is the one that might take the most time to develop though, as the software work will be extensive.

Another board we wanted to do for a while is an Intel Edison adapter deck:

edison

 

One thing that delayed us to make this board is the use-case: the main use-case we see for Edison is to connect a camera but the Edisson does not have the MIPI interface required to connect a small and lightweight camera. On this deck we wired the USB port both to a uUSB connector and to breakout pins giving options on how to connect a USB camera.

Finally for the end we keep the simplest but very useful for development FTDI cable adapter deck:

ftdi

 

On the middle of this deck can be connected a standard 3V3 FTDI cable, and jumper allows to connect the RX and TX pins to UARTs on the deck port. It can be used both to debug the Crazyflie 2.0 firmwares and to debug other decks (for example to talk to the GPS deck).

We will keep you updated when we have received and gotten to work the boards (some will be much quicker that other as you can imagine).

A while ago we implemented something we called mux-mode for controllers, where the Crazyflie can be controlled from multiple controllers at once. Initially it was implemented the day before a “bring-your-kids-to-work” day at Minc (where our office is). The idea was that the kids would control roll/pitch from one controller and we would control thrust/yaw from another controller. But we would also have the possibility to take over roll/pitch by holding a button on our controller. It was a big hit and let’s just say the “take-over” functionality came in handy :-)

A couple of months later we started working with the Kinect v2 with the goal of automatically piloting the Crazyflie using it. Again the input-mux feature came in handy. Instead of having the kids controlling the roll and pitch, the autopilot was now doing it. This enabled us to work on one problem at a time, first roll/pitch then yaw and finally thrust. When we were finished the autopilot was controlling all of the axes and we just used the “take-over” functionality when things got out of control.

So far this functionality has been disabled by default, but last week we fixed it up and enabled the code. With this change we’ve renamed the feature to teacher/student and also changed the way mappings are selected for the client. Below is a screenshot of the new menu, but have a look at the wiki for more details. If you want to try it out, pull the latest version on the development branch. It’s a great feature if you know someone that want’s to try flying for the first time!

On a side-note we tried some other ways to mix the controllers, like one we called “mix-mux”. This would take the input from two devices and add them together, so if both give 25% thrust the total would be 50%. It was really fun to try, but impossible to fly (maybe we need to work on our communication skills…).