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.
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.
Thank you for the reply Olivier.
I have failsafe set and turned off the transmitter after a short simulated bench flight as requested. To confirm, no motors are powered whilst it is in the bench, just the APM powered by USB.
The spikes to seem to be there pre switch off, but not afterwards.
One thing that I do notice is when looking at the THROTTLE IN trace in the log, when the Tx is turned off, the output trace goes to zero.
However, when you look at the PITCH IN channel for example, the trace doesn't sit at zero and appears to be noisy, is that normal ?
Of course I could be misinterpreting the logs, so have attached them if you could advise.
I'm using a Futaba T8FG Super with matching R6208SB receiver.
Many thanks for your assistance, this has been driving me mad for months !!
Log not attaching, i have placed it here for download.
Thanks for testing this. Could you now try to connect 4 servos directly on your receiver, and let me know what they do when you power off the transmitter.
Check that all servos are working perfectly normaly when playing with the TX sticks, and power off the TX.
Can you turn their shaft by hand when the TX is powered of ? Or do they resist ? Which position do they adopt when TX is powered off ?
I don't know the Futaba T8FG, but please could you check that it is not using a 16 channel tranmission mode. If yes then try to put it in 8 channel mode and see if you still have the problem.
Futaba did design a non standard PPM 16 channels frame format that could be the problem here.
Do you have frame rate settings available in the receiver or transmitter ? If yes then try to set that to a standard output frame rate, something near 50 Hz (= 20 ms).
I don't have that many servos i'm affraid :-)
However, the one i do have seems to work fluidly when moving the Tx stick.
When the Tx is turned off, the servo remains in its position prior to turning off.
When the Tx is turned back on, the servo will move to the centre position if it was connected to the pitch or roll channel.
Servo does resist movement when Tx is off.
I can't see a frame rate setting on the Tx and nothing apprent in the manual i'm affraid. However its a 2.4ghz system and the resolution is 2048 if that helps.