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?
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:
Don’t ever crash in your application supplying the setpoints! (Duh )
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.)
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?
Replying on this thread (as opposed to creating a new one) as it seems to be the right topic.
We came across the same issue. We specifically didn’t want to latch repeated sending of our offboard setpoints inside the MAVSDK so that, if our application did crash (it rarely does but you never know!), the PX4 will then trigger an offboard failsafe (which we felt was safer for our application than continued sending of existing setpoints).
We have therefore forked the repo and implemented a parallel set of methods for making single (not latched) requests, for example, alongside the standard method: Offboard::Result set_velocity_body(Offboard::VelocityBodyYawspeed velocity_body_yawspeed);
We implement the method: Offboard::Result set_velocity_body_once(Offboard::VelocityBodyYawspeed velocity_body_yawspeed);
The only difference between the two is that our method doesn’t set the “call_every” callback.
We have piped this method through to the grpc proto (so we have a rpc SetVelocityBodyOnce(SetVelocityBodyRequest) returns(SetVelocityBodyResponse) { option (mavsdk.options.async_type) = SYNC; } for example), again alongside the default calls.
I am sure, as you say, the majority of users would prefer the default “latched” behaviour you have set up for the reasons you set out above. However if you feel some users may prefer the option of requiring the source application to resend regular setpoints, we’d be happy to prepare a pull request for you to consider?
)