rohan_k's profile - activity

Hi,

I'm trying to run the navigation stack on my own robot. I have run through the RobotSetup Tutorial and have made sure I am publishing everything I am required to.

I have published the tfs such that I have a tree that looks like map-->odom-->base_link-->base_sonarA (which is the sonar sensor I am using - data being published as a LaserScan message). However I am getting this error:

[ WARN] [1328706898.660733327]: MessageFilter [target=/map /base_sonarA ]: Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.
[ WARN] [1328706899.306808499]: MessageFilter [target=/odom /base_sonarA ]: Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.

Then when I turn on DEBUG as suggested, I get this:

[DEBUG] [1328707633.947505776]: MessageFilter [target=/map /base_sonarA ]: Removed oldest message because buffer is full, count now 50 (frame_id=base_sonarA, stamp=0.000000)
[DEBUG] [1328707633.956223854]: MessageFilter [target=/map /base_sonarA ]: Added message in frame base_sonarA at time 0.000, count now 50
[DEBUG] [1328707633.964573867]: MessageFilter [target=/odom /base_sonarA ]: Removed oldest message because buffer is full, count now 50 (frame_id=base_sonarA, stamp=0.000000)
[DEBUG] [1328707633.984351031]: MessageFilter [target=/odom /base_sonarA ]: Added message in frame base_sonarA at time 0.000, count now 50`

When I run rosrun tf tf_echo map base_sonarA I get:

At time 1328707774.058
- Translation: [2.283, 0.489, -0.035]
- Rotation: in Quaternion [0.000, 0.000, 0.829, 0.560]
        in RPY [0.000, -0.000, 1.953]

So the transform exists, but from what other threads have told me, this means the transform on the data is not happening.

As a result of this, I can't use the sensor data and hence the stack doesn't work.

Does anyone know what the problem could be?

Thanks!

EDIT 1:

Sample message from sonar sensor (LaserScan message) using rostopic echo sonar_dataA )

---
header: 
  seq: 821
  stamp: 
    secs: 0
    nsecs: 0
  frame_id: base_sonarA
angle_min: 0.0
angle_max: 10.0
angle_increment: 0.10000000149
time_increment: 1.0
scan_time: 0.10000000149
range_min: 0.00999999977648
range_max: 1.45000004768
ranges: [1.4827419519424438]
intensities: []
---

Hi, I have been using rviz with no problems up until recently where upon using "rosrun rviz rviz" it begins loading and then promptly crashes and shuts down:

rosrun rviz rviz

INFO [1311775709.546537962]: Loading general config from [/home/ros/.rviz/config]

INFO [1311775709.546746875]: Loading display config from [/home/ros/.rviz/display_config]

ERROR [1311775712.566807201]: Caught exception while loading: OGRE EXCEPTION(7:InternalErrorException): Cannot create GL vertex buffer in GLHardwareVertexBuffer::GLHardwareVertexBuffer at /code/ros/visualization_common/ogre/build/ogre_src_v1-7-1/RenderSystems/GL/src/OgreGLHardwareVertexBuffer.cpp (line 46)
Segmentation fault

I have tried cleaning and rebuilding it, but to no avail. I also haven't (knowingly) modified any files that are involved with rviz.

Any ideas?

Thanks!

Hi,

I was running the tabletop_object_detector and despite always previously working, a new error has arisen (potentially as a result of "rosmake"ing some files?):

/code/shared/sr-ros-interface/public_safety/shadow_robot/tabletop_object_detector/bin/tabletop_complete_node: error while loading shared libraries: libpcl_ros_io.so: wrong ELF class: ELFCLASS64 [tabletop_complete_node-3] process has died [pid 22274, exit code 127]. log files: /home/ros/.ros/log/07310876-b471-11e0-912d-00252274d18f/tabletop_complete_node-3*.log

A google search leads me to believe it's an issue with the fact that it is a 64-bit library when it should be a 32-bit one - any ideas how to fix that? the error is only with "libpcl_ros_io"

Thanks for the help in advance as ever!

Hi, I am trying to run the 'sr_control_gui' on a different machine to the rest of the system and I am getting this error:

[ERROR] [1311084061.470869449]: Client [/sr_control_gui] wants topic /object_manipulator/object_manipulator_pickup/result to have datatype/md5sum [object_manipulation_msgs/PickupActionResult/37706bf50c1b11b7802944213b641a54], but our version has [object_manipulation_msgs/PickupActionResult/f5b810c9cd81bc41f3d404d9b45717b9]. Dropping connection.

From what I understand of it, there is an incompatibility between the messages/topics being published by the different computers, manifesting as an issue with "md5sum"? How can I fix it?

Thanks in advance.

Hi,

I'm running the Navigation Stack on my robot with no map, and publishing Point cloud messages to represent data coming in from Sonar sensors. Though I can plot the locations of the obstacles in Rviz using markers, they won't add to the costmap properly, such that even when an obstacle has been in range for a while, typing rostopic echo /move_base/local_costmap/obstacles results in:

header: 
  seq: 153
  stamp: 
    secs: 1328893241
    nsecs: 331444433
  frame_id: /odom
cell_width: 0.0500000007451
cell_height: 0.0500000007451
cells: []

I imagine when an obstacle is seen within range (which it is, as can be seen in Rviz), the cells: [] array becomes populated?

But it isn't - does anyone have an idea as to why not or what the problem might be? I've tried to post what I think might be useful below.

Thanks in advance,

Rohan

My yaml files and launch files look like this:

move_base.launch:

<launch>
  <master auto="start"/>

<node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
<rosparam file="$(find quadcopter_2dnav)/yaml/PC_params_costmap2d.yaml" command="load" ns="global_costmap" />
<rosparam file="$(find quadcopter_2dnav)/yaml/PC_params_costmap2d.yaml" command="load" ns="local_costmap" />
<rosparam file="$(find quadcopter_2dnav)/yaml/local_costmap_params.yaml" command="load" />
<rosparam file="$(find quadcopter_2dnav)/yaml/global_costmap_params.yaml" command="load" />
<rosparam file="$(find quadcopter_2dnav)/yaml/local_costmap_params.yaml" command="load" />
</node>

</launch>

global_costmap_params.yaml:

global_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: false

local_costmap_params.yaml:

local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05

PC_params_costmap2d.yaml:

global_frame: odom
robot_base_frame: base_link
update_frequency: 20.0
publish_frequency: 20.0
publish_voxel_map: true
static_map: false
rolling_window: true
width: 6.0
height: 6.0
resolution: 0.025

map_type: voxel
origin_z: -0.1
z_resolution: 1
z_voxels: 32
unknown_threshold: 10
mark_threshold: 0

transform_tolerance: 0.3
obstacle_range: 2.5
max_obstacle_height: 1.0
min_obstacle_height: 0.10
raytrace_range: 3.0
footprint: [[-0.4, -0.4], [-0.4, 0.4], [0.4,0.4], [0.4, -0.4]]
footprint_padding: 0.01
inflation_radius: 0.55
cost_scaling_factor: 10.0

observation_sources: point_cloud_sensorA

point_cloud_sensorA: {sensor_frame: 'base_sonarA', data_type: PointCloud, topic: '/sonar_data_to_pointcloud/point_cloud_sonar_dataA', marking: true, clearing: true}

EDIT 1:

After changing min_obstacle_height to -1, the obstacle message remains the same as above. The point cloud message being published looks like this:

header: 
  seq: 380
  stamp: 
    secs: 1328903308
    nsecs: 169542053
  frame_id: base_link
points: 
  - 
    x: 1.16724598408
    y: 0.0
    z: -0.035000000149
channels: 
  - 
    name: intensities
    values: [100.0]

Hence the point being registered is within range, yet it still doesn't appear on the obstacle list in the local costmap.

There are a couple of possibilities here:

1. Something is wrong with your tf tree, and it isn't possible to transform sonar data into the base frame
2. Your sonar data is being published with the wrong frame in the header
3. Your sonar data is being published with the wrong timestamp in the header

I suspect one of the latter two problems; if you can capture and post a sample sonar message, that should narrow things down.

EDIT:

After looking at your sample message, this is definitely due to improper timestamps in your sonar messages. It should be relatively simple to set header.stamp to the current time for every message.

This is a problem because tf works in both space and time; since some frames move with time, it buffers a short history so that it can transform scan data taken a few seconds ago between moving frames. The buffer is relatively short, so it doesn't have enough information to transform data that's more than a few seconds old, much less all the way back to unix time 0 (Dec 31, 1969!).