Offboard mode - reasoning behind auto-resending of setpoints?


We’re using offboard mode to control drones in GPS denied environments, and have recently begun adding support for PX4.

We’re currently working through failure modes and failsafes. Something I’ve noticed is that there is a timer to re-send setpoints in offboard mode. We run in attitude mode, so this is a potentially a very dangerous thing to do. There are a 2 failure modes here;

  • The application which is supplying us with setpoints (our controller runs as a seperate process which communicates with the drone interface process via shared memory) crashes, so we receive no more setpoints. What we want to happen in this case is for the drone to end up in some non-offboard flight mode (either we put it there, or a px4 failsafe is triggered, which does so).
  • The application which is supply us with setpoints suffers from some timing issue, so we miss one or a few setpoints. In this case, re-sending the previous setpoint for a very limited period is ok. After the very limited period, we have to take action as in the previous point.

I can implement the above with the current mavsdk, and I’d be inclined to hack out the auto-setpoint resend thing to be safe; I would rather fix it instead of hack it out tho.

So, I was wondering if anyone can tell me the reasons behind the auto setpoint resend functionality? Is it just to account for sloppy library clients, or is there an underlying reason?


Hi Dunk,

The auto setpoint functionality is there to “make it easy” for a developer to use the offboard functionality. In the past developers often strugged to accept that they need to keep sending setpoints and it would not work as expected.

Now, for your case, the assessment is correct, I can see how that is not optimal.

I would suggest these two ways:

  1. Don’t ever crash in your application supplying the setpoints! (Duh :slight_smile:)
  2. Add a timestamp to the setpoints in shared memory and check that timestamp. If it is outdated, immediately do offboard->stop(). (Alternatively, have some sort of watchdog that checks if the other process is still alive.)

Thanks Julian,

I will implement a failsafe to cover the case where we stop receiving setpoints over shared memory.

I may also implement a change to the SDK to put a time limit on how long it’ll resend setpoints for, at least in attitude mode. Would you be receptive to merging such a change?