Synchronization Kinect v2-同步深度和颜色帧

我目前正在为一个项目寻找立体相机，Kinect v2似乎是一个不错的选择。然而，由于这对我来说是一项相当大的投资，我需要确保它满足我的要求，主要的一点是不同传感器的良好同步

显然，传感器没有硬件同步，我得到了许多关于软件部分的版本：

一些帖子中，人们抱怨两个传感器之间存在延迟，还有许多帖子要求同步传感器。两者似乎都有奇怪的解决办法，而且从答案中没有“官方”的、共同的解决方案

一些帖子是关于一个类的，它是Kinect SDK 2.0的一部分。据我所知，该类使您能够在给定时间检索所有传感器的帧（或者更少，您可以选择要从哪些传感器获取数据）。因此，您应该能够在给定的瞬间t获得不同传感器的输出，并确保这些输出是同步的

所以我的问题是，这个

MultiSourceFrame

类是否完全符合我的意思？如果是的话，为什么从来没有提出过解决方案？第一类的帖子似乎是2013年发布的，所以在SDK 2.0发布之前。但是，

MultiSourceFrame

类应该替换SDK以前版本的事件，并且

allframesrady

也不建议作为解决方案

不幸的是，文档没有提供关于它如何工作的很多信息，所以我在这里询问，以防有人已经使用了它。如果我的问题看起来很愚蠢，我很抱歉，但我想在购买这种相机之前确定一下

---

谢谢你的回答！如果需要，请随时询问更多详细信息：）

在一次讨论中，有人在使用

MultiSourceFrameReader时，RGB和深度帧之间有6.25毫秒的延迟：

彩色帧的相对时间似乎总是滞后于深度帧、红外线帧、车身帧、车身索引帧的相对时间6.25或6.375毫秒。同时，DepthFrame、InfraredFrame、BodyFrame和BodyIndexFrame之间的相对时间始终匹配

在我自己的实验中，我得到了同样的结果。但这只是基于帧的时间戳。这些时间戳直接来自Kinect v2设备，因此不太可能，但仍然可能不是100%正确

因此，虽然深度帧和RGB帧之间存在延迟，但即使在使用
MultiSourceFrameReader
时，它也很可能足够小，因此您可以忽略它

至于
MultiSourceFrame
/
MultiSourceFrameReader
的用法，一旦您习惯了Kinect v2 SDK，就非常简单了：

m_pKinectSensor->OpenMultiSourceFrameReader(
    FrameSourceTypes::FrameSourceTypes_Depth | FrameSourceTypes::FrameSourceTypes_Color,
    &m_pMultiSourceFrameReader);

// get "synced" frame
IMultiSourceFrame* pMultiSourceFrame = NULL;
m_pMultiSourceFrameReader->AcquireLatestFrame(&pMultiSourceFrame);

// get depth frame
IDepthFrameReference* pDepthFrameReference = NULL;
pMultiSourceFrame->get_DepthFrameReference(&pDepthFrameReference);
IDepthFrame* pDepthFrame = NULL;
pDepthFrameReference->AcquireFrame(&pDepthFrame);

// get RGB frame
IColorFrameReference* pColorFrameReference = NULL;
pMultiSourceFrame->get_ColorFrameReference(&pColorFrameReference);
IColorFrame* pColorFrame = NULL;
pColorFrameReference->AcquireFrame(&pColorFrame);

// ... now use both frames

安装Kinect v2 SDK后，您可以在
CoordinatedMapping Basic
示例中找到更多详细信息。
我只使用了MS SDK，但我认为规则适用。上述所有流的相对时间相同的原因是，上述所有流都是在IR帧之外创建的，因此它们都依赖于IR帧。颜色框不是来自不同的相机。
至于RelativeTime，它基本上是一个时间跨度（用C#术语），它描述了类似于Kinect自身运行时时钟中帧之间的增量时间。它可能是由Kinect服务创建的，Kinect服务从传感器获取原始输入，将IR发送到GPU以扩展到深度（实际上是几个帧的平均值）、Body和BodyFrame（以及LongExposureIR），然后将它们取回，并将数据取回CPU以分发给所有注册的侦听器（也称为不同的Kinect v2应用程序/实例）。
在MSDN论坛上还阅读了一位MVP的回复，他说MS警告他们不要将RelativeTime用于增量时间以外的任何用途。因此我不知道您是否可以将它用于单独流之间的手动同步（即不使用MultiSourceFrameReader）信心十足。
…但Kinect v2的更大问题是硬件要求，特别是USB 3.0控制器。除非您尝试，否则您永远无法确定您的控制器是否正常工作。@HenningJ非常感谢您的回答！以前从未发现过此问题，因此这对您来说是一个真正的帮助。您能详细介绍一下USB 3.0问题吗e？根据官方要求，你需要一个Intel或Renesas USB 3.0控制器。但即使如此，也很难预测它会对谁起作用，也就是说，如果它能起作用，或者它能起作用，你将获得多少FPS。唯一确定的方法是尝试它。如果它不能与内置USB 3控制器一起工作，那么USB 3就有很多PCIe扩展卡应该可以工作。谢谢，那么我想我只能试试：）。@SoniaSeddiki我们开发了一个开源软件，可以同步获取Kinect v2数据。请随意使用我在那里。我是GitHub问题的作者。只是澄清一下，我不认为相对时间来自Kinect V2设备。libfreenect2的作者对USB数据包进行了反向工程，这些数据包的时间戳具有错误的分辨率。RelativeTime的分辨率为0.1微秒，但USB数据包的时间戳分辨率仅为0.1毫秒。所以我的猜测是相对时间是在PC上计算的，而不是在Kinect V2设备上。