fwh's profile - activity

I am using actionlib in fuerte on ubuntu 12.04 to send goals between a planner/exec and an execution system.

I have noticed that on some goal.cancel() calls the node hangs. None of the under-the-hood messages are being published.

I was able to trace the problem to the following line:

boost::recursive_mutex::scoped_lock lock(gm_->list_mutex_);

in /opt/ros/fuerte/include/actionlib/client/client_goal_handle_imp.h (line 221).

In instances where the node hangs, it never acquires this lock.

Is this a known issue? With a solution/workaround?

For now I do not cancel any goals and instead deal with goal-to-goal transitions otherwise., but I would like to go back to how it seems like the interface should work.

I'm having trouble with a sensor that stops providing data at times cluttering my costmap. To reproduce the problem, I start the system, see the costmap update properly, then unplug the sensor. The last sensor reading stays in the costmap.

I tracked this down to the following function:

bool Costmap2DROS::getMarkingObservations(std::vector<Observation>& marking_observations) const {
  bool current = true;
  //get the marking observations
  for(unsigned int i = 0; i < marking_buffers_.size(); ++i){
    marking_buffers_[i]->lock();
    marking_buffers_[i]->getObservations(marking_observations);
    current = marking_buffers_[i]->isCurrent() && current;
    marking_buffers_[i]->unlock();
  }
  return current;
}

getObservations() removes stale observations, but it keeps one observation. As a result, the last reading from the sensor continues to be used as a marking observation.

The following change allows me to drop the sensor as soon as it is detected as no longer active. Are there any implications of this change I'm missing, or do people have other ways of dealing with sensors that stop providing data?

bool Costmap2DROS::getMarkingObservations(std::vector<Observation>& marking_observations) const {
  bool current = true;
  //get the marking observations
  for(unsigned int i = 0; i < marking_buffers_.size(); ++i){
    marking_buffers_[i]->lock();
    bool obsCurrent = marking_buffers_[i]->isCurrent();
    if (obsCurrent) {
      marking_buffers_[i]->getObservations(marking_observations);
    }
    current = obsCurrent && current;
    marking_buffers_[i]->unlock();
  }
  return current;
}

I am looking for a way to have a bit more control over where/how ROS logs data beyond the screen/log output parameter for nodes in launch files. Named loggers only give more fine-grained control over verbosity levels but still all lines end up in the same file *-stdout.log file.

Ideally I would like no (or minimal) output going to screen, and all output going to one of two files: one for "data" (number, etc. to analyze later) and another one for "events" (such that tailing that file lets me check what's going on in the system).

Is there a ROS way of doing this, or has anyone solved a similar problem before?