search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.17k stars 13.36k forks source link

Cross check CPPM operation on IO v1.3 with FrSky receivers #921

Closed LorenzMeier closed 9 years ago

LorenzMeier commented 10 years ago

Some users with FrSky receivers had issues. We need to work out if something particular about the D4R-II is an issue or if there is something on our side that would need to be addressed. There are no reports of issues with that receiver on Pixhawk (IO v2.3/2.4).

TickTock- commented 10 years ago

Sorry not much help here except I can say that I do not see any issues with a FlySky TH9X (OpenTX) feeding EZUHF radio transmitting 12 channels on the latest master.

Kynos commented 10 years ago

On a FMU-v1 & IO 1.3? If so, where did you connect CPPM - to J4 on the IO board or to J1 on the FMU board?

I had serious trouble some time back using the 3DR CPPM converter and a Spektrum Rx: frequent RC signal loss conditions and nonsense RC channel values. This was completely fixed by adding a 1K0 in series with the CPPM signal (just like what you get when you connect CPPM to J1 on the FMU board). Pixhawk uses a (different value) series resistor for the CPPM signal, too.

The FrSky D4R-II Rx works fine here, although with the 1K0 fix. Haven't tried a direct connection yet and won't be able to do so soon cause I first have to rebuild my stuff after a crash.

TickTock- commented 10 years ago

Not sure what CPPM is, but I am connecting my radio PPM output to the PX4IO PPM input next to the eight servo outputs.

Kynos commented 10 years ago

In an RC context, PPM by default denotes a single channel signal, so CPPM (= Combined PPM) is often used for marking the difference. Graupner called it "Summensignal" long time ago.

tstellanova commented 10 years ago

Yep, we connect the FrSky D4R-II to the PX4IO (v1.x) PPM input to the far right of the eight servo outputs. I've confirmed this works very smoothly with git commit 6dce571 running on multiple PX4 1.x boards, with multiple D4R-IIs (fresh from factory, not reflashed, not running all 8 channels at max at any time). With the current "continuous" build we see throttle spikes after arming on one PX4FMU+PX4IO combo, which can cause a quad to flip on the ground if props are on. My next step is to try swapping in a different PX4IO to see if that IO is bad.

tstellanova commented 10 years ago

Tried exchanging PX4IO with another and result is the same: 6dce571 shows no RC2 (throttle) spikes, whereas running latest CONTINUOUS build shows occasional full RC2/throttle spikes and throttle shutdown after arming.

LorenzMeier commented 10 years ago

This seems to be related to #930.

LorenzMeier commented 10 years ago

I've created #943 to track the I2C issues - if we cannot reproduce CPPM issues with current NuttX master (where the change is reverted) we can close this card and focus on the I2C aspects.

R-Lefebvre commented 10 years ago

I went through a lot of problems with the CPPM signal using Arducopter on 2 different PX4's in November. I would get input glitching on multiple/all channels simultaneously. The RCInput in logs would show Zero values, even though there was code that should never have allowed values of less than 900 (IIRC) to be returned. These were single frame errors.

On one of the machines, an RC Helicopter with a belt drive, I discovered the root cause was static buildup and discharge from the belt drive. Not a lot. And not enough to cause problems with other electronic systems on this model of helicopter, the problem seemed unique to PX4 and/or my particular helicopter. I installed extensive ground wiring to eliminate the buildup, and the problem went away.

The other machine however was a quadcopter. I never found the cause, there was no source of static. I eventually replaced the PX4 with a Pixhawk with no other changes, and the problem went away.

I now have PX4's running on two other helicopters with no issues. Neither of these have belt drives so no static buildup.

I wish I had more conclusive evidence. But I spent something approaching 100 hours on the problem, and once I solved it I didn't circle back to find out exactly what the problem was.

LorenzMeier commented 10 years ago

Ok Rob, thanks. I think the problem is essentially noise and I'm currently looking into improving noise immunity. What I hadn't realised earlier but noticed today is that we actually use a more resilient implementation of the FMU <-> IO communication on FMUv2. Bringing some of that to FMUv1 will likely put this to rest, even in very noisy environments.

R-Lefebvre commented 10 years ago

Are those noise immunity differences in software or hardware?

px4dev commented 10 years ago

There's a link integrity check on the v2 boards that isn't currently implemented for the i2c interface on the v1 systems. I sent Lorenz a prototype that adds similar checking to the i2c link today; it will probably require some tweaking before it's ready to deploy.

Note however that this is a band-aid; it will reduce the likelihood of data corruption between IO and FMU passing un-noticed, but it won't do anything about the root cause of the corruption.

The edge detector in the STM32 that is used to decode the PPM signal has several clocks (my recollection is 3 @ 24MHz) of debounce filtering. If you are seeing noise glitches longer than a microsecond or so, they may be recognized as false transitions in the stream.

The IO-side decoder is edge-direction sensitive, so for a short glitch it will drop the next two edges, meaning that you will normally see corruption of one or two adjacent channels. The FMU-side decoder is edge-direction agnostic, so in many cases you will lose the entire remaining PPM sequence (the channel hit by the glitch and all higher-numbered channels).

Improving IO<->FMU link integrity will do nothing for either of these issues. It would help if anyone experiencing problems with PPM input glitching could try some specific interference suppression techniques.

1) A 10nF capacitor from the PPM input to ground, as close to the connector as possible (on the pins on the bottom of the board would be ideal). If this helps but not enough, increase to 0.1uF (but remove any series resistor if you do this).

2) Shielded cable for the PPM signal from your receiver to the PX4. One half of a stereo cable, or cable from an old pair of headphones will do. At a pinch, use discrete wires and twist them around each other; try to get at least one twist per inch. You can buy pre-twisted servo cables, which may also help.

Combining both techniques may help further, and we would appreciate feedback from anyone that has an opportunity to try this.

tstellanova commented 10 years ago

Per suggestion from @LorenzMeier I tried this:

cd Firmware/NuttX git checkout ed45e813aff84f5646ea7ad1d7ab50f597bdebb9 cd .. make distclean && make archives && make upload px4fmu-v1_default -j12

I first tried bench tests and could confirm that the throttle spikes and throttle shutdown/disarm problems we were seeing vanished. I then tried flying and was able to perform some very smooth flights with F450, px4fmu+io 1.x

This was with main PX4 firmware commit 15e65fda267b7e3b30305bb0aa1f00b7ee9314cb

TickTock- commented 10 years ago

Ah. Good to know that the hours I spent crimping my own custom shielded coax PWM wires ( http://pixhawk.org/platforms/multicopters/mantis_x8/frame_assembly) paid off. @Todd: I noticed in your image of your wiring you didn't have the ground wires connected on the servo outputs. This creates a large ground loop that can contribute to noise. You might be able to improve your robustness by giving reach ESC it's own ground return line. Would be interesting to see if this fixes the problem (without the software fix). On May 14, 2014 10:01 AM, "px4dev" notifications@github.com wrote:

There's a link integrity check on the v2 boards that isn't currently implemented for the i2c interface on the v1 systems. I sent Lorenz a prototype that adds similar checking to the i2c link today; it will probably require some tweaking before it's ready to deploy.

Note however that this is a band-aid; it will reduce the likelihood of data corruption between IO and FMU passing un-noticed, but it won't do anything about the root cause of the corruption.

The edge detector in the STM32 that is used to decode the PPM signal has several clocks (my recollection is 3 @ 24MHz) of debounce filtering. If you are seeing noise glitches longer than a microsecond or so, they may be recognized as false transitions in the stream.

The IO-side decoder is edge-direction sensitive, so for a short glitch it will drop the next two edges, meaning that you will normally see corruption of one or two adjacent channels. The FMU-side decoder is edge-direction agnostic, so in many cases you will lose the entire remaining PPM sequence (the channel hit by the glitch and all higher-numbered channels).

Improving IO<->FMU link integrity will do nothing for either of these issues. It would help if anyone experiencing problems with PPM input glitching could try some specific interference suppression techniques.

1) A 10nF capacitor from the PPM input to ground, as close to the connector as possible (on the pins on the bottom of the board would be ideal). If this helps but not enough, increase to 0.1uF (but remove any series resistor if you do this).

2) Shielded cable for the PPM signal from your receiver to the PX4. One half of a stereo cable, or cable from an old pair of headphones will do. At a pinch, use discrete wires and twist them around each other; try to get at least one twist per inch. You can buy pre-twisted servo cables, which may also help.

Combining both techniques may help further, and we would appreciate feedback from anyone that has an opportunity to try this.

— Reply to this email directly or view it on GitHubhttps://github.com/PX4/Firmware/issues/921#issuecomment-43107902 .

LorenzMeier commented 10 years ago

So what Robert was seeing looked like this: The first pulse looks like an I2C transfer fail (the zero decoded values would not have been returned by the decoder and I was able to reproduce this with I2C bus errors), the 2nd pulse is not entirely clear - this could very well be a decoder error, as its trivial to generate this outlier by moving / falsely detecting an edge while its not so easy to generate the opposite change on two channels with noise / software errors on the bus.

glitches_robert_3

R-Lefebvre commented 10 years ago

Is that from my logs?

On 15 May 2014 10:30, Lorenz Meier notifications@github.com wrote:

So what Robert was seeing looked like this: The first pulse looks like an I2C transfer fail, the 2nd pulse is not entirely clear - this could very well be a decoder error.

[image: glitches_robert_3]https://cloud.githubusercontent.com/assets/1208119/2985647/6c2636ba-dc3d-11e3-86b9-94fe606a0f85.png

— Reply to this email directly or view it on GitHubhttps://github.com/PX4/Firmware/issues/921#issuecomment-43216536 .

LorenzMeier commented 10 years ago

Yes, and I also downloaded the rest of the data from your PC 8).

tstellanova commented 10 years ago

Has this been fixed in the current PX4/NuttX master? I see a revert related to stm32_i2c

jdsaund commented 9 years ago

Hey guys, hope this is useful to somebody out there. I just had a bunch of issues with my PX4 glitching with FrSky D4R-II w/ 27ms firmware. PX4 is being powered by external BEC. I was having glitches every 4 seconds or so, very random and severe. Tried uploading latest PX4 firmware, tried ferrite rings on power cables, tried a different RX, none worked, still glitching.

Changed BEC voltage from 6.0V to 7.5V and there is no more glitching!!! Well, at least I am yet to experience a glitch. I will write back if I see any glitches.

jdsaund commented 9 years ago

A bit of additional info:

LorenzMeier commented 9 years ago

Thanks for the report. If you check the IO docs, you'll find that the minimum input voltage for the power port is 6.4V - hence your outcome is expected, as it can't work with the lower voltages.

R-Lefebvre commented 9 years ago

Joly, if you need, I can tell you how to supply the PX4 with down to 5.2V and still have 5.0V on the Vcc. :) Just need to replace the onboard regulator.

On 18 October 2014 08:59, Lorenz Meier notifications@github.com wrote:

Thanks for the report. If you check the IO docs, you'll find that the minimum input voltage for the power port is 6.4V - hence your outcome is expected, as it can't work with the lower voltages.

— Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/issues/921#issuecomment-59612252.

jdsaund commented 9 years ago

Lorenz, perfect. I was going off thePX4IO schematic on the pixhawk website, says 6-18v. The actual web page seems to have the correct info though. It seems that other people are referring to the I put as the "6-18v input" instead of "7-18v" which is confusing. E.g 3DR online store:

https://store.3drobotics.com/products/px4-fmu-flight-management-unit-plus-io-input-slash-output-kit

It would help a lot if these websites can somehow be updated. It makes a quick google search on the input voltage range very misleading.

What's more, I was even more confused because 5.2v was giving less issues than 6.0v, I was thinking to myself, "according to the schematic it's within range!!"

Rob, thanks I might do that one day in the future, but this heli uses HV servos :D I actually needed 7.5V but was starting off with lower voltages during the setup process. Luckily I won't have to modify anything. Thanks again.

R-Lefebvre commented 9 years ago

Yes, I use HV servos as well. But my concern is what happens when the 2S lipo gets down to 6.5V, and then there is a current spike from the servos which drag the battery voltage down below 6.0V. I didn't want the Vreg to be the thing to let me down if I can help it.

You won't have that problem with a regulator, but note there is some risk powering it that way. Many BEC's allow momentary voltage dips well below target voltage when the servos move. I'd suggest installing a 4700uF cap on the servo rail at the very least. I don't power any of my setups that way. Either 2S direct, which is "bolder" than a BEC. Or I use 2 BECs, one for the Pixhawk, and another for the servos.

On 18 October 2014 15:38, Jolyon Saunders notifications@github.com wrote:

Lorenz, perfect. I was going off thePX4IO schematic on the pixhawk website, says 6-18v. The actual web page seems to have the correct info though. It seems that other people are referring to the I put as the "6-18v input" instead of "7-18v" which is confusing. E.g 3DR online store:

https://store.3drobotics.com/products/px4-fmu-flight-management-unit-plus-io-input-slash-output-kit

It would help a lot if these websites can somehow be updated. It makes a quick google search on the input voltage range very misleading.

What's more, I was even more confused because 5.2v was giving less issues than 6.0v, I was thinking to myself, "according to the schematic it's within range!!"

Rob, thanks I might do that one day in the future, but this heli uses HV servos :D I actually needed 7.5V but was starting off with lower voltages during the setup process. Luckily I won't have to modify anything. Thanks again.

— Reply to this email directly or view it on GitHub https://github.com/PX4/Firmware/issues/921#issuecomment-59626940.

jdsaund commented 9 years ago

Good advice, appreciated. This BEC is rated to 7A continuous, 15A peak. Should be up to the job as the servos are only micro servos. I can stall one of the servos (takes much manly force) and the rail voltage doesn't budge :)

I'll heed your advice and add a cap though.