I have only recently started using PX4, never seen this before, its showing up on 2 different airframes, one with a CubeOrange and one utilizing a custom stack. Troubles tuning, neither track setpoint well and have visible twitches in the air making me think the ESC failsafe if maintaining attitude for a brief period and it dips out. Any Ideas?
Yes, that doesn’t look good. If you share a link to the log I can have a quick look if I see something suspicious.
Here is a sample log from our last flight, still working on the tune. I’ll get a log from the Cube Orange FC as well.
I can see that “switching to zero” noise on the incoming RC input. My guess is that the problem starts there. Are you using the same RC receiver for both setups, the Cube Orange and the RB5? And if so, which one is it and how is it connected, is it a PPM or SBUS, etc.?
It was present on both taranis rx8 and spekrum. I thought that initially and changed controllers/recievers.
The only thing they have in common is a microhard 2.4 telemetry radio on board. I can verify on Monday that its not knocking out the rc receivers.
Does that mean different Rx but same Tx? Or different Rx and Tx?
Right, that might be worthwhile to check.
Just a counter thought, if it was rc drops, wouldn’t it show in the RC in pilots? The idea crossed my mind that the altitude controller was overreacting to an overshoot but it was also observed in stabilize so im lost.
It’s not “RC drops”, it’s the RC signal dropping to 0, either because the RC receiver outputs a 0, or because the parsing is faulty and publishes 0, or because there is another module in PX4 also publishing RC (at 0) when it shouldn’t. The last one might be the most likely actually.
Hi @Jon305Johnson
Did you solve this problem?
I’m currently using modalAi voxl2 same px4 version and having the exact same problem .
I did not resolve it, we got an extension on our development cycle and i had to move it back on the priority list. Where I left off, it only seems to be occurring for me on platforms with a telemetry radio and a separate rc receiver. That sample size was fairly small so dont take it as a rule. I repeated the same findings on a cubeOrange platform. But when passing the RC over the microhard radio everything was smooth. This observation correspondes with the possible causes listed above however, rc out should be a direct derivative of the rate controller → motor mixer → pwm generator. RCIN should have no direct effect on that system (in position or altitude mode, ect). If RCIN can drive the outputs to PWM min in the same time sequence, then it would likely be from a desired throttle output at 0. If the math is running in that manner, regardless of the source of the interference, it tells me i have the configuration wrong and im not handling failsafes properly. I’m an ardupilot guy making the transition px4. Becoming bilingual has been slow and painful! Before looking for the source of the interference, im going to investigate handling the condition. Our platform gets exposed to counter UAS measures and I need a robust failsafe strategy like we currently have implemented. I’ll update this post as i jump back onto that task.
Thanks for the quick reply,
I did noticed that you used modalAi rb5 ,
Did you used it with the receiver connected to voxl IO board? Or directly to voxl2?
Yes, with the IO breakout board M0065.
Side note, the same problem exist with spektrum receivers and good old SBUS which steered me away from parsing issues.
I’ve just tried contacting crossfire nano rx directly to voxl2 j19 using mavlink protocol without IO breakout and the actuator outputs plot seems clear!
Good to know! That is consistent with the Modalai Sentinel we evaluated, no IO board and smooth outputs / easy to tune.
here is some log for compare ,
first one with IO breakout :
https://review.px4.io/plot_app?log=35849e36-1a8a-4718-abe1-d57c9d66a964
second without IO , crossfire nano rx connected directly to j19 on voxl2 ( crossfire mode change to mavlink ) :
https://review.px4.io/plot_app?log=00805276-82d8-41ab-827b-3b354fbeea91