BulletHingeJoint::SetVelocity not working (commented out)

[osrf-migration]

Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

re-enabling the call to bullet in pull request #852 appears to fix this issue with bullet 2.82.

To test, compile gazebo_ros_pkgs with updated gazebo, start gazebo with bullet:

gazebo -s install/lib/libgazebo_ros_api_plugin.so -e bullet

Replace plugin block in pioneer2dx.model with:

    <plugin filename="libDiffDrivePlugin.so" name="diff_drive">
      <left_joint>left_wheel_hinge</left_joint>
      <right_joint>right_wheel_hinge</right_joint>
      <torque>5</torque>
    </plugin>

Spawn (modified) pioneer2dx using the gzclient interface, then

rostopic pub /cmd_vel geometry_msgs/Twist '{ angular: { z: 1.0 } }'

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

• Edited issue description

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Seems like a duplicate of #801 (see also pull request #655).

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

The difference between pull request #852 and pull request pull request #655 is that the first one sets velocity through dynamics using a joint motor, and the second one "teleports" the child link of the joint to the new location pretending the joint is experiencing desired joint velocity relative to the parent link.

Documentation for Joint::SetVelocity does not state which is the desired case.

It seems the latter (pull request #655) with teleport is more consistent with Joint::SetPosition, which teleports joint to target position, but on the other hand ODEHingeJoint::SetVelocity sets target joint velocity as a given and let the physics engine handle the dynamics of the rest of the system. We'll have to change one or the other to stay consistent here.

It looks like we will need multiple versions of Joint::SetVelocity, potentially with different names. Options are:

1. Joint::SetVelocity: Teleport joint (related links) to target velocity ignoring dynamics.
2. Joint::SetVelocityWithID: Attempt to achieve target velocity through ID leveraging the physics engine solver.
3. Joint::SetVelocityWithPID: Attempt to achieve target velocity using joint actuation (with a PID controller) and let dynamics take its course.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

• set assignee_account_id to "557058:f3968cd3-4910-4384-8349-482a6c7889ec"
• set assignee to "hsu (Bitbucket: hsu, GitHub: hsu)"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

For Joint::SetVelocity, I would describe it as prescribing the velocity of the child link relative to the parent link. I wouldn't say "ignoring dynamics", since it's only ignoring some of the dynamics, not all of them. I also wouldn't say teleport, since it's not commanding the pose, but rather the velocity, which gets integrated into the pose.

Can you clarify the meaning of SetVelocityWithID?

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

@scpeters Sure, that's what ODEHingeJoint::SetVelocity is doing, by prescribing joint velocity and making sure all forces for the system are still balanced correctly. We should change BulletHingeJoint::SetVelocity to do something similar then. The existing implementation from pull request #655 will not balance forces on the system, so what if we rearrange the proposed API as below:

1. Joint::SetVelocity: Attempt to achieve target velocity through inverse dynamics leveraging the physics engine solver.
2. Joint::SetVelocityByTeleportingChildLink: Teleport joint (related child link and all of its children) to target position based on prescribed velocity. If the joint is part of a kinematic loop in the model, this approach might fail.
3. Joint::SetVelocityWithPIDForceController: Attempt to achieve target velocity using joint actuation (with a PID controller) and let dynamics take its course.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

The phrasing of 1 and 2 still isn't clear to me. Can we use a simple example to explain the difference? I'll work on writing one up.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

see pull request #1218

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@hsu should we consider this closed since pull request #1218 was merged?

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• changed state from "new" to "resolved"

pull request #1218

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "resolved" to "closed"