If your Mavic falls out of the sky...

[BJR981S]

I've never seen an IMU reset in a flight log - what does that look like?

To log you need a functioning IMU / FC processor.

You will never see it as the log and everything else stops at that time and the entire drone resets. You may even find that the log then corrupts / disappears.

If you research flight controllers. You will see mandatory mount requirements to prevent vibration and the effects of that vibration.

It is the equivalent of a Windows Blue Screen.

This is one of the reasons that the DJI A3 flight controller multiple IMUs are used in professional systems. Each IMU has its own CPU. And the new N3 has addition damping and vibration absorption.

I swap a Full Prop set if a nick a branch or have a heavy landing.

Cheers Brian

Components - DJI

 

[sar104]

To log you need a functioning IMU / FC processor.

You will never see it as the log and everything else stops at that time and the entire drone resets. You may even find that the log then corrupts / disappears.

If you research flight controllers. You will see mandatory mount requirements to prevent vibration and the effects of that vibration.

It is the equivalent of a Windows Blue Screen.

This is one of the reasons that the DJI A3 flight controller multiple IMUs are used in professional systems. Each IMU has its own CPU. And the new N3 has addition damping and vibration absorption.

I swap a Full Prop set if a nick a branch or have a heavy landing.

Cheers Brian

Components - DJI

Right - you mean a complete FC shutdown. I've seen a couple of those, but they do not appear to have associated with unusual flight characteristics prior to occurring, so it's not clear what has caused them.

 

[locoman]

When my Mavic crashed, the battery popped out, bounced around on the road a bit, got all scratched up, but DJI sent it back with the new Mavic, I supposed because it was still ok. which it seams to be, since I have flown with it several times. So it there was a weak solder connection you would think that the bouncing around would have broken it loose. So I am wondering if Brojon's battery was a one off, bad solder job. Maybe the person doing the work had to take a quick bathroom brake and rushed the job. Unless we take more batteries apart, we will not know if this is a typical problem or not.

 

[BJR981S]

Right - you mean a complete FC shutdown. I've seen a couple of those, but they do not appear to have associated with unusual flight characteristics prior to occurring, so it's not clear what has caused them.

Yes thats correct. And another reason to buy Quality DJI Original Props rather than knockoffs.

You wont see any unusual flight characteristics. It will be flying perfectly normal until the vibrations peak (sympothise) in the IMU. Then it will reset.

A bit like the demo of a crystal glass shattering.

I have 5 Sparks and bought some Clone props. Have a look at this one.

 

[BJR981S]

When my Mavic crashed, the battery popped out, bounced around on the road a bit, got all scratched up, but DJI sent it back with the new Mavic, I supposed because it was still ok. which it seams to be, since I have flown with it several times. So it there was a weak solder connection you would think that the bouncing around would have broken it loose. So I am wondering if Brojon's battery was a one off, bad solder job. Maybe the person doing the work had to take a quick bathroom brake and rushed the job. Unless we take more batteries apart, we will not know if this is a typical problem or not.

Here is my cut on this. I have seen similar problems on many smart batteries. Both DJI and Walkera.

The issue is the assembly process order.

The problem is soldering this joint requires a lot of heat. And that will kill anything else on the circuit board close to it.

The most Efficiency focussed assembly process is to have the board and its components built first. Before the main leads are soldered. This means that it must be done quickly and with minimum heat. Thus occasionally resulting in a cold solder joint.

The most Quality focused assembly process would be to do all the high temp work first and then then low temp items. But this would take longer and be less efficient.

I guess there will be a percentage of batteries where you will get a solder joint break away under stress. Not much you can do about it.

I dont see that a solder joint failure under normal flight would be very likely.

There are many items in the Mavic that will fail under stress in an impact. Like cracks in the Circuit boards.

Once you crash one of these its always a possibility that something will subsequently break down.

Cheers

 

[fishelectronics]

There've been many conversations about Mavics just dropping out of the sky

Perfect investigation! This may be the first step towards a serious development of this "sky falling" issue, up to a recall. I still remember the Samsung case and how all begin. Did I miss information about when you get this battery? I have 5 of them and want to figure out if there is some relation with the manufacturing date.

 

[ChrisW]

There've been many conversations about Mavics just dropping out of the sky and one of the recurring "likely scenarios" is that the operator is assumed to have not inserted the battery properly and it somehow came loose. That may not be the case...
This past week I had my MP rise suddenly and smack a bridge - fall down go boom.
The MP is deader than a doornail but I noticed an oddity in that the battery was still showing on - two solids and 1 blinky LED. So I popped it into the charger and got the expected 1 LED blink but then it went out and the charger showed red.
Being an experienced electronics guy I said "hmmmm" and proceeded to disassemble the battery. BTW this is non-reversible since they use glue or ultrasonics to hold the case together.
Guess what I found? A clean separation of the positive terminal from the battery block to the controller! Now granted the drone fell 30 feet or so but it hit relatively soft mud. This is why the battery showed ok - it can only read the cells internally via the small cable with 4 wires reads each of the 3 cells.
So it would appear that DJI needs to check their quality on soldering the battery lugs - you can see the lug is welded to the actual battery post leading me to believe the board is assembled with the power leads, then the lug is soldered to the heavy wire likely by hand given the excess solder. You can see a little crystallization of the negative terminal showing a borderline solder joint but it is pretty solid - I tried to pull it off but ultimately I had to cut it.
Just thought I would toss this out there - I will be sending the photos to DJI once I get the myriad info they require to file a support incident. I don't expect anything from them except that they check into the issue.
Meanwhile I'd treat the batteries with extra care - vibration and jarring could lead to a failure if you have a battery with one of these poor joints.

I am also an electronics designer and where ever there is an application which is exposed to vibration and harsh environments (eg automotive or aerospace) then wires should be attached by crimp terminals and certainly not rely on a solder joint. I would definitely class this product aerospace and the consequence of such a solder joint failure could be deadly. I am minded to suggest this justifies a product recall. Look around your car and see how many soldered joints you find - I suggest not any if it’s less than 10 years old. Very very worrying, and worse so because there is no way to check the integrity of that joint without compromising the batterycase. I honestly believe DJI should consider this problem and make some recommendations.

 

[sar104]

Yes thats correct. And another reason to buy Quality DJI Original Props rather than knockoffs.

You wont see any unusual flight characteristics. It will be flying perfectly normal until the vibrations peak (sympothise) in the IMU. Then it will reset.

A bit like the demo of a crystal glass shattering.

I have 5 Sparks and bought some Clone props. Have a look at this one.

View attachment 25102

Well, maybe, but I'm somewhat dubious about that in the absence of a credible hypothesis for the mechanism. Even if the vibrations were to excite a resonant oscillatory mode in the aircraft or a subsystem, integrated circuits are typically immune to vibration unless it causes structural failure in connectors, sockets, solder joints etc., but that would lead to permanent failure, not just a reset. The only possibility that I can think of offhand relates to the generation of spurious voltages in vibrating encapsulated circuits where the encapsulating polymer has piezoelectric properties.

 

[Brojon]

I am also an electronics designer and where ever there is an application which is exposed to vibration and harsh environments (eg automotive or aerospace) then wires should be attached by crimp terminals and certainly not rely on a solder joint. I would definitely class this product aerospace and the consequence of such a solder joint failure could be deadly. I am minded to suggest this justifies a product recall. Look around your car and see how many soldered joints you find - I suggest not any if it’s less than 10 years old. Very very worrying, and worse so because there is no way to check the integrity of that joint without compromising the batterycase. I honestly believe DJI should consider this problem and make some recommendations.

It seems their assembly order is:
1 - assemble controller board - all surface mount
2 - solder cell monitoring connector
3 - solder battery tabs on battery wires
4 - solder battery wires to circuit board
5 - weld connecting bridges to battery cells
6 - weld battery tabs to batteries
7 assemble and weld case together

The battery terminals would have been better served with crimp lugs and a solder ring mount to the board,
The fact they welded the lugs to the battery shows they're aware of vibration issues on the junction but they cheaped out on the battery wire assembly.

 

[dlopezjurado]

There've been many conversations about Mavics just dropping out of the sky and one of the recurring "likely scenarios" is that the operator is assumed to have not inserted the battery properly and it somehow came loose. That may not be the case...
This past week I had my MP rise suddenly and smack a bridge - fall down go boom.
The MP is deader than a doornail but I noticed an oddity in that the battery was still showing on - two solids and 1 blinky LED. So I popped it into the charger and got the expected 1 LED blink but then it went out and the charger showed red.
Being an experienced electronics guy I said "hmmmm" and proceeded to disassemble the battery. BTW this is non-reversible since they use glue or ultrasonics to hold the case together.
Guess what I found? A clean separation of the positive terminal from the battery block to the controller! Now granted the drone fell 30 feet or so but it hit relatively soft mud. This is why the battery showed ok - it can only read the cells internally via the small cable with 4 wires reads each of the 3 cells.
So it would appear that DJI needs to check their quality on soldering the battery lugs - you can see the lug is welded to the actual battery post leading me to believe the board is assembled with the power leads, then the lug is soldered to the heavy wire likely by hand given the excess solder. You can see a little crystallization of the negative terminal showing a borderline solder joint but it is pretty solid - I tried to pull it off but ultimately I had to cut it.
Just thought I would toss this out there - I will be sending the photos to DJI once I get the myriad info they require to file a support incident. I don't expect anything from them except that they check into the issue.
Meanwhile I'd treat the batteries with extra care - vibration and jarring could lead to a failure if you have a battery with one of these poor joints.

EXCELLENT JOB!!!!

Thanks...one more time...

 

[mrchris87]

Sorry I wasn't clear. The battery was NOT the cause of the crash and I'm quite sure the fall is what jarred the terminal loose.
At issue here is the poor quality of solder joint and the relative ease with which it let go.
Say someone has a battery with a poor joint. The joint will be subjected to almost constant stresses as the drone get's flown with vibration, transportation, and let's not forget the heat expansion of those battery terminals.
So here you are flying and you start bucking the wind which causes a current surge with extra heat - I can see the terminal letting go at that point.
This is why I posted with the title I did - I wonder how many of the "just fell out of the sky" posts may have been the result of a shoddy terminal solder joint.

 

[BJR981S]

Well, maybe, but I'm somewhat dubious about that in the absence of a credible hypothesis for the mechanism. Even if the vibrations were to excite a resonant oscillatory mode in the aircraft or a subsystem, integrated circuits are typically immune to vibration unless it causes structural failure in connectors, sockets, solder joints etc., but that would lead to permanent failure, not just a reset. The only possibility that I can think of offhand relates to the generation of spurious voltages in vibrating encapsulated circuits where the encapsulating polymer has piezoelectric properties.

Think of what vibrations do to the Accelerometers and Gyros. Then think about buffer overruns.

Cheers

 

[sar104]

Think of what vibrations do to the Accelerometers and Gyros. Then think about buffer overruns.

Cheers

OK, we can do that.

Vibrations are periodic oscillations with associated accelerations that may be recorded by accelerometers subject to the accelerometers dynamic range and bandwidth. Modern rate gyros are largely unaffected by linear vibrations, but may similarly measure angular accelerations if the vibrations have a torsional component. The accelerometer and rate gyro values are digitized into a fixed number of bits and written into memory at 200 samples/second.

A buffer overrun is when more bits are written to memory than has been allotted to those data, and so unallotted memory is used. That does not appear to have any relevance at all to this situation since the quantity of data (bitrate) in the accelerometer and rate gyro data streams is entirely unrelated to the magnitude of the discrete values being measured and reported.

Woud you like to try to explain what you were thinking, or is this going to remain an enigmatic "exercise left to the reader" kind of thing?

 

[BJR981S]

The accelerometer and rate gyro values are digitized into a fixed number of bits and written into memory at 500 samples/second.

I dont think so. Where did you get this information. Is this The Accelerometers and Gyros inside a DJI flight controller or a generic accelerometer you researched on the net? You words read like a generic description from Wikipedia

Even so 50 Samples per second is a lot of fast data. You did not define what a sample packet looks like e.g. number of bits. Async or Sync. Is the data stream interrupt driven? are the interrupt signals latched or not. I unfortunately do not have the internal schematics for a DJI FC, Do you?

The FC is somewhat busy processing GPS at about 10Hz Accelerometers and then Gyro Accelerometer data. Plus all the log writing etc. its a busy little beastie.

Under normal flight conditions it has enough CPU capability and internal memory. Remember that it has to process the Delta change in telemetry input and apply that to the PID settings defined in the FW.

If the FW was written in Assembler then you would most likely be able to cope but these days everything is in 3 or 4 GL and buffer reliant. Either the input pipe buffers or the free reusable memory chains. Ah good old linked list memory chains, pity when you overuse the chain.

If you don't understand what I am talking about or just trying to yank my chain then Im sorry, your loss.

Anyhow, A good example is copying data on your PC from a Solid State Drive to a Hybrid drive. Once the hybrid's solid state has been filled the Drive resets itself. Its cannot cope with the algorithms used to migrate its solid state to platter.

Some people call it "drinking from the fire" hose.

Cheers

I am finished with this thread.

 

[sar104]

I dont think so. Where did you get this information. Is this The Accelerometers and Gyros inside a DJI flight controller or a generic accelerometer you researched on the net? You words read like a generic description from Wikipedia

That's the accelerometer and rate gyro data rate, reflected in the internal DAT file record - there is no mystery about that as far as I'm aware. There are certainly faster strap-down packages available (I use some that go to 20 kHz for shock-loaded applications) so it is possible that the data rate from the sensors is higher and it's downsampled in the log, but from a Nyquist perspective it's hard to see why the FC would need more than 200 samples/second when its output rate to the motors is only 50 Hz.

Even so 50 Samples per second is a lot of fast data. You did not define what a sample packet looks like e.g. number of bits. Async or Sync. Is the data stream interrupt driven? are the interrupt signals latched or not. I unfortunately do not have the internal schematics for a DJI FC, Do you?

200 samples/second is not a fast data rate at all by modern standards.And the protocols are irrelevant because the data handling is independent of the data values.

The FC is somewhat busy processing GPS at about 10Hz Accelerometers and then Gyro Accelerometer data. Plus all the log writing etc. its a busy little beastie.

Under normal flight conditions it has enough CPU capability and internal memory. Remember that it has to process the Delta change in telemetry input and apply that to the PID settings defined in the FW.

I'm sorry but this makes no sense at all. The FC doesn't care, from a computational point of view, what the flight conditions are - it takes raw sensor data and processes them to provide output parameters for the motors. The computational load doesn't change as a function of the input parameters, and I've never seen anything in the research literature on these kinds of control systems that implies there is any kind of adaptive processing rate algorithm used.

If the FW was written in Assembler then you would most likely be able to cope but these days everything is in 3 or 4 GL and buffer reliant. Either the input pipe buffers or the free reusable memory chains. Ah good old linked list memory chains, pity when you overuse the chain.

Now you are rambling. If there is a point buried in there somewhere I'm afraid it got lost in your output buffer.

If you don't understand what I am talking about or just trying to yank my chain then Im sorry, your loss.

I appreciate the sympathy - very generous of you. But no - I was not trying to yank your chain - I was just trying to see if you could come up with an actual coherent explanation of your original "vibration causes the computer to crash" hypothesis. You cleared up that question nicely.

Anyhow, A good example is copying data on your PC from a Solid State Drive to a Hybrid drive. Once the hybrid's solid state has been filled the Drive resets itself. Its cannot cope with the algorithms used to migrate its solid state to platter.

Some people call it "drinking from the fire" hose.

I'm sure they do.

I am finished with this thread.

Probably the wisest course of action at this point.

 

[Xtreme Drone Pilot]

absence of a credible hypothesis for the mechanism. Even if the vibrations were to excite a resonant oscillatory mode in the aircraft or a subsystem, integrated circuits are typically immune to vibration unless it causes structural failure in connectors, sockets, solder joints etc., but that would lead to permanent failure, not just a reset.

Any drone with IMU must run sensor fusion and parameter state estimation algorithms such as Kalman Filter. Now, I know from experience of coding and testing Kalman filters that it's very easy to "upset" them, after which their state estimation becomes garbage... the easiest and most reliable way to restore sanity would be to reset them, start from scratch. Kalman filter heavily relies on physics of the aircraft motion and various empirical coefficients that are used in the numerical integration of the model and state prediction; it also assumes, and is heavily dependent on, on various "noises" (noisy accelerometer, gyro, compass, baro, GPS, etc. measurements) having Gaussian probability distribution, which in real life is not the case and heavy unexpected vibrations are an example of that. Yes, there are various implementations of KF that make it more robust, but still... it's very easy to upset it with real life sensor data. Overall stability and reliability of modern consumer-grade drones is actually very impressive.

 

[sar104]

Any drone with IMU must run sensor fusion and parameter state estimation algorithms such as Kalman Filter. Now, I know from experience of coding and testing Kalman filters that it's very easy to "upset" them, after which their state estimation becomes garbage... the easiest and most reliable way to restore sanity would be to reset them, start from scratch. Kalman filter heavily relies on physics of the aircraft motion and various empirical coefficients that are used in the numerical integration of the model and state prediction; it also assumes, and is heavily dependent on, on various "noises" (noisy accelerometer, gyro, compass, baro, GPS, etc. measurements) having Gaussian probability distribution, which in real life is not the case and heavy unexpected vibrations are an example of that. Yes, there are various implementations of KF that make it more robust, but still... it's very easy to upset it with real life sensor data. Overall stability and reliability of modern consumer-grade drones is actually very impressive.

Agreed, and I would say that the transition to ATTI mode is a good example of what happens when the error estimate becomes too large - the system stops caring about determining absolute position and velocity from the Kalman (or equivalent) filter scheme and instead simply controls pitch and roll, and stabilizes yaw. However, the point that I was making above was that this kind of situation is not going to require or force a reboot of the entire FC, which was the hypothesis I was questioning.

 

[BJR981S]

Agreed, and I would say that the transition to ATTI mode is a good example of what happens when the error estimate becomes too large - the system stops caring about determining absolute position and velocity from the Kalman (or equivalent) filter scheme and instead simply controls pitch and roll, and stabilizes yaw. However, the point that I was making above was that this kind of situation is not going to require or force a reboot of the entire FC, which was the hypothesis I was questioning.

And Windows never has a blue screen. Excessive parameter changes will exercise system reboots. It all about how well the pointer management, and type checking is done in the coding in input buffers. The same reason Windows has security issues on buffer overruns.

But DJI never have bugs in their code do they?

 

[sar104]

And Windows never has a blue screen. Excessive parameter changes will exercise system reboots. It all about how well the pointer management, and type checking is done in the coding in input buffers. The same reason Windows has security issues on buffer overruns.

But DJI never have bugs in their code do they?

Good grief just stop. Logical fallacies and meaningless technobabble do not constitute an argument. What a waste of electricity.

 

[BJR981S]

Its only meaningless, and technobabble to those that are ignorant of software coding.

From one that has over 10 years as a professional coder, and architected the Windows Intellimirror technology introduced in Windows 2000 I do know what I am talking about.

The first step to enlightenment, is an open mind to what you don't comprehend.