Hi Pepe, All, I ‘ve added my comments inline. BR, Gianmario Da: fiware-robotics-bounces at lists.fi-ware.org [mailto:fiware-robotics-bounces at lists.fi-ware.org] Per conto di Jose Jaime Ariza Inviato: venerdì 15 maggio 2015 15:20 A: fiware-robotics at lists.fi-ware.org Oggetto: Re: [Fiware-robotics] R: 2 level filter for robotics GE Hi All, Roberto, about this assertion: FIROS will be in charge to filter out ROS topics by applying a white list, that is compiled from developer (what you defined as FIROS User Level Filter) and RCM will provide FIROS with all ROS topics, is it correct? I don't think we've reached to an agreement yet. We, as Gianmario says, must adopt the simplest working solution, but from the users point of view, not ours. So I still think we must shorten the number of attributes we make available to contextBroker by having a coarse filtration in RCM (call it whitelist or blacklist). Of course, FIROS is perfectly able to work without RCM filtration, so we can run our live demos without the secondary filtering, but I still think that this is not the ideal aproach: our GE must provide the 2-level filtering. We have not yet reached a shared “ideal approach” for filtering, but we have an agreement on the simplest working solution. The complexity lies in the definition of – let me say – metarules for filtering, e.g. which rules to use for defining the rules to generate filtering, depending on the applications requirements, user needs, robotics use and purposes. This is what Roberto called the (nonlocal) “a priory” knowledge. Well, in few words, this will imply also a knowledge of the Robotics GE early adopters (expertise, feedback, design approach, app types) that we don’t have yet. We'll add the required API documentation and improve the architecture description ASAP. Good. Considering these API are agreed and strictly required for all live demos, we need to add them before the imminent release of the first architecture deliverable. We've made some comments in the minutes (28 April '15 and 5 May '15) in order to correct some innacuracies we found, please have a look at them. Comments are always welcomed. Minutes are just snapshots of evolving definitions. We wrote them while the discussion was going on, and subsequent actions have added or evolved these information. I would suggest you to check also the shared Robotics document (renamed Robotics GE - OpenSpec draft<https://docs.google.com/document/d/1eWO5MYYkjJEo1xLLm2YsX_bhCnET5eX4dm4_cL9MFg0/edit?pli=1#heading=h.5wyw0jlpfq50> ) and put there notes and suggestions for technical aspects to be shared. Specifically, that document is the one that defines the common agreed assumptions for RCM-FIROS and will become the official deliverable. BR, Pepe. On 14/05/15 15:32, Bollano Gianmario wrote: Hi All, thank you all for the different contributions, e-mails and the discussion in the last call. We have considered constraints, usage, technical issues for the Robotics GE. We made hypothesis and proposals based on our reciprocal experience, and we put effort in our analysis. But we still do not have direct feedback from users/groups potentially interested in the Robotics GE. Then, for now we don’t know which might be the best solution. I would suggest, as Roberto has proposed, to adopt the simplest working solution. We need now the best effort solution, to enable the implementation of the live demos. In this moment it appears that the Whitelist filtering (user level), implemented in FIROS, is not only the straight solution, but also the one able to work, without further changes, for the live demos. After the live demos further feedback might come, from GE users of from other groups. We’ll be able to apply refinement after feedbacks, taking into account also the available resources. I really want to stick to “Occam’s razor principle”: if we cannot weight alternatives, choose the simplest available one. The FIROS User level Whitelist also implies the presence of API; as suggested by Roberto and Pier (please see the Robotics call minutes<https://docs.google.com/document/d/1CAwhNqoMf7KnP_yHjITo2gRrVoWCKMsthiWX3ZWWLHo/edit?pli=1>), it’s important to provide documentation in the Robotics Architecture<https://forge.fiware.org/plugins/mediawiki/wiki/fiwarei2nd/index.php/FIWARE.ArchitectureDescription.I2ND.Robotics> page, which now only shows the RDAPI of RCM and CBAPI of FIROS. Please, specify if the Filtering in FIROS needs further API besides CBAPI, and write few line to describe them (more detailed description will be provided in the Open API Deliverable). We will have to publish the Architecture very shortly, then I would ask and remind you to update the FIROS API in the block diagram and text, as soon as possible. BR, Gianmario Da: fiware-robotics-bounces at lists.fi-ware.org<mailto:fiware-robotics-bounces at lists.fi-ware.org> [mailto:fiware-robotics-bounces at lists.fi-ware.org] Per conto di Antonini Roberto Inviato: mercoledì 13 maggio 2015 15:22 A: fiware-robotics at lists.fi-ware.org<mailto:fiware-robotics at lists.fi-ware.org> Oggetto: [Fiware-robotics] R: 2 level filter for robotics GE Hi all, Just to try to summarize what we discussed yesterday and the two different positions: · ET claims that FIWARE application developers won’t use Robotics GE, if we provide them with lot of attributes (ROS topics), the most of which will be never used. · TI claims that we need to provide FIWARE application developers with the most flexibility for building new application, hence it will be the developer who will select the attributes/topics to update or be notified with. The unawareness of ROS and all this topics/attributes is directly proportioned to the API level, not to a-priori filtering. Starting from this two different positions, what we agreed was: FIROS will be in charge to filter out ROS topics by applying a white list, that is compiled from developer (what you defined as FIROS User Level Filter) and RCM will provide FIROS with all ROS topics, is it correct? If so, I would ask you to please add to the architecture in the WIKI page the API for managing this filtering at developer level. BR, Roberto Da: fiware-robotics-bounces at lists.fi-ware.org<mailto:fiware-robotics-bounces at lists.fi-ware.org> [mailto:fiware-robotics-bounces at lists.fi-ware.org] Per conto di Iñigo Gonzalez Inviato: giovedì 7 maggio 2015 15:18 A: fiware-robotics at lists.fi-ware.org<mailto:fiware-robotics at lists.fi-ware.org> Oggetto: [Fiware-robotics] 2 level filter for robotics GE Hi, as we talk in the call, here yo have what we talked about in the last call, I explain why we should use the 2 level filter and answer the points that were asked in the call: Proposal The robotics GE’s main objective is to make easy for users the robot managing. Most of those users are common developers that have development knowledges but no knowledge in robotics, so to make an easy and user friendly integration of FIWARE + robots we have thought that FIROS + RCM Generic enabler should have a 2 level filter: RCM - Application level filter RCM will filter the topics that aren’t necessary for the user, for example those used only in navigation algorithms like happens with the cloud of points. This is quite important for the common user, because this filter will reduce the amount of topics he will be notificated of, making easier to know which topics are important to interact with the robot. When RCM is going to bring up the robot with its configuration, a kobuki for example, it knows that it should bring up a kinect (or a laser), a mobile base and navigation algorithms. Many of the topics generated aren’t necessary for user interaction and/or aren’t compatible with the contextbroker, so if the robot contains topics of this type (not necessary for user or not CB compatible) it won’t send them to FIROS. So this filter will be an application level filter and the user shouldn’t touch it. If a user wants to change this configuration (something not recommended) RCM shall provide an API to override the configuration as it is done in FIROS. RCM should filter the topics as it is configured to, but if the users send to the api new filter rules, the new ones should overwrite the default ones. FIROS - User Level filter In the other hand firos has a robot → topic whitelist. This list will be a user level filter, where the user defines the robot and the topics he wants publish or listen to. This whitelist supports regular expressions so a user can connect with more topics writing less. With this solution RCM will send to FIROS the topics that the user can use (sending all has no sense, because the user can’t do anything with them). And the user will select from this list which ones will use. Comments from the talk Use a blacklist instead a whitelist The user will use less topics that the ones that won’t be used so using a whitelist the user will have to configure less things. RCM sends all the topics and the user should say which ones aren’t compatible with CB If a user that is not familiar with robotics have to check each messages’ format and size to change the configuration no one will use the robotics GE, because configuring one robot would take lots of hours, a kobuki with a kinect brings up at least 30 topics, as is said check the format and size (the size can be different depending on content) of each one can take hours or days of work. To give flexibility RCM will send all the topics to Firos and it will filter them This is not a good idea, FIROS doesn’t know about robots, so it shouldn’t know what things it has to filter, but RCM knows which things are brought up, so RCM should filter some thing. If it would be necessary in some moment to have access to other topics RCM will provide of an api to change the filter as is said before. FIROS have this implemented for the user level filter, it has a file where the user adds the robots and the topics, but it haves a rest api that overwrites this configuration, so if a user only configures FIROS to publish to goal, and after that adds the teleop using the api it will listen to both of topics. So RCM should do the same, by default send only the topics needed by the user and if the user needs more he will ask for them. RCM should publish all the topics, since the user maybe wants to use ros via rosbridge Rosbridge is a ros tools and is independent to firos and RCM, if a user wants to work with rosbridge it won't go through FIROS and RCM, so FIROS and RCM don’t need any change to allow a user to use rosbridge. Regards, Iñigo Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è necessario. -- José Jaime Ariza R&D Engineer +34 696604288 Ikergune, Etxe-Tar group -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-robotics/attachments/20150515/7002e5cc/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy