Hello Folks:-)

I have a big problem to get the Pixhawk running with my Taranis plus and the X8R receiver.

Here I already posted the Issue.

What I have:

Taranis Plus with Firmware 2.0.17 and latest  internal XJT non_EU  update.

X8R Frsky Rx also with latest non_EU update.

3DR Pixhawk and a clone from belize

Arducopter 3.3-rc7 (also test 3.2.1)

What I did:

I flew many hours with my small grasshopper 250 very well with my old Futaba with Jeti TX system. The Jeti Rx has a CPPM out. The System is stable in all phases and all Modes.

Now I want to give my Taranis plus a try which I bought in 12/2014. So connected the X8R SBUS direct to the RCin from the Pixhawk and calibrated the Radio in Missionplaner with no problem.

The Issue:

The Copter flies, with the FrSky system, in stabilize as usual and very good. As soon the Mode changed to Alt.hold, Pos.hold or RTL the copter get some wobbling or unstable attitude if a interference coming up. The interference can come from a gust, or a RC input. Special when  switch in Autotune the Copter become very unstable, sometime he fall out of the Sky.

Once it was possible to complete the Autotune in roll and it gives me a PID from P=0.01;I=0.01!!

I also switched off the Tx during a fast forward flight, as the RTL command came the copter wobbles very heavy, which It not does with the Jeti Rx!

What I tried to solve:

Changed old to new Firmwares on the Rx,Tx and Pixhawk, 

Tried another Pixhawk, another Rx and a D4R-2.

Changed the PID in a lot of direction (I´ve experiences in tuning PID´s)

Changed in between, with exact the same setup, to my old Futaba/Jeti system without any Issue!

I've setup the system from the scratch, several times.

Bind the Tx/Rx in differend modes several times.

Had a look on the sbus out with a Oscilloscope to check the Signal.

Now I´m at the end of my knowledge and need help from the Forum to figure out the problem.

I´ve seen that the sbus signal goes to another input of the STM32F100C8T6B (IO CPU) in the Pixhawk. So maybe the Firmware of that CPU has a bug. Does the IO CPU will be update with the Firmware from the Missionplaner, or is in the STM32F100C8T6B a fixe Firmware?

I know the beaver is strange and unbelievable but true!
May be there is someone from Germany who has the same setup and like to help me personal.

All constructive inputs are welcome!

the test Copter:

here is a log from the Autotune with AGGR 0.05

Views: 4117

Reply to This

Replies to This Discussion

I think you bark at a wrong tree. All those simptoms indicate emi interference on gps unit.
If it is x8r that affects gps receiver or other components - it is not clear. Try to reposition gps receiver, put ground plate under it, emi shield, etc.

On a second thought - where did you power x8r from? Erratic flight may be caused by power starvation of flight controller, if you got too many consumers affecting vcc core voltage.

All i can say - x8r has no interference to pixhawk and it works fine over sbus.

Hello Paul,

I switched off the GPS and have the same behavior.

the Vcc is normal, there a no extra consumers.

I use various FRSKY receivers with all my Pixhawks... all work perfectly including on 3.3 RC7

Note that the X8R sends telemetry back to the Taranis... In some cases if the X8R receiver is too close to the your GPS, you may get less satelites as the X8R telemetry transmissions swamp the GPS receiver.  If this is happening, try separating the X8R further from your GPS and see how you do.

If the wobbles are there in stabilize, you most likely have a tuning issue.  If the wobbles are only there in GPS assisted modes, I'd suspect poor GPS reception due to swamping from your X8R.  Achieving maximum practical physical separation of anything that transmits from anything that receives is a good idea.

I have an X8R receiver with a 9XR Pro transmitter and have seen no such issues.  If your problem is with the receiver then we should see some kind of fluctuation in the RCIN from the logs since there does not seem to be any reported interference from the receiver baring the fact that the receiver could be defective.

Zero issue with the same hardware, check your wiring and the component position.

I tried different Rx (X8r and D4R-II), all the same issue.

I used a PPM to CPPM converter from 3DR, no issue!

I guess wiring and interference's are not the problem.

for me that means if I´m using a CPPM signal there is no Issue, using a SBUS signal I´ve got the Issue.

You are using the new etsi....that's your problem

That was also my thought!

So I flashed the non EU Version on the Tx and Rx, as I described above.

I can also switch of the Tx and have the same issue in Auto mode or RTL.

That is it what you mean with ETSI?

Your setup must have something special because 99% of the people on this forum fly with a taranis,x8r and a Pixhawk without issues. Are you sure you connect the CPPM servo cable at the right ports of your receiver and Pixhawk? How is the receiver powered? How is Pixhawk powered?

I don´t have a Camera

"Are you sure you connect the CPPM servo cable at the right ports of your receiver and Pixhawk? How is the receiver powered? How is Pixhawk powered?"

with CPPM you mean the SBUS from the X8R? Yes sure it is correct connected to the RCin port of the Pixhawk. As I wrote above, the RC channels are working!

The Pixhawk is powered with a 3dr Powermodule and 2nd with a 2A BEC on the RC side!

I experienced a similar problem with a APM on a mini 250 racing quad.

I could fly fine in stabilize mode.  As soon as I went to altitude hold or GPS the copter would act very strange not holding altitude well and typically jumping up a bit as soon a AH was engaged and then falling to the ground.

The issue was the close proximity of the props to an exposed flight controller.

The pressure from the props confused the barometer.  Looking at the logs this could be seen.

I did a quick and dirty test by enveloping the flight controller completely in a tape shield and it flew much better.

The props are creating a negative pressure when they spin up.  The flight controller is above the props so it can see the negative pressure above the props.  It would then try to slow the motors and since lower pressure would be seen as a increase in altitude ending in a flop on the ground.

This could be what you are seeing.  Normally the flight controller is much further away from the props in most copter and is not affected in the same way.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service