Having successfully reflashed the escs ( much smoother by the way) the original problem which put me on this path remains. Basically, As i lift off, the quad spins and as soon as it makes one or two hops, it seems to jar its brain and then flies in a directed and far more oriented manner that resembles controllable. What could this be?

Setup: Stock everything with 4-12 x 3.8


Also I seem to get caught in a loop with the newer planner when trying to graph, as the connection demands the mavlink version 1 despite it being the 1.0 version already and cannot create a graph. Any thoughts?


tLogs are attached if thats helpful

TIA Bart

Views: 1549


Reply to This

Replies to This Discussion


That's an excellent idea! Im still trying to get a handle on what is statistically significant here however. The frame and motors all appear to be straight on all axes. Thats not to say they perhaps arent off by a degree or two, but Its not visually apparent. I should perhaps elaborate a little, but the rotation is not slow but rather 360 degrees per second or so. basically enough so that its tough as a fairly decent fixed wing RC pilot, I cannot get it to maintain a consistant heading and will mash it if i try, so i end up up wussing out and setting down.

Ill try that immediately. Ill disable and attempt a flight or 2

Thanks for the great idea


So I just flew a battery with some marginally stable time, but the same issue continues even though the compass was disabled. It may have been slightly better, but not enough for me to say without a doubt that was part of the problem. Also, JSYK, there does not seem to be a way to disable GPS as Ive an APM 2. Any references to it involve desoldering or rewiring. Am i missing something here? Disabling the magnetometer was no problem though.


Heres a quick description, again, of what i routinely experience:

As I lift off, the quad starts to rotate clockwise quite quickly, and even appears to accelerate. For the most part its straight up, but occasionally will require a little control input to lift off somewhat cleanly ( perhaps due to breezes, but also when calm). 4-8 seconds of the quad spinning out of control forces me to reduce throttle where it bounces a few times then seems to straighten out mostly and resembles something flyable.

when I connect through the CLI( yes, latest Rev) I get a bunch of screen prints of ASCII that the APM appears to try and parse. Heres an example:

Opened com port

Init ArduCopter V2.6

Free RAM: 2370

FW Ver: 118


load_all took 10536us

Press ENTER 3 times for CLI

G  MTK1.6  OK




3GROUND START?Q`'?Init Gyro QC^`'* Q.P`'H * 3Initialising APM...?Q2`'_ IMU


G_off: 0.00, -0.01, -0.03

A_off: 0.12, 0.39, -0.07

Ready to FLY 

Q?Q ?Q?

Q@u Q~?Q?Q?Q?QQ-{ Q?Q#?QQg QpQi Q?QN? Qx !Q("Q?#Q?$Q{?%Q?&Qv ArduCopter V2.6]  logs

Invalid command, type 'help'

( no keyboard input from me until this point)


No logs

Log]  help







No logs

Log]  erase

3Erasing logs?3Log erase completelogs enabled:  ATTITUDE_MED GPS PM CTUN NTUN CMD CURRENT MOTORS PID

No logs

Log] < this last half shows clean but that is not always the case- other examples illustrating this are available here http://www.diydrones.com/xn/detail/705844:Comment:902824

Again, WTF? is this a normal occurrance or is my APM screwy? and how am i supposed to get an RMA if support refuses to answer?

I added motors to the logging before this last one and the CLI claims no logs are available but several tlogs and rlogs appear on my drive. ANd yes, the above example shows my clearing logs, but this is after many attempts at connecting and reconnecting then finally clearing whatever is there.

I feel sufficiently vindicated that ive eliminated fields as an issue, and also Frame and motor alignment is seemingly within acceptable tolerances, but there is something going on that i cant isolate. Do I need to document this with a video or what? Respect to all whove attempted to help thus far, but any other help would be greatly appreciated.




Good Thought, except they arent and the behaviour is temporary and you wouldnt have yaw authority as i do now. If you read the rest of the post, youll see that the APM has been doing wierd things in mission planner, including spitting out misc. characters in CLI mode. Im leaning that direction now.

YAW PROBLEM SOLVED - Many thanks to all who helped! I learned something from everyone and greatly appreciate your contributions.
Paul- Im preparing to eat a slice of delicious humble pie. That is almost what the problem was, but maybe not in the way you or I thought. The props were reversed but not in a thrust way, nor were they all pushers, rather the rotation was opposite for every rotor.

The correct orientation of the pushers and pullers is ( from above, forward at top)


ccc, cw

I had them oriented



While technically the rotors were oriented properly as they related to one another, they were not oriented in the way the APM expected. My APM issue of garbage chars in the CLI continues, however and Id love to know if anyone else experiences the same or knows if thats normal or pre-failure behaviour?



Pleased you got the props sussed. I bet you wont do that again :)

Regarding garbage, how are you connecting to the APM? Using USB, or 3DR radio, Or xbees?

For terminal type business I understand USB is the only way to go. I defo get garbage with my xbees.

You always get garabage AKA not human readable for a reason, that's binary mavlink data.

One of the first rules they taught us in a programming class is that sending serial data in ASCII human readable statements takes lots of resources on the Arduino. I know everybody thinks these are blinding fast but when you send human readable text, nothing else(reading sensors, performing calcs, reading RC inputs, outputing PWMs) can happen. Sending the binary data is much shorter bursts of CPU cycles and thus much better performance of the entire system.

That's the reason, you are in a flight controller and thus it needs the maximum performance so mavlink defaults to binary format which either mission planner, or some of the ground stations and also the minimOSD understand and decode. You are asking about seeing command line (human readable), and by sending enter 3 times (stated in the instructions), it switches the mode to human readable text. You wouldn't want to do this while flying and I don't know if the software limits it, but in theory, you might have some problems on a multi-rotor platform because they need the active stability. Those tiny pauses, even if slight, are the equiavalent of bad PID tuning because by the time the quad has moved or leaned, it's that much further time wise before it gets corrected. I think the USB may sometimes default to human readable text, but again, you do not want that while flying a multi-rotor.

On APM1.0 this was such big deal, they used a hardware switch on the shield to switch modes, but APM 2.0 is software based and thus you send enter 3 times and it switches.

When Id asked before, it appeared that no one else had experienced this. I guess for me the issue of seeing machine code in the CLI was unsettling as it also appeared to respond to itself. In other words, it would show the init strings for the CLI after Id pressed ENTER 3x. The mavlink ASCII would print to screen at the cursor and then the APM would appear to respond with a "Bad command" or whatever the error trapping string is. I had not touched the keyboard since the enter commands and therefore i was reasoning that that spurious data included a char(13) in there somewhere. You bring up a good point though that maybe theres such a lag that it one of the enter commends pushed in ASCII that had not yet been written to screen. Dunno I guess its all moot since I decided to follow the laws of physics and realized it works properly in spite of its telemetric incontinence.

Like they say you only have to worry about talking to yourself if you answer and that's what appeared to happen here.

Anyway I need to get out and fly...



Nothing like a little karmic de-pantsing to bring one back to humilityville. @DaveC I should have reasoned that one out as the prop-er direction directs torque to center while my nifty new innovation of torque dispersal ( did that sound legit enough to rescue me? lolol) perhaps wasn't the best idea. Though I will say that was due to oversight on my part as my concern was merely that the counter rotation was mirrored and that the motor direction was in keeping with the prop direction.  As a friend used to say to me "Check everything twice and you'll be guaranteed to be wrong only 75% of the time"

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service