ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Random-I-Am's profile - activity

2013-05-05 13:41:59 -0500 received badge  Popular Question (source)
2013-05-05 13:41:59 -0500 received badge  Famous Question (source)
2013-05-05 13:41:59 -0500 received badge  Notable Question (source)
2013-04-10 11:30:35 -0500 received badge  Taxonomist
2013-03-11 21:49:36 -0500 received badge  Famous Question (source)
2012-12-05 01:21:24 -0500 asked a question NodeHandle::getParam() is unable to resolve Environmental variables

I have a launchfile in which I want to specify the path to a specific file, e.g. haarcascade_frontalface_alt.xml. Normally, I would just use the <param> tag like this:

<param name="haarcascade_filename" type="string" value="$(env ROS_ROOT)/../OpenCV/haarcascades/haarcascade_frontalface_alt.xml" />

and try to load it during initialization using NodeHandle::param():

ros::NodeHandle local_nh("~");
local_nh.param("haarcascade_filename", name_, std::string(""));

This is the way it is done for example in the face_detector stack. Assume that I now want to specify multiple files using a <rosparam> list:

<rosparam param="haarcascade_filename_list">["$(env ROS_ROOT)/../OpenCV/haarcascades/haarcascade_frontalface_alt.xml", "morestrings.."]</rosparam>

This is the way I'm trying to load all the entries of the list:

    XmlRpc::XmlRpcValue my_xmlrpc_haarlist;
    local_nh.getParam("haarcascade_filename_list", my_xmlrpc_haarlist);
    ROS_ASSERT(my_xmlrpc_haarlist.getType() == XmlRpc::XmlRpcValue::TypeArray);

    for (int32_t i = 0; i < my_xmlrpc_haarlist.size(); ++i) {
        ROS_ASSERT(my_xmlrpc_haarlist[i].getType() == XmlRpc::XmlRpcValue::TypeString);
        haar_filename_list_.push_back(static_cast<std::string> (my_xmlrpc_haarlist[i]));
    }

The problem is if I now do ROS_INFO_STREAM("Filename: " << supername_); and ROS_INFO_STREAM("Filename list: " << haar_filename_list_.at(0)); the results are not the same:

[ INFO] [1354712164.859028413]: Filename: /opt/ros/fuerte/share/ros/../OpenCV/haarcascades/haarcascade_frontalface_alt.xml
[ INFO] [1354712164.859087292]: Filename list: $(env ROS_ROOT)/../OpenCV/haarcascades/haarcascade_frontalface_alt.xml

How do I solve this issue?

2012-12-05 01:06:16 -0500 received badge  Notable Question (source)
2012-12-05 01:06:16 -0500 received badge  Popular Question (source)
2012-10-01 02:48:22 -0500 received badge  Famous Question (source)
2012-10-01 02:48:22 -0500 received badge  Notable Question (source)
2012-10-01 02:48:22 -0500 received badge  Popular Question (source)
2012-09-06 05:11:17 -0500 received badge  Famous Question (source)
2012-09-06 05:11:17 -0500 received badge  Notable Question (source)
2012-09-06 05:11:17 -0500 received badge  Popular Question (source)
2012-08-24 17:07:44 -0500 received badge  Popular Question (source)
2012-08-24 17:07:44 -0500 received badge  Notable Question (source)
2012-06-13 05:12:28 -0500 asked a question Dynamic goal tolerance

I was wondering if there was any way to change the yaw_goal_tolerance and xy_goal_tolerance of e.g. the base_local_planner.

There are several situations where we want to apply a very small tolerance (+decrease accs and vels). But since this should definitely not be the default we want to be capable of 'dynamically reconfigure' those params. Unfortunately, those parameters are missing from the according reconfigure message.

What recently came to my mind was killing and restarting the node and apply a different set of default parameters. In my opinion, that would be a really dirty hack though.

2012-06-13 04:47:56 -0500 commented answer Clear obstacles resulting from skewed LaserScan data

What I ended up doing was to write a LaserFilter plugin which increased the timestamp of the LaserData frames by 200ms. This resolves all the issues I described above!

2012-06-11 23:50:12 -0500 commented answer Clear obstacles resulting from skewed LaserScan data

This is a general problem but espacially painful while rotating. The most problematic result of this is when the LaserData are creating obstacles while rotating, since those might not be removed because the robot now looks to e.g. the opposite direction. I'll look into the timestamp issue!

2012-06-11 06:25:05 -0500 asked a question Clear obstacles resulting from skewed LaserScan data

I recently stumbled upon a strange behavior my robot is showing while rotating. Now, when it rotates I am capable of observing two strange things (visualized using rviz).

  • LaserData is always displayed slightly delayed. Meaning, the RobotFootprint is refreshed quick (almost real-time) while the LaserData is not.
  • When the rotation of the robot stops the rotation of the visualized RobotFootprint is stopping as well. Unfortunately this is not the case with the LaserData. LaserData will continue to follow the rotation for at least a few frames and then suddenly jump back matching the end pose.

While on first sight this might just seem to be some kind of visualization problem it really affects path planning. For a better understanding assume the robot stands in front of an opened door and rotates to the left. The laser scans representing the right side of the door frame keep moving to the left. In the end they are right in the middle of the door yielding obstacles preventing my robot to plan any path through that door.

The only issue that came to my mind that could lead to such a behavior is the following:

  • Some problem with publishing frequencies

Any suggestion is appreciated. I will update my question as soon as someone comes up with any idea and post additional information.

(Our Kinect PointCloud is fine. No delay, no jumps in between two frames)

2012-06-10 23:27:53 -0500 commented answer Retrieve "current configuration" from dynamic reconfigurable node

I tried the second approach before but couldn't get the subscriber to work (for whatever reasons). I did it again and it seems to work now. A different approach seems to send a Reconfigure object with an empty request. The response will then contain the current configuration as a response. Feedback?

2012-06-10 23:25:27 -0500 received badge  Scholar (source)
2012-06-08 10:30:09 -0500 received badge  Nice Question (source)
2012-06-08 04:56:47 -0500 received badge  Student (source)
2012-06-08 03:20:51 -0500 received badge  Editor (source)
2012-06-08 03:16:42 -0500 asked a question Retrieve "current configuration" from dynamic reconfigurable node

Lets say I just created a piece of software which is capable of sending dynamic_reconfigure configs towards the /move_base/local_costmap/set_parameter server.

The only way to send a configuration is to send the whole configuration and therefore one needs to send the values of each member of the configuration object. Since my design allows for manipulating only single or few parameters I need to retrieve the current values of all the other members so they are not set to their datatypes default values.

What I found so far is the following:

  • Use the response of the dynamic_reconfigure call (won't help, since that leads to the same problem of creating the first configuration which I would send to get the response)
  • Various topics including /move_base/local_costmap/parameter_(descriptions||update) (won't help for the same reason)

Obviously, my question now is how to get a configuration object holding the current values of the server.

2012-05-02 06:29:03 -0500 asked a question Problem adding a laser scanner to robot model in stage

Setting up stage worked like a charm (more or less). We managed to find a model of the robot we are using and we set up the world. Nevertheless, connecting a laser to the platform will just not work.

The problem we encountered is the following: On stage startup, it seems, that the laser beams are reflected by its associated geometry, giving us invalid values. However, once the robot has been moved by the user (e.g. drag&drop) everything is fine. Moving the scanner to certain positions led to the explained issue. Moving it to other positions did not. We could not make up any reasonable explanation which location are problematic and which are not.

Below I pasted the *.world file a as well as the *.inc files which describe both, robot and laser. Feel free to leave a comment if this is not enough information.

worldfile

# simple.world - basic world file example
# Authors: Richard Vaughan
# $Id$

include "map.inc"
include "sick.inc"
include "pioneer.inc"
include "leg.inc"
include "furniture.inc"

# time to pause (in GUI mode) or quit (in headless mode (-g)) the simulation
quit_time 3600 # 1 hour of simulated time

paused 0

resolution 0.02

interval_sim 60  # simulation timestep in milliseconds

# configure the GUI window
window
(
  size [ 753.000 690.000 ] # in pixels
  scale 77.813   # pixels per meter
  center [ 2.907 12.920 ]
  rotate [ 0  0 ]

  show_data 1              # 1=on 0=off
)

# load an environment bitmap
floorplan
( 
  name "labor"
  size [13.850 41.800 2.000]
  pose [0 0 0 0]
  bitmap "maps/map.pgm"
)

patrolbot
(         
  # can refer to the robot by this name
  name "ToBI"
  pose [ 5.401 12.333 0 -179.518 ] 
)

#create two green legs
leg
(
name "greenLeg1"
color "green"
pose [-3.124 8.798 0 0]
)

... setting up more legs and furniture ...

sick.inc (laser scanner)

define sicksensor laser
(               
  # factory settings for LMS200 
  range [ 0.0 8.0 ]
  pose [ 0 0 0.1 0 ]
  fov 179.0
  samples 361
  #samples 90 # still useful but much faster to compute
  color_rgba [ 0 0 1 0.15 ]
)

define sickcommon ranger
(
  color "blue"
  size [ 0.156 0.155 0.19 ] # dimensions from LMS200 data sheet 
 )

define sickbase sickcommon
(
    block( points 4
                 point[0] [0 0]
                 point[1] [0 1]
                 point[2] [1 1]
                 point[3] [1 0]
                 z [0 0.21]
                 )
)

# extends sicklaser to add nice-looking but relatively expensive geometry
define fancysickbase sickcommon
(
  # bottom
  block( 
    points 4
    point[0] [ -0.02 -0.077 ]
    point[1] [  0.078 -0.077 ]
    point[2] [  0.078  0.077 ]
    point[3] [ -0.02  0.077 ]
    z [0 0.02 ]
  )

  # back
  block(
    points 4
    point[0] [ -0.078 -0.077 ]
    point[1] [ -0.02  -0.077 ]
    point[2] [ -0.02   0.077 ]
    point[3] [ -0.078  0.077 ]
    z [0 0.21 ]
  )

  # top
  block( points 4
    point[0] [ -0.02 -0.077 ]
    point[1] [  0.078 -0.077 ]
    point[2] [  0.078  0.077 ]
    point[3] [ -0.02  0.077 ]
    z [0.12 0.21 ]  
  )

  # laser bit
  block( points 4 ...
(more)
2012-03-30 03:48:32 -0500 received badge  Supporter (source)