improve end to end control latency measurement

[dagar]

pixracer (multicopter)

nsh> perf
fmu control latency: 31096 events, 6985713us elapsed, 224us avg, min 201us max 566us 16.366us rms

pixracer (fixedwing)

nsh> perf
fmu control latency: 3182 events, 1534797us elapsed, 482us avg, min 171us max 5798us 395.665us rms

pixhawk 2 (multicopter)

nsh> perf
fmu control latency: 0 events, 0us elapsed, 0us avg, min 0us max 0us 0.000us rms
io control latency: 1016 events, 290388us elapsed, 285us avg, min 225us max 621us 33.261us rms

pixhawk 2 (fixedwing)

nsh> perf
fmu control latency: 0 events, 0us elapsed, 0us avg, min 0us max 0us 0.000us rms
io control latency: 5014 events, 2387356us elapsed, 476us avg, min 156us max 1745us 362.783us rms

pixhawk 2 (VTOL)

nsh> perf
fmu control latency: 29874 events, 445943798us elapsed, 14927us avg, min 3747us max 28028us 6376.741us rms
io control latency: 25358 events, 10419801us elapsed, 410us avg, min 316us max 1397us 35.020us rms

[dagar]

Note the VTOL FW output (fmu/aux outputs). This is mainly the result of the fmu module running in the high priority work queue. A small portion is also the vtol attitude controller. The FW numbers are still only counting the time from the vehicle_attitude publication.

[bkueng]

• typo: latenccy
• can you use int i = 0?
• can you move this block after orb_publish_auto(ORB_ID(actuator_outputs) and use actuator_outputs.timestamp instead of hrt_elapsed_time?

[dagar]

Done

[dagar]

Comments addressed and I also added the perf counter to linux_pwm_out, snapdragon_pwm_out, and pwm_out_sim for consistency.