First use cases for review and discussion #2
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # Collision Avoidance | ||
| As a Robot user I want to my robot to avoid colliding with people or objects so that it won't damage anything or hurt anyone | ||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for indoor and outdoor robot navigation in most (all?) cases | ||
| - Example: a robot in a warehouse should avoid colliding into the walls or shelving, and dynamically avoid people that cross its path | ||
|
There was a problem hiding this comment. one of the biggest shortcomings of the current system is the inability to model/predict where obstacles will be in the future -- this leads to colliding with other moving objects. There was a problem hiding this comment. Yes, I think we need to handle this cleanly, thus the example here. There was a problem hiding this comment. Moreover there are situations in which one cannot wait on the planner to react, thus the need for some kind of preemptable states. |
||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to walk in front of a robot and it should avoid crashing into that person | ||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
There was a problem hiding this comment. I'm not sure if collision recovery should be considered as a use case (the expected user interaction when the robot crashes into something) or that comes later as an error handling requirement. There was a problem hiding this comment. @orduno - yes we will need a collision recovery use case. We probably need some for other use cases such as "I'm lost" or "I'm stuck and can't move" or "I have a malfunction", etc. |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # Indoor Localization | ||
| As a Robot user I want my robot to know its location on a given map of an indoor area so that it can move around the area | ||
|
There was a problem hiding this comment. Robot location, is that metric (3.12, 7.42), topologic (node 5), semantic maybe (near the fridge) ... ? There was a problem hiding this comment. @artivis - should the user specify or care about what metric to use for robot location? There was a problem hiding this comment. The user may not care about specifying explicitly what metric to use but he/she may care about it when requesting feedback about the robot location and/or when sending it a navigation goal. There was a problem hiding this comment. So, sounds like there are a couple use case-level interactions here between the Robot User and the Robot: Determine Current Robot Location and Send Robot to Location. Then, in the context of these interactions, there might be details about how the location is to be specified. |
||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for indoor robot navigation in most (all?) cases | ||
| - Example: a courier robot in a logistics warehouse | ||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify a map to use and a location on that map for the robot | ||
|
There was a problem hiding this comment. Is this robot's initial location? There was a problem hiding this comment. In most cases it will be but we shouldn't limit the design to only handle the initial position. Sometimes the robot may need to be given an adjusted position, for example if it is in a very large space it may not have a nearby point of reference. There was a problem hiding this comment. Sounds like then there is an option for specifying a relative location. What kind of semantics are associated with these potential anchor locations? For example, "meet me by the water cooler." It sounds like, during the mapping process, that the Robot User would need to identify names/IDs for these significant locations. |
||
| - The robot should be able to deduce it's own position on a map autonomously | ||
|
There was a problem hiding this comment. After an initial localization? Or are we trying to solve the kidnapped robot problem? (if the latter, I'm having deja vu flashbacks to PCL 2.0 development) There was a problem hiding this comment. Well ideally yes it would solve the kidnapped robot problem, but in the cases it doesn't know where it is (which may be often), we want to be able to tell the robot "you are here". There was a problem hiding this comment. There might be a need to physically (programmatically) distinguish from 'location tracker' (amcl, EKF...) and (re)localizer (DboW, WIFI? and such), so that they can be distinguished in the overall navigation scheme too. |
||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
There was a problem hiding this comment. A tool should provide feedback about the overall confidence of the localization. Also in a non-expert fashion (Localized, Uncertain, Lost ...). There was a problem hiding this comment. The same manner as ROS1 |
||
|
|
||
|
There was a problem hiding this comment. Related to my comment above about collision avoidance, what does the user expect the robot to do when it get's lost. There was a problem hiding this comment. Probably alert the Robot User so the user could rectify the situation. Would the robot retrace its steps to a point that it wasn't lost? If so, what would prevent it from following the same path again? |
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # Indoor Navigation | ||
| As a Robot user I want my robot to autonomously navigate to a given location on a given map so that it can help me at that location | ||
|
|
||
|
There was a problem hiding this comment. Should the robot also update the map as it moves? There was a problem hiding this comment. Mapping should really be separate from the navigation system -- if something like cartographer/karto supports dynamic updates, that's great, but I wouldn't try to integrate it into the navigation system itself. There was a problem hiding this comment. Will the user expect the robot to handle any environment? fixed, dynamic, unstructured, etc. |
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for indoor robot navigation in most (all?) cases | ||
| - Example: a courier robot in a logistics warehouse | ||
|
There was a problem hiding this comment. Something to consider -- RE: indoor vs. outdoor as well: ramps are non-planar. They are poorly supported in today's system -- yet they are still indoor. The dividing line really is "all 2d planar environment" vs "environment that has non-planar ground". The efficiencies of the 2d planar case really helps for robots like Turtlebot, where there isn't a huge processing power onboard. There was a problem hiding this comment. I tried to cover 2D+ separately in a different use case. I didn't specifically mention ramps though, but I did mention stairs and elevators. I think ramps belong in that use case also. I can add them there. |
||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify a map to use and a location on that map for the robot to move to. | ||
|
There was a problem hiding this comment. one of the big things that should be better defined in 2.0 is how we handle "unknown space" -- it's horribly hacky and hard to understand in the current navigation system (each planner/costmap has separate parameters for how it deals with unknown space and they are loosely coupled enough that is easy to get the configuration wrong). There was a problem hiding this comment. By unknown space do you mean areas that aren't on the map or something else? There was a problem hiding this comment. Both: in global maps, it can be areas beyond the edge of the map, or areas within the center of the map for which we didn't have any observations during map building. In the current system, this is the "dark grey" portion of the map (free space is light grey, obstacles are black). There was a problem hiding this comment. What's the best way to handle unknown space? Is it to have the robot treat it as free space that can be traversed, as a keep-out area or something else? I think this one will require more thought / discussion. I do agree with your point however, that it needs to be handled in a consistent way. Maybe it needs to be a dynamically configurable way. There was a problem hiding this comment. It's highly dependent on the application -- hence why it is parameterized in the current system. I'm not suggesting we move away from allowing different modes of dealing with unknown space, I'm suggesting that the ways we deal with it are consistent throughout (ideally single parameter to select the mode of dealing with unknown space) There was a problem hiding this comment. As a pair of examples: in a warehouse which you have fully mapped, you probably don't want to allow navigation in unknown space. In an application where the robot is using navigation to explore the space and build a map, you almost certainly need to plan towards, and probably into, unknown space, to avoid start/stopping/replanning a lot. There was a problem hiding this comment. Somewhat related, the area enclosed by the edges of an obstacle (obstacle body so to speak) could be automatically painted as obstacle rather than unknown space. This would prevent e.g. simple discrete horizon-based planners from doing stupid things. |
||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
There was a problem hiding this comment. I would suggest that we have a specific requirement that the system is capable of this 2d mode on a low-end processor -- something like the current turtlebot. There was a problem hiding this comment. Good point. Do you mean the Turtlebot 3? I think we need to be specific about a minimum CPU level, I'll follow up on that. There was a problem hiding this comment. I'm not sure what the exact "starting processor" is, but yes, they are using some fairly low-end processors in the latest turtlebots, and still manage to run the existing navigation system. There was a problem hiding this comment. The map-representation(s) will be one of the driving wheel of the design and impose a de facto computation power requirements. |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # Keep Out Zones | ||
| As a Robot user I want to be able to designate keep-out zones or areas on a map so that my robot will go around those areas instead of through them | ||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for indoor/outdoor robot navigation in areas where there may be safety issues or hazards | ||
| - Example: a courier robot in a logistics warehouse may be required to avoid areas where the forklift is unloading pallets from trucks | ||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify a keep out zones on a map through a GUI | ||
| - The keep out zones should also be able to be specified programmatically through an API or config file | ||
|
||
|
|
||
|
There was a problem hiding this comment. We might also need to specify a physical way that the user can present keep out areas to the robot such as - The user can define keep out areas by marking the floor with tape. There was a problem hiding this comment. I recommend keeping the use case at a high level to avoid specific implementation decisions. In this case, for example, the intent is to identify keep-out zones. That can be accomplished in multiple ways, which don't have to be specified here. So, we could drop the "on a map" part. There was a problem hiding this comment. @orduno - I'm not sure about that one, I don't know that anyone really expects to be able to do that. It would be great however if we could support it in some way, but probably an enhancement / nice to have feature. There was a problem hiding this comment. @mjeronimo - Is it an implementation decision to say the user expects to be able to use a GUI to designate a keep-out-zone? There was a problem hiding this comment. @mkhansen-intel Yes. As Carlos has pointed out a keep-out zone could be defined another way, such as marking the floor with tape. The intention is that the Robot User is able to define the keep-out zones. The requirement is the same, but different systems could satisfy this requirement in different ways. We may decide to use a GUI to designate the keep-out zone, and that could even be included as a suggestion, but it isn't itself the use case/requirement, IMO. There was a problem hiding this comment. @mjeronimo - OK, I'll remove the GUI, Map, API parts from the UC and keep it more abstract for now, we can add more details later in the requirements level |
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
There was a problem hiding this comment. If this is just a map, then Image editors can be used to make keepout zones. (we did this on the fetch research robot -- https://github.com/fetchrobotics/fetch_ros/tree/indigo-devel/fetch_maps/maps). If it is some config file or API, we probably need a graphical tool for this to be useful to most people. There was a problem hiding this comment. I think we need both, the GUI will either create the config file or call the underlying API |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # Multi-story Building Navigation (2D+) | ||
| As a Robot user I want my robot to be able to navigate stairways, ramps or elevators to move to another portion of the multi-story building so that it can do something useful | ||
|
There was a problem hiding this comment. 'multi-story building' do that mean having several maps and switching from one another ? Or a single one ? How does that operate with the localization system ? There was a problem hiding this comment. The user is requesting that the robot should be capable of interfacing with the elevator to move between floors. I wonder if there are any other use cases that require the robot to interact with other machines. There was a problem hiding this comment. @orduno - I would expect the robot to be able to know to navigate into the elevator, at which point it might provide a message to another module which then controls the elevator and tells it when to get off. I believe there will be other "navigate to a known point, broadcast X, listen for Y, proceed to next location" scenarios. |
||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - Example: a delivery robot in an office building | ||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify stairways, ramps and elevators on a map for a robot to use or not use | ||
| - via a GUI | ||
| - via a config file or API so that it can be done by another program | ||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
There was a problem hiding this comment. Specifying this from yaml at the command line will be horrible. RVIZ or other GUI integration that allows users to click on maps and specify this would be much better. There was a problem hiding this comment. I'll update this one to state that we need both a GUI and a config file or API so that it can be done programmatically |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # Outdoor Localization | ||
| As a Robot user I want my robot to know its location on a given map of an outdoor area, such as a street or college campus, so that it can move around the area | ||
|
There was a problem hiding this comment. I would suggest that localization be handled external to the navigation stack -- packages like "robot_localization" already offer this outdoor localization and it is a whole system/project in it's own right. In that direction, I would also suggest that AMCL be moved external to navigation stack, so that when somebody finally make something from this millennium, we can start using it (without people thinking that AMCL is the "default" they should stick with) There was a problem hiding this comment. Agree that we should treat localization packages as something that can change, but still think the use case is relevant as we need to define the interfaces and message types being passed in order to make this possible. We may be the ones writing the "something from this millenium" in this case, I'm not assuming at all that we're using AMCL. That's a decision that we can discuss separately. There was a problem hiding this comment. I agree with Matt that even if it is an external package, we should consider/review its interface to allow for replacing it as a component. |
||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for outdoor robot navigation in most (all?) cases | ||
| - Example: a delivery robot on a college campus | ||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify a map to use and a location on that map for the robot | ||
| - The robot should be able to deduce it's own position on a map autonomously | ||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # Outdoor Navigation | ||
|
There was a problem hiding this comment. Rather than calling this "outdoor" -- I would suggest simply noting that we want non-planar navigation (that is, navigation on uneven ground). There was a problem hiding this comment. Why not outdoor? We have many use cases for outdoor delivery robots. Non-planarity may be a sub-requirement to this, but I'm not sure it captures the full intent. There may be other factors to consider for outdoor navigation besides planarity. There was a problem hiding this comment. If there are other requirements specific to outdoor, than that is fine name for the use case. As it it stands, there aren't any outdoor-specific requirements here, it was mainly >2D requirements. There was a problem hiding this comment. I want to capture more detailed requirements in the design/requirements folder. This is mainly intended to scope things at the top level. At this high level, we want the navigation to work outdoors as well as indoors. Wait until we start talking about drone and submarine navigation! :) There was a problem hiding this comment. I agree with Matt, from a robot user standpoint the request can be to handle indoor navigation, outdoor, or both. The characteristics of each can be derived later. There was a problem hiding this comment. Actually we should be able to handle indoor and outdoor dynamically switching between the two as needed. That might be another use case to add. |
||
| As a Robot user I want my robot to autonomously navigate to a given location on a given outdoor map, such as a college campus or street, so that it can do something useful at that location | ||
|
There was a problem hiding this comment. In these use cases, we keep referring to navigating to a specific location. Should we include navigating to that position with a specific orientation? It's not really an issue for a turtlebot, but for a car-like robot it matters. There was a problem hiding this comment. I think it's a good idea to generalize, where appropriate (as in this case). There was a problem hiding this comment. @crdelsey - I think it will be necessary to specify a location and pose (orientation), but also agree with @mjeronimo that we keep it general here if possible |
||
|
|
||
| ## More details | ||
| - Why is this needed? | ||
| - This is needed for outdoor robot navigation in most (all?) cases | ||
| - Example: a delivery robot on a college campus | ||
|
|
||
| - What is the expected user interaction? | ||
| - The user should be able to specify a map to use and a location on that map for the robot to move to. | ||
|
|
||
| - Are there any non-functional requirements? (build system, tools, performance, etc) | ||
|
|
||
|
|
||
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.
"fast enough" might not be a good metric -- there is a big divide between systems that simply process the environment around them and those that predict how the environment will change (through things like dynamic obstacle modeling)
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 was the template example, but if you have a suggestion as to how to better quantify the performance, please add it to the comments and we'll adjust the collision avoidance uc.
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 think this is more of a safety requirement - the robot should avoid other moving objects (collision avoidance). Also, we'd have to quantify what we mean by "avoid." For example, should the robot maintain a space buffer between itself and other moving objects? Does this vary by speed? To meet this safety requirement we will, of course, need sufficient processing power, but that comes later, when we design a system to meet the requirements.