Category: Software

Home / Blog

Tools

  2012-10-01  |     |    4 Comments

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.

Logging and parameters

  2012-08-13  |     |    3 Comments

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

Summertime update

  2012-07-23  |     |    6 Comments

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

 

 

More testing

  2012-06-12  |     |    2 Comments

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.

Controlling the Crazyflie

  2012-05-28  |     |    6 Comments

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.

Teaser video

  2012-04-23  |     |    8 Comments

We wish we had something interesting to write about, but recently we have just been cleaning up and reorganizing the Crazyflie firmware. We are doing this so it would be simpler to further develop the software when it is released. We have also been preparing the new drivers for the digital sensors so they will be ready when the next version of prototypes arrives within the next two weeks.

One funny thing we have though is this little teaser video we put together while testing the speed of the Crazyflie. It is not recommended crashing into something hard at this speed 8O

Testing sensors

  2012-03-13  |     |    6 Comments

When we built the latest prototypes we built two different versions. One with the ST accelerometer LIS344ALH and with the ISZ-IDG650 gyros. The other one with BOSH accelerometer BMA145 and with the ISZ-IDG500 gyros. It turned out that the LIS344ALH accelerometer is very vibration sensitive and doesn’t work that well for an application as this. If we would just have spent some time on the Internet we could have found this information in before hand… luckily we made the hardware design work with both and the BMA145 is working pretty well, however now we no longer have an alternative :-(.

The ISZ650 and IDG650 works pretty well even though they are less sensitive with their ±2000deg/s output. We can’t see any direct stability issues compared to the IXX500 versions with ±500deg/s output. Maybe we will stick with the IXX650, that way  we don’t limit the flip and loop speed to much. Not that the Crazyflie can do flips/rolls right now but we are very confident it will be able to in the future, judging from its agility.

We have also been working on getting the Crazyflie easier to control for beginners. With some slew rate limiting and thrust control we seem to be getting there. Now even Marcus can fly it without any problem. He used to hit the wall or ceiling all the time before :-).

A little bit further

  2012-02-28  |     |    12 Comments

We had to cancel our weekly Monday meeting due to illnesses but we have at least made some small progress we can write about.

The radio dongle code has been updated to flash either of the two LED’s when sending data or in case of bad transmission.

On our latest prototypes we discovered that the radio transmission went pretty bad on some copters as soon as the motors where turned on. This was not a nice discovery at this time of our project and we had not really seen it before. This kind of problem could require a big re-design of the PCB! After some debugging it turned out to be the PWM switching of the motors causing ripple on the digital supply voltage. It wasn’t that much, about 60mV peak-to-peak but enough to throw the radio off balance. After some tries with different decoupling techniques to get rid of the ripple, which showed only minor improvement, we increased the motor PWM frequency from 17kHz to 280kHz. That made the ripple go away, now about 10mV peak-to-peak, and so did the radio transmission problems, yeay!

Screenshots of the PC side user interface

  2012-02-06  |     |    1 Comment

As promised here’s a new Monday post. Below are some screenshots of our PC side/ground station software written in Python using pyUSB, pyGame and PyQt4. It’s far from finished but it’s good enough for us to get real-time plots of flight data and control parameters. Unfortunatly we did not have a flying prototype at hand while writing this post so the data is somewhat fake but good enough to show the concept.