Newton 空间向量约定全解Twist、Wrench、四元数、坐标轴与碰撞原语的跨引擎规范对照【免费下载链接】newtonAn open-source, GPU-accelerated physics simulation engine built upon NVIDIA Warp, specifically targeting roboticists and simulation researchers.项目地址: https://gitcode.com/GitHub_Trending/newton9/newtonNewton基于 NVIDIA Warp 的 GPU 加速物理仿真引擎的公开 API 大量使用 6 维空间向量spatial vectors速度用 twist 表示外力用 wrench 表示。这些向量“长什么样”并不取决于物理本身而取决于参照点reference point在哪里、各分量在哪个坐标系下表达、以及分量在内存中的排列顺序。本篇技术指南完整梳理 docs/concepts/conventions.rst 所定义的 Newton 空间向量约定——包括 twist 与 wrench 的参照点/坐标系规则、与 Modern Robotics / Drake / MuJoCo / Isaac Lab 的约定对照与转换公式、四元数存储顺序、up 轴与颜色空间约定、以及碰撞原语的形状规范与跨引擎参数映射帮助你在接入第三方框架或编写自定义求解器/传感器时一次性避开坐标约定类 bug。一、前提知识刚体空间力的参照点运动学Newton API 中的刚体空间力wrench6 维与空间速度twist6 维都是相对于某个参照点定义的。当参照点发生平移时力矩分量与线速度分量会随之更新以保证 wrench 的物理效果和 twist 描述的速度场在新参照点下保持不变。一个 6D wrench/twist 由线性 3 维分量和角 3 维分量组成它们对参照点的依赖关系分为两类与参照点无关的分量线性力 (\mathbf{f})、角速度 (\boldsymbol{\omega})依赖参照点的分量角力矩 (\boldsymbol{\tau})、线速度 (\mathbf{v})。将参照点平移 (\mathbf{r} (\mathbf{p}{\text{new}} - \mathbf{p}{\text{old}})) 时点相关分量的更新公式为$$ \boldsymbol{\tau}{\text{new}} \boldsymbol{\tau} \mathbf{r} \times \mathbf{f}, \qquad \mathbf{v}{\text{new}} \mathbf{v} \boldsymbol{\omega} \times \mathbf{r} $$这一点是后文所有转换公式的根基Newton 的文档在给出每个量时都会同时说明它在哪个坐标系下表达以及以哪个点为参照。如果你在自己的代码里用别的参照点计算了 wrench必须先平移到 Newton 期望的参照点再传入。二、空间 Twist 约定2.1 Modern Robotics 中的两种 twist 表示机器人学教材Modern RoboticsLynch Park定义了同一个刚体运动的两种等价 twist 表示Body twist(V_b)以刚体自身的 body frame 表达。其中 (\omega_b) 是 body 系下的角速度(v_b) 是 body 原点例如质心 COM的线速度在 body 系下的表达即 (V_b (\omega_b, v_b))代表“刚体用自己坐标系观察自己的运动”。Spatial twist(V_s)以固定的世界系space frame表达。(\omega_s) 是世界坐标下的角速度(v_s) 是“假想一个刚体上瞬时位于世界原点的点”的线速度等价地$$ v_s \dot{p} - \omega_s \times p $$其中 (p) 是从世界原点指向 body 原点的向量故 (V_s (v_s, \omega_s)) 称为 spatial twist。注意(v_s) 并不等于 COM 速度那是 (\dot{p})而是世界原点“若刚性附着在刚体上”时的速度。两种表示的差别只在坐标系body vs. world与参照点body 原点 vs. 世界原点上角速度本身只差一个坐标旋转。2.2 主流物理引擎的存储约定大多数物理引擎实际存储的是COM 线速度 角速度通常都放在世界坐标系下概念上等价于“在 COM 处取 twist、在世界系下表达”但细节各不相同系统线速度平移角速度旋转Twist 术语Modern Robotics— Body twistBody 原点常取 COMbody 系body 系Body twist (V_b)Modern Robotics— Spatial twist世界原点world 系world 系Spatial twist (V_s)Drakebody 系原点 (B_o)不一定是 COMworld 系world 系空间速度 (V_{WB}^{W})MuJoCobody 系原点world 系body 系混合坐标系 6 向量mixed-frameIsaac Gym / Isaac LabCOMworld 系world 系root 线/角速度PhysXCOMworld 系world 系无“twist”命名通常视作 ([\mathbf{v}_{com}^W;\ \boldsymbol{\omega}^W])NewtonCOMworld 系world 系State.body_qd要点解读Drake多体库使用显式 frame 命名的完整空间向量默认记法 (V_{MB}^{E})“frame B 相对 M 的速度、在 E 系下表达”。常规使用 (V_{WB}^{W})两分量都在世界系与通用物理引擎约定一致。MuJoCofree body 使用mixed-frame 格式——线性部分 ((v_x,v_y,v_z)) 是body frame 原点即qpos[0:3]所在位置在世界系下的速度角速度部分 ((\omega_x,\omega_y,\omega_z)) 则在body frame下表达。这一选择源于四元数积分角速度“生活在”四元数的切空间局部系中。特别地当质心body_ipos与 body 系原点存在偏移时MuJoCo 的线速度不是COM 速度二者关系见 2.4 节。Isaac Lab / Isaac Gymroot-state 张量给出 ((v_x,v_y,v_z,\omega_x,\omega_y,\omega_z))全部在世界系下表达与 Bullet / ODE / PhysX 一致。2.3 Newton 的body_qd约定Newton 的绝大多数求解器遵循标准物理引擎约定与 Isaac Lab 完全一致State.body_qd存储世界系下的 COM 线速度前 3 维与世界系下的角速度后 3 维Newton 公开 API 的spatial_vector数组统一采用(linear, angular)顺序这与 Warp 原生的(angular, linear)顺序相反。该约定适用于State.body_qd、State.body_f等所有空间向量数组。这一点在源码中有直接印证。State 定义 中body_qd的文档字符串明确写着self.body_qd: wp.array | None None Rigid body velocities (spatial) [m/s, rad/s], shape (body_count,), dtype :class:spatial_vector. First three entries: linear velocity [m/s] relative to the bodys center of mass in world frame; last three: angular velocity [rad/s] in world frame.因此一个典型的 Warp kernel 读取约定如下原文档示例wp.kernel def get_body_twist(body_qd: wp.array[wp.spatial_vector]): body_id wp.tid() # body_qd is a 6D wp.spatial_vector in world frame twist body_qd[body_id] # linear velocity is the velocity of the bodys center of mass in world frame linear_velocity twist[0:3] # angular velocity is the angular velocity of the body in world frame angular_velocity twist[3:6] wp.launch(get_body_twist, dimmodel.body_count, inputs[state.body_qd])如果你需要的不是 COM 速度而是body 系原点的速度用 body 的 COM 偏移在世界系下的向量 (r_{\text{com}}^W) 平移线速度项$$ v_{\text{origin}}^W v_{\text{com}}^W - \omega^W \times r_{\text{com}}^W $$源码层面Newton 在 newton/_src/math/spatial.py 提供了velocity_at_point辅助函数它先做布局转换再调用 Warp 原生实现其 docstring 直接说明了两种布局的差异wp.func def velocity_at_point(qd: wp.spatial_vector, r: wp.vec3) - wp.vec3: Evaluate the linear velocity of an offset point on a rigid body. In Newton, spatial twist vectors are stored as :math:q_d (v, \\omega), where :math:v is linear velocity and :math:\\omega is angular velocity. Warps warp.velocity_at_point() uses :math:(\\omega, v) ordering, so this wrapper converts the layout before calling Warp. ... qd_wp wp.spatial_vector(wp.spatial_bottom(qd), wp.spatial_top(qd)) return wp.velocity_at_point(qd_wp, r)这提示了一个实战要点当你直接调用 Warp 原生空间向量工具函数时需要留意(linear, angular)与(angular, linear)的布局差异Newton 内部已用此类 wrapper 封装好了。此外Newton 在使用SolverMuJoCo时会自动完成与 MuJoCo mixed-frame 格式的双向转换包括角速度的坐标系转换world ↔ body和线速度的参照点转换COM ↔ body frame 原点用户无需手动处理。2.4 各表示之间的映射公式Body ↔ SpatialModern Robotics对 body 位姿 (T_{sb} (R, p))$$ \omega_s R,\omega_b, \qquad v_s R,v_b \omega_s \times p $$即 (V_s \mathrm{Ad}_{(R,p)},V_b)逆变换用 (R^{\mathsf T}) 与 (-R^{\mathsf T}p)。物理引擎 → Modern Robotics已知引擎给出的 ((v_{\text{com}}^W, \omega^W))世界系 COM 速度与角速度在 COM 处构造 spatial twist(V_{WB}^{W} (v_{\text{com}}^W, \omega^W))转 body 系(\omega_b R^{\mathsf T}\omega^W)(v_b R^{\mathsf T}v_{\text{com}}^W)平移到距 COM 偏移 (r) 的其他原点(v_{\text{origin}}^W v_{\text{com}}^W \omega^W \times r^W)其中 (r^W R,r)。MuJoCo 转换Newton 与 MuJoCo 之间需要两步转换。角速度坐标系MuJoCo 的角速度在 body 系下需旋转 (R) 得到世界系角速度或反之$$ \omega^W R,\omega^B, \qquad \omega^B R^{\mathsf T}\omega^W $$线速度参照点MuJoCo 的线速度取在 body frame 原点Newton 取在 COM。若刚体存在非零 COM 偏移 (r)MuJoCo 中为body_iposNewton 中为body_com$$ v_{\text{origin}}^W v_{\text{com}}^W - \omega^W \times r^W, \qquad v_{\text{com}}^W v_{\text{origin}}^W \omega^W \times r^W $$其中 (r^W R,r^B) 是 COM 偏移的世界系表达。总而言之所有转换都归结为两件事参照点COM 还是其他点与坐标系world 还是 body。物理不变任何点的线速度都满足 (v_{\text{new}} v \omega \times r)。三、空间 Wrench 约定State.body_f与Control.joint_fNewton 把外部刚体力表示为空间 wrench存于State.body_f在世界系下按如下顺序排列$$ \mathbf{w} \begin{bmatrix} \mathbf{f} \ \boldsymbol{\tau} \end{bmatrix} $$其中 (\mathbf{f}) 为线性力(\boldsymbol{\tau}) 为关于刚体质心COM的力矩两者都在世界坐标下表达。由于力矩项依赖参照点将 wrench 平移到偏移 (\mathbf{r}) 的点时$$ \boldsymbol{\tau}_{\text{new}} \boldsymbol{\tau} \mathbf{r} \times \mathbf{f} $$这一约定适用于所有 Newton 求解器。源码 State 定义 同样明确self.body_f: wp.array | None None Rigid body forces (spatial) [N, N·m], shape (body_count,), dtype :class:spatial_vector. First three entries: linear force [N] in world frame applied at the bodys center of mass (COM). Last three: torque (moment) [N·m] in world frame. .. note:: :attr:body_f represents an external wrench in world frame with the bodys center of mass (COM) as reference point.扩展属性body_parent_f关节传入 wrench同样以 COM 为参照点。若需要批量清零外力可用State.clear_forces()将particle_f与body_f置零见 state.py。关节广义坐标下的关节力torque数组存于Control.joint_f。对于FREE与DISTANCE关节该数组中对应的 6 个维度就是世界坐标下的物理 wrench其力与力矩同样以子刚体child body的 COM为参照点。MuJoCo 特例MuJoCo 的根自由关节广义力qfrc_applied采用 mixed-frame 约定。为了在自由关节场景下保留 Newton 的 COM-wrench 语义SolverMuJoCo的做法是自由关节的joint_f通过xfrc_applied世界系、以 COM 为参照的 wrench施加而qfrc_applied只用于非自由关节。源码中可见这一路由逻辑kernels.py 的注释明确写道 “Free/DISTANCE joint forces are routed via xfrc_applied in a separate kernel”solver_mujoco.py 处同样注明 “Free/DISTANCE joint forces are applied via xfrc_applied to preserve COM-wrench semantics”。为什么不直接把自由关节 wrench 写进qfrc_applied因为qfrc_applied是广义力空间而非物理 wrench对自由关节而言6 维基向量取决于当前cdof子树 COM 系旋转分量又在 body 系下表达简单的 world-to-body 旋转并不足够正确的映射是 MuJoCo 内部使用的 Jacobian 转置操作与xfrc_applied相同的路径。经由xfrc_applied路由可保证 wrench 在世界系下、以 COM 为参照被一致地映射为广义力。四、四元数存储顺序约定不同物理引擎和图形框架存储四元数分量的顺序不同数据在系统间传递时极易踩坑。四元数 (q w xi yj zk)(w) 为标量部((x,y,z)) 为向量部的存储顺序如下系统存储顺序说明Newton / Warp(x, y, z, w)向量部在前标量在后Isaac Lab / Isaac Sim(w, x, y, z)标量在前向量部在后MuJoCo(w, x, y, z)标量在前向量部在后USD(x, y, z, w)向量部在前标量在后要点数学记法常写 (q w xi yj zk) 或 (q (w,x,y,z))但这不决定存储顺序两者是独立约定系统间转换必须重排分量。例如从 Isaac Lab 转到 Newtonnewton_quat (isaac_quat[1], isaac_quat[2], isaac_quat[3], isaac_quat[0])旋转语义与存储顺序无关差异只在内存布局Warp 的quat类型为(x, y, z, w)可通过quat[0](x)、quat[1](y)、quat[2](z)、quat[3](w) 访问。在多系统管线下务必在数据入口处核对四元数顺序否则会出现完全错误的朝向。五、坐标系与 Up 轴约定系统Up 轴手性备注NewtonZ默认右手系可通过Axis.X/Y/Z配置MuJoCoZ默认右手系标准机器人学约定USDY默认右手系可配置为Y或ZIsaac Lab / Isaac SimZ默认右手系遵循机器人学约定核心设计原则Newton 本身是坐标系无关的可以配合任意 up 轴工作——物理算法不依赖特定坐标朝向。真正需要跟踪的是各资产与数据源的约定以便在运行时做正确转换。常见集成场景USD → Newton从 USD 的 Y-up或 Z-up转换到 Newton 配置的 up 轴MuJoCo → Newton从 MuJoCo 的 Z-up 转换到 Newton 配置的 up 轴混合资产管线按资产跟踪 up 轴并施加相应变换。跨 up 轴转换时施加相应旋转Y-up ↔ Z-up 是绕 X 轴的 90° 旋转同时必须保持右手系不变。配置示例原文档示例import newton # 配置 Newton 使用 Z-up 坐标系机器人学约定 builder newton.ModelBuilder(up_axisnewton.Axis.Z, gravity(0.0, 0.0, -9.81)) # 或使用 Y-up图形/动画约定 builder newton.ModelBuilder(up_axisnewton.Axis.Y, gravity(0.0, -9.81, 0.0))从 ModelBuilder 源码 可以确认参数行为up_axis默认为Axis.Zgravity省略时默认取沿up_axis方向的-9.81传递标量形式的 gravity 已被标记为废弃。注意 up 轴只约束几何约定并不约束显式传入的 gravity 向量二者可以独立指定。导入侧同样内置了 up 轴处理ModelBuilder.add_usd()提供apply_up_axis_from_stage参数见 builder.py——为False默认时USD stage 会被旋转到 builder 的 up 轴对齐为True时则用 stage 自身的 up 轴来设置ModelBuilder.up_axis。add_urdf()/ MuJoCo 场景加载的up_axis参数默认 Z也承担同类职责。六、颜色空间约定Newton 将作者提供的表面颜色一律视为display/sRGB 的 RGB 值。公开颜色入口——如Model.shape_color、Mesh.color以及ModelBuilder形状辅助函数的color参数——都应传入你希望屏幕上看到的值分量取值在[0, 1]。渲染后端负责把 display 颜色转换为 linear light 参与光照计算不要在赋给 Newton 之前自行预线性化形状或网格颜色当确实需要 linear-light 运算时在边界处用newton.utils.color_srgb_to_linear与newton.utils.color_linear_to_srgb转换。示例import newton display_color (0.125, 0.125, 0.15) builder newton.ModelBuilder() builder.add_ground_plane(colordisplay_color) linear_color newton.utils.color_srgb_to_linear(display_color)实现层面newton/_src/utils/color.py 定义了ColorSpace枚举LINEAR/SRGB与上述两个转换函数采用标准 Rec.709 分段公式sRGB → linear 时按rgb 0.04045 ? rgb/12.92 : ((rgb0.055)/1.055)^2.4处理负分量先钳制为 0。同文件中还有对应的 Warp GPU 侧实现srgb_to_linear_wp/linear_to_srgb_wp供渲染 kernel 使用。纹理与传感器同样遵循该约定模型上的 base-color 纹理保持 display/sRGB 编码存储SensorTiledCamera的 packed color / albedo 输出默认也是 display/sRGB 编码当下游需要线性 RGB 字节时设置SensorTiledCamera.RenderConfig(output_color_spacenewton.utils.ColorSpace.LINEAR)clear color 以 display/sRGB 的 packed RGBA 值指定请求线性输出时会相应转换。七、碰撞原语约定本节规范在以下场景尤为重要用ModelBuilder程序化创建碰撞几何、调试资产导入后的异常碰撞行为、理解非对称形状的质心计算。7.1 Newton 碰撞原语规范形状原点参数说明Box几何中心hx,hy,hz半长边与局部坐标轴对齐Sphere球心radius各向同性Capsule几何中心radius,half_height沿 Z 轴延伸half_height不含两端半球帽Cylinder几何中心radius,half_height可选barrel_radius沿 Z 轴延伸barrel_radius把侧面弯成对称圆弧Cone几何中心radius底面、half_height沿 Z 轴延伸底面在 -half_height顶点在 half_heightPlane形状坐标系原点width,length或 0,0 表示无限法线沿形状系 ZMesh用户定义顶点与三角形数组通用三角网格可非凸CCW 绕向定义外法线形状朝向与对齐所有带主轴的原语capsule、cylinder、cone在其局部坐标系中都沿Z 轴对齐最终世界/父刚体下的位姿由形状变换决定。barrel_radius细节针对圆柱radius是两端半径将barrel_radius设为非零值会用该半径的对称圆弧替代直边轮廓再绕 Z 轴旋转成面此时要求barrel_radius half_height默认值 0 即普通圆柱。这一参数在 builder.py 中以scale wp.vec3(radius, half_height, barrel_radius)编码进形状参数USD 导入侧同文件约 L12887 起也把shape_scale解包为(end_radius, half_height, barrel_radius)且要求barrel_radius half_height才生效。质心考量多数原语的质心与几何原点重合锥体是重要例外其 COM 位于形状局部系的(0, 0, -half_height/2)即从底面朝顶点方向总高度的 1/4 处。7.2 跨引擎碰撞原语对照Sphere系统参数约定说明Newtonradius原点在球心MuJoCosize[0] radius原点在球心USD (UsdGeomSphere)radius属性原点在球心USD Physicsradius属性原点在球心Box系统参数约定说明Newton半长(hx, hy, hz)中心到面的距离MuJoCosize属性中的半尺寸还支持fromtoNewton 导入器不支持USD (UsdGeomCube)size属性全尺寸是边长不是半长USD PhysicshalfExtents属性与 Newton 约定一致Capsule系统参数约定说明Newtonradius,half_height不含帽总长 2×(radius half_height)MuJoCosize[0] radiussize[1] 半长不含帽也可用fromto指定端点USD (UsdGeomCapsule)radius,height不含帽圆柱段的完整高度USD Physicsradius,halfHeight不含帽与 Newton 类似Cylinder系统参数约定说明Newtonradius,half_height可选barrel_radius沿 Z 轴延伸MuJoCosize[0] radiussize[1] 半长支持fromtoNewton 的 MJCF 导入器将圆柱映射为 capsuleUSD (UsdGeomCylinder)radius,height全高视觉形状USD Physicsradius,halfHeightNewton 的 USD 导入器会创建真实圆柱Cone系统参数约定说明Newtonradius底面、half_heightCOM 偏移在 -half_height/2MuJoCo不支持—USD (UsdGeomCone)radius,height全高视觉表示USD Physicsradius,halfHeight物理表示Plane系统定义方式法线方向Newton基于变换或平面方程形状系 ZMuJoCobody 系下的尺寸与朝向geom 系 ZUSD无标准平面原语取决于实现Mesh系统网格类型说明Newton通用三角网格可非凸MuJoCo碰撞仅凸包视觉网格可非凸USD (UsdGeomMesh)通用多边形网格视觉表示USD Physics取决于实现可能使用凸近似7.3 导入时的自动处理Newton 的各类导入器USD / MJCF / URDF在加载资产时自动处理约定差异使用这些导入器无需手动转换形状会被自动变换为 Newton 的原语约定。结合第五节的 up 轴参数导入管线同时解决“坐标系朝向”与“形状参数语义”两类差异。八、约定速查清单在把 Newton 接入外部系统RL 框架、MuJoCo 模型、USD 资产、相机管线时建议按以下清单逐项核对Twist 布局Newton 是(linear, angular)Warp 原生是(angular, linear)body_qd前 3 维为世界系 COM 线速度后 3 维为世界系角速度见 state.py。Wrench 参照点body_f、自由/距离关节的joint_f均取COM为参照点、世界系表达跨参照点平移遵循 (\tau_{new} \tau r \times f)。MuJoCo 互操作角速度需 world↔body 旋转线速度需 COM↔body 原点参照点平移自由关节力经xfrc_applied路由以保持 COM-wrench 语义。四元数顺序Newton/Warp/USD 为(x,y,z,w)Isaac/MuJoCo 为(w,x,y,z)接入时显式重排分量。Up 轴Newton 默认 Z-up 但完全坐标无关省略gravity时默认沿 up 轴取 -9.81标量 gravity 已废弃。颜色所有作者颜色形状颜色、纹理、clear color、相机默认输出按sRGB/display处理需要线性光时在边界用newton.utils.color_srgb_to_linear/color_linear_to_srgb或相机RenderConfig(output_color_space...)转换。碰撞原语主轴原语一律沿局部 Z 轴capsule/cylinder 的half_height均不含帽/端帽锥体 COM 在-half_height/2box 用半长而 UsdGeomCube 用全边长导入器会自动归一。把握这些约定后Newton 中“同一个 6 维向量在不同系统里含义不同”的坑基本可以被系统性规避物理本身不会变变的只有参照点、坐标系与内存布局这三件事。【免费下载链接】newtonAn open-source, GPU-accelerated physics simulation engine built upon NVIDIA Warp, specifically targeting roboticists and simulation researchers.项目地址: https://gitcode.com/GitHub_Trending/newton9/newton创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考