如果你在网上搜“蓝牙RSSI定位”大概率会看到两种声音一种是直接告诉你“RSSI测距不准别想了”另一种是拿几个理想环境下的Demo说“能达到厘米级”。我自己的实际感受是这两种说法都有道理但都只说了一半。前阵子一个仓储项目需要在没有GPS的钢结构仓库里追踪几台小车的相对位置预算有限、部署时间又紧我最后老老实实把BLE4.0的RSSI信号捡起来调了一遍。这篇文章就是那次实战的完整复盘用Arduino生态里最常见的ESP32开发板配合BLE4.0广播与扫描从信标广播、RSSI采集、滤波处理、距离标定一路走到三边定位最终在串口里实时读出移动端的坐标。文中的所有代码都是完整可直接烧录的适合刚接触室内定位、手上有一两块ESP32或者Arduino兼容板、想低成本验证定位效果的读者。说实话先把“厘米级”这个预期放一放。蓝牙RSSI在真实室内环境下的典型精度是1到3米通过多基站、多帧平滑和算法优化后可以逼近亚米级但离宣传里的“厘米级”还有距离。想清楚这个边界后面做的每一件事才有意义。1. RSSI为什么能定位从无线电衰减到距离估算定位这件事本质上是解几何题。你知道了自己到三个固定点的距离就能反推出自己在哪。蓝牙RSSI能参与定位靠的就是“距离越远接收到的信号越弱”这条物理规律但这条规律在室内并不是一条干净笔直的线。1.1 信号强度的物理模型接收信号强度RSSI的单位是dBm它是一个相对功率值。蓝牙接收端得到的RSSI和距离之间的关系通常用对数路径损耗模型描述PR(d) PR(d0) - 10 × n × log10(d / d0) Xσ这个公式看着复杂拆开就不难了PR(d0)是参照距离d0处的信号强度工程上习惯取1米处测量值记作An是环境衰减系数自由空间取2.0办公室、仓库这类有家具和设备遮挡的环境实测一般在2.2到3.5之间Xσ是一个随机噪声项幅度通常在±5到±10dBm这正是BLE定位误差的主要来源。把公式反解一下就可以从RSSI算出距离dd 10 ^ ((A - RSSI) / (10 × n))这个式子整套系统的基础。A和n不是你拍脑袋定的必须靠实测标定后面会专门讲。1.2 dBm这个单位的直觉理解dBm是个对数单位很多人一看到就头大。你可以这样理解RSSI每下降6dB对应的距离大约翻一倍每下降10dB距离大约变为原来的3.16倍。这不是巧合而是对数模型本身的特性。这个直觉非常有用。比如你在1米处测到RSSI是-65dBm按n2.3计算2米处大约是-71.9dBm4米处大约是-78.8dBm。可以看到距离越远相同距离差造成的RSSI变化越小。这就是为什么RSSI定位近处相对准、远处容易飘的根本原因。所以后面布信标时相邻信标间距不要拉太大4到6米是比较合理的范围。1.3 多径效应和人体吸收精度杀手室内环境里蓝牙信号从发射端到接收端通常不是只走直线而是会经过墙壁、金属货架、地面反弹之后才到达接收天线这就是多径效应。多条路径的信号在接收端叠加可能增强也可能抵消最终RSSI会出现明显的抖动。我做过一个统计实验在相对空旷的办公室里距离2米固定不动连续采集60秒RSSI波动范围可以达到15dBm以上。人体对2.4GHz信号的影响也不能忽略。人体含水量高本身就是个信号吸收体人站在信标和接收端之间RSSI往往直接掉4到8dBm。换算成距离可能从2米直接“测”成3.5米。后面实测优化部分我会具体说怎么处理这类问题。2. 硬件选型和通信链路信标与观测站的职责分工蓝牙定位的系统架构有很多种我推荐先把职责分开固定位置只负责广播移动端只负责扫描解算。这样标签端的功耗可以做得很低移动端也不用频繁发送数据整个时序清晰很多。2.1 板子怎么选ESP32是入门首选标题里写“用ArduinoBLE4.0”实际操作时建议直接用ESP32而不是传统Arduino Uno搭配蓝牙转串口模块。原因有几点Arduino Uno本身不带BLE功能外接CC2541、HM-10这类模块时主控通过串口收发数据虽然也能拿到RSSI但模块通常工作在透传模式或AT指令模式数据获取链路长、时序控制麻烦ESP32原生支持BLE4.2向下兼容BLE4.0在Arduino IDE中可以直接调用开发体验顺滑很多ESP32自带Wi-Fi和BLE后续如果要把定位结果发到上位机或者服务器同一块板子就能搞定不用再增加硬件。如果不是非要追求极致的低功耗ESP32开发板做信标和移动端都是够用的。手头确实只有Arduino Uno的读者也不要灰心用HM-10模块采集RSSI在原理上完全可行只是代码要从串口解析部分开始写起整体会多出一截工作。2.2 完整的硬件清单参考角色硬件方案数量备注定位信标ESP32开发板刷beacon广播程序3固定在三脚架或非金属支架上移动端ESP32开发板刷扫描定位程序1用充电宝供电实时输出坐标尺子5米以上卷尺1标定和布点都要用串口工具一根USB转MicroUSB线1接电脑看串口输出上位机Arduino IDE串口监视器-或者用Python读串口也行一共4块ESP32就能把整套系统跑起来。如果你手头只有2块板子可以先拿手机充当信标装一个iBeacon模拟App这样也能完成验证。2.3 通信链路谁在说话谁在听这套系统里三个固定信标持续发出BLE广播包移动端作为一个扫描设备周期性扫描附近所有BLE广播并从广播包中解析出信标的标识和当前RSSI。移动端不需要和信标建立连接广播模式本身也不支持连接这种设计让链路很简单。广播包里需要携带信标的身份信息。iBeacon协议是一个很通用的广播格式广播数据中包含了UUID、Major、Minor三个字段Major和Minor可以用来区分不同位置的信标。我的做法是三个信标的Major分别设为1、2、3Minor设为相同值移动端扫描到广播包后根据Major判断是几号信标再把对应的RSSI存入自己维护的数组。BLE4.0和BLE4.2在这里的差别其实不大广播包解析逻辑完全一致。没必要为了旧版本协议特意去买老模块市面上现成的ESP32开发板都是带BLE4.2的能识别BLE4.0的广播包。3. 数据采集代码不是拿到RSSI就够了很多入门教程在讲蓝牙定位时往往只教怎么扫描到RSSI然后直接套一个距离转换公式就算完事。实际操作时你会发现如果没有一套可靠的数据采集策略后面所有算法都是建立在一堆抖动值上输出结果自然没法看。这一节先把完整的扫描代码放出来再讲采样策略。3.1 信标端一个可用的iBeacon广播程序这段代码烧录到三个固定位置的ESP32上使用的库是Arduino IDE中ESP32开发板包自带的BLE库不需要额外下载第三方库。三个信标唯一的区别是BEACON_MAJOR不同。#include BLEDevice.h #include BLEUtils.h #include BLEServer.h #include BLEBeacon.h #define BEACON_MAJOR 1 // 三个信标分别改为1、2、3 #define BEACON_MINOR 100 BLEAdvertising *pAdvertising; void setup() { Serial.begin(115200); BLEDevice::init(ESP32_BEACON); BLEBeacon beacon; beacon.setManufacturerId(0x004C); // 苹果公司ID兼容大多数扫描工具 beacon.setMajor(BEACON_MAJOR); // 区分信标编号 beacon.setMinor(BEACON_MINOR); beacon.setSignalPower(-65); // 1米处实测RSSI标定后修改 BLEAdvertisementData advData; advData.setFlags(0x06); advData.setManufacturerData(beacon.getData()); pAdvertising BLEDevice::getAdvertising(); pAdvertising-setAdvertisementType(ADV_TYPE_IND); pAdvertising-setMinInterval(100); // 广播间隔100ms到150ms pAdvertising-setMaxInterval(150); pAdvertising-setAdvertisementData(advData); pAdvertising-start(); Serial.println(Beacon started); } void loop() { delay(1000); }提示如果你用的ESP32 Arduino库版本较老setSignalPower参数类型可能报错可以传0xBF这个无符号值它和-65dBm的补码表示一致。广播间隔设置在100到150毫秒之间这是一个兼顾功耗和扫描成功率的区间。间隔太短会费电间隔太长会导致移动端扫描时漏掉某一个信标。3.2 移动端扫描三个信标并缓存RSSI移动端程序的核心是在扫描回调里判断广播包来源把不同Major的RSSI分别存下来同时维护一个最近N次的历史缓冲区供后续滤波使用。#include BLEDevice.h #include BLEUtils.h #include BLEScan.h #include BLEAdvertisedDevice.h #include math.h #define SCAN_TIME 3 // 每秒扫描窗口 #define WINDOW_SIZE 10 // 滑动窗口大小 const float BCN_X[3] {0.0, 6.0, 0.0}; const float BCN_Y[3] {0.0, 0.0, 6.0}; const float CALIB_A -65.0; // 1米处RSSI const float PATH_LOSS_N 2.3; // 环境衰减指数 float rssiHistory[3][WINDOW_SIZE]; int histIndex[3] {0, 0, 0}; int histCount[3] {0, 0, 0}; float lastX -1, lastY -1; class ScanCallback : public BLEAdvertisedDeviceCallbacks { void onResult(BLEAdvertisedDevice dev) { if (!dev.haveManufacturerData()) return; std::string md dev.getManufacturerData(); if (md.length() 25) return; uint16_t major (md[20] 8) | md[21]; if (major 1 || major 3) return; int idx major - 1; int rssi dev.getRSSI(); rssiHistory[idx][histIndex[idx]] rssi; histIndex[idx] (histIndex[idx] 1) % WINDOW_SIZE; if (histCount[idx] WINDOW_SIZE) histCount[idx]; } }; BLEScan *pScanner; void setup() { Serial.begin(115200); BLEDevice::init(); pScanner BLEDevice::getScan(); pScanner-setAdvertisedDeviceCallbacks(new ScanCallback()); pScanner-setActiveScan(false); // 被动扫描广播包足够 pScanner-setInterval(100); pScanner-setWindow(99); } float filteredRSSI(int idx) { if (histCount[idx] 0) return 0; float buf[WINDOW_SIZE]; int n histCount[idx]; for (int i 0; i n; i) buf[i] rssiHistory[idx][i]; // 冒泡排序取中值 for (int i 0; i n - 1; i) { for (int j 0; j n - i - 1; j) { if (buf[j] buf[j 1]) { float t buf[j]; buf[j] buf[j 1]; buf[j 1] t; } } } return buf[n / 2]; } float rssiToDist(float rssi) { return pow(10.0, (CALIB_A - rssi) / (10.0 * PATH_LOSS_N)); } void loop() { pScanner-start(SCAN_TIME, false); pScanner-clearResults(); float d[3]; bool valid true; for (int i 0; i 3; i) { float r filteredRSSI(i); if (r 0 || histCount[i] 5) { valid false; break; } d[i] rssiToDist(r); } if (valid) { float x, y; if (trilaterate(BCN_X, BCN_Y, d, x, y)) { // 简单的速率限制防止跳变 if (lastX 0) { if (fabs(x - lastX) 2.0 || fabs(y - lastY) 2.0) { x lastX; y lastY; } } lastX x; lastY y; Serial.print(POS,); Serial.print(x, 2); Serial.print(,); Serial.println(y, 2); } } delay(500); }这个程序在loop()里每次扫描3秒休息0.5秒然后输出一次位置。pos格式的串口输出方便后续用Excel或Python直接收集分析。3.3 滤波处理中值滤波为什么比均值更稳RSSI抖动大的时候均值滤波容易被个别极端值带偏。比如连续采集10个值中间混入一个因为瞬态干扰产生的-90dBm平均值立刻被拉低不少换算距离时误差会被放大。中值滤波能把这样的离群点直接挡在计算之外。上面的代码里我用了冒泡排序取中值写法笨了一点但胜在逻辑直白、没有第三方依赖。在ESP32这种资源不紧张的平台上排10个数的时间完全可以忽略。如果你希望动态跟踪效果更好可以在中值滤波之后再套一个一阶低通滤波相当于对输出的坐标再次平滑。需要注意滤波窗口太长会导致定位结果反应迟钝。我做实验时把窗口从10改到30坐标确实更稳了但人走一步之后要两三秒才跟上体验很差。静态应用可以适当加大窗口动态移动场景控制在5到10次采样比较平衡。4. 从RSSI到坐标三边定位的完整算法链路数据采好了接下来就是把三组距离信息变成坐标。这里有两个关键环节距离换算参数的标定以及三边定位的解算。4.1 距离标定数据怎么采、参数怎么拟合标定A和n两个参数没有捷径只能实地走一遍。流程是这样的在目标环境的空地上拉一条卷尺信标固定在地面1.2米高的三脚架上从0.5米处开始依次在1米、2米、3米、4米、6米、8米处各采集一组RSSI每个点连续采集30到50次取中位数作为该点的有效RSSI用Excel或Python对数拟合出n值。我一次实测的数据大概长这样距离(m)实测RSSI中位数(dBm)0.5-561.0-652.0-723.0-774.0-816.0-881米处的A值直接取-65然后取2米数据代入公式反推nn (A - RSSI) / (10 × log10(d))以2米为例n (-65 - (-72)) / (10 × 0.3010) ≈ 2.33。取多个距离点求平均最后定在2.3左右。注意信标和移动端的天线方向要保持和实际使用时一致。天线的指向变化会让RSSI出现3到5dBm的差异标定时是一个姿态实际部署时又是另一个姿态那标定数据就白做了。4.2 三边定位的数学推导和代码实现有了三组距离就有了三个圆求坐标等价于求三个圆的交点。但因为RSSI测距有误差三个圆往往不能整齐交于一点这时要用最小二乘的思想求一个“最接近三个圆的位置”。公式推导不展开太多思路是把圆方程两两相减消去二次项得到线性方程再用克拉默法则直接解二元一次方程组。bool trilaterate(const float *x, const float *y, const float *d, float *outX, float *outY) { float A 2 * (x[1] - x[0]); float B 2 * (y[1] - y[0]); float C 2 * (x[2] - x[0]); float D 2 * (y[2] - y[0]); float E d[0]*d[0] - d[1]*d[1] - x[0]*x[0] x[1]*x[1] - y[0]*y[0] y[1]*y[1]; float F d[0]*d[0] - d[2]*d[2] - x[0]*x[0] x[2]*x[2] - y[0]*y[0] y[2]*y[2]; float det A * D - B * C; if (fabs(det) 1e-6) return false; *outX (E * D - B * F) / det; *outY (A * F - E * C) / det; // 合理性检查 if (isnan(*outX) || isnan(*outY)) return false; if (*outX -5 || *outX 15 || *outY -5 || *outY 15) return false; return true; }克拉默法则计算量极小ESP32执行一次不到1毫秒。代码里额外做了坐标合理性检查避免某个距离突然变大导致解算结果跑到部署区域外面。速率限制的逻辑也在loop()里防止坐标“跳崖”。4.3 实际定位效果静置测试和移动测试这套代码跑通以后我在一个6米×6米的房间里做了测试。三个信标分别放在(0,0)、(6,0)、(0,6)三个点移动端放在中心点(3,3)附近静置连续输出2分钟坐标结果的散布范围大概在半径0.4到0.7米的圆内。移动测试时人拿着移动端沿着直线走路径上的坐标点能形成一条大致平行的轨迹但每走一步都有一定抖动。整体手感是判断“人在哪个区域”完全够用但要精确定位到某一把椅子上还差点意思。这也是蓝牙RSSI方案的真实天花板。5. 实测优化与避坑把定位精度从“能用”调到“够用”代码跑通只是第一步真正花时间的往往是调试环境中的各种意外。下面这几个问题我踩坑踩得最狠提前列出来能帮你少走弯路。5.1 人脸朝着信标走RSSI却在掉第一次实测时我拿着移动端走向信标串口打印出来的RSSI没有持续增大反而忽高忽低一度跌到比远处还低。排查了半天发现是人体遮挡方向的问题——移动端被我的身体挡在信标和板子之间人体吸收了大部分信号。这个问题的解决方式不是换硬件而是调整部署策略信标尽量架高到2米以上减少人体直接遮挡的可能移动端不要贴身握持放在高于腰部的位置比如背包肩带上或手持举到胸前测试路线设计时尽量避免让身体处于信标和移动端的连线上。人体遮挡导致的RSSI衰减是4到8dBm量级的这已经远大于算法本身能修正的范围。物理层面的规避比任何滤波都有效。5.2 天线板方向和金属支架是隐蔽的RSSI吞噬者ESP32的开发板天线一般是PCB天线板子本身的铺铜、芯片金属罩都会对天线方向图产生影响。实际测试时同一块板子竖直放置和水平放置在2米处的RSSI可以差5dBm。另外如果信标直接用金属三脚架固定天线靠近金属时会出现严重的阻抗失配RSSI可能整体衰减好几个dBm。我的建议是信标和移动端都保持相同的姿态固定时用塑料或者木质支架离金属结构至少10厘米以上。标定时是什么姿态后面实测就保持什么姿态这是保证标定参数有效的底线。5.3 扫描窗口和广播间隔的配合问题前期调试时我遇到过扫描端经常漏掉某一个信标的情况表现为串口半天不输出坐标。一开始以为是代码问题后来查了BLE协议特性才发现广播包的发送是周期性的如果扫描窗口正好落在广播间隔的间隙里就会发生漏检。解决方法是把广播间隔设短同时把扫描窗口设得尽量连续。比如广播间隔100到150毫秒扫描间隔100毫秒、扫描窗口99毫秒这样扫描器几乎处于连续监听状态。代价是功耗上升但定位场景下移动端本来就由充电宝供电功耗不是首要矛盾。如果做成电池供电的可穿戴标签就需要重新权衡这些参数。5.4 想要更准除了加钱和加算法还能加信标三边定位是这套系统的基础版本但它对测距误差几乎没有任何容忍能力。想进一步提高精度可以在部署区域增加第四个信标然后用加权最小二乘替代三边定位。所有信标参与解算距离越近的信标权重越高这样即便某一个距离测偏了解算结果也不会被完全带跑。如果应用场景相对固定比如同一个房间长期使用更推荐指纹定位方案先离线采集网格点的RSSI分布在线定位时用最近邻算法匹配。指纹定位在同一个环境里的稳定性通常优于三边定位但部署成本要高出一个量级需要根据项目需求权衡。另外提一个工程细节调试阶段要养成记录日志的习惯。每次移动端输出坐标时同时把三个原始RSSI值打到串口定位异常时才能判断究竟是哪个信标的数据出了问题。我见过不少项目最后查不出问题就是因为只留了一个坐标结果原始数据都被丢了。这套系统跑通到现在我再回看标题里“厘米级”这个词感触更深。蓝牙RSSI定位的价值不在于挑战物理极限而在于用极低的成本换来“大致知道你在哪”的能力。对于货物流转、人员区域管理、导览讲解这类场景它已经足够形成闭环。如果你后续要在真实产品里做到二三十厘米的稳定精度更现实的路径是换UWB或者加指纹库但在那之前先用蓝牙把定位逻辑和技术链路走通会是个试错成本很低的起点。