Improving the Crazyflie 2.0 I2C driver

2016-09-05 | Tobias | 2 Comments

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

Testflight with the BigQuad-deck and a GoPro

2016-08-15 | Tobias | 5 Comments

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.

[Show as slideshow]

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

Summer at Bitcraze

2016-07-04 | Tobias | Leave a comment

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

BigQuad deck just released as early access hardware

2016-03-07 | Tobias | 2 Comments

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.

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

#crazyflie #quadcopter shown at #MWC16 keynote by @HansV_Ericsson (around 23:20min) https://t.co/t8JxkKzh2g pic.twitter.com/XBrGmGBlwv

— Fred G (@fr3dg) February 23, 2016

Crazyflie 2.0 drones used in amazing TED talk

2016-02-22 | Tobias | 3 Comments

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!

Back from vacation

2015-08-10 | Tobias | Leave a comment

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!

Crazyflie Nano (1.0) and Crazyflie 2.0 firmwares are now merged

2015-07-27 | Tobias | 1 Comment

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.

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

Interfacing Crazyflie 2.0 with external motor controllers: Part 2 – Firmware

2015-06-22 | Tobias | Leave a comment

Continuing from last Monday post where the hardware wiring part was discussed we now move on to the software side. The brushed motors are controlled with a normal PWM where the duty cycle will adjust how much power goes into the motors. A brushless motor on the other hand needs more complicated controlling and uses it’s own micro-controller to handle this. These brushless motor controllers (BLMC or Brushless ESC) comes in many flavors and sizes but what is pretty common is how they are interfaced/controlled. This is inherited from how R/C receivers are controlling servos and how the receiver gets updates from the transmitter. This is a PWM where the width of the high pulse define the duty cycle. 1ms equals min and 2ms equals max and this is repeated every 20ms, thus giving an update rate of 50Hz. ServoPwm

This way of interfacing the BLMC is currently the most common way but interfacing with I2C, CAN, etc is getting more common.

To generate the servo PWM on the Crazyflie we have just reconfigured the timer a bit using a conversion macro so that setting the motor ratio of zero will result in a 1ms high pulse and setting it to max (uint16) will result in a 2ms pulse. The period time can be set with the BLMC_PERIOD define in motors.h. The standard period time of 20ms is actually a big drawback as it adds a latency from when a new output is calculated to when it is actually set. Therefore many motor controllers allow to shrink this period down to 2.5ms (400Hz) which result in lower latency and better flight stability.

Brushless prototype board

First you need to put together the brushless prototype board from the last post. The output will be generated on the pins marked BLMC 1,2,3,4 which should be connected in the same position an rotational direction as the brushed M1, M2, M3, M4 respectively. The output signal will be 0v – 3.0v which should work fine with 5V BLMC but it might be worth keeping that in mind.

Building the brushless firmware

The code which contains the brushless functionality is currently on the bigmerge branch so start by pulling the latest changes and switching to that branch.

git pull
git checkout bigmerge

Then to activate the brushless functionality enable the brushless defines

BRUSHLESS_MOTORCONTROLLER
BRUSHLESS_PROTO_DECK_MAPPING

This can be done by by either creating defines in config.h or by creating aconfig.mk file in the same directory as the Makefile with the content:

CFLAGS += -DBRUSHLESS_MOTORCONTROLLER
CFLAGS += -DBRUSHLESS_PROTO_DECK_MAPPING

The period time BLMC_PERIOD is by default set to 2.5ms (400Hz) so change that if needed.

Then build the firmware (make sure to clean first)

make clean
make

It will build for the Crazyflie 2.0 and for wireless bootloading by default. Put the Crazyflie 2.0 in bootloader mode by holding the power button until the blue led start to blink, then flash it with the wireless bootloader (Crazyradio required).

make cload

Causion!

You are now probably dealing with powerful and dangerous stuff so make sure to take precautions. E.g. don’t have propellers mounted when you test! When you have taken all the safety precautions do your first test. Remember the Crazyflie firmware has not yet been developed for big quads, it is all at your own risk! And another thing, even though the Crazyflie 2.0 can be controlled using a mobile device we don’t recommend this, use a Crazyradio.

Tuning

With that cautions being said it is great seeing a big quad fly and we will soon put out a video showing some of our builds. Our bigger quads have flown quite well with the stock tuning (PID parameters) but tuning should be done as well. Plenty of guides can be found on ways how to do it so I will not go into details here. The values can be found in pid.h and can be updated (but not saved) live using the cfclient. To save them the pid.h file must be changed and the firmware flashed again.

Interfacing Crazyflie 2.0 with external motor controllers

2015-06-15 | Tobias | Leave a comment

So last week we had a bit of fun connecting the Crazyflie 2.0 to a bigger quad frame. This is something we did a while ago with the Crazyflie Nano (1.0) , see this forum thread. This time it was the Crazyflie 2.0 turn and we wanted to use the deck port and the proto-deck so it would be easy to attach and remove, which is a great thing with the deck expansion port. Rewriting the current motor drivers would be the easiest way forward so finding 4 suitable timer outputs on the deck port was the first step. Looking at the pin mapping from the STM32F405 datasheet and the deck port you get something like this. Expansion deck pins

From this map one can identify a couple of timers and on pin 7,8 left as well as pin 1,2 right there are some suitable ones, TIM3_CH2, TIM3_CH1, TIM2_CH3 and TIM2_CH4 respectively. The timers will be used to generate a PWM control signal for the brushless motor controller (BLMC). As the deck port also has the VUSB input, from where the Crazyflie 2.0 can be powered (and charged), it can be externally powered from 4.5V – 6V. The Crazyflie 2.0 electronics consumes about 100mA without power optimization, can be good to keep in mind when powering it from something else. With all this information we took a prototype deck, a 2.54mm header, some small wire and got to work. As we already had a frame we wanted to interface with we tailored the output for this, but one could of course tailor it for other quad setups.

And viola, the final results looks like this.

We must inform you that this setup is very experimental, and as we are now dealing with dangerous things, much more care must be taken. So don’t do this if you don’t know what you are doing. The software also needs additional safety features before we think it is really usable in a bigger setup.

Next post will be about what to change in the software to make it all work, until then, happy hacking!

By the way Fred released a new version of the Android app last week, nicely done Fred!

Autonomous flight using Kinect2 for position control

2015-05-25 | Tobias | 5 Comments

So we are back at our office and the “great” Swedish weather. We don’t miss the California sunshine at all, we promise.

We have spent the last days documenting the setup we used to fly the Crazyflie autonomous using the Kinect2 for position control. It is still a work in progress but we think it worth sharing as we think many of you out there will be way better at improving it than we are. What we like so much with this setup is that it’s affordable compared to the professional systems such as VICON and PhaseSpace which makes it possible to play with at home, in the office or at school. It might be limiting in volume but until an affordable system such as the Valve’s lighthouse is available it is a pretty good alternative.

We have put all documentation on the wiki and hopefully it should be pretty straight forward to setup and get up and running.

The Kinect uses its IR time of flight sensor to detect the altitude of the copter. The image processing is detecting the copter and then gets its position. The controller can the compare the current versus wanted position and then sends correction to bring the copter closer to the wanted position. These correction are sent to the copter until a new image is taken by the Kinect and a new correction is calculated. This closed loop process will keep the Crazyflie in the wanted position.

Here is a short video showing it in action.

We also thought it would be nice to show some more pictures from the Makar Faire Bay Area and our visit to USC!

[Show as slideshow]