第5名方案：Delta x,y CNN + MLP 网络
在阅读了所有其他解决方案后，我认为我做得不同的主要一点是，在预测路径“段”（从一个航点移动到另一个航点）的 delta x 和 y 时，我能够获得 < 1.0 的 MAE 误差（x 和 y 的平均值）。
我使用的网络结构是一个用于 IMU 数据的主要 CNN，但我随后将其与许多其他路径数据结合到一个大型神经网络中。
网络结构
这是基本结构：
以下是所有输入和输出的描述：
输入
IMU 12 x 100
我收集了每个轴（x, y, z）的所有 IMU 数据（acc, gyro, mag, rot），这就是“12”。然后我将该数据分箱并平均为每段 100 个点。如果一段的数据点少于 100 个，则其余值设为 0。
有些段的数据点远多于 100 个，但我发现 100 是一个很好的折中方案，既不会让 CNN 处理过多数据，也能在加速度图上清晰地看到步数。
我也尝试了 200 和 50，发现在 200 时几乎没有区别，但在 50 时性能稍差。
site_id
我将站点的 uuid 转换为整数 1 - 24，并将其作为嵌入层的输入（在这里尝试了不同大小，但主要在 ~15 左右）。
floor_id
楼层也是同样的处理，但数字范围是 1 - 139。嵌入层的大小仍然在 15 左右。
time_of_day
我计算了当地的一天中的时间（24 小时制），并将其添加到嵌入层中——我的想法是，在繁忙时段，采集者可能比非繁忙时段走得慢。我不是 100% 确定这是否有帮助（添加/删除所有这些值并进行更多测试会很有趣）。
day_of_week
与 time_of_day 相同，但是针对 day_of_week（星期几）。
total_leg_time
从航点 A 移动到航点 B 记录的总时间。
total_acc_time
我在加速度图中注意到，采集者在段的开始或结束时停顿非常常见——我想他们可能是在点击手机，或者弄清楚行进方向等。因此，我找出了加速度何时超过或低于 66%/33% 线，并将其称为“开始”时间，然后对结束时间也做了同样的处理。
这就是我所说的“acc time”——即采集者实际移动的时间，而不是仅仅拿着手机坐着。
device_id
利用我在这里概述的设备数据泄漏：https://www.kaggle.com/c/indoor-location-navigation/discussion/234543，我将校准值相差 2% 以内的任何设备视为可能是同一设备，并为每个设备分配了一个 ID，然后将这些 ID 放入嵌入层。
想法是不同的采集者会有不同的步幅，这可能可以在嵌入层中进行分类。
device_calibration
与 device_id 的想法相同，但使用的是来自传感器数据的原始校准值。
pct_leg
我计算了这段路程位于路径的百分比位置——所以路径的第一段将是 0%，最后一段将接近 100%。不确定这是否有帮助，但这很容易计算，我想着也没什么坏处……同样，做一个研究看看所有这些特征中实际上哪些重要将会很有趣。
previous_point_xy_time
当我尝试将此网络与我使用 wifi 值构建的全局 x,y 网络连接时，我计算了路径前一个点的 x、y 和时间值（全局 x,y 和时间，而不是 delta x,y,time）。
想法是我可以用这个做一些伪标签训练，但似乎效果不是很好。我在后来的版本中把它去掉了。
next_points_xy_time
与 previous_point_xy_time 相同，但是针对此段之后的点。
rays
为了尝试分类点是在狭窄的走廊还是宽阔的开放空间，我计算了从起点出发在 16 个方向上到最近墙壁的距离。（所以小值意味着狭窄走廊，大值意味着宽阔开放空间）。
这也是一种伪标签形式，随着我的测试预测变得更好，它也会变得更好。