Replies to This Discussion

Permalink Reply by ultrojo on June 14, 2012 at 11:16pm

Thanks Randy,

actually last month , i tried many times code AC2 from 3rd party and compile, but still can not get works about the minimum throtle as ultrapwm esc requirement. i was  headache , finally, i just replace standard esc. i am happy with that.

Randy,

do you think my quad setup/frame can using default parameter 2.6 version well?. i only concern about stablizer,loiter and RTL . i want to take AP/AV and FPV.

• ▶ Reply

Permalink Reply by Knut Graf on June 14, 2012 at 10:33pm

Reposting here (closing the separate original thread) as Chris A. suggested:

Fly-Away Scare.

Preface: Needless to say, correlation is not causation. The event described here occurred on my first flight with 2.6, but may be found to not be a software problem at all, like many quad issues.

The Event:

I installed 2.6 this evening and took it out to do a bit of close-in, low altitude test flying to see if my tuning was still good, just before it got dark here. Before today, I had been flying 2.5.5 without issues (besides a yet-to-tune loiter). This first flight with 2.6 went fine too, until...

...a few minutes into the flight, while I was in Stabilize mode I think, the quad suddenly started accelerating vertically, climbing away. I zeroed the throttle, and jumped into Land mode, but got no reaction. I was flying next to a tree, and the quad lodged itself high in the tree crown, preventing a total fly-away. It hung there, props spinning at high throttle like a weedwhacker, for a very-long feeling time (maybe a minute), until it came loose, tumbled down and smacked in the ground.

I flipped through my modes and wiggled the controls while the quad was in the tree, getting apparently no reaction, but I did not have the presence of mind to try to disarm it. (Note to self: remember to disarm.)

A couple of broken legs, a set of chipped props, a few popped screws and a broken cheap camera mount seem to be the only hardware crash damage - not a problem, thanks to the 3DR frame engineering. As a positive side effect, it was good to experience that my heart does not actually stop in this type of situation :-)

In my flights over the last few weeks since building the quad, I have not experienced any unpredictable behavior, scares or radio problems. The props were balanced and the battery had plenty of power.

Setup:

3dr-b frame, 880kv motors, 11*4.7 APCs, APM2, 3dr radio, sonar, optical flow (not tested yet), 4s1p LiFe 4200mAh battery, DX8 TX, AR6210 RX with satellite, DSMX.

I am attaching the log. It gets interesting just after 90% / 600s in the .tlog, and at line 13930 in the .log

---

Update:

Graphing the log myself, I see that the rc inputs go flat a couple of seconds before the unexpected climb starts. This might indicate an RC connection failure, followed by what looks like a behavior similar to the rtl-failsafe for Auto mode ("Climb!").

I wasn't in auto mode, though, and I don't have that failsafe mode enabled.

While the quad was in the tree, I power-cycled the TX, and that does not show in the RC inputs, also indicating that the RC connection may have been lost. I'll have to compare these frozen rc input values to my RX failsafe settings.

Attachments:

• 2012-06-14 19-54-44.tlog, 1.3 MB
• 2012-06-15 00-02 101.log, 748 KB

• ▶ Reply

DeveloperPermalink Reply by jasonshort on June 14, 2012 at 10:49pm

Hi Knut, 

I looked over the logs for a while and can readily pinpoint the radio loss. The set point of the throttle was just high enough at the loss to cause the climb.

Signal loss would be one explanation. Do any channels change on your radio for failsafe? that could rule that out.

A signal wire could have a short causing the PPM encoder to stop reading and outputting a constant set of last good values.

Can you look over things and see if you can reproduce it?

Jason

• ▶ Reply

Permalink Reply by Knut Graf on June 14, 2012 at 11:06pm

Thank you, Jason.

I will review the failsafe settings and take a close look at the receiver-to-apm wiring tomorrow night.

Knut

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on June 15, 2012 at 6:55am

Knut, can you confirm what your Rx does on signal loss?  I wonder if it's similar to the Turnigy (ie: drops the throttle channel).

Were any signal wires loose after you got it back?  Obviously we couldn't determine if the wires came lose before the flyaway, or after it crashed.  But it no signal wires are loose after the crash, then obviously none were lose before the flyaway, so we could rule that possibility in/out.

I consistently hear too many terrible stories about Spektrum equipment that I just won't fly it.  Just last weekend, a pilot at the airfield told me his Spektrum Tx/Rx have buggered up 3 times now.  He had to turn the Tx power off and on mid-air to re-establish connection, and now the Tx won't bind to that Rx at all anymore.

• ▶ Reply

Permalink Reply by Knut Graf on June 15, 2012 at 4:54pm

Regarding the Spektrum equipment, I think there is a range of quality available. The current DSMX systems are, at least in my experience, a lot better then the early DSM and even DSM2 systems, where a lot of fliers got burned.

Update on the analysis:

First, I reviewed the failsafe behavior, and it's working fine: upon signal loss, throttle goes to Off (under 1000µs). So radio signal loss did not prompt the climb out.

Second, I checked and wiggled the receiver-to-apm wires individually, while connected to the planner, to see if there would be any loss or input signal based on a wire shorting out. No such think occurred, and the connections were all firmly in place.

Then I investigated the following:

I had a small tilt-camera mount on the copter (keychain cam on it), driven by a powerful servo (an old Multiplex Micro Speed), which I had just installed before the flight with the fly-away event. During the flight, the camera mount had been hanging loose, with no pushrod linkage on the servo (glue still curing on the pushrod), but with the servo active. Maybe the servo got caught on the frame in the wrong way and stalled in flight.

I tried this: while connected to the planner via USB cable (no battery on the copter), I manually stalled the cam tilt servo. This caused the receiver to flicker wildly (indicating frame losses, possibly a crash) and the APM to reboot, dropping the connection to the PC. The receiver recovered when I unplugged the camera tilt servo from the APM. I reproduced the same with a full-size analog Futaba servo as the camera tilt servo, which caused the crash/reboot but would let the receiver recover immediately. I also tried two micro servos in this manner, but stalling them did not disrupt APM and receiver. So there is a possibility that drawing too much current on the camera tilt servo was the problem.

Unfortunately, I have not been able to reproduce the same "current crisis" while running the quad off a battery, with running motors. The battery provides much more power then the USB cable, and without props, on the bench, the motors don't draw all that much. Running from the battery, the board is fed through the 2Amp BEC of a 20Amp 3dr ESC. These 2 Amp are driving the APM with all its sensors, plus the dual receiver, plus the 3dr radio, plus sonar, plus optical flow. Maybe, in flight, the "current crisis" scenario did occur when a big stalled servo was added to these consumers of power.

• ▶ Reply

Permalink Reply by Cliff-E on June 15, 2012 at 8:04pm

Typically we see the quad drop out of the sky (motors off) on DSM2 signal loss pre 2.6.

I see a DSM2 drop once every month at least.

Look forward to using 2.6. Problem is I now need to port all my MAVlink code!

• ▶ Reply

Permalink Reply by Glenn M on June 14, 2012 at 11:17pm

Is there a firmware upgrade planned for the minimosd to support mavlink 10?

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on June 14, 2012 at 11:21pm

Glenn: Yes, it's already in the repository. 

• ▶ Reply

Permalink Reply by Glenn M on June 14, 2012 at 11:24pm

Ah yes, thanks.

• ▶ Reply

Permalink Reply by Glenn M on June 15, 2012 at 1:18am

I've just run into trouble with this. The minimosd is now stuck at waiting for mavlink heartbeats after the firmware update. I'm running 2.6 firmware and have mavlink 10 enabled (connects fine through ArdupilotMegaPlanner10.exe).

Have even tried loading the old firmware back on and disabling mavlink10 in arduino but even that doesn't work any more! Is my board toast? And if so how?!

http://diydrones.com/forum/topics/minimosd-stuck-on-waiting-for-mav...

• ▶ Reply

Permalink Reply by Luke on June 15, 2012 at 11:39pm

Hey Chris, is there supposed to be a new CharSet for MinimOSD 1.9 w/ 1.0 Mavlink? I updated to 1.9 w/ 1.0 and it booted and said "Update Charset" so I got the 19 zip file and updated with that mcm. The update succeeds according to the OSD Config app. Still says 'update charset' when I install and boot it. So I tried flashing the 1.9 w/ 0.9 Mavlink, then the charset then 1.9 w/ 1.0 and I still get the same thing.

Is there something special that needs to be done?

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• …
• 68
• Next ›
• Page