Symptom:
In manual mode (stabilize when manual inputs are used) I get flutter on all channels, as in all servos move when I touch the stick.
It appears that in automatic modes (RTL) the flutter appears again as my video (servos pointing the camera) jerks in flight.
They all behave properly otherwise.
They only "flutter" when I barely touch the sticks but all of them do it, as in the rudder twitches when I move ailerons.
I have a Futaba 10CAG Tx and a R6014HS Receiver
I have modified that radio with a 1W 2.4Ghz amplifier for long range. In flight it works fine, save for this flutter (which is not a big enough influence to see the effect of while in flight...yet?)
Board is APM 2.6 from 3DR.
Through extensive testing:
- If I use only a battery, the Receiver and servos directly (no APM involved, traditional RC setup) the problem does not exist. Therefore I conclude that it is not a Tx setting or a Rx fault of some kind.
- The problem persists even if the Rx is in High Speed mode or Normal mode
- No amount of ferrite ring wrapping does a thing to it.
- No possibility of induced voltages/signals due to wire straightness/proximity
- Removing servo connections one by one does not change anything
- If I look at the Calibrate Radio menu in the MP, I can SEE the PPM values jumping by about 35 points on all channels when you even just breathe on the sticks of the Tx.
- Analogue servos are worse, multiple digital servo brands used, problem persists
- There are no ground issues that I can detect either on input or output sides of the APM 2.6
- All voltage checks on input/output sides are normal so far as I can tell
- Latest firmware update to 2.78b does not solve the problem
- If I "disable" a channel via the variables list within the MP, the servo does indeed stop working while the rest flutter.
The closest thing I could find is that with Futaba radios (newer ones?) I might need to flash the Atmega32U2 chip. Which was noted in this thread. That procedure is something I don't want to do until I get more input on this problem. If it is not that, then I REALLY need help.
Replies
So, I hooked up the Rx to an APM 2.5 (good ol' reliable) and the problem does NOT occur. Does that mean I have a fualty 2.6 board? Unfortunately in the process the motor went to full (no idea why, don't care anymore either) and propelled itself onto the screen and keyboard of my brand new U925T-S2120 ultra book. I now have a damaged ultrabook. $850. Furthermore, while trying to figure this out I also crossed wires and blew two 1W 5.8 video transmitters at a cost of $150. That's a $1000 F'n DOLLARS. I have to put this stuff down now. After 3 years of fun and running NTDUG for a year I can't afford to keep replacing this stuff. I'm not blaming anyone, just really disappointed that a problem that should not have occurred in the first place has rabbit holed me down to no money in the bank.
I'd REALLY like to know if anyone figures this shit out.
I am terrible sorry to hear about your problems. There are god day, great days and also bad days. And then there are terrible days.. Usually letting the stuff rest for a little while helps getting motivation back.
I am now speaking in general and not you specifically.
The name of the game here is DIY. We are not dealing with some fine tuned, turn key solution. Instead we are experiment by mixing countless frame designs homemade or bought, with different parts from all over the world, much of it maid-in-china at lowest cost possible with little or no documentation etc.
The APM is also by definition a DIY solution, permanently stuck at the evolutionary "bleeding edge" with more advanced features then any other system out there. This can be both good and bad, and it does put responsibility on the users to understand the proper usage.
So needless to say. When mixing APM with unknown frames and parts from all over the world, problems do happen. There are just to many unknowns for it not to happen.
This is what 3DR is trying to address by trying to offer turnkey solutions for those that mainly just want to fly, and not have to thinker all the time. But even those turnkey systems struggle now and then, indicating just how "bleeding edge" all of this really is.
Thank you for the input John, here is what I found:
1. The flashed version is the correct one 2.3.16.0, problem persists
2. I bypassed the amplifier, which puts the power out to around 100mW or less, problem persists
3. Confirmed that if I use just the receiver, the transmitter and one servo hooked up directly that it works fine.
4. At 450ft in the air the problem persists, so distance might not be a factor.
5. I put the board under a magnifying glass. Nothing unusual to speak of.
Could you bring in some more folks on this?
Update:
Flashing the ATmega32U2 chip does not solve the "signal bleed" problem. I'm at a complete loss.
I used this file to flash the chip and the Flip program was version 3.4.7.
1W radio is A LOT of energy, and has the potential to cause more problems then it solves. You should not be using that, unless you really, really need it. You might be experiencing electronic interference. Try either switching back to normal radio, or move the radio away from the rest of the system to see if the flutter goes away.
Also make sure high-speed (HS) mode is disabled in the Futaba receiver. It serves no purpose when used with APM (~50hz internal refresh) and only loads the system unnecessarily.