Hi all, your friendly neighborhood navigator here.
I’m working with a student this summer on implementing assisted teleoperations to the Nav2 stack. This is an area often folks request. We’re working to make sure we can support both modalities that assisted teleop is the major task you wish to accomplish (via behavior tree) and also that assisted teleop is something you want to do on occasion as part of a larger system (server + behavior tree node access).
To that end, we need your assistance in answering some philosophical questions regarding how you want teleoperation to function:
- A) Do you want it to prevent collision but not take any active maneuvers to do so? For example, it will stop a user from being able to command a robot into the wall but it will not try to avoid the wall. So the user would then have to command the robot to turn around or whatever to move elsewhere. This is ‘Pure Collision Rejection’, lets say. This is similar to capabilities often used in industrial robotics applications to make sure you’re always a second or something away from collision (so we dynamically reduce velocity in the requested direction such that it is always predictably a second away from collision).
- B) Do you want it to prevent collision and also take active maneuvors to do so? For example, it would stop a user from running into a wall, but if there is a doorway a couple of meters over, it may try to select velocity commands near the requested command that is the most admissible. This is ‘Pure Collision Avoidance’, lets say. This is what is implemented in the navigation_experimental repo in ROS1.
Personally, I prefer option (A) from the perspective that I know what I want my robot to do, and I’d probably get pretty irritated if/when it “guessed” wrong. Another reason would be that this would be trivial to build directly into the controller server such that this could always be running even when not being teleoped, so that if your controller stinks, it still will stop collisions. Finally, I like it because its easy to implement and I don’t like making my own life more difficult than required
In defense of (B), I think that is the more intelligent solution and if you were doing some remote teleoping where you didn’t have good visibility of the surroundings, having a nudge in a less hazardous situation could be valuable. Though with the restricted band of velocities around the request, I don’t think it would be all that effective in avoiding any major additional issues unless it was small (and then probably not all that hazardous to begin with). I suppose you could open up the band of velocities it could consider around the request, but I have a feeling that would make the robot zig sometimes when you wanted it to zag, when faced with unusual or highly symmetric obstacles.
In an ideal world where we had infinite time and resources, I’d just implement both and leave it to you, the user, to select which behavior you like the best. Alas, we are limited to just one option by the clutches of time and my ADHD to tackle other problems .