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.
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.
We don’t have that much new to write about this week. The software clean-up is slowly evolving and we have been working some more on the radio protocol and the ground station.
We hope that the new prototypes will be ready this week so maybe we could make a first flight with them in the beginning of next week :-)
A none return point has been passed as we have put in an order for a shit-load of motors. Now everything has to work out or we will be sitting with a hole bunch of motors and no money to do other fun stuff.
While we are waiting for our prototypes to arrive, the ETA is the 18th of may which is a looong wait, we thought we would play around with the Crazyflie outside now when spring has finally reached the south of Sweden. The drawback with a quadcopter this small is that it doesn’t work that well when it is windy outside but the upside is that it is pretty durable which makes great for some crazy testing :-). This Monday it was very calm outside and we got the idea to throw it in the air and try to make a “throwing start”. From the beginning we thought, no way, but it actually worked better then we thought. Here are some of the clips of the more successful attempts :-)
We also bought one of these very popular key chain spy cameras to try and get some on-board action footage. We removed the electronics from the casing, removed the battery and connected it to our battery instead. We even removed the mini-USB connector to save weight. It all ended up in about 25g including the Crazyflie which is OK. Now it is really starting to look as an insect of some sort…
Frame from onboard video footage
We managed to take a short on-board video but the camera doesn’t handle the battery voltage drop and resets pretty easily as soon as you hit the thrust. Maybe it is possible to power it from our stable 2.8V instead because now it is pretty useless. Also the view-angle is to narrow as well as the framerate being too low to get any good footage. We seem to have gotten the 808 #14 model which isn’t supposed to be the best. At least the Crazyflie is looking pretty mean with it attached :-). Further investigations will be done when we have some time left over.
