March 3rd, 2015
arnaud No Responses
Some time ago we decided that it would be nice to have a name for the Crazyflie expansion boards, a bit like the Arduino shields or the Beagle bone capes. We organized a poll on our website, that ended with cheating so we organized a local vote and flykit won. In second place was the deck. Over time we started liking deck more and more since it fits better with the actual look of the boards. Finally we pushed ourselves to decide on one and we went with deck. This comes from the naming of floor in ships, planes and (more importantly) space ships. We also though we could write a bit about the Crazyflie 2.0 expantion capabilities and the deck architecture. In this post we are forcing ourselves to say deck instead of expansion port, lets see how it goes :-).
On Crazyflie 2.0 decks can be installed both on top and bottom. Each deck we make has a symbol indicating its correct orientation:
Lots of signals and functionality has been routed from the Crazyflie 2.0 to the deck port:
The OW pin is used to connect a One Wire memory with a specific data format, this allows Crazyflie 2.0 to know which board is connected and to activate automatically the right driver, so this is kind of plug-and-play. This is currently used to enable the LED ring deck driver. The aim is to develop an API that will allow anyone to easily create decks that would be automatically detected by Crazyflie.
The deck architecture opens lots of possibility. We’ve already made the LED ring that faces down, but it would be possible to make one that faces up as well. In the future we hope to have have ground facing camera, GPS boards, Camera boards. And more than one can be installed at the same time. We also investigate doing bigger expansion board for example to have Crazyflie acting as the brain for a bigger quad.
On the firmware front, we are finishing the merge of Crazyflie 1 and Crazyflie 2 firmware. Currently the source code for Crazyflie 1 and Crazyflie 2 is on two different branches which makes it harder to maintain both of them. We have come so far that we have a working merge that can compile and fly either for CF1 or for CF2. There are loots of cleaning up to be done before it can be pushed though but we are giving a heads up as the changes will affect forks that are doing rebase as well as pull requests.