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 ?
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.
after updating i tested and it works fine no more twitch. well done.
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?
Are you setting your range value in the CLI? Internally these values are stored x1000.
They are converted to floats later in the code.
Try the CLI setup::range and test::range to do what your doing.
Jason, I couldn't find any documentation on the range command. When I ran the setup::show I noticed RC6 range was 1379 (min) and 1381 (max). How those numbers got there, I don't know. I sometimes get that on PID terms changing too for no reason. Anyway, went back into PM and ran another radio calibration, then back to CLI setup:show and RC6 had the proper min/max numbers and the channel 6 options are now working.
To check if you need the latest PPM encoder there is a new RC Jitter test in the source repository.
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.
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'?
I am not familiar with the ppm encoder, but I have found a solution to my random motor twitching and jitter.
After setting the framerate for my RC transmitter from 22ms to 11ms, the problem vanished and it's as if I have a new hexacopter, super stable and solid flying characteristics. (Provided off-course the level and acc calibration has been done properly and with meticulous exactness)
Before, when my Spektrum DX7s was set to a 22ms framerate, I would even see the jitter in the radio-calibration window of the Missionplaner software. In particular, the switch I used for RTL mode, sometimes randomly twitched from 0% to 100% for a fraction of a second (!!). This caused my copter to briefly initiate RTL mode with every twitch, i.e. to fly to 15m height, and this caused a brief power-up or power-down spike on my motors, depending on current height.
I suspect there was some PWM sampling mismatch somewhere, I have a feeling that a better understanding of how the APM samples and uses the PWM from the RC receivers would reveal exactly what was going on.
I would be grateful if someone with deeper knowledge could shed a light on this?
Hi SH. The PPM encoder has nothing special in it. Because of its asynchronous design asking for more processing resources (needed for better global compatibility), some rare receivers can cause decoding performance problems, this can induce Jitter and eventually glitches in some cases. This is caused mainly by receivers that do output two or more channels in the same time slot.
So it's better to set your receiver in a mode where channels are outputted in a sequence. This is perhaps the case when you set your transmitter to 11 ms frame rate and could explain why it is working better. Some receivers like Jeti ones do allow to set the allocated time slot for each channel. In this case it is better to allocate each channel to a separate time slot.
The latest code version has been optimized to the extreme so that almost all difficult receivers will work.
Futaba is known to cause problems, as well as some older FM receivers, specially Multiplex / Hitec technology.
This new PPM encoder version is the 2.3.16 one, and the wiki page about upgrading the PPM encoder is here :