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.
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:
Good luck and let us know if these topics help to address your issues.
I'll bring this to their attention and have them review it to see if there is indeed an error, but did you notify anybody about this at 3DR? There are hundreds of posts here every day, way too many for the 3DR folks to keep up with. It's best to email the help team directly if you have an issue.
Good find, and sorry for not recognizing it earlier. Like Chris said there are so many hundreds of posts every day and things change so fast we sometimes let something slip through. We've actually got a new version of the PDB now with more descriptive soldermask. The soldermask basically does what the instructions did before (but now they're right!) Sorry for the trouble it caused you and anyone else during your build.
Chris, thanks for your response. It was my mistake to use this forum as my sole means of bug reporting without also notifying 3DR. Will be sure to do so in the future and hope to keep things progressing.
Jeff, the new design looks great. Very simple design change, but also very worthwhile when you're revving things.
On a side note regarding the PDB, I'm surprised that it doesn't also contain the voltage/current monitoring capabilities that are available in the attopilot sensor. There really isn't much to the design, and the PDB already has the relevant signals. It seems like it would create a very neat package that would could simplify the copter layout. Personally, I don't consider voltage and current measurements as ancillary data. Instantaneous voltage can provide a reasonable approximation to state of charge in and of itself, while current measurements can improve the SOC estimate and more importantly, serve as the best state of health indicator of the system. I really that this might be asking for a lot, but for future revisions of the board, I couldn't recommend it enough.
Yeah, the next version of the PDB will do all that and more. We're been working on a bunch of more advanced versions, coming soon.
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, that does sound like a hardware problem. Get in touch with email@example.com to get it sorted.
I have just emailed firstname.lastname@example.org with info.
Thanks for your help.
Does the moving of the sensors persist when you arm motors ? Gyro gets initialised on arming motors and there has been some reports of sensors going wild in the mission planner before motors were armed...
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.
In the mission planner you can see the values of the pwm signal that the APM sends to the motors. If they are approximatly equal and motors don't spin same speed, you have a motor, esc calibration, soldering, pdb board problem. If the output values are consistent with motorspeed (channel of motor1 lower then others) then maybe you do have a problem with your oilpan.
In that case you could check the roll-tilt-yaw values the apm is seeing by checking "Tuning" in the picture below. Then double click on the "legend" (the small area explaining what the colors mean) and you can select the things you wanna see graphed. You can have motorvalues graphed too.
Take a screenshot of it if possible, it will hopefully tell us something.
Hope this helps you to narrow down the problem !