Another arducopter flips on takeoff thread.

I've got a stock 3dr kit that I've just finished putting together, and it tries to flip on takeoff. I'm running x config. Arducopter 2.1 firmware.

I've run through the troubleshooting steps: checked motors with the cli motors command (successfully), made sure the correct props are on each motor, calibrated the radio and verified that the correct inputs are reaching apm, but I still cannot get this thing to take off or fly at all correctly. Apm is facing forward between the front legs, and the movements seem to show up correctly in mission planner when I move the quad around while connected to it.

If I give it a smooth throttle increase, it won't take off flat, it will just tip, so I back off the throttle. If I give it a burst of power, it will take off, but will dive off to one side and crash (just busted my first prop...)

I've run the imu test with the following results:

g   0.0209   0.0000  -0.0000  a  -0.1157  -0.0463  -9.8016.

I have downloaded logs from the last couple of flights where it was tipping when I tried to take off, but I can't figure out how to interpret them. If anyone could give me a quick rundown of the best way to view/read them that would be good. I have attached the log.

Are there any other diagnostic checks that can be run to find out what's going on? I saw another thread where someone was checking the watts of power delivered by each esc to each motor to verifiy that a esc/motor not running at full speed wasn't to blame, but I'm not sure how this would be done.

2011-12-18 09-55 2.log

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hey u4eake, so it appears that yes the sensors do zero and the drifting does go away when I arm the motors. When I disarm them though, the drifting will usually return, and rearming them will not zero the sensors or stop the drift. It seems to be intermittent whether the sensors will drift or not. Last night I had the quad connected via USB without lipo connected, and everything was rock solid for an hour, then I disconnected and reconnected, and it started to drift all over the place. 

    After a full teardown/resolder and a bunch of testing, I did manage to get the quad to hover for a few seconds today, but I do need to add some control input, and it's still very hard to get it to stay in one place. It wants to drift off to the right pretty consistently. After a few takeoffs and landings, I notice one side of the quad will want to flip over (towards the right) and just by looking at how blurred the text on the motors are as they are running, it looks like motor 1 (front right) isn't spinning as fast as the others.

    I have noticed that during the motors CLI test, holding the stick back to make the rear motors spin (2 & 4), they will go fast (from their sound), holding it left, motors 2 & 3 will go fast, but holding it up, both motors sound like they go slower, and same if I hold it right. It seems that any combination that invokes the use of motor 1 will run slowly, and I believe this is a symptom of the problems I am experiencing.

    So basically I thought the problem could be with either the motor, the ESC, or the signal path through the PDB for motor 1. I tried swapping the 3 larger connectors of ESC 1 and ESC 4, but kept the signal wire of ESC 1 plugged into the ESC1 port on the PDB. Then running the motors test, motor 4 now displays the behaviour that motor 1 previously displayed, so this tells me that motor 1 and 4 are both good.

    I then tried swapping the signal wires of ESCs 1 and 4 too, so that ESC4 is completely running motor 1, and ESC1 is running motor 4. During the motors test, any stick direction that spins motor 1 (running off ESC4 connected to the ESC1 signal on the PDB) will still make the pair spin slower than the others. This makes me believe both ESCs 1 & 4 are good too.

    So that just leaves the PDB if my logic is right? I resoldered every point for motor/esc 1 on it (the orange cable). It was after this point I did a hand test followed by a flight test, and could just get the hover, but it wasn't able to be maintained, and then after that I had the issues with it trying to flip over to the right on subsequent takeoffs.

    I'm just trying to rule out every potential place that this could be failing before I take the oilpan/mag off and send them in to 3dr since it will take weeks and I want to make absolutely sure the problem doesn't lie anywhere else, but as of now, I am stumped.

  • I have just emailed help@3drobotics.com with info.

    Thanks for your help.

  • Thanks for  that Pat, I did come across your page before I started with my build, so did take your advice into account. I have got all of my ESC's connected to the correct wires on the PDB, but did have to cross the motor connections to the ESCs over the PDB for motors 3 & 4.

    So for my issue. I'm still finding that when the quad is sitting on a flat bench, that the compass and roll sensors will constantly move, which ends up with the quad showing that it is constantly spinning in the mission planner, when it's sitting stationary. Is this indicative of a hardware problem, and how can I definitively verify it one way or another, and get this sorted. I'm itching to get this thing in the air!

  • Glenn,

    The 3DR assembly instructions are incorrect. I posted about this about a month ago and there has been another recent thread about this, but there has been no acknowledgment by the folks at 3D Robotics that this is an issue. I understand that mistakes happen, and that as a community based project, it is our responsibility to learn about these mistakes and provide feedback. With that said, I am greatly disappointed with the response of 3D Robotics, since this documentation should have been corrected already and new people should not be suffering through this.

    For reference, the posts are:

    http://diydrones.com/forum/topics/arducopter-3dr-build-documentatio...

    http://diydrones.com/forum/topics/frame-assembly-possible-error-in-...

    Good luck and let us know if these topics help to address your issues.

    Pat

  • Everything is absolutely dead level when I plug it in. I am 100% aware of the requirement for this. Even running a level command while it is sitting flat on the bench and switching back to the flight data tab, the compass and roll still show that they are moving.

  • It sounds like it's in simple mode, but it's definitely just set to straight stabilize mode without simple enabled.

    I've got it sitting on a flat bench here and connected to mavlink now, and the compass is constantly moving, and the roll is also moving quite a bit. I think this is where all my problems are coming from, but I don't know if it's indicative of a bad compass, APM or something else? I have attached a screenshot

    arduopter yaw roll drift.jpg

    https://storage.ning.com/topology/rest/1.0/file/get/3692321263?profile=original
  • Unfortunately I have been unable to successfully repeat that hand test. The thing that really gets me, is that the behaviour isn't always repeatable, and I'm not sure where the problem could be because of this.

    Last night after the successful hand test, keeping all connections exactly the same, I powered it off, plugged the lipo in again on a flat surface, and then instead of trying to maintain a flat orientation it wanted to roll strongly to the right.

    Hand testing it this morning, it seems like motors 3 and 4 are responding correctly, but motors 1 and 2 only increase or decrease in speed when the throttle is manually changed. The fact that the speed of motors 1 and 2 are changing with throttle input makes me believe that the connections from the APM through the PDB to the ESCs are fuctional, otherwise the motors wouldn't be able to have their speed controlled at all.

    I think I may have made somewhat of a breakthrough, but I'm not sure how to verify it. During the hand test, if I rotate myself (yawing the quad) different sets of motors will start to respond when the quad is deviated from flat. So in the above scenario, where motors 3 & 4 were responding correctly before, rotating it will make motors 1 & 2 start to respond, or a combination of the 4 but it still never really wants to stay flat. Does this mean that I could have a faulty magnetometer?

  • OK this just gets weirder. I pulled the whole thing apart, checked every connection, recalibrated the ESCs and gave it another hand test.

    At 25% throttle, the hand test fails. Motors 3 and 4 are doing all of the work when the quad is rolled or tilted, and 1& 2 do nothing (other than maintain a low rpm).

    However at 50% throttle, all motors work properly. In the hand test it fights every pitch or roll change off centre.

    This isn't how it's supposed to be right?

    Any ideas why at low throttle a couple of motors don't seem to be responsive?

  • Yeah I have tried swapping the connections of 1&2 and 3&4, but that doesn't help.

    Ok , so latest hand test, when rolling the quad to the left by hand, motor 2 increases in speed to compensate, and when tilting to the right, motor 1 increases in speed. This is correct behaviour yes? 

    The thing is,  it appears motors 3 and 4 remain at constant rpm no matter how much the quad is tilted either way. What could the cause of this be?

  • Actually scrap that horizon comment, that's correct behaviour and shows that the APM is oriented properly, but does anyone have any ideas about what's going on here?

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
yesterday
DIY Robocars via Twitter
yesterday
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
DIY Robocars via Twitter
Excellent use of cardboard instead of 3D printing! https://twitter.com/Ingmar_Stapel/status/1324960595318333441
Nov 7
DIY Robocars via Twitter
RT @chr1sa: We've got a record 50 teams competing in this month's @DIYRobocars @donkey_car virtual AI car race. Starting today at 10:00am…
Nov 7
DIY Robocars via Twitter
Nov 6
DIY Robocars via Twitter
RT @a1k0n: Car's view, using a fisheye camera. The ceiling light tracking algorithm gave me some ideas to improve ConeSLAM, and having grou…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: To get ground truth I measured the rug, found the pixel coordinates of its corners, calibrated my phone camera with my standard…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: @DIYRobocars is back in December, but outside. Time to reinvestigate ConeSLAM! I rigged up a quick and dirty ground-truth captur…
Nov 5
More…