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
Do you use brush motors? If yes, what the specs do they have? Do brushes degrade?
We use coreless brushed dc motors 6x15mm, 3.7V. Brushes degrade but the lifetime of the motors will not be a problem in this kind of application. The motors should also preferably be bi-directional so that they perform equally well in either running direction.
Wow…you guys have made a lot of progress, I would love to know when you will be ready with the boards for purchase!
I know you already mentioned that RTF kit will take longer; any ETA on this?
thanks and keep you the great work and have fun testing!
J.
Do u expect the motors to hum when operated a sub 100%? Why not use brushless motors – wouldn’t they be more efficient? What’s wingspan of the device (total width – including and excluding the propellors)?
We have tried with small brushless motors but they are more complex to interface, way too powerful and (more importantly) they vibrate too much. The motor we are using now are very well equilibrated and most of the vibration we get are from the propellers.
With motor mount the wingspan is of about 9.8cm without propeller and 14cm with propellers.
I was wandering. What is the practical application of crazyfly copter? Or it is just a toy?
We are intending the Crazyflie mainly as an opensouce development platform: as we will distribute the source code and schematic with it, it will be easy to modify, extend and experiment with. We can think of a lot of fun things to do with such indoor flying robot that we could never have time to do ourself (Autonomous control with OpenCV for example …).
Of course that does not prevent to play with it ;-). However the first version will certainly be a bit harder to start with as it will not be fully mounted and the softwares not fully tested.
How does payload of 4 grams can afford a camera? or other stuff?
4-5g is enough for a laptop or mobile phone camera plus the board and various chips, the challenge would be to design a board with that kind of camera and the down-link/analysis/storage. Also the cameras could be on the ground controlling the copter from a PC (its another kind of challenge…).
Not sure if this has been discussed elsewhere, but have you considered running the motor supplies as PCB traces direct to the motors? Provided the traces can handle the current, it could shave off a gram or two.
Yes we have, that was actually one of our design goals. It would have been lighter and nicer with a design like that but routing it and keeping the high current traces away from the radio and the analog part was an impossible job. Especially when we wanted to fit a expansion port as well. On our very first prototype we routed it like that but on that version we also had a lot of interference from the motor PWM. Now the design is really quiet instead which improves the performance more then the weight of the additional length of the motor wires.
On the subject of auto-flight, do you think it will be possible to use the onboard sensors in a similar way to an intertial navigation (IN) system? For example, could you access the data from the sensors in the code on the board to tell it to “fly up ##cm” or “fly left ##cm”?
Well, it is actually possible to run the motor-traces directly inside the arms while still maintaining low noise. It requires a proper layer-stackup and a very well designed power rail hierarchy.
If you keep both traces very close to each other (one above the other) i.e. 4mil/100um prepregs the magnetic field will remain very close to the coupled line.
Example.:
L1, mainly analog traces
100um prepreg
L2, ground
Core
L3, power circuitry + motor traces –
100um prepreg
L4, motor traces + digital traces…
There is also some other design techniques that prevent noise coupling.
On my designs I’m seeing less than 15mV voltage ripple on the battery itself when motors are on full power, that’s due to proper frequency matched decoupling and rather high switching frequencies.
A shielding ground-plane, will prevent capacitive coupling into high impedance analog traces (layer stackup). Also positioning of regulators and other parts is crucial (shared return paths).
Some people tend to use split ground planes on mixes signal designs.. that can also be very dangerous if you do no 100% know what you’re doing…
That technique I had not heard of before and it sounds like a good one. That could free up some space and make it possible to get the motor traces routed out to the arms but it would still be a tricky job. Maybe something we could try on a future design.
Currently we use a 4-layer design with split ground planes and it works well. We gett less then 3mV analog ripple and below 10mV digital. (If my oscilloscope can measure it that accurate which I doubt).