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 ?
Hi Jason, thank you for your reply.
So, am I right in thinking that the Rx is producing a spike before it reaches the APM from what you have indicated above ?
Yes, I do leave it in Stabilize mode, is that OK (im still learning :-) )?
Ive attached my previous log and there does seem to be spiking on the THR OUT trace, am I reading it that the two traces (THR IN & THR OUT) should be similar ?
Thank you for your assistance, I do feel a little in the dark on this one !
Did you ever find out what was causing your twitching? Mine turned out to be bad receiver. I use a Spektrum AR8000. I called them today and they are sending me out a new one to replace. I had a Spektrum AR600 which I use till my AR8000 arrives. Switching to the AR600 helped me figure out the problem. That and the logs.
Hope this helps, happy flying.
I've found certain RX to be bad on the ardu, particulaly the Futaba R617 which handles CH6 badly when connected.
My RX is linked to the Ardu2 and to a lighting system on CH8 and above. For some reason (although only 6 channels are connected to Ardu) channels 7 and 8 will not work until the Ardu has initialised so I can believe that the ARDU can effect input channels.
The 617's CH6 signal starts at the same time as its CH1 signal. The probably confuses the PPM encoder of APM. It is known to be notoriously hard to encode several PWM signals with unknown mutual phases back to a single PPM signal.
Actually it is better not to split and reassemble the signal at all - by using a receiver with a PPM output.
I use the FrSky TFR4. It's an 8 channel RX with only 4 PWM connectors on it. When shorting out 2 of these with a jumper, the remaining 2 will be PPM and RSSI. Perfect for the APM.
That is quite strange because ArduPPM has been designed to manage this correctly.
For example it is able to perfectly encode Multiplex / Hitec FM receivers PWM signals where we have this kind of simultaneous fronts on different channels.
I'm afraid we need to check what's going on with a scope on real hardware.
Yeah OK. I'm almost getting curious now how that has been solved :)
For the future, I guess traditional multiple PWM signal R/C is facing the and compatibility with Futaba SBus, Spektrum's satellite protocol etc. would be more useful to have.
Tell me if there is something I can do for the diagnosis. I have an APM, a 2 channel scope and a '617.
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!
My "twitching" saga continues...... :-(
Having replaced both the Rx and the APM, the problem still exisits.
By process of illimination, I can see it being one of the following things:
I have attached the latest log file from today, but this is the video of that flight taken after the mid-way landing.
Sorry about the skewed camera angle !
As you will see upon lift-off, there were 2 spikes that caused a bumpy take-off.
Having looked at the logs, I do seem to be experiencing spikes on the IN channels on THROTTLE, ROLL and PITCH (those are the obvious ones).
Before I start the continued and potentially time consuming task of replacing (in turn) ESC and Motors, can any experts offer a possible explanation to what I am experiencing.
Having spent a small fortune on this Hex not to mention the investment of time, I'd love to progress on my journey without having the presence of the fearful twitch.
To me it looks like the INPUT is causing the issue and its not the Rx. However, if it proves not to be the Tx also, what could it be ?
Any advice, suggestions or relaxation methods (as its stressing me), would be appriciated.
Steven, could you try to program a failsafe in your receiver, and power off your TX.
Do you still see the spikes ? If no then there are good chances that you have a problem with the TX.
If yes, then there is something wrong at the APM side (powering, interferences...) or there is a compatibility problem between the receiver and the APM.
Which receiver is it ?
Could you try as well to connect only channel 1 and 2 and see if you have this problem watching inside mission planner radio input view (green bargraphs). Then connect channel 3, 4, 5 and see if it's different.