basheersubei's profile - activity

This was ages ago, so I'm not sure but I think it was just image_geometry package. Good luck! :)

I'm running Indigo (with catkin) on Ubuntu 14, and I'm trying to use the image_geometry package in Python(without roslib). When I import the package and try to instantiate a PinholeCameraModel object, it errors out and says: AttributeError: 'module' object has no attribute 'PinholeCameraModel'. Here is the full error.

I have image_geometry installed from apt-get, and my package.xml has both build_depend and run_depend for the image_geometry package. My code is below:

#!/usr/bin/env python
import rospy
import image_geometry

if __name__ == '__main__':
    rospy.init_node('blabla_node')
    cam_model = image_geometry.PinholeCameraModel()

    rospy.spin()

My end goal is to run projectPixelTo3dRay() on image pixels and find their intersection with the ground plane.

I ran a Python shell session and tried dir(image_geometry) and it only displayed this: ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__']. I'm assuming this means it hasn't imported it properly.

Below is my PYTHONPATH in case it matters (I even added the path of image_geometry to it):

/opt/ros/indigo/lib/python2.7/dist-packages/image_geometry:/home/basheersubei/edt_ws/devel/lib/python2.7/dist-packages:/home/basheersubei/edt/new_ws/devel/lib/python2.7/dist-packages:/opt/ros/indigo/lib/python2.7/dist-packages

What am I doing wrong? Can someone provide an example on how to instantiate a PinholeCameraModel object? The only example I found here is where I got this from and it doesn't work.

EDIT I installed image_geometry from source and it worked just fine now... Even running dir(image_geometry) in Python shows the PinholeCameraModel correctly... I'm so baffled. Should I file a bug report? Does anyone else have this issue?

EDIT 2 I just tried this on another Ubuntu 14 machine (same setup) and it seems to work from the debian package... No idea what's going on...

Anyone ever find a solution to this? I think it's pretty important (arduino wifi + ROS = HOLYOMFGWTFBBQ)

Can someone check this? Is this a bug in rospy?

Oh my God this worked! I spent days trying to figure this out (at first I thought rospy had a bug with queue_size).

I think what's happening is that the default buff_size is too small for images, and so rospy just decides to use default infinite queue_size (and setting it to 1 won't help).

bump? bump bump bump?

I have a Python ROS node that subscribes to a topic of message type CompressedImage. So far it works fine (I play a rosbag with compressed images, run my node, and it correctly reads them [I checked using cv2.imshow()].

I'm probably misunderstanding what the point of compressed_image_transport is. My question is:

If I have a ROS node (say usb_cam) publishing compressed image messages, and my Python node subscribes to those compressed images (specifying sensor_msgs.msg.CompressedImage as the message type), why would I ever need image_transport or republish for my node (I know image_transport is being used in the publishing node, i.e. usb_cam, but not in my Python node). What's the point of image_transport republish in such a case?

I have a Python ROS node that subscribes to a topic of message type CompressedImage. So far it works fine (I play a rosbag with compressed images, run my node, and it correctly reads them [I checked using cv2.imshow()].

I'm probably misunderstanding what the point of compressed_image_transport is. If I have a ROS node (say usb_cam) publishing compressed image messages, and my Python node subscribes to those compressed images (specifying sensor_msgs.msg.CompressedImage as the message type), why would I ever need image_transport or republish for my node (I know it's being used in the publishing node, i.e. usb_cam).

by the way, my implementation (the one that didn't work) converts the pixels to PointCloud2 data (if that helps)...

Given that I have the following:

• known pixels from an undistorted image (taken by monocular camera)
• fixed angle of inclination of camera
• fixed height of camera and flat terrain (so the height from camera to ground is fixed)
• intrinsic parameters of the camera (published over /camera_info), and also field-of-view angle

How can I find the 3-d (well, 2-d really since height is fixed) location (in the real world relative to the camera) of each pixel? i.e. what ROS packages/nodes should I use that have that functionality? I've been searching for a solution within ROS for weeks (and I'm surprised that no one has needed this before).

I attempted my own solution using some trigonometry, but it doesn't seem to work well (my equations must be off).

Is something like projectPixelTo3dRay in image_geometry what I'm looking for?

Perhaps I simply don't know WHAT to look for when I'm searching... Can anyone point me in the right direction? I can't seem to figure this out on my own...

I noticed I can find more about it here http://wiki.ros.org/base_local_planner#LatchedStopRotateController . I will attempt to do the Navigation tutorials for now. Thanks again!

thank you for your reply. Do you have any idea where I can learn more about the latched_stop_rotate_controller and what to expect of it? Should I basically not worry about implementing a control system (for reaching goals) in my base_controller?

I haven't started working on the Navigation stack, because I need to first figure out my base_controller (and I need to find out what it should expect from Navigation). Basically, does Navigation take care of going from one point to another in a controlled manner (without overshoot)?

surely, you mean create a subscriber, not a publisher, right?

So I'm trying to wrap my head around which node exactly does the control system for moving a specific distance in the Navigation stack (using current velocity from /cmd_vel). I came to the conclusion that move_base is responsible for this, but now I'm wondering: what kind of control system does it implement? How does it know what cmd_vel to publish in order to reach the specific distance it must go? Is it a PID controller or something?

I'm mostly asking this just to make sure that I understand this right... I basically want to make sure that my robot moves to the designated destination in a controlled manner (not just full speed until it reaches target then stops and overshoots)...