First use cases for review and discussion

[mkhansenbot]

Added the first set of use cases for review

[mhpanah]

Is this robot's initial location?

[mkhansenbot]

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.

[mjeronimo]

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.

[mhpanah]

Should the robot also update the map as it moves?

[mikeferguson]

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.

[artivis]

Agree with @mikeferguson.

[orduno]

Will the user expect the robot to handle any environment? fixed, dynamic, unstructured, etc.

[mikeferguson]

"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)

[mkhansenbot]

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.

[mjeronimo]

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.

[mikeferguson]

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.

[mkhansenbot]

Yes, I think we need to handle this cleanly, thus the example here.

[artivis]

Moreover there are situations in which one cannot wait on the planner to react, thus the need for some kind of preemptable states.

[mikeferguson]

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)

[mkhansenbot]

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".

[artivis]

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.

[mikeferguson]

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.

[mikeferguson]

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).

[mkhansenbot]

By unknown space do you mean areas that aren't on the map or something else?

[mikeferguson]

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).

[mkhansenbot]

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.

[mikeferguson]

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)

[mikeferguson]

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.

[artivis]

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.

[mikeferguson]

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.

[mkhansenbot]

I think we need both, the GUI will either create the config file or call the underlying API

[artivis]

The GUI could simply be a Rviz plugin.

[mikeferguson]

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)

[mkhansenbot]

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.

[mjeronimo]

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.

[mikeferguson]

Rather than calling this "outdoor" -- I would suggest simply noting that we want non-planar navigation (that is, navigation on uneven ground).

[mkhansenbot]

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.

[mikeferguson]

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.

[mkhansenbot]

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! :)

[orduno]

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.

[mkhansenbot]

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.

[mikeferguson]

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.

[mkhansenbot]

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.

[mikeferguson]

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.

[mkhansenbot]

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.

[mikeferguson]

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.

[artivis]

The map-representation(s) will be one of the driving wheel of the design and impose a de facto computation power requirements.

[artivis]

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.

[artivis]

Robot location, is that metric (3.12, 7.42), topologic (node 5), semantic maybe (near the fridge) ... ?

[orduno]

@artivis - should the user specify or care about what metric to use for robot location?

[artivis]

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.

[mjeronimo]

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.

[artivis]

Agree with @mikeferguson.

[artivis]

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.

[artivis]

The map-representation(s) will be one of the driving wheel of the design and impose a de facto computation power requirements.

[artivis]

The GUI could simply be a Rviz plugin.

[artivis]

'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 ?

[orduno]

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.

[mkhansenbot]

@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.

[artivis]

A tool should provide feedback about the overall confidence of the localization. Also in a non-expert fashion (Localized, Uncertain, Lost ...).

[artivis]

The same manner as ROS1 move_base, ROS2 localization could offer configurable/customizable recovery-behavior.

[orduno]

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.

[mkhansenbot]

@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.

[orduno]

Related to my comment above about collision avoidance, what does the user expect the robot to do when it get's lost.

[mjeronimo]

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?

[orduno]

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.

[mjeronimo]

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.

[mkhansenbot]

@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.

[mkhansenbot]

@mjeronimo - Is it an implementation decision to say the user expects to be able to use a GUI to designate a keep-out-zone?

[mjeronimo]

@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.

[mkhansenbot]

@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

[orduno]

Looks good, I had some minor comments.

[ghost]

Additional optional sections to consider adding to the uses cases:

• Technical Variations
• Exception conditions.

For technical variations, I can see variability based on sensor suite and motion platform in some use cases.

[mkhansenbot]

@crdelsey - do you mean that if a particular sensor or motion platform is used, the use case changes? I think we want to keep it abstract enough to work with more than one set of sensors or motion platforms. Maybe I don't understand what you're suggesting here.

[ghost]

@mkhansen-intel At the level of detail these use cases are at, the platform and sensors probably don't come into play to much. However, when we try to go to the next level ... for instance, defining what exactly we mean by avoiding an obstacle, well, then it probably matters that our sensors can only see in a narrow field of view, or we have no ability to look up or down.

Even at our current level of detail, the technical variations section may be applicable to the "keep out zones" use case. The main use case could specify that the user defines the keep out zones in a gui. A technical variation could be that the user specifies the keep out zone using an API or through markers on a map or markers in the real world (eg tape on the ground, etc)

[ghost]

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.

[mjeronimo]

I think it's a good idea to generalize, where appropriate (as in this case).

[mkhansenbot]

@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

[mkhansenbot]

All commenters / reviewers - great comments and input so far. I believe this can be merged now but I'll leave it open until tomorrow before merging just to make sure everyone who wants to has a chance to give input.