Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cob_collision_velocity_filter] make cob_collission_velocity_filter usable for non-rectangular footprints #32

Open
floweisshardt opened this issue Apr 23, 2015 · 3 comments

Comments

@floweisshardt
Copy link
Contributor

floweisshardt commented Apr 23, 2015

this is needed for MLR bases

@fmessmer FYI

@fmessmer
Copy link
Contributor

fmessmer commented Sep 4, 2015

@ipa-mig @ipa-fmw
any progress here?

@fmessmer fmessmer changed the title make cob_collission_velocity_filter usable for non-rectangular footprints [cob_collision_velocity_filter] make cob_collission_velocity_filter usable for non-rectangular footprints Nov 21, 2015
@fmessmer
Copy link
Contributor

@ipa-mig
This is getting urgent.
I can have a look at this, but I guess you (or a student) already spent some thoughts on this...or even started something...that I could use as a starting point.
Could we meet up for a quick exchange of ideas?

@mgruhler
Copy link
Contributor

mgruhler commented Jan 27, 2017

as discussed, for what you wwant to do, this is actually a set of changes. I addressed them in the respective issues:

  1. adapt cob_footprint_observer to provide not a rectangular footprint, but a convex polygon: [cob_footprint_observer] provide a convex polygon as footprint, not a rectangle #131
  2. develop node that checks local costmap and provides "Safety Stop functionality" by disabling the respective drive commands in the twist_mux [cob_footprint_observer] new node providing "safety stop" functionalities based on observed footprint #132
  3. adapt this node to properly handle the convex polygon footprint

about the last point:
In principle, the current node could be adapted to work with any convex polygon. however, I'm not quite sure how complex this will get.
In the end, the proper way to do this would be to rather create a node that uses a local planner to create reasonable velocity commands based on the command input and the costmaps...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants