PedroGusmao's profile - activity

It seems that creating a Matrix3X3 from the quaternion is not necessary since a transform already contains the rotation matrix. If you are working with TF, inside every Quaternion there is a Matrix3x3 called m_basis. When you call Transform::getRotation(), what you get is

From http://docs.ros.org/indigo/api/tf/htm... :

00120         Quaternion getRotation() const { 

00121                 Quaternion q;

00122                 m_basis.getRotation(q);

00123                 return q;

00124         }

So it could be that you may get away with:

transform.getBasis().getRPY(roll, pitch, yaw);

Hi there, I am using a single camera for visual odometry. The camera is fixed to the robot and I use the common approach of matching descriptors between consecutive frames and then estimating the rotation and translation using SVD. The camera is already calibrated and I already have the points in 3D position.

From the rotation matrix and the translation matrix I can obtain the the rotation angles and the new position x,y,z of the robot.

My question then is: How can I estimate the covariance matrix for theses values in order to publish an nav_msgs::Odometry matrix? I suspect that I have to backpropagate the points from one frame to the other, but I am not sure. Any references to papers/books are also welcome =)

Thanks in advance,

Pedro

Hi, I think I have found the answer.

The problem is how to treat the "pixel binning" fields of the Camera Info Messages. The driver I am using actually publishes that the camera has already processed the original image and has used a 2x2 pixel binning to reduce the size of the image alongo with the new (reduced) dimension of the image. The package image_proc however, uses that information once again to generate an empty matrix for the rectified image. i.e.: My camera driver uses Format7 Video Mode 0 to produce a 1024x1024 image (after binning its original 2048x2048 using 2x2 bins).

The problem is that it also publishes the binning information, so

binning_x: 2
binning_y: 2

Which causes some problems for image_proc for it tries to generate a (1024/2)x(1024/2) empty matrix which will be partially filled up with the rectified frame...

See ya

Hello,
I am currently publishing an image which is 1024x1024 pixels and I am trying to rectify it using image_proc. The output of my /camera/camera_info is:

header:
seq: 3692
stamp:
secs: 1405337388
nsecs: 154563950
frame_id: camera
height: 1024
width: 1024
distortion_model: plumb_bob
D: [-0.183149270183746, 0.139143255380374, 0.00225718725189143, 0.00131346587970189, 0.0]
K: [1189.58587069262, 0.0, 501.625685647322, 0.0, 1188.97100074168, 550.474655398214, 0.0, 0.0, 1.0]
R: [1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]
P: [1151.62145996094, 0.0, 501.542604357335, 0.0, 0.0, 1150.24182128906, 553.703494449055, 0.0, 0.0, 0.0, 1.0, 0.0]
binning_x: 2
binning_y: 2
roi:
x_offset: 0
y_offset: 0
height: 0
width: 0
do_rectify: True

While the header of the output of /camera/image_raw is:
header:
seq: 7082
stamp:
secs: 1405337872
nsecs: 724561256
frame_id: camera
height: 1024
width: 1024
encoding: mono8
is_bigendian: 0
step: 1024

So the problem is that, when I run $ROS_NAMESPACE=camera image_proc image_proc I get images to be published at /camera/image_rect that have the following header:

header:
seq: 20
stamp:
secs: 1405338132
nsecs: 447977005
frame_id: camera
height: 512
width: 512
encoding: mono8
is_bigendian: 0
step: 512

I can see with image_view that the image in the rectified version is only the 512x512 upper left of the original 1024x1024 image_raw Does anyone know why image_proc is only grabbing only the first upper 512x512 pixels of my image? It seems to me to be some kind of ROI problem, but I cannot see where...

Thanks in advance, Pedro

Hi there, I have a single rgb camera with known intrinsic parameters mounted to a robot together with a chessboard pattern fixed the robot's base.

The chess board is fixed and I already publish its transform relative to the base, but the camera position may change (tilt) overtime which will certainly influence on the visual measurements I am making.

So my question is: Is there a node/package that I can use that automatically publishes the TF for a camera given a fixed pattern? I remind you that I already have the intrinsics parameters and that theses are published using CameraInfo.

Thanks, Pedro

Hi, I am currently developing a ROS packages to to PointGrey Grasshopper3 and I've seen that some packages like the camera1394 use more than one node handler. Does anyone know why?

Thanks,

Pedro

Nop... Moved to Ubuntu 12.04. Although I like Debian better, it is too much hassle

Worry no more! Where there is a hack... there is a way! Now, I have just installed Ubuntu 13.10 to later find out that it is not supported by Hydro... Sad but true...

Anyway, the thing is that the meta-package ros-hydro-desktop-full installs also gazebo, which is a simulator that requires libogre-dev to be installed. libogre-dev on the other hand needs libboost1.49 but everyone else has already already moved on to libboost1.53...

So what do we do? Simple... We compile libogre-dev and make it look like it is native package installed! This means that you have to: 1) Install libboost1.53-all-dev ( I install it all, so dependency won't be a problem) 2) Download libogre-dev source code from http://bitbucket.org/cabalistic/ogredeps 3) Cmake the project and generate the Makefile 4) Use 'sudo checkinstall' ( http://www.linuxjournal.com/content/u... ) to generate and install your libogre-dev package. BUT REMEMBER TO CHANGE THE FOLLOWING: Name of the Package: libogre-dev Version: 1.7.4+dfsg1-7 This way you are tricking ubuntu's package management system into thinking you have the original package. OBS: At this point, you have installed a libogre-dev that has been compiled with libboost1.53. I don't guarantee that gazebo will run perfectly or that it will work at all...

5) Proceed with ROS for Raring as described here: http://wiki.ros.org/hydro/Installatio...

See ya