Category: Software

It’s been another week with lots of stuff going on. Shortly after the Crazyflies were delivered things really started to accelerate. Now there’s lots of cool stuff going on and we are trying to keep up :-) Here’s a few things from the last week.

  • People have started looking at the pressure sensor that is mounted on the 10-DOF version. phiamo is working on a hover-mode using the pressure sensor. There’s more information and code in this post.
  • Contributions to the Mac OSX install instructions have been made and they are now usable.
  • Another frame has been designed by bscott and is uploaded on Thingiverse. No doubt, next on the Bitcraze shopping list is a 3D printer.
  • The USB3 issue on the Crazyradio has been fixed so there’s a new version of the firmware. If you don’t have any problems with this then don’t update, because there’s a slim chance of bricking the radio (see the wiki page). The firmware is available here and instruction on how to update it are here.
  • A nasty bug on Mac OSX has been reported. When loosing connection to the input-device the output will become 100% thrust and it will not stop until the radio looses connection. This issue has been fixed in the latest version from the repository.

The Crazyflie Nano Quadcopter kit 10-DOF is out of stock again but there’s still some 6-DOF units left. We are currently planning the next batch but until then there will be a few more units (~50) that will drop into the Bazaar.

In order to have a better overview of which problems that have been solved and which still needs attention in the Support forums we are setting up some guidelines, which will be done during the week. So if you are hanging around in these forums or you want to get some support, then please have a look at the instructions.

If you live in the south of Sweden and you are interested in the Crazyflie drop by Javaforum next Tuesday (21/5) where we will be presenting.

 

It’s been an incredible week seeing people from all over the world getting their Crazyflies into the air!! We have seen videos of people doing crazy stuff we never thought of, 3D models of cases and frames on Thingiverse and of course a lot of images of people unpacking and assembling their Crazyflies. The wiki is receiving some well needed updates and everyone is helping out answering questions in the forum. It’s really great for us to see this project come to life after such a long time and as far as we can tell we have a lot of happy users, even though there’s still a few people struggling with issues.

Like we said last week, this is the first time we distribute the software/firmware/hardware widely and there’s a few bugs that has been found. We are currently correcting the most important ones and will post updates for the firmware and software once we fix enough of them. If you want to follow the progress drop by the bug tracker on Bitbucket for the PC-client, Crazyflie and Crazyradio.

We are doing our best to answer questions and give support in the forum, but there’s a couple of issues that we would like to highlight to make the assembly and usage easier for everyone. Please be careful with your new Crazyflies, they are not unbreakable.

  • Check for shorts after solderingAfter the motor wires has been soldered make sure to inspect for shorts and especially to the resistors, red highlighted area, in the picture as it can damage the digital voltage regulator. This will show up as that the blue LEDs wont light up and the other LEDs will be dim. To fix this the regulator U9 will have to be exchanged. It is the SOT23-6 package in the picture.

 

 

  •  The Crazyradio doesn’t work on USB3 ports but a fix is on the way. Until then the work-around is to use USB2 ports.
  • If the Crazyflie crashes upside down there is a chance the motor bearing gets depressed. There is a protection for this and that is to carefully glue a spacer between the motor and the propeller, similar to what we have done in the picture. That will prevent the propeller from pushing on the bearing but will instead be pushing on the spacer which will absorb the force much better. The spacer needs to be higher then the motor bearing else it will not work that well.

 

  • Loading an already existing input-device configuration in the PC-client does not work, the best is to start from scratch (see this issue). Also when configuring the input-device you will have to map all the axis and buttons before you can save the configuration (see this issue). For more information on device-input configuration see this page on the wiki.

Unfortunately the production of the new motor-mounts has been delayed and they will not be available for order until next week. But the kits that are currently in stock still contains a spare motor-mount.

Happy flying!!

So finally it’s Monday again :-) As you might have noticed the Crazyflie got released for pre-release last week! All our code has now been pushed onto Bitbucket and our repositories can be found here. Since we did some restructuring of the code before pushing there might be some bugs that we are currently hunting. The Crazyflie is mainly a development platform where you can either add new features/hacks or improve the current features. We added a feature wishlist to the Wiki for features that we never had the time to implement and also to add new features that you suggest. So if you feel like getting you hands dirty there’s still lots of stuff to do! In order to make development easier we have:

  • Wireless Radio Bootloader: This will enable you to easily update the firmware in the Crazyflie. The bootloader cannot easily be erased without using  a JTAG so don’t worry about bricking your Crazyflie when testing new firmware
  • Crazyradio USB bootloader: The Crazyradio contains a USB bootloader for easy update of the firmware
  • Well documented: We are currently doing our best to update the documentation on the Wiki and our goal is to create a well documented platform
  • Parameter setting/getting: This is detailed a bit more here but in short it’s a framework where you can easily add parameters/variables that can be set or fetched from the client. The tab in the client where you can change PID controller parameters on the fly is implemented using the parameter framework.
  • Variable logging: This is also detailed a bit more here but in short it’s a framework where you can easily log variable values to the client. You select variables that you want to log and the rate you want to get them and the Crazyflie will automatically send you updates for these variables. The attitude indicator and roll/pitch/yaw values on the FlightTab are implemented using the logging framework.

In the upcoming week we are planning on posting a video showing some of these features.

We’re still busy with administrative stuff and preparing everything for release so sorry for the lack of tech posts. Hopefully there will be more time for those later :-)

But we did spend one night this week trying out something that we have talked about forever: Using OpenCV to auto-pilot the Crazyflie. For controlling the Crazyflie from a Python scripts it’s just a couple of lines and then you are ready to go. Add some object tracking to that and you can make an autonomous Crazyflie…or you could make a crashing one like the video below… The video is shot using a Playstation Eye lying on the floor. The camera has good potential for tracking since it’s low resolution, cheap and can do up to 120 fps. The plan is to use the size of the detection to control the thrust and the center of it to control the roll and pitch.

Unfortunately the latency was too large for doing a control loop for roll/pitch/thrust so it crashes. But hopefully in the future we, or someone in the community, will have some more time to spend on this. We think that it definitely has potential!

Part of this test was also to have another project where we use the Crazyflie Python API to make sure that it can easily be dropped into other projects.

 

Last week we received one of the new raspberry pi and we wanted to start doing something useful with it. One idea that came directly in mind was to control the copter with it. As it has 2 USB port it should be possible to use one for the gamepad and one for the Crazyradio dongle.

The Raspberry pi running Debian the operation ended up being surprisingly easy: Just apt-get install python, pygame and pyUSB and we where able to run our old script. By adding pyQT we where even able to run the GUI out of the box (it is still a bit heavy though as the GUI is not yet very optimized when receiving fast log informations). So we just made a “headless” version of the control software, launched it automatically with a udev rule when the radio is inserted and it was done!

We can power the Raspberry pi with a USB battery and we now have a small portable ground station for the Crazyflie. We have also proven that our PC software tools are easily portable to other architecture thanks to Python and all its libs. Currently the software is tested on Windows and Linux (x86 and ARM), but it should also work on MAC.

Raspberry PI controlling the Crazyflie

One of the goals during this project has been to only use open-source tools for development. The main incentive for this is that we want everyone to be able to take part in the development and look at the all the parts of it once it has has been released. Also it was a great opportunity to see how far we could push open source free development software in a non-trivial embedded project.

Some of the tool has worked great and some has caused us some headaches since we have worked with the proprietary alternatives during the daytime. Our conclusion is that a project like this is definitely doable, but some parts does still require more work (and some frustration). The open-source tools for firmware development and PC client are state of the art and could be used instead of there proprietary counterpart (of course most of the time there is no GUI and some more setup or manual job might be required, but this comes with the benefits of a greater flexibility). However the hardware design tolls are still behind there (expensive!) proprietary counterparts and often requires a great deal of efforts to reach the wanted result.

Of course it’s great that these open-source alternative exists and that a lot of great developers puts time into making them. Without them this project would not have been possible!

The firmware – For firmware development we use a wide number of applications: gedit, Eclipse, Mercurial, gcc, make, openOCD and gdb. On Crazyflie we run  FreeRTOS. As we built the development environment with cross platform tools the development can be done seamlessly on Linux or Windows, on the console or with Eclipe. The radio dongle has been developed from scratch (ie, just from the datasheet) with the help of sdcc to compile for the 8051 contained in the nordic chip.

The client software – For the client side software we use Python, libusb, pyusb, QT/PyQt. Even though there was a lot of discussion within the group (Ruby vs Python, qt vs gtk) we landed on Python due to all the bindings that works out of the box on Linux and Windows. This enables you to quickly create applications. Combining this with QT/QTDesigner and you get a nice GUI application.

The hardware – Since the very first prototype we switched from Eagle CAD to Kicad to use a fully open source e-cad program. It does the job perfectly fine but the routing part requires a lot more time as many of the time reducing functions are still lacking compared to proprietary programs.  For complex boards, if time is an issue, Kicad is not the e-cad to use, but for simple board and typical DIY boards it does the job fine (ie. our experience of kicad is a lot smoother for the radio dongle than for the copter).

The mechanics – For the mechanics we have used freeCAD which is one of the few open-source 3D CADs tools that we have found. When we started out we had a lot of problems with this software because it keep crashing during the design. After the stable release of the 0.12 branch it’s gotten better but we’ve still had some problems with crashes. Over all we managed to design and 3D print many revision of the motors holder with freeCAD.

The website – On our server we are running WordPress, Mercurial and Redmine, all these on a Linux and Apache. We will probably also run phpBB later on.

 

Sensor poll

Waiting another week did not make things clearer whether to mount all sensors or not, but the quotation to buy and mount them did. The $20 we estimated was too low, depending on the amount of boards we make of course, but we would probably have to add another $10 to that which made the decision simple. It is mainly the barometer that is very expensive so we might still decide to mount the magnetometer. First we will do some tests though to find out how much “value” it really adds. For people that wants the barometer it will still be possible to manually mount it afterwards making it a win-win decision.

One of the things that we’ve been working on for the last week is the parameter and logging systems.

Since the start of this project we’ve had a protocol in place for logging data from the Crazyflie but it’s been a bit hackish. It has relied on that the client/Crazyflie has been in sync regarding what to log and how to log it. The problem that we had was that as we start development on a new feature our logging needs change and we start tweaking what we log. Sometimes we change the size of variables to fit more data in or we switch them out completely. This has resulted in the logging breaking frequently which has been a pain…the three of us was hardly ever in sync :-D The solution that we have been working on now is more dynamic.

At start-up the client will download a TOC (table of contents) of loggable variables. By using macros when defining a variable in the Crazyflie code the variable will automatically be included in the TOC and will be loggable. It is then possible to setup a log configuration where a number of variables are pushed over the radio at a specific interval. Multiple configurations can be added so one usage is to log the battery voltage every second but to log the roll/pitch/yaw 100 times per second.

We have also been developing a similar system for getting/setting parameters. Like the logging there’s been a hackish system in place until now that’s been used to set regulation parameters during tuning. With the new system it’s possible to declare a variable using macros so it will be automatically included in the param TOC and will be gettable/settable from the client. One typical use is for tuning the regulation but it could also be used to switch between flying configurations (normal/X).

The biggest reason for implementing these systems is to make it easier for other people to tune and modify the program of the Crazyflie (also it’s a lot of fun :-D).

We haven’t seen any more problems with the prototypes since we exchanged the MPU-6050. All of the changes for the new prototype has now been tested and we are currently modifying the board design to fix the bugs that we have found. Then it’s time to order a new batch of prototypes. Our hope is that this will be our last round and that the next order will be a bit bigger!

The last couple of months we have re-designed large parts of the code to be more modular and easier to maintain and at the same time we have added more features such as rate controlled PID and flexible logging and parameter system. The UI has been slightly re-designed and the PyQwt dependency has been removed.

During the summertime we are a bit split up since we are going on vacation and are actually trying to go outside! So we have tried to define the features and tasks that are left until the first release of the project so we can focus our efforts on the right things.

We feel that we have never been this close to the release so we are really looking forward to this autumn :-D

 

 

After the problem discovered last week we have patched a couple of copter and we are now getting values from the sensors. Our biggest problem for the moment is a huge offset that we get from the MPU-6050 (both from the accelerometer and the gyro). It’s not the self-test mode since we have tried enabling/disabling but we are still investigating…

Except for that the software is going forward both on the copter and for the PC GUI. We are implementing parameters and log systems that will greatly ease future development and debugging on the system: it will basically be possible to log and observe dynamically any internal variable and to set settings, like the regulation settings, in real time from the PC GUI.

We have noticed some confusion about how we control the Crazyflie after our RC controller post. So just to clarify we are using a Playstation 3 gamepad to control the Crazyflie from the PC, this is the best we have but any gamepad or joystick would do. However there are other options.

The Crazyflie will be controllable from the CrazyRadio USB dongle. The dongle has a number of interfaces that can be used: USB, SPI/UART and PPM. A custom made controller could be connected to the SPI/UART or a RC remote to the PPM interface. If the dongle is connected to the computer using USB it can be interfaced using our Python library. Currently we are using a QT application together with a gamepad controller to interface the Python library but it’s also possible to do other stuff like one of our dreams: using openCV to track the Crazyflie and control it autonomously from a PC and a couple of webcams :)

Also we are still porting the code and testing the new prototypes. So far we haven’t fond any more problems than the JTAG reset.