Ok guys, with all the people waiting on APM2 and all the exciting new alpha and beta releases of APM firmware coming, I think many people are starting to chomp at their bits, a little.
To that end, I've opened up this discussion for all those with complaints. As I've joined the Dev Team, and not at a productive stage yet, I'll monitor this discussion, and relay things to the others on the Dev Team.
These could be both hardware or software, or just general rants and raves!
Hope everyone takes advantage of this! Maybe we'll all learn some things in the process.
Just wanted to add this response from Chris Anderson:
Please just contact sales@3drobotics.com and inquire about the status of your order. They are not necessarily shipped in order. For example, the unsoldered ones are shipped first, because they're faster to put together. Then soldered with GPS, then soldered without GPS (or maybe those two in reverse order, I can't remember). There are approximately 50 going out each day and the team tells me that the backlog should be over by Mon/Tues of next week.
I agree, please use this discussion for Rants and Raves. Order issues should be directed to 3DR directly. I think you will get better response there.
Tags:

I raised the gains for roll and pitch P to about 6.000 and still wasnt that responsive. But I must admit that I thought acro mode was just for planes? and stabilize was the base mode for multicopters? either way I have tried everything I could think of to get rtl and loiter working, probably 40 + flights of up then test then bring back down change a few things that were relevant to the problems then back up. But I could never resolve anything and as much as I changed things nothing seemed to make any noticeable difference? and it just wasn`t fun anymore. I have a carbon fibre Y6 I am building I will try the apm2.0 in that, and if it lives up to my previous expectations I will buy another or two? if not I will sell it and buy a DJI Wookong or naza? I dont mind spending the money, and I would rather have the flexibility of the apm2.0, But it has to do what I want it to do from a safety point of view? If I lose orientation of the craft I want to be able to flick a switch and know it will safley come back and not spiral out of control or drift off into the sunset until the battery goes flat and land on someones head from 400 feet.
Permalink Reply by Rick Stewart on April 26, 2012 at 11:07am I am sorry to hear you are having such problems with your board. One thing I learned is setup is essential, if you have had 40+ flights and are not getting any closer to resolving your issues then I would suggest starting from scratch and going one step at a time. If you are jacking values and not seeing the desired change then perhaps you have a misunderstanding as to what those values are responsible for. Your methodology may need to be reviewed. My issue was that it worked right out of the box about 90%, I tuned it to 95% perfect with minor issues in 2 flights, loiter worked well with a drift radius of about 3m. I used to call loiter my get out of jail free card since it saved my bacon a few times. When I went to 2.5.4 that went all out the window and now I am just trying to get it working to the same point 2.5.3 was out of the box.
Rick

I don't really know what you mean by "responsive", but if you mean roll-rate, the Pgain doesn't even control that. The maximum rate as it responds to stick input is limited by a constraint in the code. So there's a point you can't go any faster unless you dive into the code and change that constraint.

Robert, knowing both the KK and APM code. I'm pretty sure we will never get the AC code to be as responsive as the KK code. The KK is originally written in assembler code and some version are in C. It does very little calculation between setting the motor PWM. Just read gyros, mix in rc inputs, and send the PWM. It's in a very tight loop. Not so for AC.

Hmm, yes that's exactly my point. It does take some skills to fly a KK board. You're relying much less on the controller and more on yourself. Also the difference here is that you just slapped a few parts together, and tried to fly it. Obviously you have some skills. I'm just cautioning newbies against thinking that the KK is easier to fly than APM. However, given the cost difference you're not going to loose much from trying, and using it as an introduction to multirotors. In the process you will learn a lot that can be applied when you want to upgrade to a true autopilot board like the APM or DJI.

Yes you are right there, I built thr tricopter with the KK board not knowing what to expect and how to control it? but I plugged it all in and open the throttle and flew it straight away, but this wouldn`t have been possible if I had no experience in flying Heli`s, as soon as it lifted off I flew it like I would a heli and it worked. I have let friends fly it also, they were not sure of flying it but I knew they were competent heli flyers so I assured them it was the same thing, and they were able to fly without too much trouble. But learning to fly a heli from scratch is no easy task and some may never master it and a multicopter is perhaps even more difficult especially when it comes to orientation, and yes the apm does make things much easier for the beginner, I would definately reccomend it over the KK for a beginner in terms of stability. But in terms of ease of use the KK board wins, I am fairly intelligent with an IQ of 155 but starting out in the world of PID`s and programming chips and hoping for success within a week with no previous knowledge or experience is enough to fry anyones brain
Permalink Reply by Rick Stewart on April 26, 2012 at 11:13am I feel your pain. Nothing is more frustrating then watching 2 of your friends whip around the field with quads running KK boards, and I am sitting there with my laptop switching settings. The funny thing is I am not even trying to Loiter or RTL, just stabilize in a manner I think is appropriate for the board / quad. What I mean by that is no random yawing, no tilting / leaning etc. Good luck,
Rick

o.k I was had just written a long post about the highs and lows regarding my experience with apm2.0, and then my computer crashed before I could post. So in breif I have gone back to using apm2.0 and now finally got it working almost as I want it, and have learn`t some things along the way and now happy again.
But there is still a remaining problem to which I have posted several pleas for help, but as of now nobody has given me a solution?
When I download my log files using mission planner they are the wrong co-ordinates because the longtitude is missing the - sign for example the log shows 51.xxxxxxx and 21.xxxxxxx instead of 51.xxxxxxx and -21.xxxxxxxx therefore putting me 20 miles or so out.. So when replayed in google earth the traces are not anywhere near where I was flying. I really need a solution to this as it`s driving me mad... Please help someone...
Dean, please post any bug reports in the Issue Tracker. The developers can't read the thousands of comments in the various forums here, so they only address issues submitted the formal way.

I have done that now Chris, I was unaware of the issue tracker? have only been using ardupilot a couple of weeks... Thanks..
Permalink Reply by Barry Nash on Wednesday I'm not sure if it has been requested yet or not, but it would be nice if there was mores explanation on the effects of the PID settings in mission planner. I have a print out of the AC2 tweeks from the WIKI, but doesn't explain clear enough. In the mission planner software there is Stabilize_Roll, Stabilize_Pitch and Stabilize_Yaw. The only two mentioned are "Stabilize"?? and "Stabilize_Yaw". There is no mention of the other Stabilize PID or its function. Also the channel six tuning would be better if the drop down actually matched the name of the paramitter that was being tuned. It would take the guess work out of what you are tuning.
Does this make sense?
Thanks in advance.
Barry
Jason: Good questions, and thanks for the opportunity to clarify:
1) Our policy is to release the Eagle files of major revs of the hardware (2.0, 2.5, etc), but not incremental revs, simply because there are so many of them and it risks being a documentation and support nightmare. For some products the design files change several times a week as we source different components or improve our manufacturing methods. Like most other open source hardware companies we don't rev our public files with each incremental change (there can be literally hundreds), but only publish the reference designs when major changes are made.
2) What may be confusing is that I wear two hats: founder of this non-profit community, and co-founder of 3D Robotics, which is a company. When I say "we" won't support boards we don't make, I mean 3D Robotics customer support, not DIYD. As for the word "clone", I use that to describe companies that have simply copied our designs verbatim (including our logo and name, which is not open source), rather than creating variations or derivatives, which is what Open Source aims to encourage. We would like these companies to use phrases like "APM-compatible", rather than calling them APMs. Other open source hardware companies, such as Arduino, take the same approach.
3) We get bug reports every day. Until they go into the Issue Tracker, and can be verified by the dev team, we have no way of knowing whether they are in fact bugs or unique hardware or setup issues with that particular airframe. As a member of the dev team, Marco was able to fast-track that process with his issue, so we were able to identify the problem, create a patch and ship it within a matter of a week or two. It was a relatively rare effect that only showed up if a certain sequence of events took place (and had never come up in any of the testing before that), so we didn't issue a don't fly statement, but it was very thoroughly discussed in the regular forums here. I personally know of no other user who was affected by this bug.
In general, we test code as well as we can before shipping, but no code is bug-free and we can't promise that it is, only that no bugs had shown up in our own testing (both sim and autotesting, as well as at the field). If they do show up when flown by 100x-1,000x more people (the public), we have a process to confirm, understand and fix them as quickly as possible.
4) As we've said many times, we seek to constantly innovate and bring the best technologies to this community as quickly as we can. That means new products and upgrades on a much more rapid pace than most closed-source products. With autopilots, that typically means a unitary release about once a year (2.0 , 3.0) with a bridge release (2.5) in between. So too for GPS modules, where we're always evaluating the latest technologies to find those appropriate for this community. We are working on a new UBlox GPS, which is performing very well, and will bring that out as soon as possible. For planes, it may not make much difference, but it does seem to improve Loiter performance in copters, where fine-grained resolution is more important. This is why we sell APM with a port for an external GPS, so you can upgrade your module is you think a newer version will suit your needs better.
5) We're continuing to lead the discussions with Invensense to authorize public release of the code, not just for us but for all the other open source boards that use this chip. I'm optimistic that we'll find a resolution, but this is not something I can control. Be assured that when that day comes, this community will be the first to have access to the code. You are free to use the code yourself (it's out there), but we can't help you with that ourselves, for obvious reasons.
Season Two of the Trust Time Trial (T3) Contest has now begun. The third round was a reliablilty/aerial photography round for both planes and copters, which is now closed. Stay tuned for the next round, beginning soon.58 members
106 members
54 members
27 members
59 members
© 2012 Created by Chris Anderson.
