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
Sir Leonardthall, sorry for the misunderstanding.... i do not refer to APM when i say flyaway of "fully tested and more expensive systems". I am a user of arducopter for almost two years and had zero incidence of flyaway. I was referring to Youtube videos on flyaways of other system supposed to be "fully tested as advertised and also more expensive" - as an example.
I'm a complete beginner to R/C, drones and APM/Pixhawk. Being an adventurous type I built a basic Flamewheel 450/pixhawk from scratch from the word go and started with 3.1.x stable releases.
Lots of crashes while I learnt how to fly and setup/configure the craft, which I fully accepted and knew would happen as I decided not to buy an RTF kit. No question, it was a steep learning curve. RTF kits have the advantage of being buiilt, configured and tuned for a specific hardware setup (think apple/ipod/imac/dji) which is much, much, much, much easier than than trying to product software to fit all hardware combinations (think pc/android/apm).
I've never had a fly-away or even a crash that I couldn't explain myself, except for an obscure failsafe case that Randy and Jonathan fixed immediately in 3.1.5. Which considering the complexity of these things, and for an opensource project (which by their nature are historically a bit less product/customer focused), is astonishing.
I've also flown 3.2 beta regularly and frequently from master, and never hit a single bug or issue that's caused a crash. One of the biggest draws to people like me (curious tinkerer, interested in the technology) is that we can choose to download and fly fixes and features that core developers on the other side of the world have coded only hours earlier. If you're running a commercial camera ship, stick to the stable releases which thousands of people are flying without issues.
I have no doubt there are bugs, and I'm sure that the more extreme/custom rigs will hits limits/bugs in the software, but for the majority of run-of-the-mill setups the software is incredibly reliable and stable. Despite the best efforts of some of the developers, the documentation and GCS software (I don't run windows so can't use the more mature MP) needs considerable improvement before it's ready for the public non-techie masses. Also regarding the testing it's worth noting that 3DR obviously contribute a lot to the project and they're not very transparent/noisy about how they do it, but from what hints I've gleaned in my travels they actually do a lot of simulator and real-life testing on every release. Automated/unit testing appears to need a bit of work.
Since you are new here, perhaps you are not familiar with this
http://autotest.diydrones.com/
We run automated testing on every vehicle and frame type for every mode on every commit.
At:
http://autotest.diydrones.com/
What does this mean:" fly.ArduCopter - FAILED (1602.6 seconds) "
I've already investigated and I know why the autotester failing. During the GPS failsafe test the glitch is lasting longer than 5 seconds and the copter is switching to a non-gps controlled land and drifting further than the 10m that the test allows.
We need to shorten he length of the glitch by about a second.
The purpose of this particular test is to be sure the copter doesn't freak out when it experiences a short-term gps glitch.
It means the test deviated from the defined parameters and needs to be investergated to understand why. The time stamp shows where in the log it deviated. You can see the mission in the ArduCopter-test.tlog.png below. These tests run on master every day automatically and release candidates don't go out without 100% passing grade.
This doesn't mean they are bug free, it just means no problems are showing up in all the normal flight conditions. The beta testers then put a very critical eye to the code and let us know if there is something they don't like.
Only after that does it get released to the community. We then have many thousand copters load the code and start flying. By the end of the first weekend of a release there is a massive number of flying hours on the new code. The x.x1 code is generally a fix or tweek from the feedback from the first month or two of community feedback.
He, he. Been there said that, back in 2011 that was.
I built my own drone, parts bought from 3dr but never got it to work satisfactory. Now, I have bought a Nova PNF from hobbyking, based on APM 2.5 and it works flawlessly. Tried auto, FPV flights and all, just works! My 3y old self built drone never got it going, still havent been able to sort of PIDs and stuff. Filled with bugs over the years, but I was really surprised by the Nova. Just works!
I purchased an “ARDUPILOT” flight board. I’ve loaded “Mission Planner” onto my computer. But when I connect the “ARDUPLIOT” to the computer, using a micro USB cable, the “ARDUPILOT” powers up/lights! But it does not connect to the computer?
NOTE: The computer as soon as it detects the “ARDUPILOT” should have started searching for the driver’s for the “ARDUPILOT”. And on the computers desk top it should have shown that! But the computer did not detect the “flight control board”, only powered it…
I’ve tried 3 different computers, with three (3) different operating systems; to connect to the “flight control board” and I purchased a new micro USB cable, and I have even reset one of the computer’s to factory default settings. Nothing works! The “ARDUPILOT” simply will not connect to the computer? It just powers up?
My question – Is this a defective “board”?
Joe,
I strongly suspect your board is toast. If it's a genuine 3DR board you can raise an RMA and get a replacement but maybe it's a clone?
Thanks Randy. I believe the "board" is defective also. I ordered it off of Amazon from some Chinese company? It took several weeks to get to the states. I contacted the company and informed them of the issues I'm having. Waiting for a reply too see what they are going to do before I order another "board"?
-
9
-
10
-
11
-
12
-
13
of 17 Next