Replies to This Discussion

Permalink Reply by matterenergy on August 19, 2012 at 8:26pm

Turns out the quad "freakout" when the radio gets turned off was caused by a failsafe being set to 20%... when it looses the signal, it will increase throttle to 20%. That is resolved. However, still wondering what the causes this problem in the first place. I am thinking an overloaded BEC causes one ESC to shut down for a second... causing the quad to flip as well as a momentary loss of power to the receiver, then after the crash it throttles to 20% due the failsafe until the receiver re-associates.

However, I have 4 ESCs.... if one browns out, wouldn't hte others take up the slack?

• ▶ Reply

Permalink Reply by Drone Savant on August 19, 2012 at 9:30pm

I've been chasing a brownout problem for a few days now and have had similar behavior to what you describe with regard to the motors running post crash. The motors stay on from time to time after the brown out, but not always. Here is one of the brown-outs caught on tape. This is one that does indeed leave the motors running. I have found that this NOT always how it occurs though. http://www.youtube.com/watch?v=uKwUY4nHuKY. I had one instance where my PPM encoder was corrupted during the brown out as well. The ESC's just started beeping like crazy mid flight after everything suddenly stopped http://www.youtube.com/watch?v=VpUTqrcEE5g. 

After the quad flips... can you observe the A-B-C LED? Are they off? Do the do the gyro init LEDs flash shortly after the flip / crash? The reason I ask is that your board has rebooted if this occurs. Every time mine fell out of the air I had found that it was in the process of rebooting (post brownout). 

This may sound stupid... jiggle your telemetry connector on both ends and make sure that it isn't loose. I noticed at one point that this loose connector contributed to my board locking up. It certainly isn't the cause, but I think the reconnection and disconnections were just enough to cause power surges thus making the board brown out. 

How about the Schottky fix, do you have it applied? See http://code.google.com/p/ardupilot-mega/wiki/APM2Protection or http://ardupilot-mega.googlecode.com/files/APM2.0PowerFixHow-To.pdf

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 6:11am

Thanks for the input!

Unfortunately, I did not think to observe any of the LEDs at the time it happened. But, based on symptoms, it sounds like we're having some similar issues. Since my ESC felt like it was melting down, just when using the BEC function only - I ordered a 10amp dedicated BEC, and am hoping that will help with the issue. I'll post the results once I receive and install it.

• ▶ Reply

Permalink Reply by Lloyd Breckenridge on August 20, 2012 at 7:12am

(I have 4 linear ESCs tied together.) 

This is not recommended.

There have been many discussions regarding powering the APM from a single ESC/BEC.

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 9:24am

I went ahead and cut all the +5v lines except one - but the ESC powering everything still gets obscenely hot. It is a Turnigy Plush with a 2A BEC.

I have the APM, Futaba Rx, 900mhz 3DR, and Sonar attached. Could this be pushing that BEC?

In fact, I just tried another BEC from a parkflyer... has a 1A output. It gets hot as well.

What kind of power consumption should I be looking at?

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 9:38am

Actually, I just used a multimeter to test the current... it's about 300ma. Why then is it causing 1A and 2A BECs to overheat?

Update: I think I made a stupid mistake. When I tested with the parkflyer BEC - I left the other ESCs connected, and I think they were trying to draw power through the signal lines causing the little 1A BEC to overheat. I unplugged them, and now the 1A BEC is only slightly warm.

At the moment, I think I just have a bad BEC in one of the ESCs. (The one that was trying to power everything). I randomly cut the 3 wires... my luck has it, the one I didn't cut was the ESC that had been overheating in the 1st place. I will try using another ESC on the quad and report the results.

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 10:38am

Ok - So I tried using a different ESC to power and it still gets hot - 270ma draw. It's not as bad as the last one... but still gets too warm IMO. I'll look forward to trying the dedicated BEC.

• ▶ Reply

Permalink Reply by R. D. Starwalt on August 20, 2012 at 9:58am

I suggest you simplify the installation and use just what is needed to fly, remove telemetry power/connections.

Battery --> PDB --> ESC (all of them) ---> APM2.x + Radio Rx.

I use the 3DR PDB and all 4 ESC are paralled out of it for the APM power (pretty sure - ohmed it out).

Glad you caught the failsafe mode. The documentation says in failsafe, if farther than X(?) meters from launch point, it should rise 30meters, RTL, and then land. I have Spektrum gear and there is also a TX loss failsafe mode for the receiver. Check your Futaba for something similar.

I have been using a tether system on my quad. If one leg is tethered, I can go about 10ft up. Two legs, 5ft. I just have to be aware of the cord and propwash during liftoff. It wouldn't do to suck that line up into the prop. :-O

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 10:31am

I like the idea of a tether for this stage of testing, it will
- Prevent the quad from setting a course to the moon in the event of something I have not yet thought of lol
- Allow for "unlimited" duration flights - which would be nice to fly it for a few hours and measure ESC temps at various intervals and various payloads without regard for battery life.

Speaking of powering through a teather... Since it's running on 11.1V (9-12.6) I cold use a automotive deep cycle battery for power... right? (All my components are rated for 14.8 - so even at a full charge that should work).

I figured out how to remove the Futaba failsafe in the programming settings, it solved my problem there.

• ▶ Reply

Permalink Reply by Drone Savant on August 20, 2012 at 12:22pm

Do you have an Atmel ISP programmer by chance? If you do you may also consider checking the BODLEVEL on your Atmega32u2 chip. I found some interesting wording in the manual about EEPROM corruption due to low voltages. This chip is obviously responsible for the signal that goes out to the motors. 

http://www.atmel.com/Images/doc7799.pdf

During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the CPU and the EEPROM to operate properly. These issues are the same as for board level systems using EEPROM, and the same design solutions should be applied.

An EEPROM data corruption can be caused by two situations when the voltage is too low. First, a regular write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low. 

The board I am having issues with has a BODLEVEL of 2.9V. This caught my attention based on some comments from the designer of the previous PPM encoder chip that was in use on the APM1. 

http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A1257...

Also remember to set the BODLEVEL fuses to 4.3v because during power up or down the plane the flash memory might get corrupted

This may of course be unrelated, but I am curious to see what your settings are none the less. "the CPU itself can execute instructions incorrectly" was an interesting comment none the less. 

• ▶ Reply

Permalink Reply by Andrew Dunlop on August 20, 2012 at 2:08pm

Yep, I reckon 2.9V is a very adventurous level to set your brown out detection to.

If the rail is falling fast, 2.9V does not give you long before you are executing code with an out of spec supply, with all of the unpleasant consequences that that entails.

The safest reset circuit is an external one.

• ▶ Reply

Permalink Reply by matterenergy on August 20, 2012 at 4:11pm

Update: I disconnected all the +5v wires and used another ESC I had laying around as a BEC... problem appears to be solved. Flew for several mins in loiter mode with no crash. :)

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page