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 ?
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.
You do not set any "framerate".
In the LNK-Frequency menu you choose FASST betweeen MLT/MLT2/7ch.
It is also noted on the main-screen under the timer ST2 where you read MLT/MLT2 or 7ch.
MLT2 I think is for the R6014FS/HS and the MLT is for your R6208SB.
However when I had that twitching on my R6014HS there was no difference changing betweeen MLT/MLT2.
You either has yours on MLT or MLT2 as 7ch is for 617 or fewer channels. 7ch will not bind to your receiver.
Hope you sort it out, but I would have tested/borrowed another brand. At the moment It is so cold outside in Norway so unfortunately I can not go outside and test my T8FG/R6008HS combo or retest my R6014HS to see if the twitching still persist.
While I had the Futaba gear on my ArduCopter I also tested if the receiver was set in High-Speed mode, but it was not... but you might check yours... I think think Normal-Speed is a good choice when connecting to the APM.
Thank you for the reply Arild, its appriciated.
I had visited that as a possibility and can confirm I have the radio set to MLT mode, although have also tried MLT2 with no success.
Can you confirm you have experienced the same issues with this radio combo ?
Today I visited the UK service centre for Futaba and met up with 2 very helpful people. I had to rule out it was not the Tx. One of the engineers came with me to the field and we first tested my Tx and the twitches were of course present. Then having copied over all the settings to their new and test Tx, same problem was experienced.
To recap, so far I have swapped out and tested the following.
I have tried so many things with no luck as described previously.
The Futaba T8FG is certainly not a cheap Tx / Rx combo, so I'd like to think that it can't be incompatible with the APM, whilst bearing in mind I have no doubt others use this radio with their APMs.
I have uploaded the latest log here and again you can see the spikes in THROTTLE IN, ROLL IN, particulalry PITCH IN and YAW IN.
I can't see it being a motor or ESC as these spikes are still present, even when conducting a simulated flight on the desk with the motors and ESCs not powered !
I am desperate to resolve this issue, any suggestions ?
I'd appriciate anyone making comment who use the Futaba T8FG with APM 2.5 and if you have had issues.
All the best,
I am sorry I have no logs, but so I wish I had.....
It is to cold for me to go outside right now, but I just had to try a small lift inside...
The quad I had problems with is the old APM1.4 1280 chip, so no logs on that one. So I put my Futaba R6014HS in my JDrones-Hexa running APM 1.4 2580 chip.
I did a lots of testing while activating the "Tuning" option in the maps on the flight page in mission-planner.
No spikes showed up, so I got a little braver and cleaned the living room for a little hoover test.
It lifted nice, but less than 15 seconds into the flight I got a really scary twitch and I had to put it down. Fortunately no harm done to either floor or hexa :-)
I am so sorry I did not read more about logging the rc_in channels before the tests and have this twitch in a log to show you.... but for my self I do not need any log to see that it was what happened before I switched to FrSky system... good thing is that I have the CC Bec Pro delivering good power to the APM so I did not got any brownouts inside.
Some days ago I had a very nice flight with the Hexa outside in my garden. My "FrSky" radio is also the T8FG which the FASST-tx-module is removed and replaced with a FrSky DIY Telemetry module and an FrSky D8RII telemetry receiver. (The previous owner got his antenna in a propeller and he bought another T8FG. I bought both using the malfunction one as a learning radio for my son - but after some time I converted to FrSky because the repaircost from Futaba was to high)
I wish I could test more outside to help you now, but I have to wait for warmer weather :(
If the weather warms up a bit in the near future, I will activate rc_in in the logs, and do a test with the R6014HS and R6008HS receivers.
Just to clear up a little thing: both my TX'es I use for my APM is the Futaba T8FG. One stock with FASST, and one as said switched the radiomodule for FrSky.
Thanks again for your efforts Arild, its appriciated.
I have sent a message to Marco Robustini to see if there could be a developer input or some other level of debug which will help get to the bottom of this issue.
As i said previously, the T8FG is a good Tx / Rx and used widely, so i can't believe it hasn't been seen before.
I'm hoping it could be a timing issue that could be resolved in software or similar.
Having invested a lot of money into the Tx / Rx, I can't now bin that and try something else unfortunately.
I will keep this thread updated to how I get on. I'm just so desperate now to resolve it having spent the past 3 months trying to get to the bottom of the issue.
I have a new set of skids and gimbal sitting here which is waiting to go on, but i can't put it on until this fault is resolved.
Hi Steven, I'd like to see a video (recorder from the ground without wind) with the problems you mention, only to assess the level of these twitching in flight, thanks!
We could have an encoding problem with this Futaba setup. It's hard to diagnose without a radio system at hand, watching for signals on a scope to understand why we would have a problem encoding it.
I have no Futaba here to check, but i'm sending a link of this thread to another developper working on the ArduPPM side who could perhaps have that to test.
In the mean time, you could update your PPM encoder to version 2.3.10 and see if the problem has gone.
A couple performance enhancements in this version could solve your problem.
And instructions here :
In the meantime you could try as well to connect only 4 channels. It could solve the problem.
Hi Olivier, i've the latest ArduPPM and i don't remember this twiching during my latest tests, but i'm not sure.
This kind of problem has also been reported in the dev list months a go by me.
Thank you Olivier. I presume the procedure is the same for APM 2.5 ?
Is there a way to determine what version of the PPM encoder I am currently using prior to reflashing (just for documenting sake).
I'm trusting you on this one and hoping I don't brick my APM ;-)