Replies to This Discussion

Permalink Reply by Drone Savant on September 6, 2012 at 8:23pm

I thought this was already diagnosed as "the leans" wasn't it? 

• ▶ Reply

DeveloperPermalink Reply by jasonshort on September 6, 2012 at 9:39pm

The crash was caused by simple mode bearing being off by greater than 60 degrees reversing roll and pitch. It wasn't leans. It was a dcm init issue and probably mangnatometer calibration issue. These two worked together to create a yaw that was incorrect.

• ▶ Reply

Permalink Reply by marc.kulhavy on September 6, 2012 at 11:54pm

Only for information, I did the live calibration of the magnetometer as mentioned in the MP. A erase/reset was alsomdone tomget rid of all old settings. After a firmware update, i always recalibrate everything.

• ▶ Reply

Permalink Reply by Drone Savant on September 7, 2012 at 5:41am

Thanks for clarifying Jason I think this specific reply had me confused: 'This is "leans" It's due to vibration'. http://diydrones.com/forum/topics/worst-crash-ever-log-analysis-nee...

Looks like it was in response to Andke saying "I am curious of the conclusion - if you ever get one - but this is basically what I've experienced several times"

 

• ▶ Reply

Permalink Reply by Lloyd DeForrest on September 7, 2012 at 8:46am

Jason,

I've had controls reverse on two flights in simple mode.  Can you explain how this can happpen and what we need to do to prevent it?   How did my bearing get off over 60 degress?  My compass always check's out fine.

• ▶ Reply

DeveloperPermalink Reply by jasonshort on September 11, 2012 at 8:58am

The DCM uses the compass to nudge the Z gyro back into perfect alignment. It takes time and works very slowly. The Z gyro is very good, but drifts slightly over time for numerous reasons, but this is true in all systems.

The compass data is run through a small gain filter and added to the Z gyro solution. This keeps the noise from the Compass data from hurting your Yaw.

The key thing to keep in mind is the idea that it takes 20-30 seconds for a major change in the compass to finally nudge the DCM Yaw solution to a new solution.

The DCM was initing to 0 in the rev of code you used. When you took off it did not have enough time to nudge the Yaw to the correct heading. I saw at least 30° error on the yaw in your logs by measuring the buildings from your video. This bad heading was saved at arming as your simple mode reference heading. The Yaw error was compounded as you took off due to high current interfering with the Mag.

If you're calibration isn't great it can effect you a lot. I believe this made up for the rest of the difference. Once that happened your pitch was now your roll and vice versa. Pulling back made it roll and correcting the roll made it pitch forward. 

Ive had this happen to me 3-4 times over development and testing. There was a very old bug that went away after Tridge rebuilt the DCM that was a spontaneous rotation of Yaw. That would do the same thing. If you could catch it you could rotate your body to get a better reference to forward and bring it home. 

If you're not expecting it, you won't see it as a Yaw bug in the air and correct it. It's best to let go of the sticks, then push forward and see where it's going. Then rotate your radio to align with the new orientation and bring it home immediately.

Jason

Permalink Reply by Victor Iliescu on September 7, 2012 at 8:32pm

I don't know if this means anything to anyone, but I had yaw drifts with 2.7.1 when flying in ANY mode...

• ▶ Reply

Permalink Reply by Dan Gray on September 8, 2012 at 7:07pm

Hi Marc

I looked at your video, and your log file using APMLogVisualizer 1.34, and I've determined that your roll but mainly pitch sensors failed mid flight.

I wish you had logged your motors, you need to turn them on using the CLI, but even without that data, Ervine was right in saying that the roll/pitch was one way, and it was flying the other.

I suppose it could be a fierce wind that would do the same thing, but I see no evidence of that anywhere else in your video.  

So to summarize, after you pulled it back toward you, it starts moving away from you.  At that point the log file says you're pitched backwards, and in fact, looking at the video, you're pitched forward.

Dan Gray

• ▶ Reply

Permalink Reply by marc.kulhavy on September 9, 2012 at 7:56pm

Dan,

thank you very much for spending your time on this.

In the first place, I was convinced by the analysis of Jason Short that a init bug inside of the apm caused the crash, as the copter did not read out the magnetos settings correctly. I did have the time to take a look at the logs using your neat little tool and came to the same conclusion like you did.

The copter did not change its "virtual" orientation as the heading error did sum up, it began to drift and lean on the pitch axis.

As the copter crashed the board got disconnected from the lipo's so the log files stopped. But at the end of the log files you see some sinus waves of the sensors, which means - if you compare it to the video - the sensors went mad because the copter rotated along the z-axis, not along the x or y axis.

I just connected the board to the mission planner and I when I knock softly on the sensors, the wild spinning begins immediately on the artificial horizon.

Anyway, I am just about to dissasemble and every single part and will post the results shortly.

With kind Regards

Marc

• ▶ Reply

Permalink Reply by marc.kulhavy on September 9, 2012 at 10:47pm

Ok, it's time to get things to the end and come to a conclusion.

I have checked every singe component of the copter and found nothing except that the sensors on the IMU are not working correctly. Could be due to improper solder connections or a defect of the sensors themselves. Take a look at the video, than you will se what I mean.

And here comes the rest of the stuff.

First, the copter himself.

The motors.

The GPS. It has been torn off the copter and laid about 2 meters away.

A closer look on the arms and the screws, pretty much force must have been used "redesign" them.

And last but not least the charging state of the lipo cells.

Conclusion:

As the board shows odd behavior, it probably could have been the source of the problem. The variant from Jason, the dcm init error is plausible, but a closer look from Dan with the log visualiser shows that the yaw calculation seems ok. And, as the copter started to "lean" i pulled back, which was the exact opposite direction it was leaning to and orientated. So the yaw error must have been nearly 180 degree, summed up from two turns in the opposite direction.

If it's the sensors on the board and they werde not soldered properly, they could be resoldered. If not, the IMU would be the most expensive part, relative to the arms and the motors.

• ▶ Reply

Permalink Reply by Drone Savant on September 9, 2012 at 11:08pm

I didn't realize this was an APM1. That really does remind me of the first crash I experienced that was caused by a faulty gyro... This is what I caught my gyro's doing before I had it sent in for repairs, (shortly after an unexplained crash that bent sevral arms and broke all my props). http://tinypic.com/player.php?v=2edr3pt&s=7

Back then you were able to get repairs... I got some great advice on reflowing the parts myself to try out if I chose to. I have included my correspondence with support here as it may be useful for you and others. Additionally Chris Anderson offered a few protips to help check and make sure it was not my own poor soldering that caused the issue. Those can be located on this thread here: http://diydrones.com/forum/topics/arducopter-gyro-roll-values. 

The tip that really helped determine that the hardware was faulty was this: 

You can run the example test program in the AP_ADC folder in the libraries. That will give you raw data values.

 

Good luck! 

---- support correspondence follows ---- 

From: Help 3D Robotics a href="mailto:help@3drobotics.com">help@3drobotics.com>
Date: Mon, Sep 19, 2011 at 2:56 PM
Subject: Re: Blown X/Y Gyro... repair?
To: Sales 3DRobotics a href="mailto:sales@3drobotics.com">sales@3drobotics.com>


Hi KF,

Thank you for the email and I am sorry to hear about the trouble you are having with the gyros. It does seem like there may be a hardware issue with the gyros. Unfortunately with the gyros, we have found that repairs may not always be successful, since re-working the gyros may greatly reduce the life of the component, and the boards may be easily over-worked when repairing the gyros. If you have a re-flow gun or have an experienced friend you can try re-flowing the gyros at 325 degrees Fahrenheit and this may help if the gyros are no longer contacting well with the board. This may sometimes happen from wear during use or if the boards are in a crash.

 If you would like to send us your boards for repairs, we will test the boards here at the store and then we will attempt any necessary repairs. Repairs usually cost between $10 and $15 but should be no more than $20 depending on how long it takes to repair the boards and whether or not any components need to be replaced. Please let me know if you would like to send us your boards so that I can create an RMA number for your boards and send you instructions on how you can send us the boards. Thank you.

Regards,
3D Robotics

The followup a bit later

Hi KF,

Thank you for the email. We found that there was a problem with the XY Gyro on your board. We were able to repair the board, and it is currently under observation which may take quite some time. The board has been working fine, and we will be sending it back to you very soon. 

Regards,
Carmen
3D Robotics

On Sun, Nov 6, 2011 at 10:03 PM, Kevin Finisterre a href="mailto:kf@digitalmunition.com">kf@digitalmunition.com> wrote:

So it has been quite a while now... what is the story? I have not received the repaired board. 

-KF

You really are lucky that wasn't a gen 1 JDrones frame! It would be a crumbled mess, I know from experience ;)

• ▶ Reply

Permalink Reply by Ervine Lin on September 9, 2012 at 11:55pm

Your video seems to show exactly what might have gone wrong, somehow in mid flight the sensors stopped working as they should and the inputs you did to try to stabalise the quad would have been to no avail as it would be impossible to fly in stabalise mode (acro maybe?).

Now the issue is why would the sensor stop functioning properly in such a dramatic fashion, a short perhaps? Maybe a stray wire or drop of water landed where it shouldn't have?

• ▶ Reply

• ‹ Previous
• 1
• …
• 6
• 7
• 8
• 9
• Next ›
• Page