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 are still working hard on the Crazyflie code while we are waiting for the new prototypes. We are also working on finalizing the Crazyradio, the radio dongle we are making to communicate with Crazyflie.
In order for us to test the radio hardware performance we brought a RFExplorer:
The radio chip (nRF24U1) is put in continuous carrier mode, which makes it emit constantly at a single frequency. Below is a screenshot of the measured frequency and power from the radio dongle:
This measurement is not that useful as an absolute value (for one we do not have a RF test chamber) but it will give us the opportunity to compare the next prototype with this one. Our next radio prototype uses smaller SMD component for the RF parts which is supposed to give better performance. We already compared it with another dev board and our radio seems to have similar performance :).
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.
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)?
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 :-).
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!
To communicate with the Crazyflie we are using a custom radio protocol with almost-baseband 2.4GHz radio chips: the nRF24 family from Nordic semiconductor. This kind of radio chip is easy to cable, easy to use and require a very minimal software stack. Wifi or bluetooth would have required a lot more electronic and software so we chose to not use them for the Crazyflie. We however made sure to keep the possibility to add other radio on an expansion board (ie. both UART and SPI are available on the expansion connector).
One things with using a custom radio is that we have to make a computer interface in order to be able to communicate with the copter. We called it the Crazyradio dongle:
This radio dongle is built around a nRF24LU1p chip which contains, among other things, the radio transceiver, a 8051 microcontroller and an USB device peripheral. We wrote the firmware running in the nRF24LU1 from scratch and it is compiled with the SDCC compiler. This firmware source code is going to be open like the rest of the copter code.
The radio is bidirectional which permits to send command and receive telemetry from the copter. The bandwidth is not great but has been enough to debug the regulation. On the computer side we are using python and pyUsb to interface the radio dongle.
We have added a 10 pins connector that can be used to program the dongle for development purposes (the dongle can also be updated via USB) or to power the electronic and provide signals input/output. We designed the dongle in such a way that it is going to be possible to power it with up to 15V and to input a PPM signal. This will permit to use this radio dongle with a RC remote control (ie. to control the copter without the need of a PC).
It is now Monday evening which is now our official meeting day within the Crazyflie team. From now on we intend to post a progress update every Monday evening here at the Bitcraze blog. First of we can tell you that we have, since two weeks, received our second round of prototypes. For the second round of prototypes we did some small fixes and improvements which unfortunately did not all work.
We fixed an issue with the standby current which was 150uA, due to a misplaced diode, but was supposed to be below 10uA according to our design.
We moved the battery measurement point to the actual battery instead of behind the system off switch so we can measure the battery when it is charging as well. Unfortunately a design mistake made the standby current go up to 250uA instead. Fixed one issue just to introduced another one…
We have discovered a problem with the MAX16054 ON/OFF switch we use to turn the system on and off. If the battery voltage is above 3.5V it refuses to turn on but if it is below it works as expected. We sent a support message to Maxim and hope it can be solved fast. This circuit worked on our first prototypes and it seems to be due to the now removed diode we spoke about in the first bulletin…
Other then that we are getting close to a pretty well working flying PCB.
We have tested a couple of LiPo batteries in different sizes from Fullriver. We decided to go for the 170mAh 25C battery which gives us about 7min of flight time but doesn’t add to much weight.
We have tested a lot of different pager motors in mainly the sizes 6×14 and 6×15 mm. Many of them are not the best quality but we found a good one, 2.5ohm, 6x15mm motor which is of good quality and high performance.
What is left now is the motor mountings which has turned out to be a time consuming task for us since none of us has any direct mechanical/plastic experience. We also have loads of other tasks but let’s take it one step at a time.
There is a short video of the new prototype flying that somebody took when we visited Techfest if you want to have a look.