Asomerville's profile - activity

In the dynamic_reconfigure tutorial, it is claimed that dependence on driver_base is specific to the tutorial, yet an enum type from driver_base is used to set the 'reconfiguration level'.

Is this just a field to be interpreted however we like, and just used with the driver_base/SensorLevels message in this case? Or is the driver_base/SensorLevels message the standard for the 'reconfiguration level' field semantics?

I'm wondering if mappings are dynamic or handled centrally enough that it would be possible to remap a nodes topics at runtime without requiring specific support within the node.

I've seen a post on the old mailing list that suggested it was not supported, but I'm wondering more specifically if it's even feasible if one's inclined to dig below supplied tools.

Implicit question: how does remapping work under the hood?

The information is available in the camera_info message, but using standard functionality to convert would be much less error prone, and much less sloppy. Does such functionality exist?

Often when debugging, a launch which was responsible for the original Master goes down. When this happens things that were connected that stay up are unable to communicate with the new Master when it comes up.

• Is there a way around this?
• Is it perhaps possible to reinitialize the node so that it connects to a new Master?

I have a situation where I'd like to kill all other nodes launched from the same launch file once another is finished doing its work.

When running stereo_image_proc, I'm attempting to view the point cloud data with rviz. However rviz complains and throws out the messages sayin "MessageFilter [target=/ ]: Discarding message from [/stereo_image_proc] due to empty frame_id".

I can find no reference to frame_id in stereo_image_proc, and I've tried fiddling with the fixed frame parameters in rviz to no avail.

Am I missing something obvious?

I'm going through the exercise of setting up a new project that needs to be combined with other build-from-source pieces, and dealing with many of the same issues catkin was designed to solve: dependency, packaging, finding, etc.

So, my questions are:

• Is it easy to use catkin with non-ros projects?
• Are there any ros-specific pieces which will make this difficult?
• Is there a plan to move catkin out into the wider debian/ubuntu ecosystem / into official apt repositories?
  • I know python-catkin, and python-bloom already are

In debugging nodlet issues, and considering which nodes can be consolidated into a single process via nodelets, it would be nice to be able to simply list all available nodelets. Is there a command that does this?

When ROS nodes crash, modifying launch files to run under gdb is often required to get a stack trace. And a full reattempt to produce the conditions of the crash is necessary.

75% of crash failures (made up number :) could probably be solved without running in the debugger if we could see where the crash happened on each failure.

Is there functionality built into ROS to handle this?

I was under the impression that anything in roscpp should also be available in rospy. WallTime is in roscpp but I can't find it in rospy.

Since Gazebo is deprecating URDF and moving to SDF, it seems like ROS might follow suit.

Is URDF depricated, or about to be?

If so are there tools which work with SDF? For instance will robot_state_publisher be able to handle SDF defined robots?

If not, should we be sticking to using URDF for defining our robot models?