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

feature-nav parameter missmatch #77

Closed
JanezCim opened this issue Dec 20, 2020 · 9 comments
Closed

feature-nav parameter missmatch #77

JanezCim opened this issue Dec 20, 2020 · 9 comments

Comments

@JanezCim
Copy link
Contributor

Im writing this as a separate issue, because this is more clear that just adding comments to #76.

In feature-nav branch there are some paramter missmatches that i've noticed:

  • parameter that used to be robot_front_length is now forward_obstacle_threshold - old one is still exposed in collision_checker.cpp - similar is true with robot_width - now min_side_dist
  • where has the robot_back_length gone? its exposed in collision_checker.cpp but not in move_basic.cpp

These are just the parameters that i've noticed now. I think what happened is that move_basic was heavily modified without thinking about how collision_checker will be effected and now we have a slight parameter mess. I think we also have to look at collision checker and clear this before we merge into master.

This new heavily modified move_basic works very nicely, but since so many user-exposed params have changed maybe we have to think about this becoming a new version of move_basic (eg. move_basic2)

@JanezCim JanezCim added this to Backlog in UbiquityRobotics/ubiquity_main via automation Dec 20, 2020
@JanezCim JanezCim moved this from Backlog to Ready in UbiquityRobotics/ubiquity_main Dec 20, 2020
@JanezCim JanezCim self-assigned this Dec 20, 2020
@MoffKalast MoffKalast moved this from Ready to In Progress in UbiquityRobotics/ubiquity_main Feb 9, 2021
@dorkamotorka
Copy link
Contributor

I don't know to which branch this is related since some of these information does not seem to be relevant for the "master" (kinetic-devel) branch. Kinetic devel features branch is currently applying step by step features, documentation etc. We should either update the issue or create a new one related to master branch since others are project specific.

@JanezCim
Copy link
Contributor Author

In feature-nav branch there are some paramter missmatches that i've noticed:

I'm unclear on the parameter names and if they are missmatched in the feature-nav branch. This issue does not concern the parameters in master branch

@dorkamotorka
Copy link
Contributor

dorkamotorka commented Feb 16, 2021

robot_front_length, robot_width, robot_back_length are parameters for robot footprint.
forward_obstacle_threshold, min_side_dist are parameters for how far from the robot obstacles should at least be - it's like a deadzone where obstacles shouldn't be so the robot can turn and drive through.

@JanezCim
Copy link
Contributor Author

okay, why do we need robot_front_length if we already have forward_obstacle_threshold? I currently have then at the same value. Same for robot_width vs min_side_dist. Sorry for interrogation but i really dont understand the difference

@JanezCim
Copy link
Contributor Author

i guess what im asking is is there a scenario where robot_front_length would be different from forward_obstacle_threshold?

@dorkamotorka
Copy link
Contributor

  • I think the idea behind robot_front_length and robot_width is that you have a square which represent the robot(this can be further extended to have a arbitrary polygon) and with this footprint you keep calculating the distance between obstacles and the shape of the robot (this is helpful so you have distance to the shape and not to the base frame I guess)
  • If we wouldn't have a footprint shape of the robot to what would the distance to each obstacle be calculated?
  • At the same time we cannot use the robot_width and robot_front_length for collision avoidance, because of this would be true than the robot would already crash since the obstacle would be inside of footprint
  • To avoid collision we need forward_obstacle_threshold and min_side_dist

It's hard to tell from code for sure(I would say we are using in paragraphs mentioned method) whether we are using robot_width and robot_front_length also for collision checking, but if we are than I agree with you.

@MoffKalast MoffKalast moved this from In Progress to Review/Test in UbiquityRobotics/ubiquity_main Mar 8, 2021
@dorkamotorka
Copy link
Contributor

@JanezCim are we clear on that?

@MoffKalast
Copy link
Contributor

It's gonna be so funny when Janez wakes up on Thursday with a hundred million email pings from all repos.

@JanezCim
Copy link
Contributor Author

JanezCim commented Mar 25, 2021

@tp4348 If you understand all the params, both in move_basic.cpp and in collision_checker.cpp, then im fine, we can solve further issues with understanding these down the line
@MoffKalast thats why the "Unsubscribe all" button is there :)

UbiquityRobotics/ubiquity_main automation moved this from Review/Test to Done Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants