Joint visualization broken when model rotated

[osrf-migration]

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

---

See: http://answers.gazebosim.org/question/1132/possible-bug-in-gazebo-gui-after-multiple/

[osrf-migration]

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

---

Another issue is that the joint visualization currently displays a three-axis coordinate frame, but does not indicate which is the relevant joint axis. One problem is that the ~/joint messages aren't transmitted with axis information (see example gztopic output below, and not that axis1.xyz has 3 values near 0):

name: "polaris_ranger_ev_0::hand_brake_joint"
angle: 0
type: REVOLUTE
parent: "polaris_ranger_ev_0::chassis"
child: "polaris_ranger_ev_0::hand_brake"
pose {
  position {
    x: -6.5
    y: -1
    z: 1.05
  }
  orientation {
    x: 0
    y: 0
    z: 0
    w: 1
  }
}
axis1 {
  xyz {
    x: 6.91293211424352e-310
    y: 6.91300644555849e-310
    z: 6.91293211371547e-310
  }
  limit_lower: 0
  limit_upper: 0
  limit_effort: 0
  limit_velocity: 0
  damping: 0
  friction: 0
}

I think this is caused by the ~/joint message being filled and sent in Model::LoadJoint, before the joint has been fully initialized in Joint::Init.

I don't think this is the source of this current bug, but it seems related. Nate, I can file a separate ticket as a feature request if you want, asking for the joint axis to be displayed, rather than the joint pose.

[osrf-migration]

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

---

• changed version from "None" to "1.5"

[osrf-migration]

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

---

I spent a little time looking at this, and it seems that two joint visuals get created for each joint. For models that are loaded with the world file, the code this->jointMsgs.push_back(msg); is called by Scene::ProcessModelMsg, line 1351 and Scene::ProcessSceneMsg line 1279. For inserted models, that same code is called by Scene::ProcessModelMsg and Scene::OnJointMsg line 1607.

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• set assignee_account_id to "557058:10b01d41-a2e9-4a41-a907-e6e2f03b6cd5"
• changed assignee from "None (Bitbucket: None)" to "iche033 (Bitbucket: iche033, GitHub: iche033)"

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "new" to "resolved"

pull request #294

[osrf-migration]

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

---

Issue #511 was marked as a duplicate of this issue.

[osrf-migration]

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

---

• changed state from "resolved" to "open"

somehow this bug was reintroduced

[osrf-migration]

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

---

• changed state from "open" to "resolved"

fixed by d4f48bb

[osrf-migration]

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

---

• changed state from "resolved" to "open"

The proposed fix in d4f48bb works for sdf/worlds/revolute_joint_test.world but doesn't work for worlds/pioneer2dx.world.

[osrf-migration]

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

---

• removed "1.5" version
• set component to "rendering"

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

pull request #802

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "open" to "resolved"

[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"