paulbovbel
commented
5 years ago Thanks for taking it for a spin - frontier_exploration in melodic has undergone a pretty significant refactor, and I'm still shuffling things around.
Closed jaredjohansen closed 5 years ago
paulbovbel
commented
5 years ago Thanks for taking it for a spin - frontier_exploration in melodic has undergone a pretty significant refactor, and I'm still shuffling things around.
jaredjohansen
commented
5 years ago @paulbovbel - thanks for providing/maintaining this package.
Do you have an ETC for when the reshuffle will be done?
paulbovbel
commented
5 years ago Not really. Can you link me to a fork of something of husky with the updated launch you put together? Might be a good staging ground.
jaredjohansen
commented
5 years ago Sorry for the long delay, @paulbovbel. (I got called off on something else for a couple of weeks.)
I started looking into this again, today. My original costmap_exploration.yaml file looked like this:
track_unknown_space: true
global_frame: map
rolling_window: false
plugins:
- {name: external, type: "costmap_2d::StaticLayer"}
- {name: explore_boundary, type: "frontier_exploration::BoundedExploreLayer"}
#Can disable sensor layer if gmapping is fast enough to update scans
- {name: obstacles_laser, type: "costmap_2d::ObstacleLayer"}
- {name: inflation, type: "costmap_2d::InflationLayer"}
explore_boundary:
resize_to_boundary: false
frontier_travel_point: middle
#set to false for gmapping, true if re-exploring a known area
explore_clear_space: falseAnd my costmap_common.yaml looked like this:
footprint: [[-0.5, -0.33], [-0.5, 0.33], [0.65, 0.33], [0.65, -0.33]]
footprint_padding: 0.02
robot_base_frame: base_link
update_frequency: 1.0
publish_frequency: 3.0
transform_tolerance: 0.5
resolution: 0.05
obstacle_range: 5.5
raytrace_range: 6.0
#layer definitions
static:
map_topic: /map
subscribe_to_updates: true
obstacles_laser:
observation_sources: laser
laser: {data_type: LaserScan, clearing: true, marking: true, topic: scan, inf_is_valid: true}
inflation:
inflation_radius: 1.0
cost_scaling_factor: 2.0I found that the frontier_exploration::BoundedExploreLayer didn't exist anymore, so I had updated it the file to this (which caused the "failed to update polygon service" error):
track_unknown_space: true
global_frame: map
rolling_window: false
plugins:
- {name: external, type: "costmap_2d::StaticLayer"}
- {name: explore_boundary, type: "polygon_layer::PolygonLayer"}
#Can disable sensor layer if gmapping is fast enough to update scans
- {name: obstacles_laser, type: "costmap_2d::ObstacleLayer"}
- {name: inflation, type: "costmap_2d::InflationLayer"}
explore_boundary:
resize_to_boundary: false
frontier_travel_point: middle
#set to false for gmapping, true if re-exploring a known area
explore_clear_space: falseThat brings us to today, when I did some more digging. From the digging, I updated the file to this:
track_unknown_space: true
global_frame: map
rolling_window: false
plugins:
- {name: static, type: "costmap_2d::StaticLayer"}
- {name: polygon_layer, type: "polygon_layer::PolygonLayer"}
#Can disable sensor layer if gmapping is fast enough to update scans
- {name: obstacles_laser, type: "costmap_2d::ObstacleLayer"}
- {name: inflation, type: "costmap_2d::InflationLayer"}
polygon_layer:
resize_to_polygon: false
frontier_travel_point: middle
#set to false for gmapping, true if re-exploring a known area
explore_clear_space: falseWith this latest update, I think that all my layers (and parameters) are named properly. It succesfully gets past the line that was triggering the "Failed to call update polygon service" error. So, in short, problem solved!
(It now gets stuck on something else...but I'll ask about that in a separate issue.)
erinline
commented
5 years ago @jaredjohansen regarding:
I am attempting to run the husky exploration demo (http://www.clearpathrobotics.com/assets/guides/husky/HuskyFrontiers.html#instructions). Their exploration.launch hasn't been updated to the new naming/organization scheme of frontier_exploration, so I updated the nodes in exploration.launch to fit the new naming/organization scheme. Likewise, their costmap_exploration uses the old BoundedExploreLayer rather than the new PolygonLayer, so I updated that as well.
What change did you make to the nodes in exploration.launch to fit the new naming/organization scheme? I am trying to do the same thing, but new to ROS and simply renaming the nodes in the launch file did not work for me. (I may have the new names wrong as well- I assume explore_server is now exploration_server and explore_client is now plugin_client, is that correct?)
Perhaps you could post your file, exploration.launch?
erinline
commented
5 years ago Nevermind, figured it out from looking at the frontier_exploration package's exploration.launch. In case anyone else has the same question, the nodes' packages have to be changed as well. These are the relevant lines in husky_navigation/launch/exploration.launch, modified to work with the latest frontier_exploration package:
<node pkg="exploration_server" type="plugin_client" name="explore_client" output="screen"/> <node pkg="exploration_server" type="exploration_server_node" name="explore_server" .../>
(And of course you also have to make the changes to costmap_exploration.yaml mentioned above by @jaredjohansen )
I am getting the following error when attempting to use frontier_exploration:
A few notes about my environment:
After making these changes, I am able to get my workspace to compile. I am able to run the exploration_demo.launch without any errors. I am able to select points in rviz without any errors. I am able to complete the polygon without any errors. I am able to select a point to initialize the exploration without any errors. But when it tries to communicate with the polygon service, things die.
The mechanisms for how it uses the service and communicates with the other nodes is a bit beyond my initial attempts to understand. Any help to understand (or to fix any bugs that may be involved) would be appreciated!