Steve you have a lot of interesting points. What iF a company came out with a true system that had a triple redundant flight control system/navigation/GPS system. One where the GPS was of commercial and military quality that had an accuracy of 1 cm. A system that could deploy a parachute bailout system in case all 3 systems failed. A System that was built properly that had plenty of head room even if 2 motors failed. A system that could fly miles without any user input? What would everyone here pay for a system like this? Let's forget about the frame for a second and pretend that this system could easily be incorporated into your existing frame. What would you pay for a system like this? You don't even have to reply, just think about it. Would you scuff at 20K? Would it be out of line to scuff at 20K? If you have invested $10K between a camera and gimbal combo what should one be willing to spend on it to protect this investment? TO protect people and property?
Dave: I've been doing a frame-by-frame analysis of your crash video, trying to figure out what might have happened. The time line goes something like this (and I'm quoting hours, minutes, seconds, and frames): 00:00:00:15 : Motor start 00:00:01:22 : Take-off 00:00:02:13 : Boom comes into frame (so roll must have started before this point in time) All of what follows is pure speculation, so I'm hoping your recall of the incident can add to the information I've gleaned from the video. Did you see/hear any anomalies in the way that the motors started? Like did one motor start up either going the wrong way briefly, or hesitate when it started? My concern is that there's basically only one second between motor start and throttle up, and I was wondering whether one "lazy" motor started the "tip over" from the outset? The copter gets airborne and I assume immediately starts to roll over -- the boom comes into view at 00:00:02:13 -- roughly one second after takeoff. That suggests one other possibility: Is there any chance you might have accidentally recalibrated the ACC without the copter being level? Certainly *if* you did (and I'm not saying you did, of course), then it would produce exactly this effect -- the FC board has a false sense of what is "level" so it immediately causes the copter to roll to what it think is level (which, of course, is not!) Several forum members have done this accidentally (including me) -- it's all too easy to just deflect the left stick to top right for long enough to trigger a recalibration. Did you start the camera rolling before the video we see on the clip? If so, might we see the entire clip -- there's just a chance (in this case) that we might hear the beeps of the ACC recalibration if indeed it happened. There was one other thing that you wrote that I'm not sure I understand completely: "The copters motors were unresponsive and I couldn't even shut the power off to the motors. It just stopped once it couldn't move any more." When you say the copter's motors were unresponsive, were some of the motors/props still spinning, but you could not issue a Motor Off command? If so, that's probably because of the I2C Databus error. The stick positions are received by the receiver and the flight control board's firmware has to recognize the "gesture" of "Motors Off" and then send data via the databus to the Double Quadro board to tell the BL-Ctrl's to shut down. If the databus electrical pathway is broken, or there is gibberish on the bus, then, while the receiver and FC might be working ok (they don't use the databus), the FC would not be able to communicate with the Double Quadro board. Hope this all helps... Andy.
Hi Andy See below in red Thank you kind sir. I appreciate it. No I didn't hear any anomalies. The motors started up like they normally did. I normally get the copter up pretty fast as I don't pussy foot around with getting it off the ground. That's kinda my startup routine. As I mentioned before the KDE 4012's appeared to me to have less power than the U5's as far as take off throttle needed and hover throttle. Going by the specs this never made sense to me. NO I don't think so. I never have ever caught myself doing that as I'm pretty delibrate with my routine and commands. I'm like a robot with stick upper left and sticks lower right to start the motors. As soon as I saw the copter pitch over I tried to shut the motors off and it never worked. I never gave the copter any throttle after it started rolling over. I was operating the commands completely on feel but have a really good feel for my controls eve if I was blindfolded. It could have only recognized roll nick as lower left which could have caused the motors to behave that way. I tried shutting the motors off several times (at least 4) and it just kept going and I heard it throttle up quite high even though I had no stick input at one point. It happened quite fast but that's what I remember. I guess its possible I went straight down lower right instead of lower left in the panic as it happened so fast. I just uploaded the entire recorded portion of the crash. It has a couple more seconds in the beginning. I can hear me moving one of the props as I reached down to turn record on the camera. I don't have a hard record switch for the 5D just yet so I have to manually hit record. Here's the new version password: I2C
Thanks for the additional information, Dave. I've downloaded the longer video and I don't see/hear anything out of the ordinary. Do you have any recall of when you first heard Fraulein Graupner tell you about the databus error? The noise of copter-on-asphalt and the motors prevents us from hearing the audio from the transmitter. One thing you could do with MK Tool and the Flight Control board on the copter at the time of the video, is to connect up to MK Tool and go into the 3D screen and see, with the FC board level, whether it shows that the little quadcopter image is also level. If it is not, then somehow, the ACC got out of kilter. If it shows the little quadcopter as level, then another of my elegant theories craters big time. Note that the 3D quadcopter does a constant little dance -- it's just small quantization errors in the sensors -- and that is quite normal. Given everything you've said, it sounds like the databus error might have occurred on throttle up at which point, I'm afraid the copter was no longer controllable by either you or the flight control board. Wish I could be of more help, but the evidence we got is the evidence we got. I'll do a forensic backup of your microSD card when it shows up and then see whether I can find any evidence of a second GPX file corresponding to this "flight" (it barely merits the word, does it!) Andy.
It was after the copter shut off. The copters pretty loud when it takes off and I probably can't hear Ms Graupner until the copter is away from me a little bit. Even I could hear something I have it set to talk every 10 seconds so it might not have been on the right timing and I probably wouldn't have heard it with what was going on had my attention. I can't check the level of the FCB because I changed it out on site to see if the issue was the board. I switched out the cable first, then the board and still had the same error so I packed it up.
Actually, you can still check the FCB. If there's something wrong with the ACC calibration, it will have stored the calibration parameters in flash memory and you can still test it today. The test is just to see what that FCB thinks is level based on its currently stored ACC calibration data. So the experiment is still a valid one, even now. (Don't do any ACC recalibration operations on that FCB board, of course! We need to preserve the data currently stored in its flash memory for the ACC parameters). Does that make sense? Andy.
Dave: I just got the microSD from your and a colleague did a forensic image of it. I'll analyze it tomorrow. I just realized that there may be one just, maybe, possible scenario that fits the description of what happened on the second flight. Bear in mind this is pure speculation....so you can shoot it down with a simple check of the transmitter (assuming it's pretty much as you left it after the crash). What if (and it's a big if) somehow, the nick or roll trim got displaced way off center? Firstly, when you took off the sticks would be "fighting" the trim settings and would produce the flight profile we see on the video, and, worse yet, the trim setting would prevent you from turning off the motors because you could never send the "Motor Off" stick movement -- the flight controller would never "see" the correct stick gesture. The weak spot in this hypothesis is: If a trim control was so far off that you couldn't give a Motor Off, how did you even start the motors? Can you tell I'm "stretching" to try and create a hypothesis here? But if you could power on the transmitter and check where the trim indicators are, then we can eliminate this hypothesis. Also, let me know what you find with the ACC on the Flight Controller please. Is the 3D "quadcopter" model level when you have the FC board level? Thanks Andy
HI Andy Since the poorly designed rocker switches can easily bump the servo trims I always check my servo display menu to check my trims before I fly. Right after the crash I checked them as well and they were all 0 or minus 1. I would have to put the entire copter back together to check the ACC. I can do this but it needs to wait till after I finish a project for a client.
Hmm. Ok, thanks for the information re: the trims. There goes another theory. Regarding the ACC, no, you don't need to put the copter back together. All you need is: PC -> MK USB Adapter -> FC It can all be just sitting on your bench with nothing else attached to the FC but the MK USB adapter cable. Install the little shorting plug on the MK USB adapter and it will provide +5v to the FC and you can then do the test. Andy.
Dave: I've analyzed the forensic image of your microSD card. There is absolutely no trace of a second GPX file -- there is not even an entry in the file allocation for a suitably named file. Therefore, my current theory du jour (one of them's going to be right any day now) is that the databus error occurred shortly after you throttled up -- there would be a lag between you throttling up and the FC/PDB responding and spooling up the motors. So the copter "saw" the throttle up command, then came the databus errors, at which point the copter was flying -- but did you feel you had any flight control of the copter or did it just crash regardless of what you did with the sticks? (It could be that the databus was "sick" but some valid data packets were getting between the various MK boards sufficient to throttle up and/or kinda control the copter.) When the throttle setting exceeded 40%, that's the point where the file name is constructed from the GPS based on date and time.The databus error therefore must have disabled the creation of the empty file and further disabled the writing of any data to the microSD card. That's my story and I'm sticking with it.... Andy.
I truly appreciate your help. What doesn't make any sense is that this copter with the KDE 4012's at the payload I was flying requires about 75% throttle to get the copter off the ground. Hover throttle with this setup is about 65-67%. So it definitely exceeded the 40% requirement. One thing that I can tell you is that I remember throttling up hard (because I have to) but then immediately responded to my next stick request to stop climbing but after that request is just banked hard and went out of control. The reason I remember this is because the shot I was about to do was going to be only 15-20 feet off the ground. I truly believe it saw my command to stop climbing after initial up but it all happened so fast it really is hard. Anyway it should have started recording upon initial launch because of the throttle required to get off the ground at that payload.
Dave, we've all learned that the SD card's GPX recording is buffered, so often the last few seconds of a flight where there's a serious problem are often lost. I presume that in your case, the immediate throttle-up (triggering recording to begin) was subsequently interrupted by whatever took out the MK electronics, causing the GPX file to never be written. As a matter of course, I always throttle up slowly, and then let the motors idle at 25% or so for a moment. It also helps to stabilize the MōVI, especially in single operator ("majestic") mode. My GPX files always show a few seconds of low power before I take off. I think Holger should start GPX recording as soon as power is applied to the Nav board. But obviously this doesn't change the fact that some kind of catastrophic error took place in the electronic stack.
Dave and I have been in contact with MK and the current firmware logic is that the throttle has to be greater than 40% AND the copter has to have climbed more than 1.5m before the logging starts to the GPX file. That's why there was no log file created -- the copter never got above 1.5m AGL. Holger's opinion is that the bus error was caused by the crash, not the other way around, therefore. This comports with Dave's feeling that he had initial control. I concur with Steve's start'n'pause approach. Personally, I like to start, pause for two or three seconds (to allow the motors to spool up), look, listen, takeoff to 2m, and hold just to double check that the systems are all sounding and looking good. My camera operator tells me I routinely say, "Look's good....sounds good" before I fly the copter away -- I didn't realize I was doing that. It's a habit from powered flight otherwise known as run-up checks that you do in the holding area at the end of the runway just to make sure that the spinning things are working and that, if you've got'em, both magnetos are magnetoing.... Dave: You don't have much thrust "headroom." I'm sure you've done the numbers but, at first blush, I'd say you're close to the weight threshold -- remember you need that headroom for yaw, nick, and roll control... Let me know the results of the FC ACC test when you have a chance, Dave. Andy.
I will be doing a bunch of bench work coming up soon. Andy you are right I don't have much headroom and I don't understand why. I have been waiting for you to do the tests and see what you come up with. The specs lead to believe that it should be fine carrying 23 pounds. Either one of two things are occurirng, the specs on the motors are less than advertised or there is a lot of inefficiency through the MK BL's. I plan on testing the Wookong with the 4012's and seeing what I get.
I'm gradually getting to the testing, Dave. I decided to have a test stand re-built professionally to withstand the forces generated by the newer, bigger, motors. I also discovered that my thrust measurements were off by a few grams -- ordinarily that wouldn't matter, but when you multiply that by eight it increases/decreases the total available net thrust to the point where it bothered me. I'm going to re-test the QC-3328's later today or tomorrow with the new setup just to make sure I'm getting consistent results. Static calibration tests (with calibration weights) show an excellent linear response. Andy.