Author: Tobias

So we are now back in the cold and dark Sweden after about a weeks visit to a warm and nice Shenzhen, China. Every time we go there something major has happened. When we visited last time, about a year ago, cash was king. Now apparently payments are done with QR codes, even in small lunch restaurants. And I was kind of proud about the BankID and Swish payments we have here is Sweden, until now… Another observation we did was that there are now a lot of colorful rental bikes which can be found about everywhere and which can be rented for around 1 RMB/hour. A great way of resource sharing and pushing Eco-friendly transportation. It has it downside though as piles of bikes could be commonly found and e.g. written about by theguardian.

Aside from the above observations the Maker Faire Shenzhen was one of the reasons we came to visit. As Shenzhen is called the “the silicon valley for hardware” we had pretty high expectations when coming to the Maker Faire. Even though it was a great Faire it did not really reach our high expectations but it is growing fast and I’m pretty sure in a couple of years it is the Maker Faire to be at. A quick summarize, robotics was one of the top categories of products on the faire. 3D printers which are popular on European and US faires was not that common which surprised us. Now let the pictures do the talking:

 

We exhibited on the faire sharing booth with Seeedstudio where we showed an autonomous sequence on top of a table using the flow deck. By pressing a button, the Crazyflie 2.0 would take of, fly in a circle, come back and land roughly in the same spot. It was a very engaging demo catching many peoples attention and especially the kids. The kids constantly wanted to press the button and interact with the Crazyflie.

All the interaction made us very happy and next time we will try to add the obstacle avoidance deck to make it even more engaging.

 

Unfortunately the Crazyradio PA is out of stock in our store and is estimated back around December 1. Until then please checkout our distributors for availability.

 

A long time ago we got a request for a bright LED deck from a community member. When working with high powered leds heat becomes a problem that needs to be taken into account. From the community member we got suggestions of using one of the luxeon rebel leds and so we did. We designed a prototype pretty quickly but also realized that it is a bit harder than we first thought. If using a simple control scheme such as PWM and a mosfet the circuit is simple but brightness will be effected by battery voltage. Using a dedicated LED driver the brightness would be stable but the circuit more complicated and expensive. Trying to list the pros and cons:

MOSFET
+ Low complexity
+ Low cost
+ High efficiency
– varying brightness depending on battery voltage
– Might stress LED (could be solved with low ohm resistor)

LED driver
+ Stable brightness
+ Not as high efficiency (~80%)
– Higher cost
– Higher complexity

We ended up trying booth. The LED driver design failed due to that the battery voltage needed to be lower than the LED voltage + schottky and it is just in the middle. The PWM design half failed since the LED anode and cathode was swapped in the design but was possible to patch afterward. So at least we got something up and running.

The effect is very nice and it is what we used for the wedding show. The question now is, is this something we should finish and put in the store?

It was inevitable. At some point we needed to do a drone show of our own and wouldn’t the best occasion be on one of our coworkers wedding party! Well we have done demos before on maker fairs and conferences but never a one time show. This time we also had the possibility to collaborate with an acrobat, namely Arnauds brother, Adrien. Perfect match! The only problem was that we only had one day to pull something off and no possibility to rehearse anything with Adrien before the live show. Probably a piece of cake for a true artist such as Adrien but for newbies like us it was definitely increasing the stakes. There was no time to wank about that but better to get our hands dirty.

We wanted to create a choreography with a Crazyflie interacting with Adrien as he did some awesome acrobatics. The Crayzflie should be clearly visible with lights and we wanted it all to be synchronized to music. The final requirement was to minimize the equipment required since the wedding was abroad and we did not want to carry too much equipment.

We decided to use the Loco positioning system as a base to be able to do scripted flight and chose Two Way Ranging to reduce the number of anchors needed. We used only four anchors arranged as a 3×3 m square, three of them on the floor and the fourth 1.5 meters up on a tripod. Two Way Ranging works very well outside of the convex hull (which is really small in this case) but with the drawback that we only could position one Crazyflie – no swarm show.
For the visibility we used a prototype deck with a high intensity LED pointing downwards.

Photo by Eric Cunha

Again to minimize the equipment we decided to pre-program the sequence in the Crazyflie and put a start button on it to run the sequence. The piece of music to be used (composed by the groom during the bachelor party) was about one and a half minute long and the idea was to start the music and the sequence manually at exactly the same time and let them run without any further synchronisation.

We based our purpose built firmware on the demo code from ICRA earlier this year. It contained the sequencing but we had to add functionality to control the LED. We wrote a python script that generated data for the sequence that could be pasted into the firmware. A button was soldered on top of the Loco Positioning Deck and connected to a GPIO pin to be used as a start button.

We are engineers and not choreographers but after some trial and error we managed to create a sequence with light that was synchronized to the music. The overall idea was to start the Crazyflie on the floor in the center of the space, go out into the audience during the intro and turn on the light over Adrian (that was carefully positioned on the correct spot) and guide him onto the “stage”. While Adrien improvised acrobatics on the floor the Crazyflie circled around and above him with flashing lights. At the end of the music the procedure was reversed and the Crazyflie guided him back into the crowd and landed quietly in the center of the stage.

Photo by Eric Cunha

After dinner when it was time for the show we set up the positioning system and the crowd gathered. The first two attempts failed as it turned out that the ceiling of the venue was lower than expected and the Crazyflie hit a beam! What to do? We had a pre-programmed sequence that was going too high! We simply moved the anchors 30 cm away from each other and “stretched” the space to trick the Positioning system a bit. We had not tried this before and live hacking is a bit stressful, but we were possibly strengthened by one or two glasses of wine :-)

The third attempt was almost perfect with an incredible performance by Adrien! Phhuuu and what a success on the third attempt. Heart failure was close but did not kill us this time! :-) Maybe this is why we stay away from live shows and rather sitt down in a dark basement coding :-).

For a while now we have been selling the BigQuad deck which makes it possible to transform the CF2 to control a bigger sized drone. It does so by becoming the quadrotor control board, controlling external brushless motor controllers, which allows to scale up the size. This can be very convenient when trying out/developing new things as it first can be tested on the small CF2 and later scaled up by attaching it to a bigger quad. However for a more permanent setup it is a bit bulky, so we have been playing around a bit and designed something in the middle. The result is a stand alone control board targeting quads around 0.1 – 0.5kg.

We call it the CF-RZR as it is inspired by the smaller sized racers with some fundamental differences. It is designed with a higher level of autonomous functionality in mind and being easy to repair while still being fully compatible with the CF2 firmware and decks. Listing the biggest features of the current prototype:

  • Fully compatible with the CF2 firmware, expansion decks as well as radio.
  • Connectors to attach motor controllers (still possible to solder though) so it is easy to build and repair.
  • Power distributions built into controller board. (Max ~8A per motor controller though)
  • Motor controllers can be switched of by the system so the system can go into deep sleep and consume around 50uA.
  • Voltage input 1S-4S (3V to 17V)
  • Standard mounting (M3 mounting holes placed 30.5mm square)
  • External antenna for increased range

To summarize, the strength of the CF2 but in a little bit bigger package :-). Last week we got a chance to test fly it for the first time. We used a off the shelf racer frame, ESC and motors. At first it did not fly that well at all but after some PID tuning it became pretty stable and we had a lot of fun :-).

We would love your feedback, good/bad idea, what do you like/dislike etc!

Link to video


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