Author: Marcus

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 found a few workarounds for the JTAG reset problem but finally none of them are needed since we unfortunately have to make a new revision anyway and thus we can properly fix the probem. After spending hours debugging the PWM for the motors we finally opened up the errata and found a serious problem with our new version. Like we mentioned before we moved the PWM for two of the motors so we could have one dedicated SPI for the expansion header and not shared with the radio. This was done by moving one of the motors to PB5 (alternative function TIM3_CH2) while also switching to new sensors that use I2C. According to the errata it’s not possible to clock I2C1 (where the MPU6050 is connected) and TIM3 while using TIM3_CH2 remapped and as output (to drive the PWM for the motor).

On a happier note we did some range-testing of the radio since we have now changed to 0402 components in the radio filter on the USB radio dongle and the quadcopter. The measurements shows that we get up to ~65 meters before we start loosing packets and up to ~80 meters before we loose communication completely. The test was done outside and using the 250Kbps mode.

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.

A large part of this Monday was spent assembling and testing the new prototypes with the digital sensors which arrived today. Eager to try them out we pretty quickly got stuck when we tried to program them with the JTAG. The copter wouldn’t respond to any JTAG commands… After a long time of testing we found our rookie mistake: We have been moving around some of the signals now when we have digital sensors to make the expansion port use a dedicated SPI port and not share it with the radio, which is a great improvement. With this moving around we managed to put one of the motor outputs on the optional JTAG reset pin, NJTRST. The motors are pulled low so they don’t start unintentionally which then makes the JTAG go in constant reset :o This can be walked around by temporarily holding that pin low during the first programming of the boot loader which will then immediately remap the NJTRST pin to be unused by the JTAG. If the bootloader is never removed the problem is gone but if the boot loader is unintentionally overwritten then one have to do the “pull low” trick again. So now we have to decide whether to live with this flaw or do yet another board re-spin… :-( There are still plenty of sensor testing left to do that maybe need another re-spin.

Before we have any maiden flight video the show below is a photo of the new Rev.D PCB. There are more in this album.

Crazyflie Rev.D PCB

 

Due to the IDG/ISZ-500 gyros EOL problem we are removing the  IDG/ISZ-500/BMA145 and going for the MPU-6050 instead. We where pretty certain the gyro part of the MPU-6050 would work but not so sure about the accelerometer.

To minimize the risk we wanted to try it out with our design before pushing the order button. We looked around for small IMUs with this chip and found that the FreeIMU uses the sensors that we are interested in testing. So we bought one and attached to the Crazyflie using the expansion connector. Here’s a image of what it looks like:

Since we now free up some space by replacing three sensor ICs with one we added a HMC5883L magnetometer and MS5611 pressure sensor which are the most common IMU sensors right now. If they will be mounted or not in the final version depends on cost and possible performance increase. If we don’t mount them there is always the possibility to do this yourself. Actually, as of this writing, we just made a virgin flight using the MPU-6050 data from the FreeIMU with good results.

We realized the other day that we have spent a lot of time discussing issues and developing stuff and not so much actual flying. We haven’t even left the rockie piloting stage… So when we met up on Sunday we spent a lot of time just flying around and having some fun :)

Here’s a first cut from some of the video we shot.

So as we were putting the finishing touches on what we hoped would be our last prototype before the final production version we noticed something rather serious on the InvenSense webpage. The IDG500/650 (and the ISZ-500/650) that we are using are EOL (and the LTB has passed). So this puts us in a rather tight spot where we have a couple of alternatives:

Stay with the IDG/ISZ 500/650 – We could stay with the sensors we have and try to source as many as possible but this would leave us in an awkward position if we get more demand than we can source gyros.

Analogue replacement – We could find an analogue replacement that would replace the X/Y and Z gyros we have today (that are analogue). The best candidate for this is currently the new ST gyro L3G462A but it is still under Evaluation and we don’t know if and when it will be available. It’s easy to put in our current design but we are unsure about the performance and immunity to vibrations.

Going digital – The most attractive option but the option that requires most work is switching from analogue to digital sensors. This is a step that we wanted to take eventually but taking it now delays everything but we do get a chance to get a bit more up to date by putting in a MPU-6050 and maybe a pressure sensor. But we are not sure how the sensors will respond to the vibrations and ripples on the supply voltage.

Our current plan is to drop the old analogue sensors from InvenSense and start on the digital design using the MPU-6050. We will keep the analogue ST gyro as a backup plan just in case we hit into any problems with the digital version.

Do you have any other ideas for sensors or comments about the performance of the MPU-6050 or L3G462A (if you managed to get a sample)?

Ever since we decided to make the Crazyflie available as a kit we have looked at different possibilities for manufacturing and selling it. Because we don’t have much time to spend (due to that we all have daytime jobs…) and rather spend or time doing development, we needed someone that could take care of manufacturing and selling it.

During development we have been cooperating with Seeedstudio for prototype manufacturing and component sourcing. We were really pleased with their work so we decided to continue the cooperation to also let them manufacture and sell the Crazyflie and the USBRadio dongle.

Currently the plan is to start out with a small series of 100 kits which will be a “DIY” version.  The motors/battery has to be soldered and the motor mounts attached. If you have some soldering skills it won’t be a problem to assemble.  The next step would then be to increase the volume and also offer a RTF kit where everything is assembled. The reason for not doing the RTF kit from the beginning is that it’s more time consuming since we have to specify testing requirements and packaging for the platform.

As for the price we still have no number but our hope are that it will be in the 100-200USD range. Since we are still working on the motor mounts and we are unsure of the assembly/testing cost for the platform we don’t know for sure how much the units will cost to produce. Once this is clear we will post more info of the pricing for the different kits (DIY/RTF and USBRadion dongle).

 

One of the ideas with the Crazyflie was to make a simple flying platform and what’s simpler than just attaching the motors directly to the PCB? On our first prototypes we used hot-glue to attach the motors which work out pretty well. The problem was that when you crashed the motors often came loose, and in some cases, so did the wires attached to the motors. Reparing this turned out to be pretty teadious and it makes flying it a lot less fun, since the iteration time for trying new things becomes longer. We did a few tests with different protections, like soldering a ring of piano-wire, but when we decided to make a kit out of the Crazyflie we realized that we needed something that was easier to manufacture.

Since we could not find any off-the-shelf motor mounts we decided to make our own. Our idea is to place the motor in the mount and the mount on the wing. We have tried a few different solutions but the current leading design is one where we feed the cable from the mount out under the wing and to the soldering point for the wire. We have also made a telescopic version so it is possible to adjust the arm length for adjustable flight dynamics or to attach bigger propellers. After some more testing we will decide which one we will go for.

The CAD work is done in an open-source CAD tool named FreeCAD. After struggling for a while with an unstable versions, the 0.12 branch finally became very stable. The images below is the second iteration of prototypes that we have done using Shapeways. It’s is a 3D printing house in the Netherlands that has a great service where you upload models, choose what material you want them printed in, and then two weeks later you receive them in the mail! The durability is pretty good as well. We have only managed to break one, and that’s after a lot of violent crashes and a more fragile design.

 

FreeCAD showing a model of the motor mount prototype

 

Prototype 1 (shown in CAD model above)

Prototype 2

Crazyflie with Prototype 1 motormounts

 

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.