Patrick Bouffard's profile - activity

There should be some straightforward guidelines as to which one to pick. Also what is the scope of answers.ros.org , is it the same as ros-users? What about questions that would otherwise have been asked on ros-developers, ros-kinect, or pcl-users?

I've noticed that when I google something, e.g. "roslaunch machine tag", that the results that typically show up for the wiki pages are from the UMD mirror of the wiki rather than the wiki itself. I'm not sure when this started happening but it definitely didn't happen before, as this has always been my (admittedly somewhat lazy) way to access the documentation.

Did something change on the server side of the (real) wiki that is making Google avoid it in search results? It might not just be Google, either--I'm having trouble getting Bing to return any ros.org wiki results either..

The most that the wiki page says about these is:

Removed in ROS 1.1

The -q and -t options were removed from the command-line and replaced with check boxes in the toolbar.

What exactly do they actually do?

I'm a bit confused about this. The Eigen wiki page indicates that, for Fuerte, a package's manifest.xml needs to have

  <depend package="common_rosdeps" />
  <rosdep name="eigen" />

.. but the common_rosdeps wiki page says that this "stack/package" (which is it?) is "deprecated" and "no longer necessary".

I've tried commenting out both lines above and my code still seems to build happily so maybe this only matters in a rosinstall situation (which I tend not to do). But at any rate the information on the Eigen wiki page is still a bit confusing since it recommends depending on a deprecated package.

In Electric and earlier it was possible to do

rosrun rxtools rxplot

.. more importantly, this means that in launch files I could do

<node pkg="rxtools" type="rxplot" name="my_plot" args="/some/topic" />

and so on. It looks like this is no longer possible in Fuerte; only rxconsole and rxloggerlevel seem to be rosrun-able now.

So is this intentional? If not I'll file a ticket. If so could someone suggest a workaround to allow rxplot to be launched from a launch file?

The main website/wiki, code.ros.org, and willowgarage.com all seem to be down.

I was just looking into the use of the <export> tag and noticed a couple of problems on the wiki page for manifest.xml:

• There is an error message:

  Unsupported navigation scheme 'Menus/ROSFilesystemConcepts'!

  at the top of the page

• Clicking on the "manifest.xml tags reference" link takes you to a page titled "ROS packages Fuerte documentation" which doesn't seem correct given that Fuerte isn't out yet.

I feel a vague sense of guiltiness reporting a bug on answers.ros.org--probably it should go on trac but I'm feeling lazy. If in fact it would be better to report it there, it would be nice if every wiki page had a link somewhere that got you to the right part of trac to report wiki problems...

I haven't released anything yet or even really settled on version numbering schemes etc. But I'd like to at least start some version numbering. Should I be using branches, tags, or both? Are there (de facto or otherwise) any rules on naming of branches/tags?

It looks like there is some related information on the rosdistro/rules page but I wonder whether that's the whole story.

Although I don't have a timeline for using the full-blown ROS release process, I want to avoid having difficulties if/when it does come to doing a release.

One thing that might help is to look at well-maintained repositories that have releases, and use Mercurial. Ideally they also are hosted on bitbucket like my repo but that's less important. I thought I once saw a breakdown of ROS repositories by VCS type, am I recalling correctly?

I'm starting to write a new node(let) and initially wrote my launch file to start that nodelet 'standalone'. However I noticed that messages from the rosconsole macros (ROS_INFO(), ROS_ERROR and the like -- and there is no difference if I use the nodelet wrapper versions, i.e. NODELET_INFO() etc.) were not showing up. I tried initially mucking around with logger levels but that didn't seem to have an effect. Then I tried starting a nodelet manager and loading my nodelet into the manager. Then the messages appeared.

I'd been (mistakenly I suppose) assuming that for all intents and purposes running a nodelet 'standalone' and running a single nodelet within a nodelet manager were equivalent but it seems that this isn't the case, at least for the output of the rosconsole logging macros.

So my question is, is what I've observed expected behaviour and are there any other differences to be aware of when running a nodelet 'standalone'? Aside from requiring one less <node> tag in a launch file is there any advantage of using the standalone method as opposed to loading a single node into a nodelet manager?

The wiki page for tf2 doesn't give any obvious indication that tf2 is experimental, though I can imply that by the fact that it's in the geometry_experimental stack. Regardless, I'm curious about how tf2 differs from tf, how far along in the development process it is, if it is targeted to replace tf at some point and if so when, etc.

EDIT: Another relevant page, though it doesn't quite answer the questions I have.

I recently came across this error when running roswtf to try and diagnose the cause of a weird intermittent failure:

ERROR The following packages have rpath issues in manifest.xml: * flyer_controller: found flag "-L/home/bouffard/ros/starmac-ros-pkg/starmac_flyer/flyer_controller/lib", but no matching "-Wl,-rpath,/home/bouffard/ros/starmac-ros-pkg/starmac_flyer/flyer_controller/lib"

The manifest actually has this (note the -L after the rpath):

  <export>
    <nodelet plugin="${prefix}/flyer_controller_nodelets.xml"/>
    <cpp cflags="-I${prefix}/include" 
         lflags="-L${prefix}/lib -Wl,-rpath,-L${prefix}/lib -lros"/>
  </export>

.. and the package (and others which depend on it and use the library) does build and seems to work.

If I remove that -L then the roswtf error goes away. However according to the example on the Manifest/XML wiki page the -L should be present; I don't actually know what all these flags do but the -L just seems out of place there to me. My guess is that the wiki page is incorrect, but I don't quite see how I never had build problems with the wrong syntax.

In particular, I am sending some joy/Joy messages over a WLAN and am hinting ros::TransportHints().unreliable() in the subscriber (the publisher is a joy/joy_node).

I've occasionally seen a delay of > 0.5 s, where the in the received messages based on timing within the subscriber's callback, and I'd like to see if that might have to do with dropped UDP packets. I was thinking that I would just look at the header.seq field in each received message, looking for and increment greater than 1, and then realized that joy/Joy messages have no header.

Am I SOL or is there some way to determine whether messages are being dropped?

I also wonder about out-of-order messages which I think are theoretically possible with UDP and was hoping to also watch out for those in a similar manner. Maybe a Header could be added to joy/Joy in a future release?

.. and why are there so many connections involving them. e.g.:

bouffard@lipschitz:~/ros$ rosnode info /pelican2/camera1394_nodelet
--------------------------------------------------------------------------------
Node [/pelican2/camera1394_nodelet]
...    
contacting node http://pelican2:59141/ ...
Pid: 7324
Connections:
...
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/camera1394_nodelet
    * direction: outbound
    * transport: INTRAPROCESS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/camera_nodelet_manager
    * direction: outbound
    * transport: TCPROS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/jplvision_node
    * direction: outbound
    * transport: TCPROS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:59141/
    * direction: inbound
    * transport: INTRAPROCESS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:35545/
    * direction: inbound
    * transport: TCPROS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:52260/
    * direction: inbound
    * transport: TCPROS

and

bouffard@lipschitz:~/ros$ rosnode info /pelican2/camera_nodelet_manager
--------------------------------------------------------------------------------
Node [/pelican2/camera_nodelet_manager]
...
contacting node http://pelican2:35545/ ...
Pid: 7317
Connections:
...
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/camera_nodelet_manager
    * direction: outbound
    * transport: INTRAPROCESS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/camera1394_nodelet
    * direction: outbound
    * transport: TCPROS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: /pelican2/jplvision_node
    * direction: outbound
    * transport: TCPROS
...
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:35545/
    * direction: inbound
    * transport: INTRAPROCESS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:59141/
    * direction: inbound
    * transport: TCPROS
 * topic: /pelican2/camera_nodelet_manager/bond
    * to: http://pelican2:52260/
    * direction: inbound
    * transport: TCPROS
...

In particular I'm interested why there are multiple connections on the same bond topic, some of which are using transport TCPROS despite the use of nodelets?

Edit with a followup question:

Doesn't having a 'spawner' process that hangs around for the lifetime of my nodelet, and moreover, is constantly communicating over TCPROS, defeat some of the main purposes of having nodelets, namely to reduce the number of processes and unnecessary network-level communication? In all my use cases at least, nodelets are a nice way to couple together what would otherwise be nodes but I don't need any of the respawning behaviour that you describe--either the entire manager plus its loaded nodelets are up, or they are all down. Could the 'spawner' nodes optionally exit after their nodelet has been loaded successfully?

I've started to look at using camera1394 for my Point Grey Firefly MV USB camera. This camera implements 1394-over-USB and seems to work fine with camera1394 as far as I can tell, with one exception: The timestamps on the output are incorrect. They are typically sometime in January 1970 :)

---
header: 
  seq: 191
  stamp: 
    secs: 34
    nsecs: 533856000
  frame_id: /camera

Looking at the code it seems that the timestamp is generated using data from the camera:

image.header.stamp = ros::Time((double) frame->timestamp / 1000000.0);

I'm not sure why the timestamp is nonzero--it could just be from uninitialized memory. These cameras _do_ have an option to output some kind of timestamp, and I have enabled it, but in their own tool ("FlyCapture2"), the "seconds" and "microseconds" fields are zero even with this option enabled. There are however some other fields, "1394 cycle time seconds", "1394 cycle time count", and "1394 cycle time offset" but this seems to be time since capture started, not since the epoch.

Anyhow the question is, has anyone else using these cameras found a way to have the true timestamp included in the image/camera_info header?

UPDATE: Here is what is printed when camera1394_node is started:

$ rosrun camera1394 camera1394_node _guid:=00b09d010090a878
[ INFO] [1299180874.481328850]: Found camera with GUID b09d010090a878
[ INFO] [1299180874.481629395]: camera model: Point Grey Research Firefly MV FMVU-03MTM
[ INFO] [1299180874.490429490]: [00b09d010090a878] opened: 640x480_mono8, 15 fps, 400 Mb/s
[ INFO] [1299180874.528790077]: feature exposure value not available from device
[ WARN] [1299180874.612162273]: [00b09d010090a878] calibration does not match video mode (publishing uncalibrated data)

Or even just on Linux--the ROS interfacing is probably relatively simple. I'd be interested to hear of anyone's experiences with any kind of haptic input devices, though I'm interested mostly in something like a force-feedback joystick, as opposed to extremely high resolution haptics used for robotic surgery and the like. Thanks!

Background: I just had some difficulty rebuilding a stack (openni) after copying it to a new directory, and the failures were due to the old path being cached somehow, even when using rosmake --pre-clean. The solution seems to have been to do 'make wipe' in the affected packages. Is there something like rosmake --wipe? Was there a better way to do this?

(edit: question title was originally "Should I always use rosmake or can I use make sometimes?" but I went on a bit of a tangent in the body. The new title is a bit better I think.)

And if so, how?