ROS节点本质：从进程到自治智能体的系统级认知 1. 什么是ROS节点——从“程序进程”到“系统角色”的认知跃迁如果你刚接触ROSRobot Operating System看到“节点”Node这个词第一反应可能是“不就是个运行的程序吗”——这没错但远远不够。我带过几十个零基础的机器人方向实习生几乎所有人最初都卡在这一步他们能照着教程敲出rosrun turtlesim turtlesim_node看到小海龟窗口弹出来却说不清“这个窗口背后到底发生了什么”。真正的理解不是记住定义而是看清它在整套机器人系统中扮演的角色。ROS节点本质上是一个具备明确身份、独立生命周期、遵循统一通信契约的最小可执行单元。它不是孤立的进程而是整个ROS计算图Computation Graph里的一个活的“细胞”。这个细胞必须注册到ROS Master主节点上声明自己能发布哪些话题Topic、能订阅哪些话题、能提供哪些服务Service、能调用哪些服务——就像新员工入职要填《岗位职责说明书》和《通讯录登记表》一样。没有这份“注册声明”它就只是操作系统里一个默默无闻的进程无法被ROS生态识别、调度和协同。这也是为什么你直接用./my_node运行一个可执行文件ROS系统完全“看不见”它而必须用rosrun或roslaunch启动因为这两个命令背后是自动帮你完成了向Master注册、参数加载、日志配置等一系列“入职手续”。理解这一点你就抓住了ROS设计哲学的核心去中心化协作而非集中式控制。每个节点只关心自己该做什么、和谁说话、说什么话不需要知道整个系统有多少节点、它们在哪台机器上运行——这种松耦合正是ROS能支撑从单片机小车到多臂协作机械臂复杂系统的底层逻辑。对初学者而言把“节点”当成“有身份证、有通讯录、有岗位职责的智能体”比当成“一个C/Python程序”更能建立正确的系统观。它解决的根本问题是让成百上千个异构程序视觉处理、激光建图、运动规划、语音识别能在同一台机器人或分布式集群中像一支训练有素的军队那样各司其职、无缝协同。2. 节点设计与实现为什么必须用ros::init()和ros::spin()2.1 ros::init()节点的“出生证明”与“社会关系网”初始化很多新手写完第一个节点代码编译通过一运行就报错[ERROR] [1715823456.123456]: Failed to contact master然后开始疯狂查网络配置、防火墙、IP地址。其实90%的情况问题出在ros::init()这一行。它绝不仅仅是个“初始化函数”而是节点在ROS世界里的“出生仪式”。我们来看标准C节点的开头int main(int argc, char **argv) { ros::init(argc, argv, my_first_node); ros::NodeHandle nh; // ... 后续代码 }这里ros::init()做了三件关键且不可替代的事解析命令行参数它会自动识别并处理ROS特有的参数比如__name:new_name重命名节点、__ns:/my_robot指定命名空间、__log:/path/to/log指定日志路径。如果你跳过ros::init()这些参数就完全失效节点名永远是你代码里写的硬编码调试时想临时改个名字都做不到。连接ROS Master这是最常被误解的一点。ros::init()本身并不建立网络连接但它为后续所有ROS API调用如advertise()、subscribe()准备好了连接上下文。它会读取环境变量ROS_MASTER_URI默认是http://localhost:11311并创建一个内部的NodeHandle管理器。真正发起TCP连接的是NodeHandle的构造函数或者第一次调用advertise()/subscribe()时。但如果没有ros::init()NodeHandle根本无法正确初始化整个通信链路就断了。你可以把它想象成ros::init()是去派出所办户口本NodeHandle是拿着户口本去银行开户——没户口本银行根本不认你。设置节点元信息它将你传入的第三个参数my_first_node作为节点的默认名称并将其注册到ROS Master的节点列表中。这个名称是全局唯一的也是你在rosnode list、rqt_graph里看到的名字。更重要的是它还设置了节点的命名空间Namespace默认是/但你可以通过__ns参数或NodeHandle的构造函数来改变。命名空间是ROS组织大型系统的关键机制比如所有底盘控制相关的节点可以放在/base下所有机械臂节点放在/arm下避免名称冲突也方便批量操作rosnode kill /base/*。提示ros::init()必须在main()函数最开始调用且只能调用一次。我见过太多人把它放在某个条件判断里或者在循环里反复调用结果导致节点注册失败或内存泄漏。它就像人的出生只有一次且必须在生命开始时完成。2.2 ros::spin()节点的“心跳”与“事件循环”驱动器另一个高频错误是节点程序启动后立刻退出rosnode list里一闪而过就没了。原因几乎都是忘了加ros::spin()。它的作用是让节点进入一个阻塞式的事件循环持续监听来自ROS Master和其他节点的消息、服务请求、参数更新等事件并分发给对应的回调函数Callback。没有它你的main()函数执行完最后一行进程就自然结束了。int main(int argc, char **argv) { ros::init(argc, argv, my_first_node); ros::NodeHandle nh; ros::Publisher pub nh.advertisestd_msgs::String(chatter, 10); ros::Rate loop_rate(10); // 10Hz int count 0; while (ros::ok()) { // 这是另一种写法但本质相同 std_msgs::String msg; msg.data Hello World std::to_string(count); pub.publish(msg); ROS_INFO(Published: %s, msg.data.c_str()); loop_rate.sleep(); } return 0; }上面这段代码用的是while (ros::ok())循环它和ros::spin()是两种等效的模式ros::spin()适用于纯事件驱动的节点即所有逻辑都由回调函数触发比如一个只订阅激光雷达数据并发布障碍物信息的节点。它内部是一个无限循环调用ros::getGlobalCallbackQueue()-callAvailable(ros::WallDuration(0.1))等待并执行所有已注册的回调。优点是CPU占用极低空闲时几乎不耗资源代码简洁缺点是无法在主循环里做周期性任务比如每秒发一次心跳包。while (ros::ok())ros::Rate适用于混合驱动的节点即既有事件回调又有固定周期的任务比如既要处理传感器数据又要每100ms发一次电机控制指令。ros::ok()检查节点是否被rosnode kill或CtrlC终止ros::Rate则精确控制循环频率避免忙等待Busy Waiting吃光CPU。这是工业级节点最常用的模式因为它给了你完全的控制权。注意ros::spin()和ros::spinOnce()是两回事。spinOnce()只执行一次“检查所有回调并执行”通常用在需要与其他框架如OpenCV GUI线程、Qt事件循环集成的场景你得自己在外面套一个循环。对初学者强烈建议先用ros::spin()或while (ros::ok())避免陷入复杂的线程同步陷阱。3. 节点通信机制深度解析话题、服务与参数服务器的协同逻辑3.1 话题Topic一对多的“广播电台”与“收音机”ROS中最常用、最基础的通信方式是话题Topic。它的模型非常直观一个节点Publisher像电台一样持续不断地向一个名为/scan的频道“广播”激光雷达数据其他任意数量的节点Subscriber只要调谐到这个/scan频道就能实时“收听”到这些数据。这种一对多、异步、无连接的特性让它成为传感器数据分发的黄金标准。但背后的实现细节决定了你的节点是否健壮。当你调用nh.advertisesensor_msgs::LaserScan(/scan, 10)时数字10不是“发送10次”而是发布队列的长度。ROS内部为每个Publisher维护一个缓冲区当Subscriber处理速度跟不上Publisher发送速度时旧的数据会被丢弃只保留最新的10条。这个值的选择是性能与可靠性的权衡设得太小如1Subscriber稍一卡顿最新数据就被覆盖可能错过关键帧。设得太大如1000内存占用飙升尤其在高频率如IMU 1000Hz下几秒就吃掉几百MB内存。我实际调试一个SLAM建图节点时发现它在复杂环境下频繁丢帧。排查后发现它的激光雷达Publisher队列设为了100但Subscriberslam_gmapping的处理延迟波动很大平均要150ms。这意味着队列里永远堆着15帧数据一旦网络抖动新数据进不来老数据又来不及处理最终导致建图漂移。解决方案不是盲目加大队列而是将队列设为1只保留最新一帧并在Subscriber端用message_filters库做时间戳同步确保拿到的是“当前时刻”最匹配的多源数据。这才是工程上的正解。实操心得对于传感器数据/scan,/image_rawPublisher队列长度建议设为1或5强制Subscriber必须跟上节奏对于状态信息/robot_status,/battery可以设为10允许一定延迟。3.2 服务Service一对一的“电话呼叫”与“即时响应”当话题的“广播”模式不够用时你就需要服务Service。想象一下你想让机器人“立即停止所有运动”这不是一个持续的状态而是一个瞬时的、需要确认的指令。话题做不到因为Subscriber可能刚好没在监听或者消息被丢弃了。服务则不同它是一次完整的“请求-响应”Request-Response交互类似打电话Client节点调用方向Server节点服务方发起一个StopCommand.srv请求。Server节点收到后执行停止逻辑如置零电机PWM然后打包一个StopCommandResponse返回。Client节点收到响应才确认指令已成功执行。这个过程是同步、阻塞、有保证的。ros::service::call()会一直等待直到收到响应或超时。这带来了确定性但也带来了风险如果Server节点崩溃或网络中断Client会一直卡在call()里整个程序就僵死了。因此工业级设计必须加入超时和异常处理// C 示例带超时的服务调用 std_srvs::Trigger srv; bool success ros::service::call(/stop_motor, srv, ros::Duration(2.0)); if (!success) { ROS_WARN(Failed to call /stop_motor service. Timeout or server not available.); // 执行降级策略如直接发空控制指令 } else if (!srv.response.success) { ROS_ERROR(Service /stop_motor reported failure: %s, srv.response.message.c_str()); }这里ros::Duration(2.0)指定了2秒超时srv.response.success是服务定义里约定的返回字段。我曾在一个AGV项目中因未加超时一个临时离线的导航服务导致上位机监控程序全线卡死排查了三天才发现根源在这里。所以任何服务调用必须配超时必须判响应这是铁律。3.3 参数服务器Parameter Server全系统的“中央数据库”最后是参数服务器Parameter Server它是ROS的“全局配置中心”。所有节点都可以从中读取getParam()或写入setParam()键值对比如/robot/max_velocity、/camera/exposure_time。它解决了硬编码参数的噩梦你不用为了改一个速度值就重新编译整个系统只需rosparam set /robot/max_velocity 0.5所有订阅了该参数的节点会立刻生效前提是它们用了param()的动态重载机制。但它的局限性也很明显它不是为高频数据设计的。参数服务器基于XML-RPC协议每次读写都有网络开销。如果你在一个100Hz的控制循环里每周期都getParam(/pid/kp)性能会断崖式下跌。正确的做法是在节点初始化时onInit()或main()开头一次性读取所有参数到本地变量后续直接使用本地变量。只有在需要动态调整时如通过rqt_reconfigure界面才监听参数变化的回调。常见误区有人把大量传感器原始数据如整张图像存到参数服务器这是灾难性的。参数服务器只适合存储静态、低频、小体积的配置项数据流必须走话题或服务。4. 实操全流程从零编写、编译、调试一个完整ROS节点4.1 环境准备与工作空间搭建以ROS Noetic为例在开始写代码前确保你的Ubuntu 20.04系统已正确安装ROS Noetic。验证方法$ rosversion -d noetic $ echo $ROS_PACKAGE_PATH /home/yourname/catkin_ws/src:/opt/ros/noetic/share如果$ROS_PACKAGE_PATH为空或不包含/opt/ros/noetic/share说明环境变量没source执行$ source /opt/ros/noetic/setup.bash接下来创建一个标准的catkin工作空间Workspace。这是ROS项目的“容器”所有自定义包都放在这里$ mkdir -p ~/catkin_ws/src $ cd ~/catkin_ws $ catkin_make $ source devel/setup.bashcatkin_make会生成devel/和build/两个目录。devel/里存放编译好的可执行文件和脚本source devel/setup.bash就是把它们加入你的PATH和ROS_PACKAGE_PATH。这一步至关重要漏掉它你的节点rosrun找不到。注意catkin_make必须在工作空间根目录~/catkin_ws下执行不能在src/里。我见过太多人cd进src/然后catkin_make结果报错Could not find a package configuration file就是因为路径错了。4.2 创建功能包Package与节点骨架ROS的一切都围绕“包”Package展开。一个包是功能的最小集合单位包含节点、消息、服务、配置等。用catkin_create_pkg命令创建$ cd ~/catkin_ws/src $ catkin_create_pkg my_first_pkg std_msgs rospy roscpp这条命令创建了一个名为my_first_pkg的包依赖std_msgs标准消息类型、rospyPython客户端库、roscppC客户端库。现在你的目录结构是~/catkin_ws/ ├── src/ │ └── my_first_pkg/ │ ├── CMakeLists.txt # C编译规则 │ ├── package.xml # 包元信息作者、依赖、描述 │ └── ...接着创建C节点文件。按惯例节点源码放在src/子目录下$ mkdir -p ~/catkin_ws/src/my_first_pkg/src $ touch ~/catkin_ws/src/my_first_pkg/src/talker.cpp用你喜欢的编辑器如gedit、vscode打开talker.cpp填入标准模板#include ros/ros.h #include std_msgs/String.h int main(int argc, char **argv) { // 初始化ROS指定节点名 ros::init(argc, argv, talker); // 创建节点句柄 ros::NodeHandle nh; // 创建Publisher发布到/chatter话题队列长度10 ros::Publisher pub nh.advertisestd_msgs::String(chatter, 10); // 设置发布频率为10Hz ros::Rate loop_rate(10); int count 0; while (ros::ok()) { // 构造消息 std_msgs::String msg; msg.data Hello World std::to_string(count); // 发布消息 pub.publish(msg); ROS_INFO(Published: %s, msg.data.c_str()); // 按照设定频率休眠 loop_rate.sleep(); } return 0; }4.3 配置CMakeLists.txt与编译光有源码还不够必须告诉编译器怎么编译它。编辑~/catkin_ws/src/my_first_pkg/CMakeLists.txt找到## Declare a cpp executable部分取消注释并修改## Declare a cpp executable add_executable(talker src/talker.cpp) target_link_libraries(talker ${catkin_LIBRARIES}) add_dependencies(talker my_first_pkg_generate_messages_cpp)这里add_executable(talker ...)定义了可执行文件名talkertarget_link_libraries链接了所有依赖库add_dependencies确保消息生成器如果有自定义消息先于talker编译。保存后回到工作空间根目录编译$ cd ~/catkin_ws $ catkin_make如果一切顺利你会看到[100%] Built target talker。编译产物在devel/lib/my_first_pkg/下你可以直接运行$ ./devel/lib/my_first_pkg/talker但更标准的方式是用rosrun$ rosrun my_first_pkg talkerrosrun会自动查找devel/lib/下的可执行文件并注入ROS环境变量是调试的首选。4.4 调试与可视化用工具链看清节点的“生命体征”写完节点下一步是验证它是否按预期工作。ROS提供了强大的调试工具链rosnode list查看所有活跃节点。你应该能看到/talker。rostopic list查看所有活跃话题。你应该能看到/chatter。rostopic echo /chatter实时打印/chatter话题的消息内容验证发布是否正常。rqt_graph图形化显示节点与话题的连接关系。启动它你会看到一个圆圈/talker指向一条线/chatter直观展示数据流向。实操技巧rqt_graph默认只显示活跃连接。如果节点刚启动还没发数据它可能不显示。此时先rostopic echo /chatter触发一下再刷新rqt_graph。另外rqt_graph支持右键节点选择“Hide Node”可以过滤掉/rosout等系统节点让图更清晰。5. 常见问题与避坑指南那些年我们踩过的“节点”深坑5.1 “节点名冲突”与“命名空间污染”一场静默的灾难现象你启动了两个相同的节点rosnode list里只显示一个或者rostopic list里出现/my_robot/chatter和/chatter两个同名话题但订阅者收不到数据。原因ROS节点名必须全局唯一。当你用rosrun my_pkg talker启动节点名默认是talker。如果已经有一个talker在运行新的rosrun会静默地复用已有的节点名而不是报错。更糟的是如果两个节点都试图发布到/chatter它们会互相竞争导致数据混乱。解决方案永远显式指定节点名。用__name参数$ rosrun my_pkg talker __name:talker_1 $ rosrun my_pkg talker __name:talker_2或者在代码里用ros::init()的第三个参数动态生成唯一名std::string node_name talker_ std::to_string(getpid()); ros::init(argc, argv, node_name.c_str());对于大型系统强制使用命名空间是更优雅的方案。在roslaunch文件中launch group nsrobot1 node pkgmy_pkg typetalker nametalker / /group group nsrobot2 node pkgmy_pkg typetalker nametalker / /group /launch这样两个talker分别在/robot1/chatter和/robot2/chatter下彻底隔离。5.2 “回调函数阻塞”让整个ROS系统窒息的定时炸弹现象你的节点能发布数据但rqt_plot显示曲线断断续续或者rosnode info /talker显示Subscriptions: 0明明有Subscriber在监听。原因你在回调函数里做了耗时操作。例如在一个图像处理节点的image_callback()里直接调用cv::imwrite()保存图片到硬盘。硬盘I/O可能耗时100ms而图像话题是30Hz33ms一帧结果就是第1帧进来开始保存第2帧进来发现回调还在执行被丢弃第3帧同理……最终90%的数据都被丢弃了。解决方案回调函数必须轻量、非阻塞。所有耗时操作文件IO、网络请求、复杂计算必须放到独立线程或异步队列中。标准做法是在回调里只做最快速的操作拷贝数据、时间戳记录、放入std::queue。在主循环while (ros::ok())里从队列取数据交给工作线程处理。// 全局队列 std::queuesensor_msgs::Image::Ptr image_queue; std::mutex queue_mutex; void image_callback(const sensor_msgs::Image::ConstPtr msg) { std::lock_guardstd::mutex lock(queue_mutex); image_queue.push(std::make_sharedsensor_msgs::Image(*msg)); // 深拷贝 } int main(...) { // ... init, publisher, subscriber ... while (ros::ok()) { // 从队列取数据 sensor_msgs::Image::Ptr img_ptr; { std::lock_guardstd::mutex lock(queue_mutex); if (!image_queue.empty()) { img_ptr image_queue.front(); image_queue.pop(); } } if (img_ptr) { // 在这里做耗时的图像处理 process_image(*img_ptr); } loop_rate.sleep(); } }我的血泪教训在一个无人机视觉项目中因在回调里直接调用OpenCV的cv::findContours()导致图像处理延迟从5ms飙升到200ms最终飞控信号严重滞后差点炸机。从此我把“回调函数里禁止任何超过1ms的计算”写进了团队开发规范。5.3 “节点生命周期管理”如何优雅地“关机”现象你用CtrlC结束节点但rosnode list里节点名还在或者rostopic info /chatter显示Publisher为NoneSubscriber却还连着。原因CtrlC发送SIGINT信号ROS的ros::ok()会捕获并置为false但如果你的节点在sleep()或call()里阻塞它可能无法及时响应。更常见的是节点在退出前没有清理资源如关闭串口、释放GPU内存导致下次启动失败。解决方案注册信号处理函数做优雅退出。在main()开头添加#include signal.h #include iostream volatile sig_atomic_t g_shutdown_flag 0; void signalHandler(int signum) { ROS_INFO(Caught signal %d, shutting down..., signum); g_shutdown_flag 1; } int main(...) { signal(SIGINT, signalHandler); signal(SIGTERM, signalHandler); ros::init(argc, argv, my_node); ros::NodeHandle nh; // ... your code ... while (ros::ok() !g_shutdown_flag) { // main loop ros::spinOnce(); loop_rate.sleep(); } // 清理代码 ROS_INFO(Cleaning up...); close_serial_port(); // 伪代码 release_gpu_memory(); // 伪代码 return 0; }这样无论你是CtrlC还是rosnode kill节点都能执行完清理逻辑再退出避免资源泄露。6. 节点进阶从单机到分布式理解节点的物理边界与网络拓扑6.1 单机模式默认的“localhost”信任域在默认配置下所有ROS节点都运行在同一台机器上通过localhost127.0.0.1连接ROS Master。这是最简单、最安全的模式也是所有初学者的起点。Master的URL由环境变量ROS_MASTER_URI决定默认是http://localhost:11311。在这种模式下节点间的通信走的是本地回环loopback网络延迟极低微秒级带宽极高GBps几乎不存在网络问题。但这也带来一个隐含假设所有节点都信任彼此且共享同一个时钟。ROS的时间戳ros::Time::now()默认使用系统时钟CLOCK_REALTIME。如果两个节点运行在不同机器上而它们的系统时间不同步那么/tf坐标变换树就会错乱message_filters的时间同步会失败SLAM建图会漂移。这就是为什么分布式部署的第一步永远是时间同步。6.2 分布式模式跨机器协作的三要素当你需要把视觉处理放在高性能GPU服务器上而把运动控制放在嵌入式ARM板上时就必须进入分布式模式。这需要同时配置三台机器A: Master, B: Publisher, C: Subscriber统一Master选择一台稳定的机器通常是工控机或服务器作为Master。在它上面设置ROS_MASTER_URIhttp://MASTER_IP:11311并确保ROS_IPMASTER_IP注意是ROS_IP不是ROS_HOSTNAME后者在DNS不稳定时会出问题。网络互通所有机器必须能互相ping通且防火墙开放11311端口Master和随机高端口节点间通信。在B和C上设置export ROS_MASTER_URIhttp://MASTER_IP:11311 export ROS_IPB_IP # 在B机器上 export ROS_IPC_IP # 在C机器上时间同步NTP这是最容易被忽视、却最致命的一环。在所有机器上安装并配置NTP$ sudo apt install ntp $ sudo systemctl enable ntp $ sudo systemctl start ntp然后用ntpq -p检查同步状态确保*号指向的服务器是有效的。我曾在一个多机器人编队项目中因一台树莓派的NTP服务未启动导致其时间慢了3秒结果所有机器人的/tf变换全部错位编队瞬间崩溃。修复后rosrun tf view_frames生成的PDF里坐标系树才变得清晰稳定。关键提醒ROS_IP必须设置为机器的真实IP地址不能是127.0.0.1或localhost。否则其他机器会尝试连接127.0.0.1也就是它自己导致连接失败。这是一个新手100%会踩的坑。6.3 容器化部署Docker与ROS节点的现代实践随着机器人系统越来越复杂依赖管理OpenCV版本、CUDA驱动、Python包成了新痛点。Docker提供了完美的解决方案把节点及其所有依赖打包成镜像一键部署到任何Linux机器上。一个典型的Dockerfile如下FROM ros:noetic-ros-base # 复制工作空间 COPY catkin_ws /root/catkin_ws # 安装依赖 RUN cd /root/catkin_ws rosdep install --from-paths src --ignore-src -r -y # 编译 RUN cd /root/catkin_ws catkin_make # 设置环境 ENV ROS_MASTER_URIhttp://host.docker.internal:11311 ENV ROS_IPhost.docker.internal # 启动节点 CMD [roslaunch, my_first_pkg, my_launch_file.launch]这里的关键是host.docker.internal它是Docker为容器提供的特殊DNS指向宿主机。这样容器内的节点就能无缝连接宿主机上的ROS Master无需手动配置IP。我们团队现在所有新项目都采用Docker部署开发、测试、交付环境完全一致彻底告别了“在我机器上是好的”这类经典甩锅语句。7. 总结与延伸节点不是终点而是ROS系统思维的起点写到这里你应该已经明白“理解ROS节点”远不止是学会ros::init()和ros::spin()。它是一把钥匙开启了整个ROS系统架构的大门。每一个节点都是一个自治的、有边界的“微服务”它们通过话题、服务、参数服务器这三根“神经”编织成一张动态的、可伸缩的计算图。这种设计让ROS既能跑在树莓派上控制一个轮式小车也能调度上百个节点在集群中完成无人配送的全栈任务。对我个人而言从第一次在turtlesim里让小海龟画圆到后来主导一个12自由度仿人机器人的全身协调控制节点的概念始终是基石。我逐渐意识到写好一个节点70%的功夫在设计30%在编码。设计时要想清楚它要和谁通信数据频率多高容错要求多严生命周期如何管理这些思考比纠结于ros::spinOnce()和ros::spin()的区别重要得多。最后分享一个小技巧当你面对一个复杂的ROS系统不知从何下手时不要急着看代码先运行rqt_graph然后点击All Nodes和All Topics把整个计算图导出为PDF。拿一张白纸在图上用红笔标出数据流的主干道比如/camera/image_raw-/darknet_ros/detections-/move_base_simple/goal再用蓝笔标出控制流/cmd_vel-/move_base/cmd_vel-/navfn/path。这张图就是你理解整个系统的地图。节点就是地图上的每一个坐标点。理解了点才能看清线最终掌握面。这条路没有捷径但每一次亲手编译、调试、修复一个节点你都在把抽象的ROS概念锻造成自己肌肉记忆的一部分。坚持下去那个曾经让你困惑的“节点”终将成为你构建智能机器的最可靠砖石。