autonomy's profile - activity

I am dealing with a 16-bit mono image, publishing it using image_transport. I have no issues with the raw data topic, I can view it directly, bag it, replay it, and view again. If I run rostopic echo /cam/image | grep step I get 1280 as the result.

When I'm using image_view _image_transport:=compressed, I get an error message saying this:

Unable to convert 'mono16' image for display: : 'Image is wrongly formed: step < width * byte_depth * num_channels or 640 != 640 * 2 * 1

I'm using a vanilla image_transport publisher without changing any parameters. Am I missing something or is this a bug in the image_transport plugins?

I read http://answers.ros.org/question/12327... and http://answers.ros.org/question/33772... questions and I am confused. I see people mention the possibility of running bash scripts via .launch files but I can't find any documentation describing how to do it. Is it even possible?

(I'm trying to delay the launch of a gpsd_client node because during startup it scans and usurps other serial ports.)

Export bag of CompressedImage to disk without decoding I have a bag of compressed images (/camera/image/compressed). I w

Image timestamps in files saved by extract_images... or another way? I bagged some image data and now I am running image

<node name="$(anon dynparam)" pkg="dynamic_reconfigure" type="dynparam" args="set /camera/image/compressed format 'pn

Is that documented? I don't see it on the wiki. I am dealing with an actual 16-bit image in the wild, not depth. Compres

mono16 image is wrongly formed when using compressed image_transport I am dealing with a 16-bit mono image, publishing i

Why do you say (x,y) is calculated using yaw? It should be the other way around - encoder counts from each wheel input

You've got a very difficult task ahead of you, given how you describe the requirements. On the surface, what you're try

Take a look here, maybe that can help increase the sensor frequency. Also, take care to set your magnetic_declination_ra

2Hz seems low for an IMU. I worked with IMUs running anywhere between 30 to 100Hz. You are requesting robot_localization

2Hz sounds low for an IMU. I worked with IMUs running anywhere between 30 to 100Hz. You are requesting robot_localizatio

For 2, did you try running view_frames to see how old your static transform is? (http://wiki.ros.org/tf2/Tutorials/Intro

Tom would be the authoritative input on this, but in the meantime - for your 1st problem, what frequency are you expecti

What @gvdhoorn wrote, plus - what is the name of your package / msg file?

Yeah, we have no idea what you're trying to do if you don't give us any specifics. Kind of like saying "combine phone in

Why isn't ROS using its own clock server for live situations? I'm well aware of the fact that if you run ROS nodes on mu

I'm trying to distribute a binary version of my package. I have the catkin_make install command create the install directory in the right place and copy the required libs. The contents of the install directory are as follows:

include

(contains exported packages with generated header files for messages)

lib

(contains 3rd party dependencies as well as exported packages with executables)

share

(contains exported packages with misc. files such as package.xml)

My problem is that when I copy this directory to a new computer, I can't use ROS to run anything from it. I tried doing the following on the new machine within the distributed install directory:

• Create a src directory
• Run catkin_init_workspace
• Run catkin_make to generate the devel and build directories
• Source the generated devel/setup.bash script

rosrun my_package my_package_node still doesn't find my package. What can I do to get ROS to see my installed packages the way packages in /opt/ros/indigo work?

I am trying to set up a pan/tilt base with two Dynamixel servos and I would like to use joint_state_publisher with robot_state_publisher to publish the transforms (and maybe even control the joints via joint_state_publisher's GUI).

The problem is that the dynamixel_controllers stack publishes dynamixel_msgs/JointState messages while joint_state_publisher expects sensor_msgs/JointState messages, and the two are incompatible.

My Google-Fu failed to turn up any existing conversion between dynamixel_msgs and sensor_msgs JointState messages - but I have seen out there Dynamixel-based robots visualized in Rviz. Are my only options to publish my own transforms with the Dynamixels or write my own conversion between the two different JointState messages? Maybe someone can suggest an existing open-source solution?

I am experimenting with a robot which is supposed to follow a beacon outside. The waypoints are sent at 1Hz (I could go faster) and are within 3 to 10 meters of the robot. I tried using move_base with the built-in planners but had unsatisfactory results.

• DWA planner's motion was good but it made the robot pause at every goal update making for unsmooth motion
• TrajectoryPlannerRos starts oscillating on straightaways, that type of motion isn't acceptable
• TebLocalPlanner was a mix of the two, but it did a lot of spinning in place and eventually would cause the map update loop miss its target update rate

I tried to play with oscillation reset flag and other parameters but still did not achieve good results and to be honest, I'm not really sure how most of these work. I am starting to think that these planners weren't meant to be used for what I'm using them for. Is there a better planner for me to use such that I can update it frequently yet still get the benefit of obstacle following? If not, are there parameters I should be tuning that will make path updates faster and smoother? (local map size/resolution? oscillation flag? others?)

How to tune move_base local planners for frequent goal updates I am experimenting with a robot which is supposed to foll