mpthompson's profile - activity

Under ROS Hydro, I'm attempting to publish static transforms using the tf2_ros static_transform_publisher using the following in may .launch files:

<node name="tag00001_publisher" pkg="tf2_ros" type="static_transform_publisher" args="1.00 1.00 0.35 0.00 0.00 0.7071 0.7071 /map /tag00001" />

In my C++ code I want to use these transform. To do so making a call using the canTransform() method on the tf2_ros::Buffer object to make sure the transform can occur before getting the transform with the lookupTransform() method.

if (tf_buffer_.canTransform(map_frame_, tag_frame_, ros::Time::now(), ros::Duration(0.1), &tf_err) {
  ...
}

This method call will succeed the first time, but subsequent calls will fail. However, if I use tf to publish the static transform as shown below, the code above will always succeed.

<node name="tag00001_publisher" pkg="tf" type="static_transform_publisher" args="1.00 1.00 0.35 0.00 0.00 1.57 /map /tag00001 100" />

Is this an issue with the tf2_ros::Buffer.canTransform() not yet properly working with latched transform publishers?

What's puzzling to me is why the call to the canTransform() method will succeed once, but not on subsequent calls unless I'm using the tf version of the static_transform_publisher.

I have a feeling there is something missing in my understanding of tf2 and how the tf2_ros::Buffer class. Unfortunately, the tf2 tutorials are woefully outdated and not very helpful in this regards.

The electronic version of the book can be purchased online for about $15 from: http://www.lulu.com/spotlight/pirobot Definitely worth the money.

Yes, this is possible. If you don't have it already, I would suggest getting the book ROS By Example by R. Patrick Goebel. In this book Patrick goes step-by-step through the process required to get a robot similar to the Turtlebot up and running. This includes the nodes that implement motion control via motors, wheels and encoders and how they relate to the navigation and other ROS nodes which are not robot specific. With this information, you would gain a good sense of which turtlebot packages you would need to replace to get your specific platform running under ROS.

I'm working on camera based visual odometry node that publishes /tf transforms when fiducial tags are present within a camera image. As the image process is somewhat computationally heavy, I would only like to process images only when there is a subscriber that cares about the transforms from my node. The ImageTransport infrastructure provides a connectCallback mechanism for accomplishing this where client nodes subscribe to an image. However, I don't see there is a similar connect callback mechanism for the TransformBroadcaster which I'm using to send transforms. I presume this is because there is no way to tell when transforms a subscriber to /tf really cares about.

Is there a recommended way of accomplishing this? I presume I could create a service that clients can use to manually enable/disable image processing, but I was hoping for something a bit more automatic.

Thank you very much. That is indeed the problem I ran into. The following command worked for me to remove the older version of catkin-pkg that I must have installed at sometime with pip: "sudo pip uninstall catkin-pkg" This allowed the binary debian package to then be found and catkin_make was again happy.

Under ROS hydro, catkin_make has been working fine for me. However, now when I change to my local workspace and execute catkin_make, I get the following error:

~/catkin_ws $ catkin_make
Traceback (most recent call last):
  File "/opt/ros/hydro/bin/catkin_make", line 15, in <module>
    from catkin.builder import cmake_input_changed
  File "/opt/ros/hydro/lib/python2.7/dist-packages/catkin/builder.py", line 61, in <module>
    from catkin_pkg.workspaces import ensure_workspace_marker
ImportError: cannot import name ensure_workspace_marker

A few days ago there was a massive upgrade of packages for ROS hydro which I installed, but I'm not sure if that is related or not.

What might have broken with my ROS installation that is causing this error?

Any help would be appreciated. Thanks.

With ROS Groovy and Ubuntu 12.04 LTS on a Create based TurtleBot, I use the following to bring up the TurtleBot:

roslaunch turtlebot_bringup minimal.launch

I then use the following to bring up the dashboard (I can do this on the robot itself or on a workstation with the ROS_MASTER_URI and ROS_HOSTNAME properly set).

rqt -s create_dashboard

The "create_dashboard" comes up, but unfortunately doesn't seem to work as it did in Fuerte. If I had to guess, it looks like it's reporting Kabuki based information, although I have the Create base and I'm calling "create_dashboard". However, this is just a guess on my part. The information in the "Robot Monitor" window is:

Error Device Message /Input Ports Stale /Kobuki Stale /Sensors Stale

Unfortuantely, my silly karma is insufficient to post a link to how the dashboard looks, but the following may work.

http-colon-//i50.tinypic.com/2j2damf.jpg

It seems strange to me to see the "Kobuki" device -- as if the dashboard is somehow configured to look for Kobuki devices.

Has anyone actually got a Create based TurtleBot running with Groovy? I assume so since there are so many of them out in the wild. And if so, what needs to be configured to get correctly get the dashboard working with the Create devices rather than Kobuki devices.

I'm working on updating some old ROSSerial classes to work with the latest version of ROSJava under Groovy. To add support for parameters, I'm looking at the ParameterTree interface and it appears that one must know what the parameter type is before retrieving it -- getBoolean(), getInteger(), getDouble(), getString(), etc... Unfortunately, with ROSSerial only the name is passed up from the attached client and I don't know the type of the object prior to getting it from the ParameterTree. Can anyone suggest a way around this?

Looking at the implementation of DefaultParameterTree it appears that the XML RPC interfaces get a generic Object and then cast it as needed to support the API. It would be nice if the ParameterTree api included the option of returning the generic Object and then reflection could be used to cast the object to appropriate type for serialization to the ROSSerial client.

For the Python side of things, I recently needed to come up to speed pretty quickly with the Python syntax to better be able to make out the ROS examples in the language. I found a bunch of Python tutorials on YouTube, but I settled on the videos of the 2-day Python class given by Nick Parlante at Google for their employees:

http://www.youtube.com/watch?v=tKTZoB2Vjuk

It takes about 5 hours to sit through all the videos, but Nick is pretty good instructor and the class moves a long at a pretty good clip so you won't get bored if you are already generally familiar with basic programming concepts.

This class won't teach you everything about Python, but for the things that you didn't learn you be well prepared to then pick up the missing pieces from many of the Python programming books.