-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add beam sensor model #160
Conversation
|
||
int error = 0; | ||
// Needed because of the way OccupancyGrid signals an out of bounds index. | ||
std::size_t last_ok_index = steep ? grid.index(y * grid.resolution(), x * grid.resolution()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is weird but needed.
I think it'd be nice to provide an abstaction of index()
that signals an out-of-bound cell differently, instead of the current approach that returns size()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out loud, index()
could return std::optional
as a poor mans substitute to e.g. abseil::StatusOr
.
b05bb3f
to
7596970
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great start. It needs polishing but functionality is pretty much there.
|
||
int error = 0; | ||
// Needed because of the way OccupancyGrid signals an out of bounds index. | ||
std::size_t last_ok_index = steep ? grid.index(y * grid.resolution(), x * grid.resolution()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out loud, index()
could return std::optional
as a poor mans substitute to e.g. abseil::StatusOr
.
// TODO(Ramiro): We're converting from range + bearing to cartesian points in the ROS node, but we want range + | ||
// bearing here. We might want to make that conversion in the likelihood model instead, and let the measurement | ||
// type be range, bearing instead of x, y. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out loud, measurement_type
should perhaps be a proxy object to iterate over points in either cartesian or polar coordinate, which may or may not incur additional overhead depending on underlying data (e.g. in ROS, LaserScan
messages use polar coordinates where PointCloud2
messages normally use cartesian coordinates).
I'll give this a shot. |
@@ -0,0 +1,186 @@ | |||
// Copyright 2022 Ekumen, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
date
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to using 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 875d382.
last_ok_index = index; | ||
x += 1; | ||
error += delta_y; | ||
if (2 * error >= delta_x) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a source for this version of the algorithm? Isn't this comparison done before updating the error with delta_y
?
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Ramiro Serra <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
31d666c
to
c77b3d2
Compare
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
* - Give possibly const values `x` and `y` of type `double`, `g.index(x, y)` returns a `std::size`, | ||
* representing the index of the cell. | ||
* - Give a possibly const `Eigen::Vector2d` `p`, `g.index(p)` is equivalent to `g.index(p.x(), p.y())`. | ||
* - Give possibly const values `x` and `y` of type `int`, `g.index(x, y)` returns a `std::size`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* - Give possibly const values `x` and `y` of type `int`, `g.index(x, y)` returns a `std::size`, | |
* - Given possibly const values `x` and `y` of type `int`, `g.index(x, y)` returns a `std::size`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this and concluded this is error prone.
Let's say an user defines its own Grid
, that defines the double
variant of this method, i.e. index(double x , double y)
, this will still compile and produce incorrect results.
How do we feel about enforcing this through an abstract interface? Or removing the builtin type variants in favor of Eigen::Vector2
ones that prevent this from happening.
I'd also be happy coming up with a different name for continous vs discrete methods to prevent this from happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's say an user defines its own Grid, that defines the double variant of this method, i.e. index(double x , double y) , this will still compile and produce incorrect results.
That is possible, yes.
How do we feel about enforcing this through an abstract interface? Or removing the builtin type variants in favor of Eigen::Vector2 ones that prevent this from happening.
I'd also be happy coming up with a different name for continous vs discrete methods to prevent this from happening.
I think the OccupancyGrid concept needs to be reworked, but I didn't want to do it here. Better method naming is perhaps best. I'd suggest deferring it to a follow-up PR though, where we can address semantics and code reuse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed typos in aa3f86c.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another aspect of the current changes to the OccupancyGrid that is perhaps more controversial is the use of plain int
s.
I understand why std::size_t
was used but arithmetic with unsigned numeric types is error prone even when defined, and thus why you normally don't see unsigned scalars in vector types. I'd also argue that the current API is unnecessarily low level. Storage layout details can be abstracted without compromising performance.
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
Signed-off-by: Michel Hidalgo <[email protected]>
Anything else here @glpuga @nahueespinosa ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -0,0 +1,186 @@ | |||
// Copyright 2022 Ekumen, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to using 2023
@hidmic Nop, it GO on my side. 🟢🟢🟢 |
Signed-off-by: Michel Hidalgo <[email protected]>
Which tasks of Make beluga_amcl a drop-in replacement of nav2_amcl was implemented? @hidmic |
It would say (in terms of parameters):
Beam skip parameters have not been implemented. It's a rather simple variation though. |
Related to #99
Summary
Checklist