After a rather painful and stressful process of getting my new APM 2.0 board working on my 3DR Quad, I have finally got it to fly, but it is really twitchy and scary.
I had recently started with an APM 1 board, and had that flying very nicely including a really good loiter. However, I seemed to have had the IC2 problem on that board, as the quad insisted on committing suicide on a regular basis, and then everytime. That board is going back to Martin at BYOD to see if he can fix it. Luckily I had pre-ordered an APM 2.0 board, and even more luckily it turned up yesterday. I effectively built a new Quad from spares to eliminate any problems, including new ESCs and motors. It was very stressful getting it to work, with the problems connecting to MAVLink, having to manually recalibrate the ESCs often, going back to square one so often with not being able to complete a firmware upload, Set Up and hand test cycle without something locking up. Anyway, eventually I have succeeded, although I am using my Xbees where possible to communicate between Mission Planner and the board.
When flying the Quad, it appears to be ok for a few seconds at a time, and will then twitch, sometimes quite violently, including dropping in height. The throttle response seems a bit digital. There is a bit of wind, but nothing that the APM 1 board would not have coped with. I do not have the sonar fitted, as that seemed to cause a problem and I have taken off as many ancillaries as possible to cut down problem sources. I have not changed the Stabilise PIDs at all from the firmware update. Any ideas on what might be causing the problem, or what PIDs I should be using for an APM 2.0 board?
Just to add a bit more to this. Other problems I am coming across are that sometimes when I connect to MAVLink using my Xbees, the sensors don't work. Other times, I get ready to fly and one motor/ESC starts beeping, so I have to manually recalibrate it. Other times, everything looks fine in Mission Planner, sensors working, but I cannot arm it. It really seems hit and miss as to whether I can get everything working to try and fly it.
I had a go at tuning down the PIDs, which seems to have helped a bit, but there are still some major twitches, at times the throttle seems to stop for a heartbeat and it is simply not stable. Unfortunately, the wind has got up, which is making it more difficult to control and try and make sense of its behaviour. Would be really grateful for somebody's inputs.
Has anybody else actually flown this board yet? I am using a stock 3DR kit, using a Futaba T7CP tx with a Corona RP8D1 rx.
Maybe you're having interference on your Tx-rx. No 2.4Ghz right ? Get some logs and look at the rc input values. If they show strange spikes at the times of strange behaviour, you're getting hit by RF interference.
Not sure about the best way of obtaining, or viewing the data logs, especially as that has been disabled in the CLI for APM 2. From the Flight Data screen, did watch the raw sensor view for the last log, lots of spikes on the gyros and accelerometers from 47-53% of the log, but cannot see rc input values. Log attached if anybody can diagnose the problems.
It is extremely unlikely that it is the R/C causing the problems. I was using the same set on the quad with the APM 1 board, and that flew well, apart from the suicide problems which I suspect was an IC2 problem. I am in the middle of nowhere with no other R/C users around. The other problems that I am having do point to there being a problem with the new board.
You likely have different PPM encoder in APM 2 board if you have not updated the older board and maybe that is the difference. Those Corona's are not that good with resolution and centering, see this:
Try different rx to see if it makes difference.
Jani, thanks for that suggestion. I am still not sure I understand how the new board would have made it worse, and the rx appeared to work fine on the APM 1 board - I presume any resolution or centering problems would have showed up there as well. When I am in Stabilize mode, apart from correcting for wind drift, I make few pitch or roll inputs and the quad was really doing its own thing most of the time, with the terrible twitching that scared me so much.The reason that I am using the T7CP is that is the Tx with the most number of channels that I have to hand, so by mixing Ch 5 and 7 I can currently get 5 flight modes. I do have a T6EX on 2.4GHz, but that will limit the number of flight modes that I can use. I do have a very old Futaba R147F for the 35MHz T7 - is that likely to make any difference? Bill
I'm not pro with logs and data analyzating, but there's definitely something weird in your rc input or at least logging. See CH1-CH8 input in APM "status" window starting about 59% of log, where i think you armed motors. You seems to have a lot of random values and mode changes. Did you have all 8 input connected?
My guess is that motors and esc are Interferencing with rx. Try to change rx place or antenna routing or try your 2,4Ghz radio to be sure :) I had many problems with 35Mhz radio(with Futaba PCM) and powerful electric plane before change to 2.4Ghz..
You are right, there is something weird going on. I had the Mission Planner voice set up to alert to mode changes and there is no way that I changed modes so often. I will try the 2.4Ghz set and live with just Stabilize and whatever other mode I can set up, to test it.
Have a Happy Christmas,
I've been flying a 3DR with APM2. The only PID change I made is to set the stabilize Roll and Pitch P to 3.6 instead of the default 4.6. This was just to make it a bit less bouncy with sudden stick inputs.
Using the latest 2.1.1 it loiters at least as well as my APM1 did on 2.55 (or what ever it got up to before APM2 came out). I does get into the circle mode a bit, but alt hold on baro only does seem better. I would see 50 ft or more excursions with the old APM1 baro.
Part of the trick in starting up seems to be not to have the GCS xbee link enabled when starting the APM2. About 1/2 the time it comes right up, other times I have to push the reset button.With the GCS xbee active the data from the remote xbee to the APM seems to be causing the startup problems.
Starting with USB plugged in seems to be reliable. I guess this is because it detect the USB and switched the port there. The USB won't emit data until the USB device on the APM is enumerated and the driver loaded on the host. At least, I guess this is why USB startup is reliable.
There should be a beep from the ESCs when they aquire a PWM signal. This is after the series of beeps indicating the cell count.
If they lose PWM subsequently they emit regular beeps as a warning that they are armed but not getting a signal. I still have the original ESC calibration from when I first set up the quad with an APM 1280.
As you can see from my reply to Jani's suggestion that it was the rx at fault, I have now got it to fly, and well. There was a brief window of still/light winds between being dragged out to see the rellies, so I had 2 quick flights and had Stabilise, Altitude Hold and Loiter with my APM 1 PIDs working well (which I think turn out to be very similar to yours).
I have sorted out my ESCs (calibrated to the nth degree) I am still having problems connecting with APM. Contrary to your experience, I find the Xbee is the most reliable.
Just out of interest, what exactly does the reset button do on the APM? Is it just a reboot?
I switched rxs, initially to my 2.4GHz set and it flew absolutely rock solid in Stabilise and held Altitude Hold pretty well. I then switched to my old R147F 35MHz rx, so I could get 7 channels and more flight modes. That worked very well again with a really very good Loiter (in light winds, using my PIDs that I had tuned with my APM 1 board), although with a slightly curious backwards trim in Stabilise, but essentially you were right that the Corona was the cause of the problems. I now feel much happier.
Tried to reply to your recent post...
Sorry if I did not believe you straight up, but it seemed very unlikely to me as the same setup had worked well with my APM 1 board (although I now wonder whether the I2C/suicide problems are indeed connected to the Corona rx I was using). I guess when 2 people say the same thing, and also when it became clearer from Jani's comments on my logs, then I was forced to test it and thank goodness I did.
I suppose the lesson is to take all advice seriously, so thanks.
Forget about it, was just having a bad hair day ;-)
Glad you got a stable copter now and thx for reporting back.