Blog

We have noticed that there’s a lot more work to be done in this project than only designing hardware and developing software :-) It’s now about 14 months ago that we decided to make a Crazyflie kit that we would try to sell. At that point we had already had the first version of the Crazyflie flying for about 1 year. The list of things that we have done since then is pretty long…a lot longer that we first thought it would be. But let’s save that list for another post…

One of the things that we’ve had to spend some time on is setting up our IT environment and now we are trying to make the final push. Up until now we have been using Mercurial/Redmine hosted on our own VPS. Here’s a list of what we are thinking about using in the future:

  • CM for code and schematics: Bitbucket
  • Issue handling: Bitbucket
  • Wiki: Dokuwiki
  • Forum: phpBB
  • Blog: WordPress :-D

Any thoughts or ideas about these? Any services that’s missing? Anyone that has good/bad experience with Bitbucket?

We are still mostly on vacation but we are continuing the development but not as actively. Like we wrote last time we compiled a list of tasks that has to be finished in order for us to release the project so that’s what we are working on :-D

Apart from that we are also working on some mandatory IT-stuff, like deciding what forum/SCM/VPS provider to use etc.

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

 

 

One Sunday in March when we met up to work on the Crazyflie we suddenly realized that we do a lot of developing and discussing when we meet, but we don’t actually do that much flying. After realizing this we spent most of the Sunday just flying and playing around with the quadcopters.

So what could we try that we haden’t tried before…well we could try to crash each other while we are flying around: Crazyflie dogfight! The idea is that you should try to push the opponent out of the air without being dragged with him/her. This is easiest done by flying above the opponent making his/her crazyflie unstable and crash, however it is easier said then done!

This is not the first time two Crazyflies crash into each other in the air, but it’s the first time it’s actually intentional! It was a lot of fun but it can quickly end if something breaks. This dogfight however ended up with nothing to repair :-)

We replaced the broken MPU-6050 with the replacements we got and Crazyflie is now flying again! Until now we did not really know if the new architecture with digital sensors was working and able to fly. Now we know it can, and the performance of the copter seems really very good!

Replacing QFN components are not that easy if you don’t have access to good tools. Luckily they have a hot air station at work which makes the job a lot easier. We took a photo of the replaced MPU-6050 and it is actually hard to distinguish between the original re-flow soldered one, except maybe for the crocked capacitors. Ohh and what looks as a short on two of the pins are supposed to be there ;-)

 

We think the stability is a bit better than with the IDG500/ISZ500 gyros. Judge for your self ;-)

A couple of weeks ago we discovered that the sensors of our new prototype where not functioning. We have now received new MPU-6050 sensors from Seeedstudio that we are going to solder with hot-air during the week (photos of the soldering will be posted during later this week).

On the manufacturing side we received the motors we will use which brings us one step closer to making the Crazyflie available (as long as everything else is working :-))

On the software side we are working hard to clean up the copter firmware and PC client architecture. The goal is to make it as easy as possible to setup and fly but also to modify or tweak.

 

During this spring we have been involved in a Master thesis together with Epsilon. The goal for the thesis was to embed a camera module on the Crazyflie so it could be remotely controlled. Finding a lightweight camera module with access to documentation without buying a million units turned out to be trickier then we thought. The aptina MT9D131 was chosen as it can be bought from normal distributors, there is access to documentation and it has on-board JPG compression. The NRF24L01 radio was tested to see if it could handle low resolution video streaming, and it could, so no additional radio was needed. An addon board was built which could attach to the Crazyflie expansion port and it was called… Crazycam! (I wonder when we will become crazy for real :-)) . The Crazycam board uses the same STM32F103CB MCU that the Crazyflie uses to read out images from the camera chip.

Crazycam v0.1 (sensor side, mcu side, with mounted lens)

It turned out that the bandwidth to read out the images from the MT9D131 to the STM32 wasn’t enough and finding lightweight lenses was not that easy so the end result wasn’t as good as we hoped for. It wights about 5g and can stream images at about 6FPS. There are still things to try out and in theory it should handle 15-20FPS. It might be fixable so it ain’t over yet. If you would like to read the full report it is available at Linköpings university under the link “fulltext”. Even though we didn’t get all the way Thomas and Joakim, the authors, did a great job!

After investigating the problem with the MPU6050 from last week we found out that all our prototypes have defect MPU6050 sensors :-(. The bias offset values are way out of spec and several of the accelerometer axis is locked to their min or max value. The manufacturer must have dropped the hole batch in the floor or something because we would have expected at least one out of the six prototypes to have a working sensor. Without working sensors it is hard to make a maiden flight, which we are very eager to do. We will have to order new sensors and hopefully we can replace the new sensors without damaging them.

We also finished to patch all our test copters so that they will now be able to fly when we change the  sensor:

 

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.