Category: Crazyflie

If you have been reading our previous blog post you know that we redesigned the Crazyflie to use the MPU6050 instead of the IDG500-ISZ500-BMA145 combo. This was done because the IDG500 became obsolete, recently we found out it was because Invensens had production problems with this sensor, anyway when redesigning we managed to squeeze in a HMC5883l magnetometer and a MS5611 pressure sensor.  Now when we are getting close to actually making some kits we have to take some decisions and one of them is if we should build the Crazyflies with the HMC5883l magnetometer and the MS5611 pressure sensor mounted. This will of course increase the price which we have estimated to be about $20. Currently we do not use neither the magnetometer nor the pressure sensor. The yaw drift is so low that when you pilot the Crazyflie it isn’t noticeable and therefore we do not use the magnetometer. The pressure sensor we have just tested briefly and we do not really know how well it would work. Altitude hold might not be so useful inside but maybe outside.

Because of this little decision whether to mount the magnetometer and pressure sensor or not we would like to make a poll so please give us your thoughts.

 

 

Should we mount the pressure sensor and the magnetometer?

View Results

Loading ... Loading ...

The coming week we are reviewing the new revision of the hardware before we press the order button. With the previous prototype we had a few violent incidents where one of the arms broke off. Fixing it wasn’t to hard. We used an aluminium tube we cut to the right size and glued over the arm and it holds up well. For this next revision we have changed the board outline around the arm joint to be smoother as this seams to be the weakest point. If everything goes according to plan the next prototype should be the last before we can order a larger batch.

During the last week we also did a little test making an small Android app and plugging the radio dongle in one of our Galaxy Nexus. It’s detected and can be used via the USB API.  It’s nothing that we are planning on spending any time on right now but in the future…

 

 

 

We’re all back from vacations and now it’s time to focus and ramp up the work again. After syncing what we have been doing during the summer (and doing some catching up) we think that we are in good shape. There’s still lots to do but now we have re-charged our batteries!

Since the weather is nice we decided to do some flying outside and at the same time do some range testing. Unfortunently we waited a bit too long so it was pretty dark outside. The Crazyflie is normally hard to see when you get too far away and when it’s dark it’s even harder… So the range test was done by flying slowly forward until the radio connection watchdog kicks in and the motors are cut. We then used MyTracks on Android to measure the distance to where we found it in the grass :-D We only did two tests but the best one was 55m.

Here’s some images of the test and the flying:

Crazyflies at night

Crazyflie at night (far away)

Crazyflie range test

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

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: