-
Notifications
You must be signed in to change notification settings - Fork 22
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 support for multiple destinations to choose from. #101
Conversation
Signed-off-by: Arjo Chakravarty <arjoc@google.com>
This commit adds support for selecting the nearest spot on the same floor. This behaviour is convenient when looking at things from a cancellation perspective. This commit depends on open-rmf/rmf_task#101 Signed-off-by: Arjo Chakravarty <arjoc@google.com>
This pr depends on: * open-rmf/rmf_task#101 * open-rmf/rmf_ros2#308 You can ask a robot to go to its nearest spot using the newly added script. Signed-off-by: Arjo Chakravarty <arjoc@google.com>
Whats the use case for this? Having the model always return the first destination does not sound accurate unless the list of destinations is always sorted by distance. But for doing that you'll either need the Graph information or rely on some heuristic such as Euclidean distance from current state of the robot. |
@Yadunund, ideally, we would only use this feature in a cancellation phase, hence the model should not matter. An example of that would be if we were to cancel a delivery and want the robot to go to the nearest drop-off spot to drop off a cart. There isn't any API to enforce that down stream and the work required would be a fair bit more. The reason I've kept the 0th index as the model is that it allows us to preserve the old behavior. I can put a note in the code or file an issue to remind us to change this. I don't think it'll be impossible to estimate the nearest location given the last location, if you think thats a good idea I can update this PR to do so tomorrow. I've already had a chat with @mxgrey about this offline. |
Signed-off-by: Arjo Chakravarty <arjoc@google.com>
I see thanks for explaining that. It still feels like a hack to make an existing event work for the required cancellation behavior especially since the behavior of going to the nearest waypoint among the list is not apparent from the description of the event. What do you think about creating a new event, If that is too much effort for short term, I think it would still be nice to have a But if @mxgrey feels the existing approach is okay, then let's go ahead. |
This is kind of what we are aiming for. In my mind the use of the reservation system will be implicit. I think grey wants to keep the reservation system for next-gen RMF but I could be wrong. If you see the schema downstream in I actually don't see a reason for creating a new event as we'd have to maintain two versions of similar logic. Ultimately people could just use And yeah this is a hack. |
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Yeah I think |
Signed-off-by: Arjo Chakravarty <arjoc@google.com> Signed-off-by: Michael X. Grey <grey@openrobotics.org> Co-authored-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Arjo Chakravarty <arjoc@google.com> Signed-off-by: Michael X. Grey <grey@openrobotics.org> Co-authored-by: Michael X. Grey <grey@openrobotics.org>
|
||
auto invariant_duration = rmf_traffic::Duration(0); | ||
auto selected_goal = goals[0]; |
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.
@arjo129 This line causes a segfault when goals
is empty.
This commit adds support for selecting the nearest spot on the same floor. This behaviour is convenient when looking at things from a cancellation perspective. This commit depends on open-rmf/rmf_task#101 Signed-off-by: Arjo Chakravarty <arjoc@google.com>
New feature implementation
Implemented feature
Implementation description