introduce uORB::SubscriptionBlocking and use in navigator and simulator

[dagar]

This PR introduces a new uORB Subscription class that has a blocking update. This can be used in place of the traditional orb subscriptions and polling.

Also contained in this PR are the other minor uORB changes needed for logger. #12123

Example

Existing orb + poll usage

int local_pos_sub = orb_subscribe(ORB_ID(vehicle_local_position));

/* wakeup source(s) */
px4_pollfd_struct_t fds[1] = {};

/* Setup of loop */
fds[0].fd = local_pos_sub;
fds[0].events = POLLIN;

/* rate-limit position subscription to 20 Hz / 50 ms */
orb_set_interval(local_pos_sub, 50);

while (!should_exit()) {

/* wait for up to 1000ms for data */
int pret = px4_poll(&fds[0], (sizeof(fds) / sizeof(fds[0])), 1000);

if (pret == 0) {
/* Let the loop run anyway, don't do `continue` here. */

} else if (pret < 0) {
/* this is undesirable but not much we can do - might want to flag unhappy status */
PX4_ERR("poll error %d, %d", pret, errno);
px4_usleep(10000);
continue;

} else {
if (fds[0].revents & POLLIN) {
/* success, local pos is available */
orb_copy(ORB_ID(vehicle_local_position), local_pos_sub, &_local_pos);
}
}

// DO THE WORK
}

orb_unsubscribe(local_pos_sub);

Simplifies to this (using PR)

uORB::SubscriptionBlocking<vehicle_local_position_s> local_pos_sub{ORB_ID(vehicle_local_position), 50};

while (!should_exit()) {

// wait for data
if (!local_pos_sub.updateBlocking(_local_pos)) {
continue;
}

// DO THE WORK
}

[dagar]

One point to discuss is the desired timeout behavior. There might be exceptions that I haven't come across, but in our orb related poll usage there's a timeout that does nothing but a fresh poll setup. So the question is if we need to preserve the ability to do anything else on a timeout, and if that timeout even needs to configurable.

[dagar]

@AuterionWrikeBot keeps helpfully clobbering the formatting in my example.

[dagar]

Out of flash on fmu-v2 again.

[julianoes]

@dagar ok what do you need me to do here? Review or do we need to disable something else for v2?

[dagar]

@dagar ok what do you need me to do here? Review or do we need to disable something else for v2?

I'll ping you again once it's been resolved.

[dagar]

Updated LPE to kill off uORB::SubscriptionPollable entirely.

[julianoes]

With the previous implementation we still ran this loop on timeout, with the new one we're just continuing, right? Do we know the implications?

[dagar]

Partially, but we need to be careful and think it through module by module. In the past for mc_pos_control this was important for stabilized/manual mode, but that's been moved.

[julianoes]

@MaEtUgR could you check?

[MaEtUgR]

This is solved in a different way now right? https://github.com/PX4/Firmware/blob/f956bafa4eda7ceb298790ef0fff5540fd3c589f/src/modules/mc_pos_control/mc_pos_control_main.cpp#L535
I think it's much better to run the controller up on new estimation data but we need to make sure there's instant and reliable emergency handling in case of a timeout. Last resort the attitude controller should keep the vehicle stable level if attitude setpoints are missing.

[dagar]

Yes it will need to be updated, although that entire topic needs to be reviewed. Commander and mc_pos_control have separate notions of position and velocity validity.

[dagar]

Actually, mc_pos_control was pulled out of this PR (moved to a WQ).

[julianoes]

I think pthread_mutexattr_destroy is missing here.

[julianoes]

Shouldn't this be based on the monotonic clock?

And then we need to set pthread_condattr_setclock (&cond_attr, CLOCK_MONOTONIC) but that's probably only possible on Posix but not NuttX.
https://github.com/PX4/Firmware/blob/07d656e971a72d1202651dfd3b4642736fb078d7/platforms/posix/src/px4/common/px4_sem.cpp#L65

[dagar]

CLOCK_MONOTONIC is available on NuttX, but needs to be added to several boards. Trying it now.

[dagar]

CLOCK_MONOTONIC hangs pthread_cond_timedwait, which appears to use CLOCK_REALTIME internally.

[julianoes]

Right but can we use it for Posix then?

[dagar]

The estimators (attq and lpe) might as well transition straight to a WQ with callbacks. #13287

[dagar]

Moving camera_feedback to a WQ. #13044

[dagar]

I'm going to merge uORB::SubscriptionBlocking without the remaining use cases (commander low priority and simulator) so we can start experimenting with it and stop rebasing this PR.