Closed neilyoung closed 4 years ago
Another user who had the unhandled extension types during recording recently was advised that they are "expected and not indicative of misbehaviour".
@MartyG-RealSense Nice find, but I'm not that much concerned about the exceptions. I'm concerned about the outages in the stream. I can't believe, that stream outages, wich affect the video and the pose stream, are "desired behaviour". It's like letting drive the robot with someone in the front passenger seat who covers the robot's eyes for a few seconds from time to time. Somehow I can't imagine that that's what you want to do. I now check whether these gaps also apply to the "pose only" stream. If so, this is a serious problem for the T265.
It wasn't desired behavior, but 'expected' behavior.
A debugging rule of thumb that I use is to look at the first occurrence of an error in a log, since an error may cause a cascade of subsequent areas in other areas that would not be erroring if the initial error had not occurred (i.e focusing on the first error helps to avoid investigating in areas where there may not be a problem).
If we ignore the extension handling warnings because they are 'expected', the next "real" error after that is the mempool error.
WARNING [0x7000024f2000] (tm-device.cpp:1386) T265 FW message: 434145045981: [0x /5:100] mempool out of memory: video
In both occasions when this error appears, it is immediately followed by time-out errors. So it might be reasonably expected that the mempool error is the trigger for timeouts.
Thanks @neilyoung, and also great to see your tests outdoors in #5472. The data outages are definitely not expected. I added a recent patch to #5213 yesterday which may help with this:
64c753b. I'm not sure that's what you are experiencing here, but it feels like it might be related. You may also try enabling only the pose stream (maybe you already are) to reduce the amount of data that needs to be processed on your host machine.
@MartyG-RealSense Cool, no problem with your wording :) I probably misunderstood your sentence.
@bfulkers-i Great, will patch soon. As you said: I already enabled just the pose stream but the results are not too encouraging. I will report later in the original thread https://github.com/IntelRealSense/librealsense/issues/5472. Thanks for now
@neilyoung, this indicates a firmware issue:
mempool out of memory: video
Ok. Then there is hope :)
@bfulkers-i Great, will patch soon. As you said: I already enabled just the pose stream but the results are not too encouraging. I will report later in the original thread #5472. Thanks for now
While reviewing this I found, that this statement is not true. Using only the pose stream did not show any outage. I tested it later and these are the results https://github.com/IntelRealSense/librealsense/issues/5472#issuecomment-567010861
Very accurate in timing, but drifty :)
@neilyoung, were you recording the images when you got the drops in #5472? Is so, then the drops are likely caused by writing the data to SSD without sufficient bandwidth. You have to be very careful when recording to avoid this issue.
Yes. Video was on. And the Mac was running with lid closed, but this was not the issue. I could reproduce with lid open. Maybe I try with a ram disk next time.
closed for lack of interest
Issue Description
I made several rounds in larger venues. T265 mounted to the macbook pro. Proper USB cables used. Also after replacement no change.
I'm using the realsense-viewer app and it can be pretty good seen, how the video and all IMU streams are stuck for up to 5 seconds. With the original cable the outages were not that long, but there were.
Not sure if it is related, but this is the console output of the last run: