gazebo actor sdf 1.3 parser error

[osrf-migration]

Original report (archived issue) by max_staehr (Bitbucket: max_staehr).

---

Hello,

I'been trying to get the actor tag running in the latest gazebo version 1.4. However I've not succeded. I always get the following error:

#!console

Msg Waiting for master.Gazebo multi-robot simulator, version 1.4.0
Copyright (C) 2013 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

Msg Waiting for master
Msg Connected to gazebo master @ http://127.0.0.1:11345
Msg Publicized address: 10.100.1.2

Msg Connected to gazebo master @ http://127.0.0.1:11345
Msg Publicized address: 10.100.1.2
Error [SDF.cc:757] Missing element description for [filename]
gazebo: /usr/include/boost/smart_ptr/shared_ptr.hpp:424: T* boost::shared_ptr<T>::operator->() const [with T = sdf::Element]: Assertion `px != 0' failed.
Warning [gazebo_main.cc:62] escalating to SIGKILL on client

The corresponding world file is as follows:

#!xml

<?xml version="1.0" ?>
<sdf version="1.3">
  <world name="default">
    <!-- A global light source -->
    <include>
      <uri>model://sun</uri>
    </include>

    <!-- A ground plane -->
    <include>
      <uri>model://ground_plane</uri>
    </include>

            <actor name="actor1" static="true">
            <pose>0 0 0 0 0 0</pose>
            <skin>
              <filename> walk.dae </filename>
        </skin>
        </actor>
  </world>
</sdf>

[osrf-migration]

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

---

The actor class within Gazebo hasn't been updated in a while. The soonest OSRF can start looking into the problem is after July 2013. However, we can offer you help and guidance if you want to tackle this problem yourself.

[osrf-migration]

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

---

• changed state from "new" to "on hold"

On hold until Gazebo 2.0

[osrf-migration]

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

---

• changed state from "on hold" to "open"

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

I am using Gazebo 3.0 and getting errors for Actor element, such as element[animation] is not defined in SDF. It seems still the character animation is not fixed after v 1.0. Just want to know any predicted time frame for a fix. If it is not going to happen in near future (in one month), could you give some points regarding why this is broken, what sort of effort it needs if I am going to have a fix by myself? I am desperate in getting a fix for this great feature for the project I am currently involved in.

Thank you very much!

[osrf-migration]

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

---

We will not have a chance to address this issue within a month.

This feature has been broken for a few years. Significant amount of work is likely required to resurrect this code. I'd start be forking gazebo, and run the example actor world through the debugger.

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

Most of the SDF errors were fixed by updating .world file to comply with actor.sdf of SDF 1.5 version. Then a boost null pointer assertion popped up at following in Actor::AddActorVisual(). Referring to the schemas, I changed GetElement("filename") to GetElement("uri").

#!c++
meshSdf->GetElement("filename")->Set(this->skinFile);

Then it loaded the actor with skin in Gazebo. Z/Y axis misaligned human character was moved in an approximated circle (as per the trajectory description) without actual walking movements (walk.dae). It seemed only the initial skeleton pose was rendered and thereafter skeleton poses were not processed. Later it was found, in Scene::PreRender(), it never entered following IF condition, hinting there is no visual bound with pose animation skeleton model.

#!c++
Visual_M::iterator iter = this->visuals.find((*spIter)->model_id());
if (iter != this->visuals.end())
{
    iter->second->SetSkeletonPose(*(*spIter).get());
    SkeletonPoseMsgs_L::iterator prev = spIter++;
    this->skeletonPoseMsgs.erase(prev);
}

Actually Visual_M map didn't include any visual with the searching ID (unique id). According to below, in Actor::Load(), a different ID was assigned which is not the actual id of actor::actor_pose::actor_visual. Then I modified the ID for that by searching Visual_M for the particular visual name.

#!c++
this->visualId = gazebo::physics::getUniqueId(); 

Now some sort of skeletal animation happens. However the animated human is having a very weird appearance. I verfied the transformations in COLLADA files are passed as is to OrgeNode::SetPosition() and OrgeNode::SetOrientation().

If I set the bone orientation by;

#!c++
bone->getInitialOrientation() 

in Visual::SetSkeletonPos() instead of the instantaneous bone transformations, initial pose for the human is loaded correctly, except it is set horizontal than the expected vertical alignment. Curious whether I need to do any operation on raw transformation values read from COLLADA before it is set to OGRE bones. Transformation for each keyframe seems to be local trnasformation, but not the deltas.

A suspicion is whether this is due to the incorrect initial pose setup. That has some explanation why it works if the pose is set to initial pose with unexpected Z/Y direction, but rendered compeletely weird for consecutive frames. Also if the initial pose was not set, some human walk like animation is seen (more recognizable than before), still with scaling and some orientation and fewer deorientation issues.

Any suggestion ?

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

My modifications on top of gazebo_3.1 has been committed to the fork at following gazebo_3.1_actor_animation_fix.

BTW since the problem at hand now is different to the original issue, I was considering to open this as a new issue. But the modifications I've done haven't been verified and merged in to main source yet. So I am still posting under the same issue (#538).

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

I was able to get the animation working correctly in Gazebo (Had to do couple more fixes for where visual id is required). Then if the animation is initiated with .world file with a skin file name sub_16.dae, walk.dae, stand.dae, talk_a.dae, talk_b.dae or run.dae it fails. But it works for moonwalk.dae, sit_down.dae, sitting.dae and stand_up.dae. A workaround that I am using is to have a skin file of a correctly working DAE and have the animation file name to be any of the DAE files. It seems for the DAE files simulation become weird, there is a scale difference between the initial actor visual and skeleton armature. Anyhow now the actor animation is rendered fine on Gazebo simulator. However if I spawn a Turtlebot simulator with "turtlebot_simulator" ROS package and observed /camera/rgb/image_raw topic in RViz the pose of the actor is incorrect. There in RViz image, human is walking in a vertical plane instead of walking on the floor in a horizontal plane. Poses of all other objects in RViz are correctly rendered.

Scene in Gazebo window (for moonwalk.dae)

Image visualization for /camera/rgb/image_raw in RViz

My impression is if the scene is rendered properly in Gazebo simulator, RViz camera should see the same. Does the camera (Created by Turtlebot Kinect Depth sensor) ray trace the scene before or after Gazebo renders it in its window? Any suggestion?

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

Got it fixed! Now actor animation in Gazebo and RViz works like a charm after couple of years.

Issue had been assigning the visual id of actor to link pose message id and not assigning a non existing id to bone pose message in Actor::SetPose(). If the bone pose message has some existing visual id (by default 0 <-> refers to world_node), in Scene::PreRender() skeleton message processing it sets the pose for world_node.

[osrf-migration]

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

---

Nice! This is great work. We would love to see your work pulled back into Gazebo. Would you be willing to create a pull request?

[osrf-migration]

Original comment by Kalana Ishara (Bitbucket: pwkalana9).

---

:) It is a pleasure to bring back this great feature specially for HRI. I've just made a pull request for gazebo_3.1_actor_animation_fix

[osrf-migration]

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

---

Fantastic. Thanks! We will try to review your pull request as soon as possible.

[osrf-migration]

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

---

• changed state from "open" to "resolved"

pull request #1133

[osrf-migration]

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

---

• changed state from "resolved" to "closed"