Rc_input/RC_output transfer function

[Benykoz]

Hey guys, I’m implementing an indoor flight controller (no GPS, position estimated using a tether connected to the drone) on a Navio2 (Cotper 3.6.5) and ROS.

I’m using mavros and ROS matlab toolbox to control the drone - send RCOVERRIDE commands using udp (wifi) and recieve and log RCIN and RCOUT signals.
I realize using setpoint_raw topic is better for my purpose, but I’m having trouble with publishing to this topic in GUIDED_NOGPS mode, might be a navio2 issue.

Anyway, The controller tries to make the drone hover in place but I encounter several issues.

I have attached the plots of the 3 topics sent using ROS - the X coordinates are time in 50ms intervals, which as i understood, is mavlinks max refresh rate (20Hz), is this sampling time sufficient to control simple drone maneuvers ?

2 other Issues I can’t wrap my head around - the delay from the moment I publish the RCoverride command, to the moment I sense changes in rc_out signals - which is roughly 0.15-0.2 seconds from RCoverride to RCIN and another 0.2 seconds from RCIN to RCOUT. is this delay normal ? I would expect the time from RCIN to RCOUT to be neglectable…

BTW, other pinging tests done provided the same results.

another issue is the divergence of the RCOUT signals as time passes (due to noise?) - do arducopter changes the way RCIN affect RCOUT during flight ? some kind of RC trims done mid flight ? can these be removed ?

I hope this is not a ROS issue, so any input would be amazing,
Thank you very much for this great community.

[Anubis (Rick)]

I probably won’t be able to help with the more technical matters of ROS, but…

@Benykoz

is this sampling time sufficient to control simple drone maneuvers ?

Yeah, that should be plenty fast enough. Depending on the size of your drone and the maximum control effort you command, it’s conceivable that your position control could start oscillating, but 20Hz is more than enough, I’d guess.
That said, the “proper” way to do this is to avoid using RC override and send position targets instead as you suggested, so the onboard navigation controller takes care of it (I think it runs at 50Hz).

@Benykoz

and another 0.2 seconds from RCIN to RCOUT. is this delay normal ?

Not sure about the override->RCIN delay, but RCIN->RCOUT might make sense depending on your flight mode. In stabilize or althold it should be pretty much instant, but I wouldn’t be surprised if the navigation controller adds a bit of delay if you’re in Loiter, Guided, etc.

@Benykoz

do arducopter changes the way RCIN affect RCOUT during flight ?

The short answer is yes, as the EKF learns various biases and such, but I’d think that these things might not be so easily visible, so there might be something else going on. But if it’s the EKF learning, you’d probably not want to turn it off because it should make the drone’s behavior more consistent when controlling it with RCs.