@xiangxiang123 多次短按试试，第1步是绑定（只用绑定一次），第2步才是配对（每次重启机器后都要操作一次）。第1步绑定成功后，断开usb和手柄连接，重启系统，然后直接进行第2步操作

计算当前时间前n个数的滑动平均值时，有一种常用数值加速办法：构造一个n*1大小的先进、先出的堆栈队列数据结构，然后记录这n个数的和sum，每次只需要把sum减去最老的值再加上最新的值就可以得到最新的和值，这样相当于把n次求和变成了2次加减运算，可以加速计算。
但是，如果因为数据异常，某次新加入的值很大，求和的时候，就会引入截断误差，从而导致后续的sum值一致存在一个偏差（即当队列里面值都更新为0时，sum值依然为一个不可忽略的的小量）。
解决办法是把异常值过滤掉，或者改为直接求和计算。

FreeRTOS系统进行任务调度的时间精度只能保证小于调度周期，调度周期一般是毫秒级。因此在FreeRTOS中执行定时调度任务时，如果要获取这个任务两次调度的精确间隔时间，是不能只由xTaskGetTickCount()系统函数返回值计算得到的（这是一个毫秒级的整数），需要结合stm32 的systemtick定时器得到微秒级精度间隔时间。

@leslie 仔细看上面教程，你发的命令不是保存充电桩命令，同时浏览前人回复的帖子，检查里程计设置

@whut_gao 你可能搞错红外设备的含义了，单目加kinect这样的深度摄像头进行稠密建图，kinect是红外结构光摄像头

@rockyren 非线性优化求解（包括二次规划类），可以用google的Ceres 库，http://ceres-solver.org/nnls_tutorial.html

@kevin 暂时只支持尾部

@kevin 上面launch没有remap那个里程计话题名字，{remap from="/odom" to="/xqserial_server/Odom" }改成{remap from="/odom" to=“你的里程计话题名字” }

launch文件贴一下

@kevin launch里面的里程计话题有没有改成自己小车的里程计名字，还有slamdb文件夹创建一下,发布dockposition_save命令后看一下里面是否有一个txt文件dock_station.txt。

mkdir  ~/slamdb

dock_station.txt文件里面第三行，存储了当前充电桩位置，这行三个数据依次为x、y、角度。