简介这是一份坐标转换专用工具CooRD-MG2.0的完整软件包内含可执行程序与配套参数文件面向测绘、GIS及图像处理领域的工程师和开发者解决不同坐标参照系之间的换算问题。软件以COORD.exe为主程序内置大量地区转换参数覆盖中国北京54、国家80、WGS84以及韩国、比利时、南非、沙特阿拉伯等多个国家和地区的独立坐标系并兼容人脸关键点坐标转换等图像分析场景。资源共91个文件体积仅5.65MB其中49个cod参数文件可直接导入软件使用gif/jpg/png图片提供界面与操作示例csv与zgf文件包含坐标数据和格网参数dll/bin为运行组件doc文档说明了转换方法与注意事项。已有2397人学习。这套工具既能满足实际生产中的坐标转换需求又可作为学习测绘坐标系理论、了解全球坐标系统的实用参考资料尤其适合需要处理多源坐标数据的专业技术人员快速上手。 做无人机的自主定位一年多我最深的体会是传感器选型和算法调参往往不是最折腾人的最折腾人的是坐标转换。明明点云拼接正常、里程计漂移很小一接到飞控里飞机就像喝醉了酒。前阵子收拾这一堆烂摊子的时候我把踩过的坑和沉淀下来的代码整理成了一个独立工具代号就叫笑脸转换坐标 CooRD-MG2.0。CooRD-MG2.0 的核心定位是SLAM 里程计与飞控/导航坐标系之间的位姿翻译官输入是任意传感器坐标系下的位姿位置加姿态输出是你真正想要的飞控坐标系、协议格式和时间同步后的数据。它不替代 FAST-LIO、FAST-LIVO 这类 SLAM 算法而是解决它们和无人机飞控之间那一层最后几厘米的转换问题。无论你是用 ROS 跑 SLAM 接 PX4、ArduPilot还是想把算法输出的 ENU 位姿喂给 NED 的飞控做视觉定位这个工具都能直接抄作业。下面把整个工具的设计逻辑、实测结果和踩坑记录都摊开讲一讲。1. 一个室内定位翻车现场催生出的工具1.1 那一次飞机自己转了90度的排故事情发生在室内 GPS 拒止环境下的自主悬停实验。设备是一台小型四旋翼搭载激光雷达和带 IMU 的飞控FAST-LIVO 作为定位源位姿通过 MAVLink 的 VISION_POSITION_ESTIMATE 消息发给 PX4。第一次上电试飞推杆让飞机往北屏幕上里程计显示往北但飞机实际往东冲而且悬停时一直在缓慢转圈。排查了半天排除了飞控 PID 方向问题、排除电机装反、排除遥控器通道映射最后把 FAST-LIVO 的 odom 和飞控的 local_position 一起录下来对比才发现里程计输出的位置是 ENU 约定东、北、天飞控内部是 NED 约定北、东、地两者之间差了 90 度的朝向偏差和 z 轴反向。更麻烦的是odom 输出的姿态是相对激光雷达启动瞬间的 IMU 朝向定义的而飞控要的是相对起飞点正北航向的姿态两层问题叠在一起不仔细扒拉根本看不出来。这次排故折腾了大概一个周末。解决之后我干脆把整个转换逻辑抽出来写成了 CooRD-MG2.0 的雏形。名字里的笑脸就是当时在办公室白板上画的那个终于搞定了的表情CooRD 是 Coordinate 的缩略MG 是我长期维护的一个嵌入式定位工程代号2.0 是因为第一次架构设计有问题后来推翻重写了一遍。工具的目标从一开始就很明确让坐标系适配这件事可配置、可复算、可验证而不是每个项目都靠人肉改代码。1.2 坐标转换的本质不是在转数字是在统一约定很多人第一次接触坐标转换以为不就是把 x 换成 y、把 z 加个负号。实际上系统性的坐标转换包含三件事坐标系定义统一。你必须明确每个数据分别活在哪个坐标系里。激光雷达扫描出来的点在 lidar 系IMU 测得角速度在 imu 系里程计输出的世界系叫 odom飞控的位置在 NED 局部系GPS、RTK 给的是经纬度或 UTM。这些系之间不是简单平移还包含旋转约定、重力方向、初始航向基准。姿态表示法统一。同一个姿态可以用四元数、旋转矩阵、欧拉角表示而欧拉角本身又有 zyx、zxy、zyz 等几十种顺序约定四元数也有 Hamilton 惯例和 JPL 惯例的区分w、x、y、z 的排列顺序在不同库里经常不一样。变换链完整。从 lidar 到 imu 是外参从 imu 到机体系是安装角从机体系到世界系是里程计位姿从里程计世界系到飞控世界系是基准对齐缺任何一环最后结果都是歪的。用一个生活化类比同样一句前面50米站在路口朝东的人指给你的是东边的路朝北的人指给你的是北边的路。坐标转换做的就是——不管对方朝哪个方向都告诉你该往哪走。CooRD-MG2.0 解决的就是把这几层约定全部配置化、可复算化不再靠人肉在每个项目中临时补丁。2. CooRD-MG2.0 的配置约定与核心换算逻辑2.1 一份配置文件说清楚所有坐标系工具的核心设计是一切约定都进配置代码里不写死任何朝向。我习惯用一个 YAML 文件直接定义传感器外参、世界系约定和输出格式下面是一个精简例子# coords_config.yaml frames: world_frame: enu # SLAM输出所在世界系 target_frame: ned # 飞控需要的目标系 body_frame: body_frd # 机体系前右下 sensors: lidar: frame_id: livox_frame extrinsic_to_body: translation_m: [0.0, 0.0, -0.05] quaternion: [0.0, 0.0, 0.0, 1.0] # 顺序 w,x,y,z imu: frame_id: imu_frame extrinsic_to_body: translation_m: [0.0, 0.0, 0.0] rpy_deg: [0.0, 0.0, 180.0] # 假设IMU绕z轴装反了180度 output: format: mavlink mavlink_type: VISION_POSITION_ESTIMATE topic: /drone/vision_pose这份配置的中心思想是把每个传感器相对机体的安装关系和机体系相对目标世界系的最终输出约定本文还有配套的精品资源点击获取
无人机SLAM坐标转换工具CooRD-MG2.0：ENU与NED位姿无缝对接
简介这是一份坐标转换专用工具CooRD-MG2.0的完整软件包内含可执行程序与配套参数文件面向测绘、GIS及图像处理领域的工程师和开发者解决不同坐标参照系之间的换算问题。软件以COORD.exe为主程序内置大量地区转换参数覆盖中国北京54、国家80、WGS84以及韩国、比利时、南非、沙特阿拉伯等多个国家和地区的独立坐标系并兼容人脸关键点坐标转换等图像分析场景。资源共91个文件体积仅5.65MB其中49个cod参数文件可直接导入软件使用gif/jpg/png图片提供界面与操作示例csv与zgf文件包含坐标数据和格网参数dll/bin为运行组件doc文档说明了转换方法与注意事项。已有2397人学习。这套工具既能满足实际生产中的坐标转换需求又可作为学习测绘坐标系理论、了解全球坐标系统的实用参考资料尤其适合需要处理多源坐标数据的专业技术人员快速上手。 做无人机的自主定位一年多我最深的体会是传感器选型和算法调参往往不是最折腾人的最折腾人的是坐标转换。明明点云拼接正常、里程计漂移很小一接到飞控里飞机就像喝醉了酒。前阵子收拾这一堆烂摊子的时候我把踩过的坑和沉淀下来的代码整理成了一个独立工具代号就叫笑脸转换坐标 CooRD-MG2.0。CooRD-MG2.0 的核心定位是SLAM 里程计与飞控/导航坐标系之间的位姿翻译官输入是任意传感器坐标系下的位姿位置加姿态输出是你真正想要的飞控坐标系、协议格式和时间同步后的数据。它不替代 FAST-LIO、FAST-LIVO 这类 SLAM 算法而是解决它们和无人机飞控之间那一层最后几厘米的转换问题。无论你是用 ROS 跑 SLAM 接 PX4、ArduPilot还是想把算法输出的 ENU 位姿喂给 NED 的飞控做视觉定位这个工具都能直接抄作业。下面把整个工具的设计逻辑、实测结果和踩坑记录都摊开讲一讲。1. 一个室内定位翻车现场催生出的工具1.1 那一次飞机自己转了90度的排故事情发生在室内 GPS 拒止环境下的自主悬停实验。设备是一台小型四旋翼搭载激光雷达和带 IMU 的飞控FAST-LIVO 作为定位源位姿通过 MAVLink 的 VISION_POSITION_ESTIMATE 消息发给 PX4。第一次上电试飞推杆让飞机往北屏幕上里程计显示往北但飞机实际往东冲而且悬停时一直在缓慢转圈。排查了半天排除了飞控 PID 方向问题、排除电机装反、排除遥控器通道映射最后把 FAST-LIVO 的 odom 和飞控的 local_position 一起录下来对比才发现里程计输出的位置是 ENU 约定东、北、天飞控内部是 NED 约定北、东、地两者之间差了 90 度的朝向偏差和 z 轴反向。更麻烦的是odom 输出的姿态是相对激光雷达启动瞬间的 IMU 朝向定义的而飞控要的是相对起飞点正北航向的姿态两层问题叠在一起不仔细扒拉根本看不出来。这次排故折腾了大概一个周末。解决之后我干脆把整个转换逻辑抽出来写成了 CooRD-MG2.0 的雏形。名字里的笑脸就是当时在办公室白板上画的那个终于搞定了的表情CooRD 是 Coordinate 的缩略MG 是我长期维护的一个嵌入式定位工程代号2.0 是因为第一次架构设计有问题后来推翻重写了一遍。工具的目标从一开始就很明确让坐标系适配这件事可配置、可复算、可验证而不是每个项目都靠人肉改代码。1.2 坐标转换的本质不是在转数字是在统一约定很多人第一次接触坐标转换以为不就是把 x 换成 y、把 z 加个负号。实际上系统性的坐标转换包含三件事坐标系定义统一。你必须明确每个数据分别活在哪个坐标系里。激光雷达扫描出来的点在 lidar 系IMU 测得角速度在 imu 系里程计输出的世界系叫 odom飞控的位置在 NED 局部系GPS、RTK 给的是经纬度或 UTM。这些系之间不是简单平移还包含旋转约定、重力方向、初始航向基准。姿态表示法统一。同一个姿态可以用四元数、旋转矩阵、欧拉角表示而欧拉角本身又有 zyx、zxy、zyz 等几十种顺序约定四元数也有 Hamilton 惯例和 JPL 惯例的区分w、x、y、z 的排列顺序在不同库里经常不一样。变换链完整。从 lidar 到 imu 是外参从 imu 到机体系是安装角从机体系到世界系是里程计位姿从里程计世界系到飞控世界系是基准对齐缺任何一环最后结果都是歪的。用一个生活化类比同样一句前面50米站在路口朝东的人指给你的是东边的路朝北的人指给你的是北边的路。坐标转换做的就是——不管对方朝哪个方向都告诉你该往哪走。CooRD-MG2.0 解决的就是把这几层约定全部配置化、可复算化不再靠人肉在每个项目中临时补丁。2. CooRD-MG2.0 的配置约定与核心换算逻辑2.1 一份配置文件说清楚所有坐标系工具的核心设计是一切约定都进配置代码里不写死任何朝向。我习惯用一个 YAML 文件直接定义传感器外参、世界系约定和输出格式下面是一个精简例子# coords_config.yaml frames: world_frame: enu # SLAM输出所在世界系 target_frame: ned # 飞控需要的目标系 body_frame: body_frd # 机体系前右下 sensors: lidar: frame_id: livox_frame extrinsic_to_body: translation_m: [0.0, 0.0, -0.05] quaternion: [0.0, 0.0, 0.0, 1.0] # 顺序 w,x,y,z imu: frame_id: imu_frame extrinsic_to_body: translation_m: [0.0, 0.0, 0.0] rpy_deg: [0.0, 0.0, 180.0] # 假设IMU绕z轴装反了180度 output: format: mavlink mavlink_type: VISION_POSITION_ESTIMATE topic: /drone/vision_pose这份配置的中心思想是把每个传感器相对机体的安装关系和机体系相对目标世界系的最终输出约定本文还有配套的精品资源点击获取