MuJoCo 通过 mujoco-py 接口 FetchReach-v1 场景机器人动作延迟

发布于 01-19 00:16 字数 1305 浏览 3 评论 0原文

亲爱的穆乔科社区,

在过去的几天里,我正在使用一个简单的 fetchreach-v1 Open-ai健身房Mujoco环境中的场景。我试图将MPC(模型预测控制)应用于这种情况,该方案基本上为机器人组生成了新的轨迹点。配置了MPC,以便为机器人提供可行的速度和加速度,以便它可以在时间步中实现下一个点,这等于:dt = sim.nsubsteps * sim.model.model.model.model.timestep 。

问题:将动作应用于环境后,我发现握把的下一个位置不等于我期望的位置。首先,我开始认为MPC算法的加速度和/或速度与机器人的速度不匹配。但是,在应用其他步骤(当机器人已经加速时)之后,仍然可以观察到位置的差异。 (请参阅图片)。因此,基本上我选择哪种操作并不重要,它将在提供的时间段dt中永远无法达到。因此,我想Mujoco界面背后有一些运动学之王,可以减少动作,以便机器人可以在接下来的几个时间段中减速到我之前提供的点。 (如果我不提供新的)。

是的,我删除了_SET_ACTION函数中的位置最大变化。

问题:是否有可能以某种方式禁用这种“减速”运动学,以便在没有任何延迟和减速的情况下达到这一点?在下图上,我希望“实际”位置位于“目的地”。

在下面的图片上,我用蓝色大十字和绿十字架的目的地标记了起始位置。蓝线是传递的轨迹。蓝色小十字表示实际达到的位置,该位置与绿十字不同。

“我的猜测”如何计算速度” [“未达到的mujoco

这个问题与我以前的问题有关o mujoco-py github: https://github.com/openai/mujoco-py/sissues/issues/696

Dear MuJoCo community,

in last few days I was working with a simple FetchReach-v1 scenario in open-ai gym MuJoCo environment. I was trying to apply the MPC (Model Predictive Control) to this scenario which basically generates new trajectory points for the robotic arm. The MPC is configured so to provide feasible velocities and accelerations to the robot, so that it will achieve the next point within the timestep, which is equals to: dt = sim.nsubsteps * sim.model.opt.timestep.

The problem: After applying the action to the environment I figured out that the next position of the grip is not equal to the position I expected. First I start thinking that the acceleration and/or the velocities of my MPC algorithm do not match the ones from the robot. But after applying other steps (when the robot is already being accelerated) the difference of the positions was still observable. (see picture). So it is basically does not matter which action I choose, it will never be reached within the provided timestep dt. So I guess there is some king of kinematics behind the MuJoCo interface which reduces the action so that the robot can decelerate within next few timesteps to the point I provided earlier. (if I will not provide a new one).

Yes, there is a limit maximum change in position in _set_action function, which I removed.

The question: Is it possible to somehow disable this "deceleration" kinematics so that the point will be achieved without any delay and deceleration? On the picture below I want the "actual" position to be in "destination".

On the picture below I marked the start location with the big blue cross and the destination with the green cross. The blue line is the passed trajectory. The small blue cross denotes the actual achieved position, which is not the same as the green cross.

My guess of how the velocity is computed
[MuJoCo FetchReach action not achieved

This question relates to my previous issue o mujoco-py github: https://github.com/openai/mujoco-py/issues/696

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

五里雾2025-01-26 00:16:25

听起来您希望从字面上设置速度或加速度?那不是驱动的工作方式。执行器采用力量,由此产生的运动取决于许多其他事物(惯性,阻尼等)。

您的MPC算法确实存在问题。您不能仅仅发明运动轨迹。您需要通过与实际系统相同的动态创建轨迹。换句话说,您的MPC算法需要输出一系列动作(ctrl向量),以便在推出后产生的轨迹实现了您希望实现的一切(大概是通过成本/奖励)。

It sounds like you are expecting to literally set the velocities or accelerations? That is not how actuation works. Actuators apply forces, the resulting motion depends on many other things (inertia, damping etc.).

The issue is really with your MPC algorithm. You cannot just invent a kinematic trajectory. You need to create trajectories via the same dynamics that the actual system has. In other words your MPC algorithm needs to output a sequence of actions (ctrl vectors) such that the resulting trajectory after rollout achieves whatever it is that you want it to achieve (presumably via a cost/reward).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文