Pepis's profile - activity

Hi!

Reading through some notes and material around nav2 I found a couple of mentions to a navigation setup often referred to as “reactive navigation”, which takes out continuous re-planning from the stack and replaces it for a single plan at the beginning of the navigation that connects the poses to navigate through with minimum cost lines; when there’s no static map those may as well be just straight lines.

I’m currently working on a robot that ought to work in large outdoors suburban-like environments navigating through sidewalks of different widths: some of them may barely fit the robot but are not usually populated with obstacles, while others are very wide but are very frequently populated with people moving around the robot.

I tried to set up this “reactive navigation” style on a simulated world with no static map using the DWB controller and an 8x8m local costmap, however, despite lowering the scale of the path-related critics and raising the obstacle-related, I struggled a lot to to make the robot go around even static objects that were in the way marked by the initial “straight line plan”. These obstacles would have been easily dodged by a navigation system using continuous replanning, as they would have been marked in the global costmap and the path for the controller to follow would have accounted for them. However it is not possible to mark them in a “static layer” beforehand because even though they may be static to the robot, they may be there just temporarily (ex: a parked car slightly blocking the sidewalk).

Has anyone had experience with this setup of the navigation stack? How did you set up your critics? Are there any guidelines for tuning the DWB controller for achieving a good balance between obstacle avoidance and path following? I expect the controller to dodge obstacles of all sizes, from a football ball to a full golf-car parked on the sidewalk or a big group of people the robot cannot go through, meaning it would have to be able to go pretty far away from the “straight line path”.

Do you think this setup would be more suited for dynamic outdoors environments instead of having continuous replanning at a relatively high frequency on a limited window around the robot while having the controller tuned more for path following? What would be the advantages of each approach?

Thanks for your answer steve! its going to be a few days of tuning and building that intuition for yourself to get t

[Nav2] Suggestions around single plan - controller only reactive navigation Hi! Reading through some notes and material

Best way of using nav2 to navigate continuously through indoors and outdoors environments Hi! I’m currently working on

Yes, the easiest thing IMO would be to take one of the BTs and modify it to your needs, then pass its path in the parame

It depends on the action server you call. When you launch nav2 both action servers are offered as /navigate_to_pose and

It depends on the action server you call. When you launch nav2 both action servers are offered as /navigate_to_pose and

It depends on the action server you call. When you launch nav2 both action servers are offered as /navigate_to_pose and

you probably need to fill the header field on the lastpcl_data PointCloud2 message. As the array_to_pointcloud docs stat

Hi everyone!

I'm currently using Nav2 on a robot that has to perform long navigation tasks (>1000m) across large environments (~5sqkm); I'm relying on the follow_waypoints action server for passing long sequences of sparse waypoints. I don't have a static 2d gridmap of the environment but rather a graph of sparsely interconnected nodes.

For different reasons there are small sections of the environment where the robot cannot drive autonomously. These sections are already pre-mapped in the edges between certain nodes on the aforementioned graph. See the below picture for a clearer explanation

On the picture above, considering the marked robot route (dotted arrow), what I would like to achieve is to tick the usual navigate_to_pose behavior tree for getting from node 2 to node 3 and from node 3 to node 4. When navigating from node 4 to node 5 I would like to trigger the assisted teleop behavior server to manually drive the robot. When reaching node 5 I would like to switch back to the navigate_to_pose bt to get to node_6 and so on.

I have thought of making a custom behavior tree node to switch between a navigate_to_pose branch and an assisted_teleop branch according to the goal_id that is to be reached. Also I would have to integrate a goal checker into the assisted_teleop server to SUCCEED the branch when the given goal is reached manually.

However I'm aware that some discussion has been held around this kind of "semantic navigation" to change the behavior of nav2 according to semantic labels defined on a sparse graph, so I wanted to ask the community about this beforehand.

Have someone faced the same problem? Would you recommend a different alternative? Is there any standard way of doing this?

Thanks in advance for your help and any insights you can provide :)

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

A slight variation of that, which is where I would probably start, is treating each segment as different a to b b to

Wow, thanks for your detailed answer Steve! addressing some of your points, If you're 'manually' driving, why not ha

[Nav2] Best way of alternating between autonomous navigation and assisted teleop using `follow_waypoints` action server

You could pass the gui launch descriptor. This is how it looks in the command line for ROS2: ros2 launch gazebo_ros gaz

You could pass the gui launch descriptor. This is how it looks in the command line for ROS2: ros2 launch gazebo_ros gaz

You could pass the gui launch descriptor. This is how it looks in the command line: ros2 launch gazebo_ros gazebo.launc

Hey, you are right. The default callback group for nodes is a mutually exclusive callback group, which as the docs state

Hey, you are right. The default callback group for nodes is a mutually exclusive callback group, which as the docs state

Hey, you are right. The default callback group for nodes is a mutually exclusive callback group, which as the docs state

What kind of executor are you using? If you are using the default rclcpp::spin() I think that uses a single threaded exe

Hi everyone!

I'm currently working with a robot that has what I call cliff sensors. Though their configuration is a bit different they serve the same purpose as the cliff sensors usually embedded in cleaning robots like roombas: they are pointing to the floor constantly measuring the distance from the robot to the surface and are able to detect "cliffs" - When that distance is longer than usual - and prevent the robot from falling down the stairs, curbside, etc.

I have tried to input their data after some post processing to nav2's range sensor layer by simulating a range reading in the place the cliff is, like if a solid obstacle was placed there, however this has failed. The sensors I'm using are able to detect cliffs that are ~40cm ahead of the robot's front but my guess is that since the robot I'm using is relatively big/heavy (>20kg) and runs at up to 1.5m/s more "responsiveness" is needed. I have set the deceleration values on the controller to very high amounts with little impact. Could this tackled by changing the nav2 configuration alone?

I have tried using a node independent from nav2 to hard-stop the robot (set the linear speed to 0) when a cliff is detected and this works much better.

With that in mind, I wanted to ask the community, has someone tried to do this? What would be the best way of integrating this to nav2 on a big robot? I would like to mark these obstacles on the costmap to prevent the robot from planning through that area, however I need to trigger a more "emergency stop"-like behavior that forces the robot to completely stop.