-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
while demo was running the don_bot brain died #4
Comments
this could happen in case the |
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. |
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:
The text was updated successfully, but these errors were encountered: