ROS中odom、map坐标系的理解

学ROS大半年了,以前一直没搞明白odom和map,今天从新查资料看博客加本身思考才真正理解了。深深怀疑本身的理解能力。。。html

此处参考了https://blog.youkuaiyun.com/flyinsilence/article/details/51854123,博主的解释一开始我仍是没太看明白,看了好几遍才看懂,懂了以后才发现人家写的真的是言简意赅啊!dom

我就详细的把本身的理解以及想到的例子写出来,万一有人也是不太明白这个呢。ui

举个栗子this

好比说我如今算出来了一个一维的坐标X=10(odom-->base_link),可是这个位置的真实坐标应该是X'=2(map-->base_link),也就是说我计算的坐标和真实坐标出现了误差。可是ROS在说的时候换了个说法,不说计算出来的坐标在map中漂了8,而是说是odom坐标系相对于map坐标系漂了8。因此此时base_link相对odom坐标是真实坐标x=2(由于odom坐标系短期是准确的,若是是刚开始时odom和map重合,odom中的该坐标就是真实坐标);odom相对于map坐标是driftX=8(map-->odom);最后计算出来的base_link相对于map的坐标就是X=drixfX+X'=10了。.net

若是用IMU做积分的话,经过IMU得到的是odom坐标系下的坐标,初始时odom和map重合,都为0。那么短期内,因为IMU的漂移很小,因此得到的位移deltaX是准确的,最终的在odom坐标系下的坐标是X=dextaX,在map中的坐标X'也是deltaX。可是时间长了以后,IMU积分开始产生漂移driftX了,最终在map下的坐标X=deltaX+driftX。因为咱们定义IMU在短期内产的的位移deltaX是准确的,因此deltaX是就是IMU在odom坐标系下的真实位移,可是此时odom相对于map则漂移了driftX。htm

 

因此odom至关因而根据实际计算获得的坐标和真实坐标之间的变换虚拟出来的一个坐标系。blog

 

Relationship between Frames

The map frame is the parent of odom, and odom is the parent of base_link. Although intuition would say that both map and odom should be attached to base_link, this is not allowed because each frame can only have one parent.ip

(尽管直觉上map和odom都应该和base_link链接,可是这是不行的,因为每一个坐标系只能有一个父坐标系)

<think>嗯,我现在要弄清楚ROS1中的map坐标系是否是相对于右手坐标系顺时针旋转了90度。首先,我需要回忆一下ROS中的坐标系定义。记得ROS遵循的是右手坐标系,对吧?通常右手坐标系的X轴向前,Y轴向左,Z轴向上。这种情况下,当面对X轴正方向时,Y轴的正方向是向左的,这样旋转的话,比如绕Z轴旋转,正方向应该是逆时针,符合右手法则。 那map坐标系ROS中的具体应用是怎样的呢?在导航堆栈中,map坐标系通常是一个固定的全局坐标系,用来表示机器人在环境中的位置。比如,当机器人启动时,它的初始位置可能在map的原点。那这里的map坐标系是否有可能因为某些原因被旋转了90度呢? 可能用户提到的“相对右手坐标系顺时针旋转90°”是指某些特定情况下的转换。比如,有时候地图数据在加载时可能根据地图图像的像素坐标系进行调整。例如,二维地图通常以图像形式存储,而图像的坐标系通常是左上角为原点,X轴向右,Y轴向下,这与ROS的标准右手坐标系不同。这时候可能需要将地图数据进行旋转或变换,使得地图在ROS中正确对齐。 比如,假设地图图像中的X轴向右,Y轴向下,那么在转换为ROSmap坐标系时,可能需要将图像坐标系顺时针旋转90度,使得地图的X轴对应ROS的X轴,Y轴对应ROS的Y轴。或者可能是其他转换方式,比如镜像或旋转。这种情况下,map坐标系相对于原始图像坐标系可能会有旋转,但这是否意味着map坐标系本身相对于右手坐标系旋转了呢? 其实,ROSmap坐标系本身还是遵循右手法则的,也就是X前,Y左,Z上。但在某些情况下,比如当地图数据来源于不同的坐标系定义时,可能需要进行坐标变换,例如使用static_transform_publisher来调整坐标系的转换关系。比如,如果地图数据原本的坐标系是X右,Y下,那么可能需要通过旋转来适应ROS的右手坐标系,这时候可能会涉及绕Z轴旋转-90度(即顺时针旋转90度),从而将原始坐标系的X右转换为ROS的X前,Y下转换为ROS的Y左。 所以,可能用户遇到的问题是在加载地图时,发现地图的方向与机器人的运动方向不符,进而进行了坐标变换,比如将地图顺时针旋转90度来匹配ROS的标准坐标系。这种情况下,转换后的map坐标系相对于原始数据是旋转了,但map坐标系本身在ROS中仍然是右手坐标系,只是通过变换矩阵调整了数据源的对齐方式。 总结一下,ROS中的map坐标系本身是右手坐标系,X前,Y左,Z上。但在实际应用中,如果地图数据来源的坐标系不同,可能需要通过旋转(如顺时针90度)来对齐到ROS的标准map坐标系。这种情况下,转换后的数据在map坐标系中的呈现看起来像是相对于原始坐标系旋转了,但map坐标系本身的定义并未改变。</think>在ROS1中,**map坐标系本身严格遵循右手坐标系规则**(X轴向前,Y轴向左,Z轴向上)。但具体应用场景中可能存在以下细节: --- ### 1. **坐标系定义** - **右手坐标系规则**:ROS的所有坐标系默认遵循右手法则: - **X轴**:正方向向前(机器人的前进方向) - **Y轴**:正方向向左(与X轴垂直) - **Z轴**:正方向向上(垂直于地面) --- ### 2. **地图数据的潜在调整** 若观察到map坐标系“相对右手坐标系顺时针旋转90°”,通常是**地图数据源与ROS坐标系对齐时的转换结果**,而非坐标系本身被修改。常见场景包括: - **地图图像加载**:二维地图(如PGM文件)的像素坐标系通常为: - 原点在左上角 - X轴向右(图像宽度方向) - Y轴向下(图像高度方向) - **坐标对齐**:将图像坐标系转换为ROSmap坐标系时,可能需进行以下操作: ```python # 伪代码示例:图像坐标系ROS坐标系 1. 将Y轴反向(从向下改为向上) 2. 绕Z轴顺时针旋转90°(使X轴从向右变为向前) ``` 这会导致地图数据在ROS中显示为“顺时针旋转90°”的效果,但底层坐标系规则未改变。 --- ### 3. **验证方法** - **使用RViz**:加载地图后,观察坐标系箭头: - 红色箭头(X轴)应指向机器人默认前进方向。 - 绿色箭头(Y轴)应指向左侧。 - **TF树检查**:通过`tf_echo`查看map到其他坐标系(如`odom`)的变换,确认是否存在旋转变换: ```bash rosrun tf tf_echo map odom ``` --- ### 4. **关键结论** - **map坐标系本身未旋转**:ROS定义的map坐标系严格遵循右手法则。 - **数据对齐可能导致表象旋转**:地图文件或传感器数据源的坐标系差异可能通过旋转变换(如顺时针90°)对齐到ROS标准。 建议检查地图加载时的参数(如`yaml`文件中的`origin`或`occupancy_grid`的转换矩阵),确认是否存在显式的旋转变换。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值