I have started this dedicated thread at the suggestion of another contributor.
This issue has was raised on the main 'Arducopter 2.8 / 2.8.1 released' thread and can be viewed here.
I'm still puzzled by this twitching, however look at the latest log from today and in a little more detail I can see a very small change in the THR IN trace which appears to be directly connected at the time all the motors twitch (see below).
Is the THR IN trace taken straight from the Rx ?
Not only have I done the things as detailed in the main thread, but I have also:
Grounded the aircraft (in case of interference)
Repositioned Rx to top stack
Reprogrammed all ESC
I have attached the latest log.
Would dropping the ESC Update Speed in MP from 490 - 400hz help ?
Any suggestions would be appriciated, in the mean time i am trying to get hold of a duplicate Rx. Any chance it could be the APM ?
One great way to overcome problems with PWM to PPM (back-)conversion is not to use it.
I can recommend the FrSky TFR4 receiver for FASST. It is small, inexpensive, works with 7CH and "multi" as well, it has a direct PPM output with 8 channels, it has diversity and it has an RSSI output.
It will also rid you of half a dozen servo jumper cables :)
Hi Oliver, with your latest ArduPPM this problem has been resolved, after many flights have established two quad that I have no more "kick", thank you!
You should open a discussion advising all users with Futaba tx to perform this update on APM2/2.5.
This is valid when you use FrSky's ACCST system like D8R-XP and also noted in the manual for the D8R-XP receivers.
When using the FrSky's FASST receivers like TFR4 you may use all 8 channels without any problems.
I have both and was concerned by your noted lines in the manual for the D8R-XP I intended to use for my ArduCopterHexa with PPM and telemetry.
So I did a test and the Radio Setup in MP shows no problem when using the TFR4, but the warning from FrSky regarding the D8R-XP is valid and not recomended for more than 6 channels.
So I still use the traditional way when using FrSky D8R-XP receiver and have no concern when flying with TFR4 in PPM mode and using all 8 channels.
Edit: hmmm.... strrange..... I looked up the page for TFR4 on the FrSky site now and the warning is also noted for the TFR4. The site claims "new" for the TFR4. While my TFR4 is rather old.
Please be careful and test properly before using PPM in 8 channels!
I wanted to do the update on APM2.5 but according to description here: http://code.google.com/p/ardupilot-mega/wiki/APM2Encoder I should do some jumper stuff, but on my 2.5 board there are my 2nd GPS plug on the described "jumper" location (2.0 board)
I supposed with my 2.5 board i don't have to consider this part of above description. But when using Flip 3.4.7 i'm not able to connect board with USB. I believe this is because my board is not in program mode.
So are there a description somewhere for the newest board, like mine?
Also after reading all of this tread i wonder how to put the configuration in "fly bench" mode and produce these logs?
This thread seems to have gone quiet without any news of a fix for us APM1.4 users who also use Futaba.
Has there, is there, will there, be any fix for the PPM encoder on the 1.4 boards?
Yes we are actually checking the best way to release this new code without causing user problems. The release should be available in a few days if all is going fine.
I am having a similar issue on Spektrum. Flashed to the v2.3.13 PPM encoder code and its still present. See here for the plots: http://diydrones.com/forum/topics/spektrum-pwm-read-issue
I've been beating my head against the wall all weekend wondering why I was getting this twitching or glitching issue. I was trying everything from isolating the APM via various sizes of foam to the frame, filtering, tuning, fresh batteries, logging and analyzing, and getting to the point of developing a love hate relationship with this thing. Late last night after numerous searches, I came across this thread and thinking this has got to be it. Eager to try this new firmware, today I took the APM 2.5+ out of the xcopter, opened the case to expose the board and flashed in the new firmware. Sadly, I have no time tonight to test it, but when I do, I will post up. In the meantime, here is a compilation of videos showing the twitching during my futile attempts on the weekend to resolve this issue. The big one is at 52 seconds and after that, it was like "f*&%k it", this thing is coming out.
Incidently, I am using a Futaba 2.4GHz FASST radio/receiver combo with the receiver being a R6014HS 14-channel receiver.
I'm confused by the new information in the wiki:
"Please note that Arducopter 2.8.1 and earlier versions required you use a transmitter/receiver combination that outputs at least 8 channels of ppm information. This is resolved in version 2.9 so receivers like this should work."
The linked receiver (TR4-B) in multi-mode will output 8 channels. Given the above wiki statement, wouldn't that receiver be fine for any version of arducopter? Or is the wiki comment referring to the 7CH mode?
I thought I’d report back in after trying the new firmware, and tonight I put in a couple of test flights with it. The verdict is, it works like a charm. I experienced no twitching at all and can say “problem solved” for me. This is great because now I can continue on with the tuning and feel more confident that it should be flying like it should. I want to shout out a big thanks and appreciation to the development team for the hard work, hours, if not days of research and development to fix this problem for us Futaba users. Thanks a billion people!
Now that there is a solution for the Futaba receivers, is this firmware compatible with other receivers or does a person need to flash the other version? If it’s compatible across the board, can we assume future shipments of the APM will have the new release in it?
P.S. Thanks to the OP for starting this thread, it was a big help and great resource.
Yes it is compatible with other receivers.
Futur shipments should have a version based on this firmware, with some modifications for a better code portability though different boards (APM 1.x, APM 2.x...)
Changes at this level must be done very carefully and with serious testing, this explain that new versions do not fit production boards without serious team discussions and testing. This take some time.