Finally here is the last, and probably most interesting part of the “Measuring propeller RPM” series, see part 1 and part 2 to catch up. Now it is time to gather some data and display what we get.

As described in part 2 we are now able to measure each propeller RPM with the expansion board we made and with the code we added. This can, as been described in part 2, be logged to a csv file using the cfclient. Next thing would be to do something useful with it. To do that we use Octave (very similar to Matlab but open source). The first thing that could be interesting to know is the step response for a  motor and propeller. This was acquired by altering the Crazyflie 2.0 firmware a bit to do a step from zero to max trust and then to zero again. It was done on M1 with a fully charged battery.

The motor goes from zero to 25k rpm in about 180ms, quite impressive. What is also interesting is that the falling slope in the range 15k to 20k rpm is quite similar to the rising slope in the same region. The inertia of the turning parts of the motor and the propeller is quite low so this energy will quickly be consumed when the motor and propeller starts to coast. This is good as it will lead to better maneuverability.

Knowing the RPM is great but it is the thrust that is most interesting. So to get this we need a rig where we can measure it. We made one out of a bottle to which we glued a prototype board on that we put on a scale, not a perfect rig but simple and probably good enough. Then we made a program that ramped up the PWM from 0% to 93.75% in 16 steps with stabilization disabled. We also connected the Crazyflie 2.0 to a power box where we could measure the current. The program would increase the thrust in 16 steps and during each step we took a reading of the thrust and current. The RPM, voltage and PWM was logged over the cfclient at the same time. Some manual work was needed afterwards to correlate the data and get it into a table. While in the table a lot of interesting plots could be graphed.

The first one would be the rpm and thrust as this transfer function is interesting. By using the Octave polyfit function the second order fit could be found. It is a pretty accurate fit and with this fit it is easier to get the thrust, as the rpm is the only variable needed, which is easier to measure. The fitting function returned by polyfit is:

Thrust (in gram) = 1.0942e-07*rpm² – 2.1059e-04*rpm + 0.15417.

Here is a combined plot of some other interesting parameters. Notice that the voltage graph is ~quadratic, the current ~square-root and the power linear. From the power graph one can find out that the thrust efficiency is about 3.8 gram/W. Not super good but pretty good for a quad of the Crazyflie 2.0 size.

Another interesting graph is the graph of the flight time. Since we know the power consumption and the battery characteristics we can plot a graph of an estimated flight time depending on the battery size. This graph makes the assumption the battery capacity per weight is 32mAh/g.

And finally the transfer function we set out to find, the PWM to thrust. The problem with this is that motors are controlled by voltage (PWM) and the voltage comes from the battery, which varies with the power taken from the battery due to internal resistance. Therefor we made two fitting functions, one based on measured battery voltage while applying PWM, and one based on the PWM. Looking at the graph one interesting thing is that the polyfit is making a better fit (red curve) for the PWM. I would have expected the opposite. Something that we will have to investigate further. Or maybe one of our readers have the answer?

On the wiki we will update this analysis with some more details and the raw data so if you are interested please have a look! Hopefully using this information we can make the Crazyflie 2.0 fly even better.

On the news side there is a new version of the Android client available on Google play, thanks Fred! Also Fred has uploaded the slides of his Crazyflie lightning talk at Fosdem 2015.

We finally got some time to follow up on the previous blog post Measuring propeller RPM: Part 1. In this post we will continue where we left of and describe a little about the software we have implemented.

The sensor output, as showed in the scope picture, can be connected directly to a digital input. We connected them to the expansion port signals TX2, RX2, IO2 and IO3 as they are all internally connected to a timer with capture capability, TIM5_CH3, TIM5_CH4, TIM3_CH2, TIM3_CH1 respectively. With the capture functionality it is possible to trigger a timer read on events like a pin change. Thus it is not that difficult to calculate the period time of the input signal which can be used to calculate the rpm. Setting up the timer to run at 1us tick was a bit tricky but manageable. With 1us tick it will wrap around, it’s a 16 bit timer, so after 1us * 65536 = 65.5ms. This means the slowest rpm that can be measured is about 458 rpm (1/(2*65.5ms)*60). The division by 2 is because there are 2 blades on the prop. Since hovering happens way over 458 rpm it doesn’t matter much that we can’t measure any slower speed.

Next thing was to setup the capture compare. The ST library already provides the basic API, TIM_ICInitStructure, so it was more or less just a matter of finding how to configure it. The capture part of the timer can do quite fancy things but in the end we decided it was easiest to just use it the simple way, were it stores the timer value in the corresponding capture compare register on a predefined edge. As the register values will be overwritten when the next pulse comes we setup a interrupt handler to take care of the result. What the interrupt handler ended up to do was to copy the timer value, use that to calculate the rpm and then save the result in a variable. It turned out to be good to do an average of the two latest values as the pulses was not fully symmetrical because of the two blades. This was then done the same way for each propeller input and, voilà, rpm measurements was taken. (Well, there certainly was a bit of hair pulling before it all worked but in the end it worked! Love that feeling)

Getting it down to a cfclient was a piece of cake using the logging framework. We just defined the variables to be logged, setup the logging in the cfclient and it could all be plotted. The variables was defined using the macros below.

LOG_GROUP_START(rpm)
LOG_ADD(LOG_UINT16, m1, &m1rpm)
LOG_ADD(LOG_UINT16, m2, &m2rpm)
LOG_ADD(LOG_UINT16, m3, &m3rpm)
LOG_ADD(LOG_UINT16, m4, &m4rpm)
LOG_GROUP_STOP(rpm)

Then by connecting the the Crazyflie a log configuration could be created called “motor” containing the rpm values as well as voltage and PWM.

After that by opening the Log Blocks tab the “motor” log configuration could be enabled a written to files. The data log output folder can be opened from the menu by selecting “Settings -> Open config folder”. In my case in “logdata/20150202T17-29-49/motor-20150202T17-35-09.csv”. This CSV file can then be imported to a program such as Octave, Matlab, Spreadsheet etc for further analysis.

The data can also be plotted in real-time using the plotter as in the picture below. Hmmm, interesting, the Crazyflie 2.0 seems to hover at about 19000 rpm with the RPM measurement board attached.

The idea was to do the analysis part in this post as well but it turned out to be a little bit to much, therefore stay tuned for the final analyzing part!

This week is going to be an exiting week! Crazyflie 2.0 has started to ship and we are pushing out a lot of code during the week. We wish that we would have gotten more time to work on the code before releasing it, but all three of us have been really busy with production. With the first units now shipping we can finally switch focus to software and documentation. Since there’s quite a few source code projects we are releasing, they each get its own bold headline below. As we role out the different releases we will update this post and post the link in social networks.

iOS Client

iOS joystick screen – Download on Appstore

This is our first ever iOS app, and it’s just been released. It got accepted just in time and you can get it from the AppStore, free of course. Currently it is pretty simple, you can connect to a Crazyflie 2.0 and fly it with thumb controls. There is a settings menu where you can adjust sensitivities and configure mapping. The app is all open source and the code can be found here on Github.

Android Client

Android joystick screen – Android app on Google Play

This is more or less the same as the client that has been available for the Crazyflie Nano Quadcopter, but now we have added Bluetooth LE support. Since this app has been manged by our community member Fred for a while it has more functionality then the iOS app, such as tilt control. One cool feature is that you can connect a gamepad with a USB-OTG cable to the phone to get better flight precision with real thumb sticks. The app is all open source and the code can be found here on github. Thanks to Fred Sauer the Crazyflie app has been available for a while now on the market, but now we have taken over the ownership of it. Due to a change in the certificate used to sign the app you will have to re-install the application to get the latest version (market link).

PC Client

The PC client written in Python has got some new features to support the Crazyflie 2.0. E.g. the bootloader in Crazyflie 2.0 is different as it now contains two MCU. It also has a EEPROM which needs new functionality, but other then that we are trying to keep things as common as we can to make things easier. The code is all open source and the code can be found here on Github. Edit: We have made a new tag (2014.12.1), source-code is available here and a windows installer is available here.

Crazyflie 2.0 Firmware – STM32

This firmware is based from the Crazyflie Nano Quadcopter firmware and the aim is to merge the old and new code, but we haven’t had the time to do it yet. Therefore it is now located in its on crazyflie2 branch on Github. We plan to merge them together but more work needs to be done before this is possible, a perfect job for the cold and dark winter months here in Sweden.

Crazyflie 2.0 Bootloader – STM32

This is the code that can flash new code into the STM32F405 MCU. Now the data comes from the nRF51 MCU over the uart, so the booatloader had to be updated. The code is all open source and will be released later this week on Github.

Crazyflie 2.0 Firmware – nRF51

This firmware is completely new and handles the radio communication (Bluetooth LE and Shockburst, compatible with Crazyradio). It also handles the power management and the expansion boards 1-wire memories. The code is all open source and will be released later this week on Github.

Crazyflie 2.0 Bootloader – nRF51

The program to load new code into the nRF51 over the radio link. It also boots the STM32 in bootloader mode and serves as a radio gateway to be able to flash it. The bootloader handles Bluetooth and shockburst so that not only the PC client but also future version of the mobile apps will be able to update the Cazyflie 2.0 firmware. The code is all open source and will be released later this week on Github.

Hardware

We have not yet had time to finalize the hardware files. We are reorganizing the kicad lib and we need to clean things up properly. The hardware projects therefor have to wait, but the schematics has been released if anyone needs to see how things are connected.

Winner of the expansion board naming contest

We have now done a local vote. We are almost hundred percent sure this voting was not tampered with. And the winner is… Flykit. So even though Flykit got a lot of “proxy” votes online it seems the local people liked the same thing. Deck finished second, strange, maybe the voters had read the online vote results… Anyway congratulations to Ramin who will receive a Crazyflie 2.0! We still have not decided if we should go with Flykit or Deck for the real expansion board name. As soon as we have decided we will let you all know.