Author: Tobias


For those of you out there that are new to flying drones the height is often the most difficult thing to control. One solution to that problem is our newly released Z-ranger deck that can precisely measure the distance to the ground. Using this information the drone itself can stabilize on a desired target high and therefore become much easier to control. The Crazyflie 2.0 will then behave similar to a hovercraft sweeping over the ground or climbing stairs which is a ton of fun. As an in-action example please check out the video below where a Crazyfie 2.0 with a Z-ranger e.g. follows a flight of stairs :-).

For information of how to activate the height hold mode have a look at the getting started guide and for further details please check out the Z-ranger wiki page.

This week we got an email from David Gómez, a research scientist at Multi-Agent Autonomous Systems Lab, Intel Labs. He and his team have done some cool work on trajectory planning in cluttered environments that we think needs to be shared. For their research they used the Crazyflie 2.0 which we think is even cooler :-). Watch the video to see how the Crazyflie 2.0 find its way though narrow corridors and obstacle dense environments.
 

 

If you are interested in the full paper, “A Hybrid Method for Online Trajectory Planning of Mobile Robots in Cluttered Environments”, you can find it under Crazyflie 2.0 publications in the research section.

This year we decided to do a short Merry Christmas video. The video was done during one chaotic evening last week were both time and technology seemed to be against us. We are anyway happy with the result which we hope will spread some Christmas joy!
 

 
PS. All flights, except the first take-off, where autonomous using the loco positioning system. Code and documentation to come later ;-). DS

Merry Christmas from all of Bitcraze!

It’s been over six months since our last Crazyflie 1.0/2.0 firmware release and it was about time to do a new one. We have always had the idea to release often but can’t really say we have succeed. Something we are trying to improve but it has turned out to be really hard. Since it has been quite some time since the last release a lot of things have happens. To summarize the bigger ones:

  • There is now a Kalman filter option to use with the Loco Positioning system and hopefully later with other systems such as GPS and camera based systems (thanks to @mikehamer)
  • Improved altitude hold
  • Rewrites of low level code to improve stability
  • Architecture updated to support on-board position awareness
  • New streamlined I2C driver
  • Driver for Loco Positioning deck
  • CMSIS-DSP added to the firmware project
  • Improved PID tuning for the Crazyflie 2.0 (thanks to @theseankelly)
  • More reliable radio communication link

Please go to this page for instructions about how to upgrade to release 2016.09

CF2 release

ST Microelectronics have become quite known for their complex and somewhat buggy I2C peripheral, especially for their STM32F103 device (see errata). Where for instance the I2C interrupt priority needs to be the highest in the system, otherwise some I2C events might be lost which could cause random behavior. Since we use the STM32F103 for the Crazyflie 1.0 we have been using ST provided drivers as a solution for not having to take care of these cases. On the Crazyflie 2.0 we’re using the STM32F405 which doesn’t have the same I2C implementation and where ST has moved over to using the CPAL library for I2C drivers. This driver has turned out to be “bulky” and cause compatibility problems with our FreeRTOS due to handling of CPAL timeouts. Therefore we recently decided to see if we could write our own driver for the STM32F405 instead. How hard can it be..? Well after two weeks of pulling my hair and swearing it turned out to be a bit harder than we first thought. But now we hopefully have a slick and optimized I2C driver that works great for our purpose. Instead of polling it uses interrupts for I2C writing and DMA for I2C reading to keep MCU intervention low, leaving more processing power to Kalman filters etc :-).

Like I said, there was a few more obstacles along the way than we initially thought. So here are are some pointers I collected on the way:

  • I quickly dropped the interrupt event handling the ST-LIB suggest, I2C_GetLastEvent(…), because during the address event status register 2 (SR2) needs to be cleared (by reading it) after DMA has been setup (as noted in the datasheet when reading the fine print…). The I2C_GetLastEvent reads SR1 and SR2 at once which thus doesn’t work out.
  • This took most time to find, but using my I2C analyser I found that the I2C connection suddenly stopped after a small period of time with a START then STOP event of 3.9us. Doing a lot of trial and error a eventually found that the only way to trigger such a quick start-stop condition was if both the start and stop flag in the control register where set at once. I therefore tried manipulating the CR1 register only with a write operation and not a read-modify-write which solved the problem. This requires that you know what the whole content of the register needs to be when setting it. Luckily such is the case. A very strange behaviour but now it’s working, let’s leve it at that :-)
  • And finally don’t always trust the tools. I found that using my TotalPhase Beagle I2C analyzer I sometimes got corrupt transactions. I tried a lot of things in my I2C driver but I didn’t get why. I posted a topic in the ST forum to get some desperately needed help but then one of my colleges suggested that I should try a different analyser. Well there was no problems with the I2C bus according to that analyser. Turned out that the problem was that I was using the Totalphase Data Center software in a virtual machine. I couldn’t get it to run natively on Ubuntu, which must have been causing slow USB communication or something that the Data Center software doesn’t handle correctly.

    Random corrupt I2C transaction when used in VM

    Random corrupt I2C transaction when used in VM

Summertime is a good time to get outside and play :-). For a long time we have been having an assembled Turnigy tylon frame here at the office just lying around and it was time to put a camera on it and test its wings. It is not really a frame built to host a camera, and the least to put a gimbal on it but the size supports it so why not. So that is what I did, which included plenty of tape, zip-ties, drilling etc. Wouldn’t really recommend this frame and maybe that is why they quickly made a new version. I had a really hard time fitting the motors to the mounts which required getting some motor mount adapters and drilling into the aluminium mount to make them fit. To make the gimbal fit I made some wood extensions of the legs, as that was what I could find lying around. Anyway the result wasn’t that bad so I decided to give it a go. The first flight is always a bit nervous and especially with bigger quads so I took a lot of precautions and triple checked important things. The flight went well without any crash and I just used the stock PID settings when building the firmware. I flew it with the python client and a PS3 gamepad as I normally fly the CF2 and a was watching the signal strength carefully when getting far away. It will not survive a drop from 50m as the CF2 might. The basic functionality of the BiqQuad deck works well but I must admit that there are plenty more to implement before it has a rich feature set.

Unfortunately I’m not allowed to publish the onboard GoPro video I took as it captured some public areas (if I interpret the Swedish law correctly).

As summer is here, in the northern part of the hemisphere, in Sweden we like to have a bit of vacation to charge up with new energy. Thus the forward momentum will decline a bit but it also means less distraction from email requests, meetings etc. We take this opportunity to switch focus a bit and just as last year, we will put our effort in cleaning up. That means fixing bugs, improving documentation etc, things that normally doesn’t get prioritized enough.

Along with the cleanup, the Loco positioning system is still our highest priority and we work full thrust to get it in the hands of users. Hopefully we will be able to start shipping the first systems in the beginning of next week and more widely the week after that so make sure to stay tuned and sign up for the newsletter if you are interested! Have a great summer everyone!

Upcomming loco positioning indoor explorer bundle

The upcomming early access loco positioning indoor explorer bundle

Early Access

For a long time now we have discussed the BigQuad deck which basically can transform your Crazyflie 2.0 into a bigger quad by attaching it to a bigger frame. The first simple prototype we did using the prototype deck was made already in the fall of 2015. As it turns out the BigQuad deck requires plenty of software and ads a whole new level of caution. That along with limited time and resources has slowed down the development progress. To overcome parts of this hurdle we came up with the early access program. It is basically hardware which is ready, but the software is in a early and rudimentary state. This way eager development users can get hold of the prototypes we are working on and to try out the latest and greatest designs. The benefits are mutual, we make it possible for our users to get started with new hardware and development at an earlier stage in the development cycle, in return we hope the community will help out with important feedback and contributions towards finalizing the product. First out in this program is the BigQuad deck.

BiqQuad deck

We run each “early access” project as an open project on github, in this case the repository is named early-access-big-quad-deck and is the focal point. Since many changes in the Bitcraze software stack spans over multiple repositories (firmware, clients, radio and so on), this “early-access” repo is where to post issues or feature requests, discuss solutions and what to implement. We love to collaborate with the community, join the fun!

The current sparse user documentation of the BigQuad deck is put on the corresponding wiki page. Let’s add more!

Crazyflie family

Crazyflie family

Crazyflie 2.0 used in Ericsson Mobile World demo

Erricsson have presented a demo for Mobile World congress using the Crazyflie 2.0 and the wireless charging deck.

The crazyflie was also present for the keynote in the hand of the Ericsson CEO. I is always nice for us to see Crazyflie being used for cool demo and events :-).

If you haven’t watched it already, make sure to watch the TED talk “Raffaello D’Andrea: Meet the dazzling flying machines of the future”!

We are super excited to see that they use the Crazyflie 2.0 drones for the firefly swarm demo in the end of the talk. After all, our goal is to enable people to test their ideas, so this awesome demo makes us thrilled!

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