1. 项目概述为什么Setup Assistant是MoveIt!学习路上第一个真正意义上的“拦路虎”刚接触ROS机器人运动规划时很多人以为装完moveit包、跑通demo.launch就算入门了。我带过十几届高校机器人社团和企业内训班90%的新手在第一次尝试为自己的机械臂配置自定义运动规划功能时卡死在同一个地方——不是代码报错不是编译失败而是根本不知道从哪开始写那个叫my_robot_moveit_config的包。他们翻遍官方Wiki看到“Use the Setup Assistant”这行字点开GUI界面后盯着六个标签页发呆Self-Collisions里勾选框密密麻麻像Excel表格Planning Groups里关节链怎么连才算合理Virtual Joints到底要不要加……最后默默关掉窗口转头去抄别人现成的配置包改几个名字就硬上结果仿真里机械臂自己拧成麻花实机运行时关节限位全错急得直拍桌子。这就是Setup Assistant的真实定位它不是个“一键生成”的傻瓜工具而是一套把运动规划领域三十年工程经验压缩进图形界面的决策引导系统。你每点一次“Next”背后都在回答一个专业问题你的机械臂工作空间是否包含狭窄通道末端执行器是否需要多自由度姿态解耦基座是否固定或可移动这些选择直接决定后续所有规划器的行为边界。我见过太多人跳过Setup Assistant直接手写SRDF和URDF片段结果在move_group节点启动时爆出27个XML解析错误查日志发现连最基础的joint limit单位都写反了用deg写了rad。所以别把它当成配置“前端”它本质是运动规划知识图谱的交互式入口——你填的不是参数是在构建自己对机器人构型、约束、任务边界的认知模型。本文不讲“怎么点按钮”而是带你拆解Setup Assistant每个页面背后的物理含义、工程权衡和真实踩坑现场让你下次打开它时心里清楚每一处勾选意味着什么。2. 核心设计逻辑与方案选型深度解析2.1 为什么必须用Setup Assistant手写配置包的代价有多高先说结论对于任何非标准构型的机械臂即不是UR5、Franka等官方预置型号跳过Setup Assistant的手写配置等于在没学微积分的情况下直接解偏微分方程。这不是危言耸听而是基于ROS社区十年实践的血泪总结。我们来算一笔账。一个中等复杂度的6-DOF机械臂要完成完整MoveIt!配置需手动编写/校验以下文件config/joint_limits.yaml需精确到小数点后三位的关节速度、加速度、力矩限值且必须与电机驱动器实际参数严格匹配config/kinematics.yaml为每个规划组选择IK求解器KDL、TRAC-IK、LMA并配置超参数如max_solver_iterations: 500config/ompl_planning.yamlOMPL算法参数矩阵仅RRTConnect一种算法就有12个关键参数需调优config/sensors_3d.yaml若用RealSense等深度相机需手动计算点云坐标系与base_link的TF变换偏差launch/move_group.launch需注入自定义的planning_pipeline和trajectory_execution参数稍有不慎就会导致move_group无法加载控制器。更致命的是隐性依赖关系。比如你在srdf里定义了一个gripper规划组但忘了在controllers.yaml里声明对应的gripper_controllermove_group启动时不会报错而是静默禁用该组——你调试半天发现抓取指令没响应最后发现是控制器名拼写少了个下划线。Setup Assistant的价值正在于它把上述所有环节封装成强约束的流程化向导。它强制你按顺序回答问题先确认URDF结构完整性自动检测未连接link再定义运动学链防止出现“手腕关节不在末端执行器坐标系内”的经典错误最后生成SRDF时会交叉验证所有关节限值是否在URDF定义范围内。我曾帮一家医疗机器人公司重构其手术臂配置他们原有手写配置包有47处参数不一致Setup Assistant在导入URDF后直接标红12个冲突项其中3个会导致规划器在特定姿态下直接崩溃。提示Setup Assistant不是万能的。它无法替代你对机器人硬件的理解。比如它不会告诉你“这个谐波减速器在15N·m负载下温升超过80℃需降频运行”但它会确保你填入的effort_limit值被所有规划器正确读取并参与约束计算。2.2 Setup Assistant的底层架构它到底在生成什么很多新手误以为Setup Assistant只是生成一堆YAML和XML文件。实际上它在构建一个四层约束金字塔每一层都依赖下层的正确性层级文件类型核心作用错误后果L1几何层URDF输入定义link质量、惯性张量、碰撞体积碰撞检测失效仿真重力异常L2拓扑层SRDF主输出定义规划组、禁用碰撞对、虚拟关节、末端执行器规划器找不到有效路径self-collision误报率超40%L3运动学层kinematics.yaml绑定IK求解器及参数末端位姿解算失败轨迹插值跳变L4规划层ompl_planning.yaml配置采样策略、距离度量、优化目标规划耗时从200ms飙升至8s或永远找不到解Setup Assistant的六个标签页正是按此层级递进设计Load Files校验L1层URDF语法与语义如检查joint是否都有parent和childSelf-Collisions基于L1的碰撞体积在L2层生成禁用对列表注意它用的是简化包围盒非精确网格Planning Groups将L1的关节链映射为L2的逻辑组同时注入L3的IK求解器绑定Robot Poses为L2的SRDF定义命名位姿如home、ready供后续move_group调用Virtual Joints在L2层添加基座运动约束如floating类型虚拟关节对应全向移动底盘Author Information生成L2/L3/L4文件的元数据作者、日期、版本便于团队协作追溯。关键洞察Setup Assistant生成的所有文件最终都服务于move_group节点的初始化过程。当你执行roslaunch my_robot_moveit_config move_group.launch时move_group会按固定顺序加载先读URDF→再读SRDF→然后载入kinematics.yaml→最后解析ompl_planning.yaml。Setup Assistant确保这个加载链中每个环节的输入格式合法、语义自洽。2.3 工具链选型逻辑为什么坚持用GUI而非命令行ROS社区存在两种配置方式GUI版Setup Assistantrosrun moveit_setup_assistant moveit_setup_assistant和命令行版moveit_configrosrun moveit_setup_assistant setup_assistant_cmdline.py。我坚持推荐GUI版原因有三第一实时可视化反馈不可替代。在Self-Collisions页点击“Regenerate Default Collision Matrix”后界面会动态渲染出所有link对的碰撞状态绿色启用检测红色禁用。你立刻能看到“base_link”和“wheel_link”这对被自动禁用——因为轮子本就会贴地滚动若启用检测会导致大量误报。这种视觉化决策命令行输出一长串[true/false]矩阵根本无法比拟。第二错误拦截前移。在Planning Groups页定义“arm”组时若你错误地将wrist_3_joint旋转关节和gripper_finger1_joint平移关节放在同一组Setup Assistant会弹窗警告“Joint types mismatch: rotational vs prismatic”。而命令行工具会在生成后才在move_group启动时报IK solver failed to initialize你得回溯排查半天。第三版本兼容性兜底。MoveIt!从Melodic到HumbleSRDF格式有细微变化如Humble要求disable_collisions必须带reason属性。GUI版内置了各ROS版本的模板引擎你选择ROS version后它自动生成符合规范的SRDF命令行版则需手动指定模板路径一不小心就生成Humble不兼容的文件。当然GUI版也有局限它无法批量处理多机械臂配置。这时我会用GUI生成单臂模板再用Python脚本基于xml.etree.ElementTree批量修改group名称和joint列表——但前提是你已通过GUI彻底理解了SRDF的结构逻辑。3. 实操全流程详解从URDF校验到配置包发布3.1 前置环境准备三个常被忽略的关键检查点在启动Setup Assistant前请务必完成以下三项检查。我统计过73%的Setup Assistant崩溃源于此处疏忽检查点1URDF必须通过check_urdf严格验证不要只满足于urdf_to_graphiz能画出树状图。执行check_urdf /path/to/your_robot.urdf重点观察输出末尾的ERROR和WARNING。常见陷阱WARNING: link base_link has no inertia specified虽不影响Setup Assistant启动但会导致Gazebo仿真中机械臂漂浮ERROR: joint shoulder_pan_joint has no parent linkSetup Assistant会直接闪退因它依赖URDF的完整父子关系链。检查点2确保所有mesh文件路径可访问Setup Assistant在Load Files页会加载URDF中的mesh filenamepackage://.../。若你用绝对路径如/home/user/meshes/base.dae且未设置ROS_PACKAGE_PATH界面会显示空白模型。正确做法将mesh放入your_robot_description/meshes/并在URDF中写package://your_robot_description/meshes/base.dae然后执行export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:/path/to/your_robot_description检查点3关闭所有占用ROS_MASTER_URI的进程Setup Assistant启动时会自动创建roscore。若你已运行其他ROS节点尤其rviz可能出现端口冲突。最稳妥方式# 先清理环境 killall -9 roscore rosout # 再启动Setup Assistant它会自动拉起新roscore rosrun moveit_setup_assistant moveit_setup_assistant注意Setup Assistant的GUI界面基于Qt若在Ubuntu 22.04上出现字体模糊执行export QT_SCALE_FACTOR1后再启动。3.2 Load Files页URDF解析的隐藏战场这是Setup Assistant的“安检门”表面简单实则暗藏玄机。操作步骤如下点击“Browse”选择URDF文件支持.urdf和.xacro点击“Load Files”界面右侧会显示机器人3D模型若mesh路径正确关键动作点击右下角“Edit URDF”按钮打开内置URDF编辑器。此时别急着点“Next”。请做三件事第一验证关节限值单位一致性。在URDF中查找所有limit标签joint nameelbow_joint typerevolute limit lower-2.35619 upper2.35619 effort33.0 velocity3.15/ /jointMoveIt!默认单位为弧度rad。若你的电机文档给的是角度deg必须手动转换如-135deg -2.35619rad。Setup Assistant不会帮你转换单位但会在后续Planning Groups页校验若你填的upper值大于2*PI它会警告“Joint limit exceeds 2π”。第二检查碰撞体积collision是否合理。展开左侧树状图找到link下的collision节点。对比visual中的mesh尺寸若collision用的是简化的box/cylinder其尺寸应略大于visual建议5mm否则仿真中会出现“穿模”现象机械臂看起来穿过障碍物。第三确认传动transmission定义完整。虽然Setup Assistant不直接使用transmission但move_group在实机控制时需此信息。检查是否存在transmission nameshoulder_pan_trans typetransmission_interface/SimpleTransmission/type joint nameshoulder_pan_joint/ actuator nameshoulder_pan_motor/ /transmission完成以上检查后点击“Next”。若URDF有严重错误如未闭合的robot标签Setup Assistant会弹窗报错并高亮错误行号——这是它比check_urdf更友好的地方。3.3 Self-Collisions页碰撞检测的精度与性能平衡术这是Setup Assistant中最易被误解的页面。新手常犯两个极端要么全选“Disable All”要么“Enable All”。真相是合理的碰撞矩阵是规划成功率与计算效率的黄金分割点。3.3.1 自动生成逻辑揭秘点击“Regenerate Default Collision Matrix”后Setup Assistant执行以下步骤对URDF中每对link计算其最小距离阈值基于碰撞体积的包围盒若两link在机器人典型工作姿态下永不接触如base_link与end_effector_link标记为disable若两link可能接触但无需检测如相邻手指link在抓取时本应接触标记为disable其余情况标记为enable。生成的矩阵以表格形式呈现行/列为link名称单元格颜色表示状态绿色启用碰撞检测默认红色禁用碰撞检测需人工确认灰色无意义组合如link与自身。3.3.2 必须人工干预的三类红标项类型1基座与移动部件如base_link与wheel_link、caster_wheel_link。Setup Assistant通常标红因轮子需贴地滚动。但若你的机器人是足式机器人base_link与foot_link在站立时必须接触则应改为绿色。类型2柔性部件如cable_link与arm_link。若电缆用软体建模其碰撞体积会随姿态变化Setup Assistant无法准确判断标红提示你需用disable_collisions手动排除。类型3末端执行器内部件如gripper_base_link与finger_link。在抓取时它们必然接触若启用检测会导致规划器拒绝所有抓取姿态。此时应保持红色并在SRDF中添加disable_collisions link1gripper_base_link link2finger_link reasonadjacent/实操心得我测试过某SCARA机械臂若将所有link对设为enable规划耗时增加3.2倍若过度disable如禁用shoulder_link与elbow_link仿真中出现关节自碰撞。最终采用“分区域策略”臂部链保持启用基座区域禁用耗时降低至1.3倍且无漏检。3.4 Planning Groups页运动学组的工程哲学这是Setup Assistant的核心战场。一个规划组Planning Group本质是对机器人自由度的逻辑切片其设计直接决定你能规划什么任务。3.4.1 组类型选择Chain vs End EffectorSetup Assistant提供两种创建模式Chain链式适用于串联机械臂。需指定Base Link如base_link和Tip Link如ee_link。它会自动提取两者间所有关节。End Effector末端执行器专为夹爪/吸盘设计。需指定Parent Group如arm组和EE Parent Frame如wrist_3_link。关键陷阱若你为6-DOF机械臂创建arm组时错误地将base_link设为Tip LinkSetup Assistant会反向提取关节链导致IK求解器计算出的姿态完全错误。正确做法始终让Tip Link是机械臂最远端link。3.4.2 IK求解器绑定TRAC-IK为何是首选在“Kinematic Solver”下拉菜单中你会看到KDLROS默认但对奇异位形敏感解算失败率高TRAC-IK基于KDL改进支持多目标优化如优先保持肘部朝上LMALevenberg-Marquardt算法精度高但计算慢。我强烈推荐TRAC-IK原因有二收敛性保障在kinematics.yaml中配置arm: kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin kinematics_solver_timeout: 0.05 kinematics_solver_attempts: 3timeout: 0.05确保单次求解不超过50ms避免阻塞规划循环参数可调TRAC-IK支持max_search_iterations和eps收敛精度Setup Assistant虽不提供GUI配置但生成的模板已预留注释位置。注意TRAC-IK需单独安装。在Ubuntu上执行sudo apt-get install ros-${ROS_DISTRO}-trac-ik-kinematics-plugin3.4.3 关节限值二次校验Setup Assistant会从URDF中读取limit值但某些场景需覆盖实机安全限值URDF中velocity3.15rad/s但电机驱动器实际限速为2.5rad/s此时应在joint_limits.yaml中手动覆盖任务特定限值如手术机器人要求腕部旋转范围限制在±90°-1.57~1.57rad即使电机支持±180°。Setup Assistant在生成joint_limits.yaml时会将URDF值作为默认你可在后续手动编辑。但记住move_group只读取joint_limits.yaml忽略URDF中的limit。3.5 Robot Poses页命名位姿的实战价值此页看似简单填几个位姿名称实则是提升开发效率的关键。每个命名位姿Named Pose会被写入SRDF的group_state标签供move_group的setNamedTarget()调用。3.5.1 必备位姿清单我建议至少定义以下4个位姿按重要性排序位姿名关节值示例使用场景Setup Assistant操作home[0,0,0,0,0,0]上电初始位姿避障最优在RVIZ中拖动模型到目标姿态→点击“Save Pose”ready[0,-0.5,0.5,0,0,0]抓取前预备姿态视野开阔同上但需确保末端朝向工作区中心stow[0,1.57,0.5,0,0,0]收纳姿态减少空间占用特别适用于移动机器人避免碰撞底盘calibration[0,0,0,0,0,0]标定姿态所有关节归零用于外参标定如相机-机械臂手眼标定关键技巧在RVIZ中调整姿态时按住Shift键拖动可实现平滑微调精度0.01rad避免粗暴拖拽导致关节超限。3.5.2 位姿保存的隐藏机制当你点击“Save Pose”Setup Assistant并非记录当前RVIZ视图而是读取/joint_states话题的实时值。因此务必确保joint_state_publisher节点正在运行若用Gazebo仿真需启动gazebo_ros_control插件否则/joint_states无数据。若保存后位姿名在RVIZ的“Select Goal State”下拉菜单中不显示检查my_robot_moveit_config/config/your_robot.srdf中是否生成了group_state namehome grouparm joint nameshoulder_pan_joint value0/ joint nameshoulder_lift_joint value0/ !-- ... -- /group_state3.6 Virtual Joints页移动基座的运动学建模此页专为移动机器人设计。若你的机器人是固定基座如桌面机械臂可跳过。但若含差速轮/全向轮底盘此处配置决定move_group能否规划“边走边抓”。3.6.1 虚拟关节类型选择Setup Assistant提供三种类型类型适用场景SRDF生成示例注意事项planar差速轮底盘X/Y/θvirtual_joint namevirtual_joint typeplanar parent_frameodom child_linkbase_link /parent_frame必须是odom或map不能是base_linkfloating全向轮/足式机器人X/Y/Z/roll/pitch/yawvirtual_joint namevirtual_joint typefloating parent_frameodom child_linkbase_link /计算量大建议在ompl_planning.yaml中为base组选用PRMstar算法fixed固定基座不推荐选此项virtual_joint namevirtual_joint typefixed parent_frameworld child_linkbase_link /与URDF中link namebase_link重复会导致TF树冲突3.6.2 坐标系对齐的生死线最关键的配置是parent_frame。它必须与机器人导航栈的定位坐标系严格一致若用amclmove_baseparent_frame应为map全局地图坐标系若用robot_localization融合IMU轮式里程计parent_frame应为odom里程计坐标系。错误示例某AGV公司配置parent_framebase_footprint导致move_group规划的路径在map坐标系中严重偏移。修正方法在tf树中添加静态变换rosrun tf static_transform_publisher 0 0 0 0 0 0 map base_footprint 1003.7 Author Information页配置包的可维护性基石最后一页看似无关紧要实则关乎团队协作。填写内容会写入所有生成文件的头部注释# Configuration generated by MoveIt! Setup Assistant # Author: Your Name # Date: 2023-10-15 # Package: my_robot_moveit_config为什么这很重要当多人协作时若A生成的配置包被B修改后未更新作者信息C接手时无法追溯原始设计意图。我曾遇到一个案例某机械臂的planning_groups被误删了gripper组因注释中写着“v1.0 by A”B以为这是初版缺陷不敢擅自恢复导致产线停机3小时。因此我强制团队执行每次重大修改如新增传感器、更换电机后更新Date和Author在README.md中记录每次变更的git commit hash和影响范围。4. 常见问题与排查技巧实录4.1 Setup Assistant启动失败五种高频场景及根治方案现象根本原因解决方案验证命令GUI窗口一闪而逝Qt库缺失或版本冲突Ubuntu 20.04执行sudo apt install ros-${ROS_DISTRO}-qt-gui-coreUbuntu 22.04需额外sudo apt install libqt5widgets5ldd $(rospack find moveit_setup_assistant)/lib/moveit_setup_assistant/moveit_setup_assistant3D模型显示为空白mesh路径错误或权限不足检查URDF中package://路径是否指向meshes/目录执行ls -l /path/to/meshes/确认文件可读rospack find your_robot_description确认包路径正确点击“Next”无响应URDF中存在gazebo标签Setup Assistant不解析Gazebo专用标签遇到gazebo会卡死临时重命名URDF为robot_no_gazebo.urdf删除所有gazebo块后再加载“Regenerate Default Collision Matrix”按钮灰显URDF未通过基础校验运行check_urdf修复所有ERROR如未闭合标签、重复link名check_urdf /path/to/robot.urdf 21RVIZ中无法拖动模型joint_state_publisher未运行启动独立节点rosrun joint_state_publisher joint_state_publisherrostopic echo /joint_states确认有数据输出实操心得我建立了一个setup_check.sh脚本每次启动Setup Assistant前自动运行#!/bin/bash echo Checking URDF check_urdf $1 | grep -E (ERROR|WARNING) echo Checking Mesh Paths grep package:// $1 | cut -d -f2 | xargs -I {} sh -c echo {} rospack find $(echo {} | cut -d/ -f3) echo Checking Joint States rostopic list | grep joint_states4.2 配置包生成后move_group启动失败核心日志分析法Setup Assistant生成的配置包看似完整但move_group启动失败率仍高达40%。以下是基于真实故障的日志分析指南4.2.1 日志关键词速查表日志关键词可能原因定位文件修复方案Failed to initialize OMPL interfaceompl_planning.yaml中算法名拼写错误config/ompl_planning.yaml检查planner_configs下是否定义了RRTConnectkConfigDefault注意大小写和下划线No kinematics solver loaded for group armkinematics.yaml中组名与SRDF不一致config/kinematics.yamlvsconfig/your_robot.srdf确保kinematics.yaml的顶层key如arm:与SRDF中group namearm完全相同Could not load controller arm_controllercontrollers.yaml中控制器名与move_group期望不符config/controllers.yamlmove_group默认查找group_name_controller若SRDF组名为manipulator控制器名必须为manipulator_controllerLink ee_link not found in modelSRDF中group的link引用了URDF不存在的linkconfig/your_robot.srdf执行rosrun urdfdom_headers check_urdf /path/to/robot.urdf确认所有link名拼写一致Parameter planning_plugin not setmove_group.launch未注入planning_plugin参数launch/move_group.launch在node pkgmoveit_ros_move_group typemove_group namemove_group内添加param nameplanning_plugin valueompl_interface/OMPLPlanner /4.2.2 三步诊断法从日志到修复第一步捕获完整日志不要只看终端最后一屏。执行roslaunch my_robot_moveit_config move_group.launch 21 | tee move_group.log然后搜索关键词。第二步验证SRDF与URDF一致性用MoveIt!自带工具检查rosrun moveit_core test_srdf_parser /path/to/your_robot.srdf /path/to/robot.urdf若输出[ INFO] [123456789.012345]: Successfully parsed SRDF说明SRDF语法正确。第三步可视化TF树运行rosrun rqt_tf_tree rqt_tf_tree确认base_link、ee_link、odom等关键frame均存在且连接正确。若ee_link悬空无parent说明SRDF中group的link引用错误。4.3 规划失败的隐形杀手碰撞矩阵与关节限值的协同失效这是最隐蔽的故障。现象move_group启动成功RVIZ中能拖动目标位姿但plan()返回False日志无明显错误。4.3.1 碰撞矩阵误配的典型症状症状1规划器在空旷环境仍返回无解原因base_link与floor_link被错误设为enable而floor_link的碰撞体积过大如设为10m×10m平面导致所有位姿都被判定为碰撞。诊断在RVIZ中加载Planning Scene勾选Show Collision Scene观察是否整个地面呈红色。症状2规划路径绕远路原因arm_link与table_link被禁用但table_link实际是障碍物。规划器“看不见”桌子生成的路径会穿过桌面。诊断在Planning Scene中取消勾选Show Collision Scene仅显示Show Visual Scene对比二者差异。4.3.2 关节限值协同失效的数学本质当URDF中limit与joint_limits.yaml不一致时move_group会以joint_limits.yaml为准。但若joint_limits.yaml中velocity值超过电机实际能力会导致仿真中轨迹执行缓慢Gazebo动力学模拟失真实机中驱动器报OVER_SPEED错误。根治方案建立限值校验脚本validate_limits.pyimport yaml from urdf_parser_py.urdf import URDF # 读取URDF关节限值 robot URDF.from_xml_file(/path/to/robot.urdf) urdf_limits {} for joint in robot.joints: if joint.limit: urdf_limits[joint.name] { lower: joint.limit.lower, upper: joint.limit.upper, velocity: joint.limit.velocity, effort: joint.limit.effort } # 读取YAML限值 with open(/path/to/joint_limits.yaml) as f: yaml_limits yaml.safe_load(f)[joint_limits] # 比较并告警 for joint_name, urdf_lim in urdf_limits.items(): if joint_name in yaml_limits: yaml_lim yaml_limits[joint_name] if abs(yaml_lim[upper] - urdf_lim[upper]) 0.01: print(fWARNING: {joint_name} upper limit diff 0.01rad)4.4 性能调优实战从10秒规划到200毫秒的参数精调Setup Assistant生成的默认配置面向通用场景实测规划耗时通常在3-8秒。通过以下三步可压降至200ms内4.4.1 OMPL算法参数调优以RRTConnect为例在config/ompl_planning.yaml中修改RRTConnectkConfigDefault: type: geometric::RRTConnect range: 0.5 # 原为0.3增大采样步长减少迭代次数 goal_bias: 0.05 # 原为0.05保持不变 # 新增关键参数 max_nearest_neighbors: 5 # 原为10减少近邻搜索开销 use_kdtree: true # 强制启用KD树加速距离查询4.4.2 碰撞检测粒度降级在config/planning.yaml中添加planning_scene_monitor: publish_planning_scene: true # 降低碰撞检测频率 planning_scene_monitor_options: max_update_rate: 1.0 # 原为10.0单位Hz4.4.3 启用规划缓存在launch/move_group.launch中为move_group节点添加参数param nameallow_trajectory_execution valuetrue/ param namecapabilities valuemove_group/MoveGroup