第一项要验收的是机械和运动边界。底盘空载行走和带上设备后的表现可能完全不同。加上传感器支架、屏幕、电池、外壳或上层机构后，重心会变化，轮胎抓地、悬挂压缩、转弯半径、刹车距离都会变化。验收时不能只在平整地面跑直线，要测试不同速度下的启停、原地旋转、窄通道通过、坡度或地面接缝、低速跟随和长时间连续运行。判断标准应写成可复测的条件，例如最大速度、最低稳定速度、转弯半径、定位丢失后的恢复方式，而不是一句“运行平稳”。

第二项是传感器安装和标定。激光雷达、深度相机、IMU、轮速编码器和碰撞传感器都依赖安装位置。雷达高度太低会被地面杂物干扰，太高又可能看不到低矮障碍；深度相机受光照、反光材质和视场角影响明显；IMU 如果和底盘坐标系关系不清楚，融合定位会出现慢性漂移。验收时要确认 TF 树、坐标方向、安装刚性、线束固定和遮挡范围，不能只看传感器“有数据”。一旦外壳或上层结构改动，传感器视野还要重新复核。

第三项是电源和安全。移动机器人底盘的电源系统要覆盖电机峰值电流、控制器供电、传感器供电、工控机或嵌入式主机供电，以及充电和电量估算。电池电压下降后，导航性能可能没问题，但电机驱动保护、主机重启或通信模块掉线会让整机不可控。急停、保险、过流保护、低电量策略和手动拖车模式必须在样机验收中验证。特别是面向公共空间的机器人，急停按钮的位置、碰撞边条、速度限制和异常状态提示都要被纳入工程判断。

第四项是 ROS 软件栈的可维护性。验收不是只看一次 launch 成功，而要看节点启动顺序、参数管理、日志记录、异常重启、远程诊断和版本固化。地图文件、导航参数、传感器驱动版本、底盘固件版本都应能追溯。现场调试时经常需要回答几个问题：为什么这次定位失败，为什么某个区域绕不过去，为什么速度突然降下来，为什么运行半小时后通信中断。如果系统没有日志和状态监控，只能靠现场人员猜，后续维护成本会很高。

第五项是应用负载接口。很多项目把底盘当作“会移动的平台”，但真正产品化时还要接屏幕、机械臂、灯光、语音、扫码、上位机后台或小程序。底盘控制接口要明确：速度控制频率是多少，任务状态如何反馈，急停和避障是否能打断上层任务，断网后本地策略是什么，远程后台下发任务失败时如何恢复。底盘样机验收阶段如果不定义这些接口，后续应用开发会把大量时间花在协议补丁和状态同步上。

落地验证可以分三轮做。第一轮在工作室做基础运动、电气和传感器标定；第二轮在接近真实场地的路径中做导航、避障、负载和连续运行；第三轮让非开发人员按照操作流程启动、停止、充电、恢复异常和读取状态。只有开发人员能跑起来的系统，不能算真正通过验收。验收记录应包含测试条件、参数版本、问题清单和下一版修改项，避免“演示过了”但没有工程证据。

初拓做机器人样机和 ROS 控制系统开发时，会把底盘结构、电气安全、传感器安装、ROS 节点、上位机或后台接口一起联调。这样可以更早判断底盘是否适合目标场景，也能让后续视觉、交互、任务调度和外观结构开发有稳定基础。