
简介
该用户还未填写简介
擅长的技术栈
可提供的服务
暂无可提供的服务
本方案针对eye-on-base机器人因J2形变导致的末端定位偏差,提出“纯离线表一步到位 + IMU仅记录”的控制策略。通过IMU修正手眼标定中的J2物理角度,采集多阶段离线数据(Phase A~E),采用11参数三角函数结合RBF残差拟合Δj2,实现0.1°级精度。最终放弃实时融合,改用离线表直接补偿,避免微调震荡,显著提升稳定性与可重复性,验证表明系统性误差主要源于横向形变与标定残差,而非角
解决: 在 URDF 的 <joint> 内添加 <ec_module>,并指定从站插件为 ethercat_generic_plugins/EcCiA402Drive,同时用 <param> 传递 alias 和 position。解决: 新建 ks100e_slave.yaml,包含 vendor_id、product_id、auto_enable、mode_of_operation 等字段,
根本原因:ROS2 Humble 的预编译 rviz2 依赖 Ogre 1.12.1,而 Ubuntu 22.04 系统更新到了 1.12.10,ABI 不兼容;加上 launch 环境隔离导致库找不到。最优解:从源码编译 rviz2 并内置 RPATH,使其不依赖外部环境变量。关键命令。适用范围:同样适用于其他因共享库版本不匹配导致的 launch 崩溃问题。经过上述步骤,MoveIt 的 rv
最近我在ROS2 Humble环境下开发了一个基于点云的物体抓取姿态生成系统,遇到了不少坑,尤其是法向量计算和箭头可视化部分,折腾了很久才搞定。写这篇文章记录整个开发过程,希望能帮到遇到类似问题的朋友。点云预处理(下采样、滤波、平面分割、聚类)法向量计算的多种尝试与最终方案RViz箭头可视化的巨坑与解决方案(含四元数X轴修正)完整的代码实现最高点法:无论物体如何倾斜,最高点必在顶面,其局部法向量就
关节状态的可靠获取是 MoveIt 运动规划的前提。ROS2 的 QoS 机制虽然灵活,但也容易因策略不匹配导致通信失败。通过显式配置策略、多策略回退、填充以及简化约束,可以解决大部分关节状态获取与规划集成问题。每一步都要验证中间结果。从确认数据发布,到订阅回调确认接收,再到请求的填充,每个环节的验证都能帮助我们及早发现并定位问题。
问题表象根本原因解决方案Action 无响应挂起,move_group运行在 root,普通用户无法发现其 XML-RPC 服务统一在 root shell 中操作规划失败(ABORTED)为空,OMPL 无法识别目标使用(1mm 立方体)明确目标姿态随机末端方向每次不同未加添加姿态约束并指定容差无法解析关节角度程序显示“未能解析”输出格式为 YAML 风格,解析逻辑不匹配增强解析,支持 YAML
末端位置必须严格固定(< 1mm)→ 用笛卡尔路径末端需要沿直线/圆弧运动(如工具对准、贴墙)→ 用笛卡尔路径只是从 A 点到 B 点(位置和姿态都大范围变化)→ 用普通 MoveGroup 关节空间规划即可MoveIt 的关节空间规划只保证端点,不保证中间轨迹。要做精确的末端轨迹控制,只有笛卡尔路径。过程中踩的坑:YAW 方向、奇异点、RViz 显示、executor 冲突、plan_only不
坑现象修复j5 进入极限区条件数好但残差 80mm限制 j5 在 −60°~+10°j5 齿隙补偿符号反残差 44mm(J5>0)?-BL : +BL长杆重力形变水平时 1~2° 形变平面约束法可精化基座不稳固大臂倾斜时前倾 1~2°。
摘要:SOEM驱动混合固件KS100E伺服驱动器的解决方案 本文记录了使用SOEM开源EtherCAT主站驱动科盛KS100E伺服驱动器(不同固件版本混合)时遇到的问题及解决方案。当单独或同版本驱动器工作时正常,但混合V1.6/V1.8版本时,部分从站无法使能且位置指令无效。通过调试发现: 问题并非DC同步参数导致 PDO映射相同但结构体假设错误 状态字读取偏移不匹配是主因 修正包括:调整结构体偏







