Hi all.
I could really use some help trying to figure out if Arducopter 2.6 is ever going to work for me.
I have had a total of 4 units 2x genuine 3DR APMs and 2 generic arducopter.
2 buddies also have 1 unit each.
We all have major issues with all units.
to cut a long story short. We can have 3x perfect return to launches, then the the 4th one will result in a toiletbowl effect. Just randomness like that.
I've given up on using ANY failsafe as APM is just too unreliable.
That was a week ago, now things have gotten much worse.
Even stabalize mode does not work. If the quad makes it off the ground it will sometimes dart off in one direction, other times it just falls out of the sky The quad also "pulses"
Some times the quad will just stop responding to the controls and has to be knocked out of the sky to stop it from flying.
Othertimes the unit will just disarm on takeoff.
Have tried multiple recievers, boards etc, NOTHING fixes these issues. Both my buddies have given up on their board and now fly perfectly with another (closed source) autopilot. I would like to get this going correctly but the APM just seems so unstable.
I have attached some logs in case that helps.
Please help!
Replies
See Robert you need to have a genuine interest in solving problems. I checked back in my logs of my F450 with a full size 3DR board which has no vcc problem and it fails in exactly the same way. The logs of the motors during the failure look identical, yet the hardware all around is entirely different. So quit being so defensive and try to figure out the problem.
or don't. Nobody is demanding your attention. Just simply noting their problems in a civil manner in an open forum. If this is 3DR tech support then charge a fee and lock it down to subscription holders. But if it is not then quit complaining that some people buy hardware from other vendors in an open-source project. The purpose of open source is to open a project to the participation of many people. Yes some may take the designs and produce copies. But that is allowed. That is the nature of the beast. Many newcomers may not understand where the support comes from but this is a uncommon method of development and they may not have run across it before. It is ok to educate and provide a method for them to volunteer to donate but don't yell at everyone at the top of your lungs everytime anybody asks a question.
Who's yelling?
So, are your motors and ESC's higher or lower quality than your flight controllers? Because it seems to be following those around.
Nobody is saying that clones are not allowed or wrong. But I do personally think it's wrong to complain about the firmware, or support, when you do not support the project.
There is a difference between a complaint and an honest attempt to isolate a hardware or software problem. Clearly in these two cases there is a problem, right? Could be a build problem. Could be a problem not understanding how things work well enough. Could be bad hardware and it could be a software bug. I think both parties freely admit to all those possibilities.
But both parties have spent a lot of time learning and troubleshooting. Nobody is complaining about support. I think we were both simply stating that we were running out of ideas and may have to turn to a different system. Maybe that is our lack of skill. But I have a friend who worked for two years and gave up. He bought an XAircraft and like Shane, installed it on the same aircraft and it works for him. This is an important piece of information. It means in these cases it did not make a difference what the other hardware was. The FC, or the firmware for it, made the difference.
Still not blaming anyone just a datapoint. Maybe better quality control is an issue and that is what you get when you pay $750 for fc controller. There is no free lunch.
I for one appreciate what the 3DR developers have accomplished. I am thankful Randy gave me some good ideas. That is why I sold my Phantom and started to learn about APM. But in the end I need to do aerial photography on platform that won't damage my cameras on every flight. Most likely that is my problem for not being a skilled enough craftsman but in any project if it is too difficult for people with considerable skills then there is something to look at.
I have been designing and troubleshoot circuits for 40 years. I am advanced class ham operator. I have etched my own circuit boards and I am a EE. So I am not a unqualified candidate to participate in the project.
I will figure out the problem myself with time but I think, first I will try the Virtual Robotix board to separate the hardware from the software as a legitimate troubleshoot technique.
Maybe you should do a 100% correct setup of APM Copter to start, then run auto tune, then provide those logs for the developers or users to evaluate for issues. I did have a software issue, brought it up, another user jumped on board with more computer knowledge than me and found the code error. That fix was found and made within a day or two, and only affected very few users. But patch 3.1.5 fixed the problem instantly. Crazy thing about the whole APM code is you actually have to pay attention to details to set it up. Read, understand, and follow exact instructions to be successful in setting it up. That is not the fault of the project, but the benefit of it being so versatile and user customizable. There is little to protect the end user from being stupid. Sure it will fly with minimal setup, and the results are just what you are experiencing. Spend the time to learn the software, diligently set up the APM for your copter, run all the tests, check and fix any vibration issues, do an auto tune, and no other controller comes close to the stability of APM. People ask me what controller I am running because my quad and hex fly so well. I have been running APM for a year with the only issue being the bug fixed by 3.1.5 and that didn't even lead to a crash because I was able to revert to stabilize and MANUALLY return the machine to the normal flight envelope. It took me a month to set my first copter well. On my last hex build I set up the APM in less than an hour, have 1% compass mot, zero vibration issues, and perfect autotune in one battery. So don't knock the project. If there is really a bug in the software it will be found and fixed. But my experience, and the experience of the group is that 99% of "software" issues are really hardware issues or improper setup. So provide that log with a 100% correct set up, and after an auto tune where your failure event occurs. OK?
My comment isn't unhelpful. If you provide the log it can be looked at to find what the failure point is. You can also tell what your setup is to see if that might be an issue. Logs are the way to diagnose, solve, and possibly find a software issue if there is one.
Mike, what steps have you taken to inspect the motor and ESC to make sure the problem isn't there?
My setup is 100%, maybe you should keep your totally unhelpful comments to yourself. There may be a problem still but not because i did not follow the instructions.
So you are suggesting that there is a bug in the software, which only affects certain hardware?
Can you propose a hypothesis for that?
The program outputs PWM signals. How would it be possible that it outputs PWM signals in a way that most ESC's have no problem, but some (ie: yours) would? How is that possible?
The intent here is not to say no way, no how, is there a problem. But, I can't think of any way. If you can, that would help us figure it out.
In the absence of any proof of what the problem is, where the bug is, or even simply a theory on that, your complaint sounds more like "I have a problem that I don't understand. The cause of that problem must be the thing which I understand the least, which is the software."
Its frustrating to crash over and over.
Its more so to have the developers, not only not help, but argue about... nothing really.
DJI said pretty much the same thing a few years back. "Its you, its your fault" It then turned out to be a major bug that only affected people in the southern hemisphere. Its possible. A lot of the hardware is not built very well, that maybe a factor, but its hard to diagnose and learn (then help others) when the discussion goes in this direction.
Speaking for myself at least, I am happy to get some ideas on understanding the logs a bit better. I haven't found much documentation on it.