# Enabling End-Users in Designing and Executing of Complex, Collaborative Robotic Processes
## 3 Use Cases
### Message-Flow Paths
#### 3.2.2 Environmental Skills-Virtual Storage Concept  
UCI2 uses, e.g., the bottom slide-sensor of trays to find out if there is still space to put down parts. But what if we want to change the slides to an other kind of store concept later? Or what if the sensor-name differs on another slider scenario? An initial finding is that using real sensor-names in programs makes them less portable to other settings. Also if someone wants to enlarge the space for parts at the table, e.g., by adding additional slides 'Slide_C' and 'Slide_D' later, the programs then must be massively adapted by the task engineer. This might even be too complex.  
Thus, we propose to hide these details for the task designer. Actually, the plan in the project was to include only the obvious skills of robotic devices via registration to the platform. But if we look deeper in this grab and put scenarios, we immediately see, that some kind of storage concept would be very useful for manipulators, boxes, slides and trays. If we grab objects we may have a camera at this position which can tell us if there's a part available to grab. Or some technical sensors could have this knowledge. Or some algorithm is internally counting parts on locations. One question in our use case was also whether to model the camera on the UR10 as an individual device. But we decided against this because the camera was mounted directly on the UR10. However, this now led to a sort of 'combined device' of a UR10 and a camera, which left room for discussion about what skills to provide then. For example, if someone implements only a skill _GrabObject_ and internally hides the cameras skill _DetectObject_, then the error case when the camera did not detect a part must be included in the _GrabObject_ skill.  
However, if reuse and program simplicity are to be the primary concerns, we suggest that the task engineer not be burdened with these technical details. Instead we propose to add a \"Virtual Storage\" concept providing some appropriate skills:  
At a minimum one storage skill shall give task designers the ability to count how many objects of a given objecttype are at a given location, e.g., _CountObjects(sObjType,sObjPosition). And a second skill, e.g., _CountObjectSpaces(sObjType, sObjPosition)_ is needed to give the numbers of spaces available for a special object type at a given Position. Some additional comfort functions may, e.g., be _ExistsObject(sObjType, sObjPosition)_ and _ExistsObjectSpace(sObjType, sObjPosition)_.  
The usage of these skills now can increase the interoperability between different technical robot scenarios in the future by abstracting the concrete technical implementation. This also leaves enough room for the robotic engineer for later process improvements by, e.g., adding cameras, additional sensors or slides.  
So in UCI1 instead of  
```
1 WhilenotUciUr10.GetData(Slide_A_Status_Part_Cube_StorageIsFull):now
1:whileUciUr10.CountObjectSpaces('Table','Part_Cube')>0:or even simpler
1:whileUciUr10.ExistsObjectSpace('Table','Part_Cube'):
```  
can be used to test if there's enough space left to put cubes on the (slide on the) table. And in both use cases _CountObjects_ can be used before a grab operation to not grab parts if there are none available. Whereas _CountObjectSpaces_ can prevent to try to put objects at positions where there is no space available, if this is needed in user programming.  
Thus, in order to develop more robust, portable and adaptable tasks, we recommend determining the appropriate skills based on more than just the obvious robotic skills - we see a need for some kind of environmental skills too.