MartyG-RealSense
commented
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".
Closed neilyoung closed 4 years ago
MartyG-RealSense
commented
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".
neilyoung
commented
4 years ago @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.
MartyG-RealSense
commented
4 years ago 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.
bfulkers-i
commented
4 years ago 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.
neilyoung
commented
4 years ago @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
radfordi
commented
4 years ago @neilyoung, this indicates a firmware issue:
mempool out of memory: video
neilyoung
commented
4 years ago Ok. Then there is hope :)
neilyoung
commented
4 years ago @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 :)
radfordi
commented
4 years ago @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.
neilyoung
commented
4 years ago 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.
neilyoung
commented
4 years ago 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: