Greetings all ardumates, I am almost loosing my faith for my quadcopter! :(
The basic quad installation has been providing me plenty of joy during the past months. I counted that there have been dozens of succesful missions and in calm and quiet evenings the escorting of the flying companion has been just mint... but lately something has changed and I cannot trust my installation any more.
The copter has now crashed four times in short time and each time most of the mechanical parts had to be replaced - twisted arms, sure all the propellers, one motor and one HD camera. The scene goes each time the same way: while you are flying the quad even in easy conditions, typically first three to ten minutes everything is just normal. Then without notice the copter starts to keep odd oscillating noise, like "wo-wo-woow-woow", then flips and hits the ground immediately. You never know when it happens.
I have carefully checked that all the propellers are balanced, rotating as intented and well fixed. Also all the motors are consuming the same amount of the current or replaced and ESCs have been calibrated to perform similar way. While I have build the construction now four times (and almost from the scratch with the new mechanical parts), there should not be any major defects with the arms, motors or propellers. And just the same construction was used when the flying was just perfect. Any ideas what error I am now repeating each time?
Please find attached the picture of my quadX still without the camera installation:
This installation was working just fine for several months. Only the firmware has been updated every now and then. The first pretty bad crash was done with 2.5.4 and now three flips with 2.5.5.
Unfortunately I did not manage to film the crashes with observing camera, but perhaps the onboard camera might give a hint what is happening. So, I am enclosing two short videos that might give a glue?
The first one is just about 10 seconds. After some succesful flying and switcing the battery to a fresh one I made another takeoff. Almost immediately the copter flips while being still close to the ground:
The second 35 seconds video might give a better example. After assembling the copter again to the original shape it was time for give it yet an another opportunity and test the installation to check how stabile it is:
Notice around the spot 29s (at least it is audible) the woow-woow-woow effect that comes without warning and drops your drone down!
I tried to figure out what log files might match the videos, but it was a bit difficult to be sure without proper timing information. Most likely the Arducopter3Crash is in the log #43 and the Arducopter4Crash is in the end of #45:
Flight Log #42
I am really wondering what makes it to do such things? Even if I assemble the copter the fifth time, it is clear that I do not dare to fly it until the root cause is solved. Really frustruating... any suggestions mates how I should proceed?
Your experience mirrors mine.
I am just learning to tune a jDrones hexa and was getting it quite stable.
All was going well until I updated the firmware to 2.5.5 and then random short times after launch the copter just cuts the motors for no apparent reason.
I am watching with interest if anyone else is having similar problems.
The hexa was delivered built and test flown and I have taken it back to factory defaults but it is still doing it.
Anyone have any suggestions?
I'm sure some of the dev's will be able to diagnose better than I can but the graph of your yaw and mag heading (from #45) doesn't look right to me, surely the mag heading should not be bouncing all over the place? Maybe something's wrong with the magnetometer or something's affecting it that shouldn't be?
Yes there is definately a fair bit of noise in that log, although it doesn`t show up on the number 43 log?
what I find strange though is it is not showing any input from the radio? if you look at roll or pitch in against roll or pitch there is next to no user input showing on any control? including yaw?
Unfortunately I cant watch the video, it doesn`t load properly, it should be embedded via youtube or vimeo and not uploaded as a file..
I am not too sure of having the xbee and vtx running on the same frequency either especially so physically close to each other.
Thanks for your input, that was really a good one!
The magnetometer anomaly is a good finding in this case. However, what makes such measurement to become unpredictable? But still, when flying with stabilize mode... I am really disapointed that I loose the control of a flying object... when it is not following the controls of any decent RC model.
I have no idea what caused it, was hoping one of the dev's would chime in. That was the first anomaly that I found, there may be others. Are there any other components near the board? Wires? Magnetic latches etc?
I presume I need to investigate the construction once again. There are no relays or major wires close to the magnetometer. Only potential electric magnet is the single onboard relay in V1 board, but that is not used at all. However, after packing the installation into a bit smaller space it is possible that one of the ESCs is now pretty close (about one inch) from the magnetometer board. It might be better to move it a bit more away from the compass.
Xbee and video downlinks are working just fine together, both using different part of the 2.4GHz band. Couple of the crashes happened even when downlink video was turned off.
One potential issue might be that I have not soldered the ESC cables to the motor ball connectors. There was another thread where a bit similar anomalies happened when one of the motors just did not have good enough connection using the pluggable ball connectors. After making the hard solderings the issue was cleared. It might be good to ensure also the connections, just in case.
Sorry for the videos, those were packed heavily to get the file size small enough. Those are visible with mpeg4 codecs, using applications such as VLC or DivX.
I'd definately keep the ESC's as far away from the mag as possible, that's a major no no. The motor ESC wires aren't so important, mine are still using bullet connectors after 100's of flights and no problems, I use the same connectors in a 60A application (1.3KW) and they aren't even warm so should be able to handle the 50W per motor of most quad motors. If you have a bad connection there the motor will stutter.
Update: the root cause for the problem has been found!
One of the four ESCs was broken and really nasty way: in that specific ESC there is a small segment of the control area (about 60..70% of the power) where the motor still spins but is just more or less shakes rather than makes any real good. It was really difficult to find the problem, but when making a fresh start with the latest software version and making the ESC calibration with 0...100% range I noticed that the "audio output" of that motor had a specific distortion within a really small control area. Actually, it was possible to stop the motor with fingers when the power stick was in just in proper position. Otherwise the ESC output acted just same way as any of the tree other ESCs. The fact seems to be that everything cannot be corrected even with great software - especially problems of the ESC that has a mind of its own. :)
The compass problems were coming from the camera tilt servo just below the unit. I presume the actual problem of "the dropping drone" was the fault in ESC, but perhaps the compass was also getting bad data when the copter was oscillating based on the issue of one rotors loosing power every now and then in short segment of the control area and camera mount rocking accordingly.
Thanks for the help and support. Next I am throwing the ESC so far as I can and soon replacing it with new one. :)