nav2d Operator does not update with laser scan on real Clearpath Husky

asked 2019-03-26 08:12:32 -0500

mtROS
92 ●13 ●19 ●24

updated 2019-03-27 03:48:26 -0500

Hy there,

i am trying to use the nav2d package with a real Husky but have problems with getting the costmap updated according to a lidar-measurement. The setup looks like: PC running ROS Kinetic connected over SSH to Husky. The Joystick is connected to the PC and the nav2d Operator runs on the PC. The husky is able to be moved, but he does just turn in the circle of the dark space of the map. All parameters are set to default, eccept the laser_frame is set to front_laser.

The following rqt_graph shows that the operator node successfully connects to the topic /scan/front which is correctly echoing data. image description

The result is the following in rviz: image description So no costmap updated according to the laser scan at all.

The operator node outputs following to the terminal:

[ INFO] [1553676062.818859498]: Using plugin "obstacle_layer"
[ INFO] [1553676063.385903322]:     Subscribed to Topics: scan
[ INFO] [1553676067.066342765]: Using plugin "inflation_layer"
[ WARN] [1553676072.713066832]: The scan observation buffer has not been updated for 7.25 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676072.913141790]: The scan observation buffer has not been updated for 7.45 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676073.112945804]: The scan observation buffer has not been updated for 7.65 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676073.312964877]: The scan observation buffer has not been updated for 7.85 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676073.513063737]: The scan observation buffer has not been updated for 8.05 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676073.712961420]: The scan observation buffer has not been updated for 8.25 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676073.913113372]: The scan observation buffer has not been updated for 8.45 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676074.113024278]: The scan observation buffer has not been updated for 8.65 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676074.313027468]: The scan observation buffer has not been updated for 8.85 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676074.512953558]: The scan observation buffer has not been updated for 9.05 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676074.713007869]: The scan observation buffer has not been updated for 9.25 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676074.913051751]: The scan observation buffer has not been updated for 9.45 seconds, and it should be updated every 0.40 seconds.
[ INFO] [1553676074.929597794]: Will publish desired direction on 'route' and control direction on 'desired'.
[ WARN] [1553676075.113030975]: The scan observation buffer has not been updated for 9.65 seconds, and it should be updated every 0.40 seconds.
[ WARN] [1553676075.313082459]: The scan observation buffer has not been updated for 9.85 seconds, and it should be updated ...

(more)

edit retag flag offensive close merge delete

add a comment

Comments

Thank you for your answer! i set in coastmap.yaml

scan: {data_type: LaserScan, expected_update_rate: 0.4,
  observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 1.0, min_obstacle_height: 0.01}

and configured the laser_frame in the launch file to top_plate_link. The tf Position to the base_link( which was set to /Operator/local_map/robot_base_frame) is -1.4266; 0.05741; 0.245 (from rviz)

unfortunately no changes...

mtROS ( 2019-03-27 04:27:18 -0500 )edit

Can you validate via RViz that the laser points are really above the ground and not higher then 1m?

Sebastian Kasperski ( 2019-03-27 05:43:15 -0500 )edit

And your topic is called /scan/front, if I see it correctly. MAybe you also need to change the observation name to "scan/front".

Sebastian Kasperski ( 2019-03-27 05:54:13 -0500 )edit

The laser points are in rviz below the map surface.But the parameter laser_frame of the ros.yaml is set to a tf that is within min max.

Do you mean the parameter observation_source in the coastmap.yaml to be set to scan/front?

mtROS ( 2019-03-27 06:11:49 -0500 )edit

The laser points should be above the map, if they are below there is likely something wrong with the transformations. For testing you might set min_obstacle_height=-10 to see if it changes anything, but the real solution would be to fix the coordinate frame that holds the laser scan.

And yes, I mean observation_source. Remember that the same name has to be used in the next line when giving the detailed parameters for this source.

Sebastian Kasperski ( 2019-03-27 07:35:35 -0500 )edit

thank you for your help so far. I added a python node that subscribes to scan/front and publishes a new scan topic to a tf-frame that is above ground and for sure within the boundaries. The rqt_graph shows again that the subscriptions are right, but no changes to the costmap. The observation source is set correctly. Could it be that there are some problems with tf over SSH. i spotted that in the tf-tree that the most recent transform and oldest transform of the laser_frame is 0.0 so they are static.

mtROS ( 2019-03-27 08:08:09 -0500 )edit

yeeeeah! it is working now. The problem was that the observation_source was set to the right topic but then in the line below again just scan: was used.

mtROS ( 2019-03-27 09:37:27 -0500 )edit

add a comment

nav2d Operator does not update with laser scan on real Clearpath Husky

1 Answer

Comments

Question Tools

Stats

Related questions

nav2d Operator does not update with laser scan on real Clearpath Husky edit

1 Answer

Comments

Question Tools

Stats

Related questions

nav2d Operator does not update with laser scan on real Clearpath Husky