Collision as localisation input

[mbuijs]

Some food for thought: currently I'm working on a robot that could use collisions as one of its localisation inputs (think of a Roomba-like vehicle). I'm not at the stage of developing planners yet, but my intention was to implement a planner that plans for collision in some specific cases like walls or other static objects.

What's the idea regarding the collision avoidance requirement (i.e. what kind of restrictions on the design) and how would or relate with my idea?

[mkhansenbot]

@jbvo - I'm not sure what you mean by 'planning for collisions'. Do you mean that in some cases (like a roomba), you might want to come into contact with a wall intentionally so that you can clean along the edge? Or do you mean something else? Our first cut at collsion avoidance will likely be to port the A-star and DWA algorithm used today in the global_planner and local_planners modules of the ROS Navigation stack. We intend to make those fully replaceable with other algorithms, so yours could be used instead for a roomba application.

[mjeronimo]

@jbvo That's an interesting question. As you point out, it's not necessarily true that collisions should always be avoided (they can be harmless and used as input for localization). I'm thinking that the event (a collision, for example) and the response should be decoupled so that different responses can be associated with the event, depending on the particular implementation/circumstances. I'll try to incorporate that idea into the architecture.

[mbuijs]

@mkhansen-intel

Do you mean that in some cases (like a roomba), you might want to come into contact with a wall intentionally so that you can clean along the edge?

Cleaning along the edge is one of the scenario's indeed. Maybe roomba was not the best example, I'm more thinking about the way a Neato cleans, this video shows a nice example: https://www.youtube.com/watch?v=qHEJhJ_CuOQ.
Scraping along the edge in 1 go would actually be ideal for cleaning performance. A specific case of this would be cleaning a corner as shown in this video: https://youtu.be/AmLkFQ2lDFQ?t=61

Aside of scraping an edge or corner, I was actually mainly thinking about the scenario of crossing a large area in the middle. In this case typically sensors like a laser scanner will be able to see the opposite wall when approaching it, but I have in mind scenario's where the main sensor is not functional (e.g. covered in dirt). Bumping the opposite wall would then be a nice backup method for knowing that we've crossed the area completely.

[mkhansenbot]

@jbvo - I believe we are supporting this request, since we are making the Navigation stack more of a framework with ability to change out planners to anything you want to write code to do. Maybe when we get our first working implementation done, you can try your approach as a test case and give us feedback of whether it works or not.

[mkhansenbot]

@jbvo - I'm closing this issue since right now we don't know of any work to do that is specific to this request.