Hi, thank you for the detailed description, it will be very useful for further refinements. Today Davide and Roberto are off site; they’ll provide comments and proposals as soon as possible. Best, Gianmario Da: 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-robotics/attachments/20150507/fd4e7644/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: <https://lists.fiware.org/private/fiware-robotics/attachments/20150507/fd4e7644/attachment.jpg>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy