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.
http://www.diydrones.com/forum/topics/arducopter-2-8-released?commentId=705844%3AComment%3A1022742
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 ?
You need to be a member of diydrones to add comments!
Replies
Hi guys,
I seem to be having a similar twitching issue on my copter. I have seen this in flight many times, and it seems to be random. I have an APM2.5 and am running 2.9.1b. It should be noted that I am also using a Futaba T8J and R2008SB running all 8 channels over PWM via 8x servo connections.
Was there ever any resolution on this issue? What was the root of the problem? Should I be using the s.bus PPM mode of my TX/RX? does that provide better performance?
Is it possible that my RX is receiving interference from the esc(s)? it is mounted opposite to an esc over one of my booms.
I have attached screen shots of the log browser for the titled rol or pitch IN from two separate flights as well as one log file. is this what you guys were seeing as 'spikes'?
Roll_adn_pitch.png
pitch.png
2013-06-06 18-19 3.log
To check if you need the latest PPM encoder there is a new RC Jitter test in the source repository.
https://github.com/diydrones/ardupilot/tree/master/libraries/AP_HAL...
Either compile and upload it yourself using Arduino 1.0.3 (Autopilot version) or use on of the pre-compiled files that I have included here, and upload using the "Load custom firmware" option in the Mission Planner.
The jitter test is a APM application, not a PPM encoder firmware. Do NOT try and upload it to the PPM encoder chip using the DFU bootloader.
After a successful upload, connect to the APM board using the Mission Planner Terminal window (CLI) and let the test run for about 30min. Make sure you do not touch the R/C radio while doing the test.
After a while your test should look something like this.
< 00:08:24> -------------------------------------------
ch1: center:1520 min:1516 max:1522 delta:4
ch2: center:1542 min:1539 max:1545 delta:3
ch3: center:1934 min:1930 max:1936 delta:4
ch4: center:1520 min:1516 max:1522 delta:4
ch5: center:1851 min:1849 max:1854 delta:3
ch6: center:1520 min:1517 max:1522 delta:3
ch7: center:1521 min:1519 max:1523 delta:2
ch8: center:2074 min:2069 max:2076 delta:5
If no channel show delta changes above 10, you do not need to upgrade the PPM encoder. If they are much higher (and you are sure you did not touch any of the sticks during the test), you definitively need to update to the latest version (V2.3.16).
Also, you have problems with jitter delta greater then 10, please send me a PM with some details about your radio setup.
RCJitterTest_APM2.x.hex
RCJitterTest_APM1.x.hex
I have a question for the group and this may be unrelated to this latest upgrade, but since I flashed the AdruPM v2.3.13 fw, I cannot seem to get channel 6 to tune my PID terms. The APM recognizes channel 6 with a range from 1101 to 1941, but when I set up CH6 to a P term with min=0 to max=3, I note while refreshing the config screen for each turning of the radio dial it remains at the min value until CH6 reaches somewhere between 1353 and 1381 where it then jumps to the max value. I am not getting a linear setting in between the min and max.
Has anyone else experienced this problem or tried the CH6 tuning options since they flashed in the new fw?
after updating i tested and it works fine no more twitch. well done.
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.
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'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.
https://www.youtube.com/watch?v=8PxUfscup2s
Incidently, I am using a Futaba 2.4GHz FASST radio/receiver combo with the receiver being a R6014HS 14-channel receiver.
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
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?
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.
Bests, Marco
-
1
-
2
-
3
-
4
of 4 Next