Robotics StackExchange | Archived questions

Gazebo Set or GetWorldPos scaling issue

Hello,

Im am trying to simulate a cable-driven robot in Gazebo. It is only for visualization, hence I simply try to display the cables where they should stand.

However I am facing a strange scaling issue. The 8 cables should be running from the vertices of the frame to the ones of the robot. On the figure below I am representing that, together with simple spheres that are given a SetWorldPos at the several vertices position. It is crearly visible that the spheres are not displayed at the correct position. The frame spheres are inside the frame, and the robot ones are below the robot (4 of them being hidden in the box).

Actually, there is a ~1.24 factor between the displayed positions and the good positions. Note that when printing the positions, they correspond to the dimension given in the xacro file (I am only using simple geometric primitives). Scaling issue seems to be only in the visualization.

I thought it could be a unit issue ?

image description

Asked by Olivier on 2015-01-12 05:54:36 UTC

Comments

Could you post your model file? If you have a plugin associated with the model, could you make that available as well?

Asked by nkoenig on 2015-01-12 11:05:21 UTC

Answers

Ok, the model is divided in two files as the frame is static. The robot is an invisible Gantry ,we will use our modeling to make it move.

The considered plugin is CableTrack, called by robot_cab.xacro. For now it just tries to place the cylinders and the spheres according to the effector position. It also subscribes to the "scale" topic, because the error seemed proportional to the position.

Just to compare I wrote a small Python script that does the same computation for cable 1. The results are the same, but in Python the cable is actually passing through the robot and the frame vertices. So it is more a scaling of the URDF models.

cable_track.h cable_track.cpp frame.xacro.sdf robjv_cab.xacro.sdf test_cable.py

Asked by Olivier on 2015-01-13 04:43:38 UTC

Comments