search

cram-code / cram_highlevel

DEPRECATED. All the commits from here are in the corresponding cram2 repo: https://github.com/cram2/cram_plans, the specific costmaps and semantic maps are in their separate repositories, look in cram2 organization.
0 stars 3 forks source link

Priority scores for costmap height generators #29

Open gaya- opened 10 years ago

gaya- commented 10 years ago

Different costmaps have different understanding of what the pose height should be. Priority scores (like the ones for 2d x and y positions) for height generators would be nice.

fairlight1337 commented 10 years ago

Yeah, +1! Might also be nice to have a mechanism for generating multiple z-values. Is there something already to do that? Maybe by adding multiple height generators to the same desig-costmap predicate?

gaya- commented 10 years ago

Do you want this for GSoC? I could take a look (in a couple of weeks). Just need a good mechanism to combine results from different height generators. Options are: just choose randomly, assign a priority to each generator. Then the question would be: after how many failed tries should a generator with lower priority be chosen.

fairlight1337 commented 10 years ago

Yeah, partly, but no rush. I think my student will be pretty busy with setting up everything else and getting tasks running on normal planes first for the next few weeks.

Concerning the options, I'd go for the second one, no? This way we could distinctively decide which one takes precedence over the others.

Concerning the retry count, what is a failure when merging the costmaps?

gaya- commented 10 years ago

Concerning the retry count, what is a failure when merging the costmaps?

Oh no, I mean, if a solution wasn't good enough and was rejected by a validator, should we try the same height generator again or resort to the second highest priority one.

Otherwise, we can just leave only one height generator when combining different costmaps and choose the one that has the highest priority. But then a single height generator function will have to give you heights for different shelves (say it randomly decides which shelf it like more), whereas, when having multiple generators associated with a costmap we could have different functions always returning the constant height of their certain shelf. Although, I guess, this will make things really complicated, as if costmaps are not already ...complicated.

fairlight1337 commented 10 years ago

Ah, I see. Thanks for clarifying this.

How about choosing the height randomly as well? Then we should have an evenly distributed selection of generated height values over the shelves (i.e. heights) that are in the costmap.

Meaning, when one fails, choose another generator at random. When that one fails, choose yet another random one, and so on, until the global max solution count (200 it was, right?).