-
Notifications
You must be signed in to change notification settings - Fork 19
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
Crash in camnode.py while calibrating #30
Comments
If you updated to 0.6.8 flydra then you will also need to update ros_flydra |
@etiennecampione can you confirm this is new (did not happen before)? Also: is this with the version of flydra which I just packaged and released a couple weeks ago? (What is the output of |
The version 0.6.8 of flydra is installed (it is the output of "python -c "import flydra.version; print flydra.version.version"") and ros_flydra is updated ("git pull --ff-only") and re-built ("make clean", then "make"). |
Yes, then update to git master of ros_flydra. Something like
Please close this bug if that solves it for you. |
@astraw: I already was on the last commit of the ros_flydra repository, so these command lines did not change anything and alas could not solve the problem. |
Oh, yeah, you also have to make the latest ros_flydra
Did you do that, too? |
Relevant logs on the master side:
It receives some log messages, and then the coordprocessor thread dies. At first I thought the logging code I added was responsible, but now that I see it revieves some log messages I am not sure. Thoughts? |
@astraw: I ran rosmake -s ros_flydra, this alas didn't fix the problem. |
@sdvillal can you |
done, FWIW you can do all permission fixups via strawcore
|
Yeah, since some time already permissions in strawscience are sometimes broken even when creating files with permissions properly configured. |
I just pushed 478e6ab which stops the crashes. etienne is still unable to detect points, but I think that is unrelated |
@etiennecampione writes: "Hereafter is the error message I almost always get (let's say 95% of the time) while calibrating a Flycube. Can you indicate me what is going on? It's a really annoying and time-consuming problem".
How does the transport die? Is it possible that the logging service (and therefore the transport) is closed in one camera LogMessageThread thread while there are still messages to log in some other camera thread, and so we would need to add sync code? Or could it just be a network problem? Surely @astraw will know better about this.
I'm saving the full logs of that run here; they include a few other stacktraces.
The text was updated successfully, but these errors were encountered: