m4nh's profile - activity

Hi, i'm not sure if it's correct to ask something about PyKDL here but this is a bug produced by a ros node. The question is very simple, i have a PyKDL.Frame and i notice that its conversion to translation/quaternion (before send it to TF Broadcaster) si malformed. The following two rows:

print frame, "\n"
print frame.M.GetQuaternion()

produce this result:

[[ 3.21075e-06, 3.21074e-06,   -0.999999;
 -3.21074e-06,   -0.999999,-3.21075e-06;
    -0.999999, 3.21075e-06,-3.21074e-06]
[    0.632574,    0.982814,     3.08063]] 

(0.0039903364268270795, 0.0, -0.003990323614818683, 0.00040231585169223024)

The last row is the quaternion but is wrong since the previous Rotation component seems to be a canonical base (0.99999999 should be equal to 1, and xxe-06 should be 0).

In RVIZ the corresponding TF is slightly titled, that is why i realized the presence of something wrong. Thanks

I found the problem!! It's a very strange bug... if you do:

voxels_marker.points.resize(N)

and for some reason you iterate over only

M < N

points.. this strange z_buffer problem happens

Something strange happens when i try to display CUBE_LIST in RVIz. As shown in figure: https://dl.dropboxusercontent.com/u/1...

First of all you can see that cubes are a little bit transparent since world grid is visible under them, despite alpha setted to one per cubes:

voxels_marker.colors[i].r = voxels[i].data->r;
voxels_marker.colors[i].g = voxels[i].data->g;
voxels_marker.colors[i].b = voxels[i].data->b;
voxels_marker.colors[i].a = 1;

And you can see that right part of cube list seems to be (almost) correct, but left part has some problem with z-buffer because furthest cubes are drawn before nearest.

How can i figure out ?

@gvdhoorn this is the example node: https://dl.dropboxusercontent.com/u/1... there is an external parameter per_vertex_color (bool) to activate/deactivate the malfunctioning.

the result of "per color vertex" method is the one shown in the attached figure

The issue is resolved by removing colors per each vertex! If you resize marker.colors array to the same size of marker.points array (and choose some color for each vertex) the color of rendered faces is forced to ignore light and shader. Leave colors array void and change only the marker.color parameter to paint your mesh.

In this example is just a simple node with no TF tree behind. I just set frame_id as "world" and set "world" as base frame in Rviz.. so i think is an Identity transform... could this be the problem?

Yes! It looks like flat from every vantage point. Reversing order of triangle makes all mesh go away.

Why if i create a Mesh triangle-by-triangle by using visualization_msgs::Marker (type=TRIANGLE_LIST) the shader doesn't take into account normals ? Surface shader is not working. See attached image: