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

fherrero's profile - activity

2022-03-03 03:03:28 -0500 received badge  Necromancer (source)
2019-05-15 10:32:27 -0500 answered a question move_base receiving empty plan

That warning can also show up when, while using dwa_local_planner with the parameter prune_plan set to true, the robot g

2019-01-22 21:55:36 -0500 received badge  Good Question (source)
2017-11-06 02:46:01 -0500 commented answer A is not in your SSH known_hosts file.

You need to replace host with the correct IPaddress or name (name associated to an IPaddress in your /etc/hosts file) of

2017-05-30 11:59:41 -0500 received badge  Good Answer (source)
2016-06-28 07:47:55 -0500 received badge  Good Answer (source)
2016-05-29 11:40:37 -0500 received badge  Nice Answer (source)
2016-03-30 21:27:04 -0500 received badge  Nice Question (source)
2015-07-27 12:28:41 -0500 received badge  Good Question (source)
2015-07-01 03:36:48 -0500 commented answer hokuyo UTM-30LX-EW laser scanner: problems to detect

That guide looks a bit old (ubuntu 10 and ROS Fuerte). I recommend you to reset the laser IP address (see Edit 2 of my answer) and continue trying with urg_node

2015-06-30 10:29:22 -0500 commented answer hokuyo UTM-30LX-EW laser scanner: problems to detect

Reading this question, they basically say your computer and the laser must be on the same net (192.168.0.XX).

2015-06-30 09:17:35 -0500 received badge  Nice Answer (source)
2015-06-30 07:33:40 -0500 answered a question hokuyo UTM-30LX-EW laser scanner: problems to detect

With the Hokuyo UTM-30LX-EW connected through ethernet, you can use the urg_node, setting the ip_address parameter value. Default factory Hokuyos come with IP 192.168.0.10.

rosrun urg_node urg_node _ip_address:=192.168.0.10

-- Edit 1:

PC and laser must be on the same net 192.168.0.XX. Then, you should be able to ping the laser first,

ping 192.168.0.10

-- Edit 2:

If it does not work on a PC with IP 192.168.0.XX, maybe your Hokuyo laser has a different IP address.

To be sure, you can reset the laser IP address to the default one (192.168.0.10), following the instructions from the Laser specification (last page, section 9 - Ethernet settings - IP Initialization ), provided at the Hokuyo webpage.

If you manage to make it work with the default IP address but then you need to work in a different sub net, in the Hokuyo webpage there is a tool (for Windows) to change the laser IP address.

2015-05-23 22:13:01 -0500 marked best answer Limit rotation speed/acc in Navigation/base_local_planner

We are trying to use the navigation stack on a segway_rmp200. Currently we have configurated everything as said in this tutorial, we are not using a map yet, and we are sending a goal through rviz which can be reached going in a straight way (no obstacles between the robot and the goal).

Then, the segway starts doing weird translations and rotations, leaving the desired path, rotating, returning to the path, etc. Although it finally reaches the goal, the way it has moved is very weird. This is our first problem, and may result in a new question if the second problem is solved.

The second problem is that all these rotations are done with too high speed/acceleration and abrupt changes of direction, making it dangerous and not desirable to continue doing tests/debug to solve the first problem.

The parameters of the base_local_planner_params.yaml related to velocity and acceleration are set with low values (which seem to be ignored):

TrajectoryPlannerROS:    
  max_vel_x: 0.5    
  min_vel_x: 0.1    
  max_rotational_vel: 0.2    
  min_in_place_rotational_vel: 0.1    
  acc_lim_th: 0.05    
  acc_lim_x: 0.1    
  acc_lim_y: 0.1    
  holonomic_robot: false

In addition, running the dynamic reconfigure there are other similar parameters with different names as: max_vel_theta, min_vel_theta, min_in_place_vel_theta, acc_lim_theta; which have default higher values than the previous ones. We have modified them, but nothing has changed.

  1. Why is the rotation speed/acc not being limited with the configuration parameters?
  2. Why are there different parameter names (config yaml vs dynamic reconfigure) and which of them are the correct ones to tune? (3. Maybe related to 1, if not, future question: Why is our platform moving so weird to reach easy goals? How can we debug this behavior/state to see what is happening?)

Edited (after KruseT answer)

Now we are sure using the trajectory planner (dwa:false in base_local_planner_params.yaml), and can see the same values for yaml and dynamic-reconfigure parameters.

The problem continues. We set max_vel_th: 0.2 and acc_lim_th: 0.05, and the robot performs faster rotations. For example, the platform has received this two consecutive commands, where those limits have not been respected, and this is happening most of the time:

New Command Received: vT=0.100000 vR=0.000000
New Command Received: vT=0.117907 vR=1.371679

Translations are working fine. We have disabled recovery_behaviors, but there are no obstacles in the way so they shouldn't be used. We don't know how to continue debugging this to find out what's happening.

Any ideas?

2015-05-21 02:30:09 -0500 commented answer Problem installing ar_tools in Catkin

I guess he was using the catkin branch of xqms, while LucidOne repo wasn't catkinized yet.

2015-05-19 10:21:24 -0500 received badge  Nice Answer (source)
2015-03-26 06:52:17 -0500 received badge  Famous Question (source)
2015-03-12 13:11:30 -0500 received badge  Notable Question (source)
2015-03-12 11:38:11 -0500 commented answer dwa_local_planner: in place rotation FIRST goal does not work

Just tried it, still the same. I noticed the local_costmap_params.yaml seems to be missing the footprint_layer plugin, but adding it didn't fix it either.

2015-03-12 11:04:12 -0500 received badge  Popular Question (source)
2015-03-11 05:51:22 -0500 asked a question dwa_local_planner: in place rotation FIRST goal does not work

When running the navigation with dwa_local_planner, and give the first goal as an in place rotation, the robot won't move (except for recovery behaviors), and gives the below output. But, if you give a translation goal first, it moves normally, and from then on, it can rotate in place without a problem.

[ERROR] [...]: Footprint spec is empty, maybe missing call to setFootprint?
[ WARN] [...]: Invalid Trajectory 0.000000, 0.000000, -0.401014, cost: -9.000000
[ WARN] [...]: Rotation cmd in collision
[ INFO] [...]: Error when rotating.

I think the error actually comes from line 80 in obstacle_cost_function.cpp at base_local_planner, something about the footprint is not properly initialized:

double ObstacleCostFunction::scoreTrajectory(Trajectory &traj) {
...
if (footprint_spec_.size() == 0) {
  // Bug, should never happen
  ROS_ERROR("Footprint spec is empty, maybe missing call to setFootprint?");
  return -9;
}
...

All this is easy to reproduce running, for example, turtlebot simulator and navigation amcl demo:

$ roslaunch turtlebot_gazebo turtlebot_world.launch
$ roslaunch turtlebot_gazebo amcl_demo.launch
$ roslaunch turtlebot_rviz_launchers view_navigation.launch

EDIT: The local costmap config used in the example above is the one from turtlebot packages, which can be found here: local_costmap_params.yaml

EDIT2: I use ROS Indigo on Ubuntu 14.04.2, but i've also tried with Hydro on 12.04. And yes, I have all installed via apt-get

2015-02-17 13:31:02 -0500 received badge  Necromancer (source)
2015-02-17 10:25:43 -0500 answered a question Problem installing ar_tools in Catkin

It just happened to me today also, and I had to compile artoolkit separately first.

 $ catkin_make --only-pkg-with-deps artoolkit

I don't know the reason, because I've had compiled ar_tools before without experiencing this.

2014-09-17 02:36:22 -0500 commented question Navigation: Tuning Parameters

With no laser, is the local_costmap empty? (no obstacles). There is a parameter, pdist_scale if you use base_local_planner, or path_distance_bias in dwa_local_planner, that makes the robot stay close to the path.

2014-09-17 02:03:13 -0500 commented question Messages not being generated before dependent package

True, my mistake. I meant add_dependencies(${PROJECT_NAME} <msg_package_name>_cpp). We use this in order to ensure the necessary messages are compiled before the current package.

2014-09-16 04:20:53 -0500 commented question Messages not being generated before dependent package

I think what you need is generate_messages(DEPENDENCIES ros_opto22)

2014-09-12 05:08:45 -0500 commented question why some empty areas are with high cost in costmap?

The global costmap is updated with the scan if it has an obstacle layer. If these areas are result of mobile obstacles, they should be cleared by the scan when you go there again and it's free. The thick areas are result of the obstacle inflation, to prevent the robot to get too close to obstacles

2014-09-12 05:08:45 -0500 received badge  Commentator
2014-09-05 02:03:50 -0500 answered a question How to refresh automatically global costmap in Rviz

The costmap_2d has a parameter called publish_frequency (default: 0.0)

2014-09-01 07:03:38 -0500 commented question How to view old .vcg file in RVIZ?

I think a vcg-rviz conversion tool doesn't exist (yet?)

2014-09-01 01:45:58 -0500 commented question How to refresh automatically global costmap in Rviz

The costmap_2d has a parameter called publish_frequency (default: 0.0)

2014-07-28 16:13:12 -0500 received badge  Guru (source)
2014-07-28 16:13:12 -0500 received badge  Great Answer (source)
2014-07-03 05:56:04 -0500 commented question Invalid package manifest of qt-ros when invoking catkin_make
2014-06-25 05:23:32 -0500 received badge  Nice Question (source)
2014-06-05 03:56:29 -0500 received badge  Citizen Patrol (source)
2014-05-28 00:31:57 -0500 received badge  Critic (source)