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
Mike, nobody is saying that the system is perfect, and there are never any problems. But you are suggesting something that is highly unlikely, and not bringing any solid evidence to back that up.
What you are suggesting seems to be:
- There is a bug in the firmware, which makes it randomly shut off a motor and crash.
- This bug happens frequently enough that it strikes you often. Would you say it happens once ever hour of flight time?
- It seem to affect only one motor?
- You are presumably using a stable release, which means you are using the *exact* same hex file as literally 1000's of other people.
- If there really was a bug causing this, why wouldn't there be hundreds of people afflicted by this bug reporting here? There would be an overwhelming amount of data from people showing motors randomly shutting off.
What you're suggesting is that you have a found a bug which strikes your frequently, but pretty much never strikes anybody else. How is that possible? You are using the same hex file as everybody else, there is nothing unique about your particular program.
Meanwhile, you do have a different, unique hardware from everybody else. We have already identified that you have a Vcc problem. We don't know what regulator you are using, but it sounds like it's probably not a 3DR Power Module. You state that it is outputting 5.2V, yet your board is reporting ~4.3V. Again, you do not have a unique firmware, nobody else has this problem, so the voltage is not another software bug.
You state that all of your boards report different voltages, using the same BEC or whatever you're using.
Clearly, something is wrong with your hardware. That is what is unique about your situation, it is not the software.
Robert, I personally have friends like Shane with this same problem. They are giving up and moving to another platform. This is not about blaming or ranting. It is simply identifying a problem is not isolated. You have no idea that the problem is not software. The code is complex enough that being able to make that statement about all combinations of hardware and flight situations is absurd. Both Shane and I came into this simply stating we have problem that have been difficult to discover and answer for. Part of the problem is not being willing to accept that it might be possibility. You act like a corporate CEO covering their ass for a failled product. This is not the situation here. Everyone knows this is an open-source project. Everyone knows the developers are and have done an amazing job of creating this project. But that doesn't mean it can't be improved or shouldn't.
You have to accept that being an DIY environment there will be lots of people trying to use it and there will be lots of mistakes. Nature of the beast. Yes most will be operator error. But to be so defensive that everytime "someone says this is not acting right for me" you jump down their throat and call them incompetent is asking to be made a fool when one time it does indeed turn out to be a bug.
Mike, you're completely missing the point. Nowhere, have I ever said that either the software, or the hardware is infallible. This is where so many people seem to get it wrong.
Just a month ago, I suffered a crash of a prototype gas powered helicopter, because the unsupported memory battery on my GPS puck vibrated loose due to the extreme vibrations on that airframe. 3DR was notified of the problem. I'm not sure if they're going to make a production change or not, but it's sure indication the hardware isn't infallible.
I've also suffered many crashes over the past 3 years, that were due to software bugs. And those bugs were fixed.
The difference is, I concretely identify the problems, find the root cause, present evidence, and suggest a solution.
You have not really identified what exactly the problem is, have not found root cause, have no evidence what the problem is, nor have a solution. Now, not everybody can find each and every step in that chain. But you haven't even found a single one.
Gentlemen,
Let's try to keep the posts civil and continue to help troubleshoot Shane's issue.
I believe that Randy McKay, one of the ArduCopter Developers, has provided some insight into why Shane is having a problem.
All of the navigation systems on the hobby market can be prone to a flyaway or frustrating operation at an unexpected time.
However, Hugues does have a point. Since this is DIY, you have to accept that there will be a certain level of frustration during the integration and programming of a navigation controller if you are new to this hobby. You must remember that this is no longer the Heathkit world of our fathers' generation.
Since there are many DIY Drones members who have experienced success with not just 3DR navigation controllers, Shane cannot necessarily blame the Developers/Programmers for his issues.
If you are not up to or are frustrated with the DIY concept, then buying a RTF multicopter may be the only way to successfully get into the air.
Regards,
TCIII Admin
@Shane
SOrry but i only read some of the posts, but i didnt see you mention *everything* single bit of equipment electrical on the multis. Are you using any cameras, video transmitters. Some cameras (many) emit EMF and this will affect performance of other items like GPS and compass.
Are your compass and Gps really close to other electronics ?
ALso the quad pulses, as others have probably mentioned is due to vibrations. I think you also said you have frames from HK. I have used their cheapo arms in the past and they are garbage, they flex way too much. Switched over to some spare 3dr aluminium tubes, and that solves that lot of probs.
I have exactly the same problem.
http://diydrones.com/forum/topics/quad-falls-suddenly
Mike,
I've responded over on your thread. Looks like a mechanical issue perhaps brought on by the board being incorrectly powered. I highly recommend getting a power module!
Hi.
Yes, me and 3 other buddies gave up on Arducopter.
The programmers really need to stop developing new features and come back and fix the old problems.
It WILL crash, its just a matter of time. You can have 10 good flights, then bang, it'll flip and crash, or do something else stupid.
I have swapped out for a NAZA, and its perfect. Same everything, just new board +compass.
Everyone I've spoken to here agrees that Arducopter is rubbish, which is a shame as I support open source as much as possible and I like the fact I can run MP on my linux box.
I'd use your board on a ground vehicles only, and a slow one at that. Better that then hurting someone.
Judging by your tone it would have been your build and commissioning 100%.
Oh and maybe get some new buddies ;)
Its a tone of frustration.
Lots of people having these same issues. Once swapped with another type of autopilot, problems go away.
-
6
-
7
-
8
-
9
-
10
of 17 Next