Open sunava opened 6 years ago
this could happen in case the object_state_publisher
is behind and has not yet published the frame of the facing on TF topic.
Aha, interesting idea. @ichumuh what do you think?
I agree that the object state publisher is probably the problem. Knowrob knows about this facing since it returned it, but the frame doesn't exist. But it's strange I don't remember that we ever had this problem. I think we should see if it happens again.
Well it wouldn't happen deterministically. You can avoid it by asking KnowRob for the pose instead, since KnowRob has an internal pose representation that does not rely on TF frame to be published.
True but tf is more convenient. The brain is already waiting for 2 seconds for the transform to become available. I think increasing that number is an easier fix.
But it would not be a safe fix. It would just decrease the risk of it to happen.
I could also add a predicate in knowrob that triggers TF publishing and blocks until message sended.
I don't think thats necessary after seeing you latest object state publisher changes. Since you now send all the transforms with the service call, we should now be able to publish the frames within that service call without getting into a deadlock.
well the object state publisher is also not processing the stuff right away but has a separate thread for processing the queued "dirty" objects. It's up to the OS when the CPU is switching to this thread again. Surely, shouldn't be seconds but rather milliseconds. But in case other processes occupy CPU, it's not entirely predictable when this thread will be active next time
I know but we only did this to prevent deadlocks, because prolog was called to get the object information. We don't have to do this anymore because you are sending all the information we need, so we could update the objects in the callback again. Right?
yeah possible. But only if the call is fast. I don't want people complaining about slow KnowRob queries... That's why I would prefer to stick to threaded object state publisher. But potentially the call is "fast enough" anyway. Would be nice to look into how much time is spend when calling the "mark_dirty_object" service.
Good point. I can do a runtime analysis when the static transform bug is fixed.
@airballking @amaldo @ichumuh
log from the brain: