Use collision checker in Dwb

[bpwilcox]

Currently, the collision checker code is refactored from the obstacle footprint critic in dwb in order to allow for collision checking on remote nodes via the costmap and footprint topic. It would be good remove the duplicate code and have dwb use the collision checker itself.

Since the collision checker currently relies on the costmap subscriber and footprint subscriber, there could be an overloaded implementation that can directly take a shared pointer to the Costmap2DROS object and use its interface to get the needed costmap2D object and robot footprint. This way DWB would not be limited by the topic publish frequency if it has its own Costmap2DROS object.

[shivaang12]

Any one doing this?

[crdelsey]

I don't think so. If you're interested, go ahead.

I think this is a relatively big change. After taking a look at this, and figuring out how you want to approach this, I recommend you quickly describe how you want to approach the problem here to see if there is any feedback before investing a lot of time.

[shivaang12]

Cool! Before I move ahead, I need to clarify if I am understanding the problem in a right sense.

I can see there two problems here,

1. Collision checker code is refactored from obstacle footprint critic and now we want to run only collision checker code and want obstacle footprint to use the result from collision checker.

2. Currently, Collision checker itself is subscribed to costmap subscriber and footprint subscriber. Now we wanted it to work without subscription by internally passing Costmap2DROS pointer.

[SteveMacenski]

That would be correct.

Its a bit involved. Personally, I would air on the side of "meh, whatever" and close the ticket. Trying to factor out everything sounds good on paper but this is really a different usecase (subscriber vs having access to the costmaps directly) and would make both implementations messy, or result in unnecessary data transformations on big-ish costmaps into a msg datatype. And its just alot of effort for no feature-payoff.

[shivaang12]

I agree! You can close it if you want.

[SteveMacenski]

Well, not really mine to close ;-)

Edit: if you were looking for a passive task the Component stuff is low-overhead high-value: #1013 and #1244. Essentially do the registration for all the lifecycle nodes (there's 7 or 8) in the cpp files, a few lines of CMake, and then changing the Node to LifecycleNode in the launch file and work out the kinks

[bpwilcox]

If others would like to close this ticket, I am okay with it (maybe give an upvote if you agree).