Bitcraze Forums

Hi all,

I got some problem (again ) with my first version Crazyflie. It can be connected to the PC normally and also with some thrust (but not enough to lift it into the air.)

However, when larger thrust is applied, the flie just flies away uncontrollably. I saw that the connection between the PC and the flie is lost around that moment.

I suspect that I once soldered this flie too much around M3 on the below side, and the wiring on the PCB is exposed (one is connected to pin 25 of the center chip which is corresponding to the wireless part; the other one cannot be tracked.) How can I fix this?

Thanks
Veerachart

Such things happens and I'm pretty sure it can be fixed.

There is probably a small short between one of the pads. If you have access to an multimeter you can use that to measure the resistance between the pads. If a motor is connected it should be around 2-3ohm and if not there should be no connection. If its ~0ohm there is your short.

If you have access to solder flux that would be the easiest to "clean up" the pad as the solder will start flowing nicely when it is heated up, hopefully removing the short. You can also use a bit of new solder (which contains flux) to get the same effect.

All the rectangular pads are connect together so if the M3 rectangular pad is bad you can use M4 or M2 rectangular pad when soldering back the cable.

tobias wrote: There is probably a small short between one of the pads. If you have access to an multimeter you can use that to measure the resistance between the pads. If a motor is connected it should be around 2-3ohm and if not there should be no connection. If its ~0ohm there is your short.

I checked with the multimeter and the resistance between the two pads of M3 is ~4kOhm, with the motor disconnected. Seems like they are not short together, but to somewhere else.

Also when one probe of the multimeter touches the rectangle patch of M3 (I believe is the positive voltage from the batt) and the exposed wire next to M3, the flie starts like the power button is pressed.

I will try to figure out more and provide further information if any progress.

UPDATE: After removing the other wire of M3 (one was broken out of the pad before) and removing almost all of the remaining solder on both pads, I measured the resistance again.
The resistance from the circle pad to the rectangle pad is ~4.8 kOhm, and the reverse is ~ 1.1 MOhm (actually it gradually increases from a little below 1 MOhm and stops around 1.1 MOhm.)
The rectangle pad is still short with the other rectangle pads, and the circular pad is still connected to the FET Q3.

UPDATE 2: I accidentally broke the connection of M2, so I measure the resistance between M2's pads and they are in similar manners with those of M3. Then, I checked Vcc and it was 3.8 V when it should be 2.8 V (Vbatt is measured as 3.9 V.)

The cause may not be the diode as I previously guessed.

The measurements doesn't look that wrong. Since there is a schottky diode connect between the pads you should get >1Mohm measuring one way and lower the other way.

As you say the VCC voltage is off and it might actually be a tiny short to the resistors marked in green in your picture. Those resistors set the regulator output voltage and might be causing the poor radio stability.

tobias wrote:As you say the VCC voltage is off and it might actually be a tiny short to the resistors marked in green in your picture. Those resistors set the regulator output voltage and might be causing the poor radio stability.

I checked through those resisters and capacitors and cannot find any short. I then further inspected the value of PGOOD (connected to R21, R23, and pin7 of U8) and it gave ~2.3 V. I found in the datasheet here that if the battery is in correct range, PGOOD should be equal to VSS, which in this case is the ground. As I do not have other working crazyflies to compare the value I am not so sure that this is related or not (the one I tried with has broken voltage regulator.)

Another update:

I tried connecting to the quadrotor using a package in ROS by Georgia Tech, and publishing the message so that the thrust is up to 65000 (maximum). The flie can provide the thrust normally (pressed to the table by hand so it did not fly away) and the attitude can be read normally.

However, when I tried using Oliver's code to control the flie using Kinect (also in ROS), the connection was lost when I started the flight, even with just normal thrust level.

Hi,

It sounds like the Oliver's code is a bit too picky about packet lost and that is causing your disconnections. Have you tried changing channel and datarates? It could affect the radio quality. Also you can try to make the Oliver's client a bit less picky by changing the maximum number of re-transmission. It is handled by this constant: https://github.com/bitcraze/crazyflie-c ... er.py#L321 (in the Oliver's code it may be located somewhere different as his code is based on an older version).

BTW I did not know about this ROS package, we have to try out .

arnaud wrote:Hi,

It sounds like the Oliver's code is a bit too picky about packet lost and that is causing your disconnections. Have you tried changing channel and datarates? It could affect the radio quality. Also you can try to make the Oliver's client a bit less picky by changing the maximum number of re-transmission. It is handled by this constant: https://github.com/bitcraze/crazyflie-c ... er.py#L321 (in the Oliver's code it may be located somewhere different as his code is based on an older version).

BTW I did not know about this ROS package, we have to try out .

Thanks for the suggestion, Arnaud.

I haven't tried it, but I checked in the official library of cflib (at least the version I forked from the original repository a year ago) and seems like it also uses the same value. The gtagency's package also depends on cflib, so I think it's the same.