Ardupilot: PPM encoder adds lag to input

[lion13ch]

Pixhawk (with 3Dr PPM Encoder or Frsky PPM signal) have PPM input lag (delay).
Lag (delay) is between rc roll/pitch stick is moved and copter begin to roll/pitch.
Lag was found at AC3.2rc3 as well AC3.2rc2 and AC3.1.5. Lag is about 50-70 msec.
There is no lag with S.Bus input and no lag at APM2.5 with PWM and PPM input.
Can It be fixed ?

[rmackay9]

@lion13ch how did you measure the lag?

[lion13ch]

Hello Randy !

Lag was measured about eye. I made different roll/pitch stick movement (stick
position 0 to 100, 20-50, 50-100 and so on) and I saw so some delay. Delay is
about 15-20Hz like strobing video when you see sticks and copter the same time.

I can not do accurate measurements, but the lag is visible by eye and finger
feelings. The is NO Visible LAG with S.Bus reciever and no lag with APM2.5.

So I just stated a fact. I know that other Pixhawk users see this lag too.

[rmackay9]

I suspect that it's not an input lag but rather the acceleration limiting that's been introduced in AC3.2. If you're using AC3.2-rc3 could you set the ATC_ACCEL_RP_MAX and ATC_ACCEL_Y_MAX to zero? this will disable them.

[lion13ch]

OK. I'll try it.

But why this lag is visible only with PPM Sum signal ? The same receiver and
transmiter, but s.bus input have NO LAG, but PPM Sum LAG is obvious.

I guess there is some difference at input methods and PPM Sum goes through IO
module while S.Bus is not.

I think you can check this by yourself, just connect receiver by PPM !

[rmackay9]

I use PPM Sum all the time though and I haven't noticed the lag. You're using the same flight controller in your tests or two different multicopters? I'm just wondering if it's possible the configuration of the arducopter flight controller in the two tests is different.
We may need to directly pass through the input to the output and compare the two instead of looking at the response in the multicopter flying.

[lion13ch]

So maybe you can try to use S.Bus to feel the difference ?!

I use one Pixhawk with 3DR PPM Encoder + Frsky X8R reciever and X8R reciever +
S.Bus out. I also tast this copter with APM 2.5. I try AC3.1.5 (Pixhawk and APM),
AC3.2rc2-rc3 (Pixhawk only) with the same result.

How can I turn the ATC_RATE and ATC_ACCEL off at all ? Just set it to sero ?

I do not say the Lag is Big, but it is !

[rmackay9]

Ok, make sure you've loaded AC3.2-rc3 and then connect with mission planner and go to the full parameters list (you may need to check the "Advanced view" checkbox on the Config/Tuning > Planner screen first). In the full parameters list you should see ATC_ACCEL_RP_MAX and ATC_ACCE_Y_MAX. Set those to zero and press "Write Params" button.

[Christian666]

Randy, I noticed that as well. If you use the new Taranis and X8R RX with S.Bus connected directly to RC-IN of Pixhawk, it will result in a quicker response. At the moment I don't have a dual channel osciloscope to measure the signal transit time trough the external ppm Encoder. I guess 20-30ms. It's not only the 3DR Encoder, it happens also with china clone pcb's. Maybe it's going better with latest ppm firmware. I didn't check that, bcs happy with X8R :-)

[lion13ch]

Thanks a lot. ATC_ACCEL = 0 is what I like - soft response as it was at 3.1.5 at
APM. But 3.2rc3 defaults I like too - it's sharp and good to make correct PID
settings.

I will try it later with PPM bcs of Rain. But I am pretty sure it will not fix
the lag. I saw lag at Pixhawk AC3.1.5 with PPM where is no ATC_ACCEL paramerers
at all.

[lion13ch]

As I know default PPM Sum frame time is 20 ms. The S.Bus frame time is 7 ms. But APM have internal PPM encoder and do not have the lag. Lag is exactly more than 20 ms bcs it's too small to feel (50Hz). The lag can be 40 ms and more to be visible (25Hz). I think PX4IO have incorrect priority settings for PPM Sum input.

[lion13ch]

Randy, I tested ATC_ACCEL=0 with PPM Sum. The Lag is is still there. But with soft response it is difficult to measure the Lag. So I made this test at sharp response settings (ATC_ACCEL_RP_MAX,126000
ATC_ACCEL_Y_MAX,36000
ATC_RATE_RP_MAX,36000
ATC_RATE_Y_MAX,36000
RC_FEEL_RP,100).
I made test at hands with Throttle = 45% (Hover), moved roll stick at 30% (to avoid deadzone) left and than made small stick movement by 5-10% left-right:

1. If I used Pixhawk + Frsky X8R by S.Bus output = NO LAG.
2. If I used Pixhawk + 3DR PPM Encoder + Frsky X8R by PWM output = LAG IS PRESENTS.
   So I measured the Lag by inner feelings like this:
3. Make stick move and say "Ta" by inner voice the same time.
4. Listen and see the copter movement and say "Da" by inner voice.
5. repeat this 5-10 times and you will listen crisp sound "Ta-Da".
6. try to reproduce this sound interval at "Android stopwatch program" (or other) by quick doubleclick and you will see that LAG is about 50-70 msec.

So It is the Pixhawk PPM Sum input bug (soft or hard I do not know) !!

[ausi1972]

I have a Pixhawk board and found the same problem. There does indeed seem to be an issue with lag with a PPM encoder connected.

[rmackay9]

Ok, so really this looks like a PPM encoder issue? It's not that attaching a PPMsum encoder directly to the pixhawk introduces a lag right?

[lion13ch]

Pixhawk + Frsky PPMsum have lag too. So it is not just PPM encoder issue.

[github-0]

I noticed this too.

Pixhawk (plane 3.1.1)
3DR PPM Encoder
Futaba 7C + R617FS receiver
= lag

[rmackay9]

We're out of time for AC3.3 so pushing to AC3.4.

[WickedShell]

Somewhere between plane 3.2 and 3.3 this got far better for plane, I'd be interested if it's still a problem on copter. I did testing with plane 3.3 and an oscilloscope and in manual was getting the correct servo outputs requested as soon as was possible. (Startup could introduce a time offset between the RC reciever, ppm encoder, and pixhawk which can affect the worst case pass through time, but the pixhawk was doing as good as it possibly could be expected to).

[rmackay9]

Not sure if this is still a problem or not but pushing to AC-3.5 in any case.

[hiro2233]

@rmackay9 i have investigated this problem, i had the same problem when i use the ppm, it's happening because the time interrupts are individual for each channel in serial transmision with an unkwon time interrupt intervals between the channels and it take little microseconds difference, but it has a big impact when the copter autoactivate the auto trim after the 20 seconds in the loop, i deactivate this by hardcoded an the problem go out but without auto trim.

The reason that it work fine in a SBUS are because the data adquisicion process do it when it fill the buffer and then finish the process it to complete data channel and fire it.

[Naterater]

Still relevant with ChibiOS?

[rmackay9]

I don't think hardly anyone uses PPM encoders any more. It was really transitional while the old individual channel RC receivers were still popular. I'll close this I think.