[Fiware-robotics] R: R: Interesting topics

[Antonini Roberto]

Hi all,
Hence, once paid attention to:

·         ROS messages not conveying more than 1MB per message,

·         update rate less than ... (please specify)

·         not have binary-alike data

Theoretically we could create whichever attribute coming from whichever ROS message, as FIROS doesn't have limitations.
Just an example to better understand what we mean, here is the ROS message conveying info from kobuki robot (the turtlebot base):

~sensors/core (kobuki_msgs/SensorState<http://docs.ros.org/api/kobuki_msgs/html/msg/SensorState.html>)
·         Kobuki sensor data messages. This topic provides detailed information about the entire state package that is transmitted at 50Hz from the robot.


info there are also related to robot and PC battery and, as you can see, it's a very flat message; hoping that 50 hz of frequency rate could be accepted by CB, for sure the amount of data is very far less than 1MB.
As you can see,  if we want to engage turtlebot2 robot, this message inform users of its remaining battery.
A couple of questions from example above:

·         Given RCM being able to retrieve this message from the clone of turtlebot robot, could FIROS filter it out, as it's not included in the list you sent us?

·         Starting for message type example above, have you considered that ROS message type provided to FIROS strictly depend on the launched ROS nodes (kobuki driver ROS node)? In our view, you shouldn't limit a-priori the ROS message types, otherwise, in this case, we wouldn't know anything about robot battery.

Our suggestion is a black list instead of a white list, that is the list of ROS message type the CB is not able to manage!
What d'you think?

BR
RCM Team.




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: giovedì 30 aprile 2015 12:44
A: fiware-robotics at lists.fi-ware.org
Oggetto: Re: [Fiware-robotics] R: Interesting topics

Hi all,

We've found some limitations in contextBroker:
1) As you can find in the wiki, the request maximum size is 1MB<https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#Request_maximum_size>, which is not enough for some topics.
2) ContextBroker does not recycle TCP sockets, neither it accepts keep-alive http connections. So, the TCP sockets usage is really high, which results in weird network behavior or outages. This one can be avoided by limitting the update rate or the number of elements that must be updated.
3) We've some issues while sending binary-alike data to contextBroker (images and so).

There are other issues in coding and minor differences between the several versions of contextBroker, but FIROS usually can handle them.

BR,
Pepe

On 30/04/15 09:18, Antonini Roberto wrote:
Hi Pepe,
starting from the list below, I have some doubt about how CB is working, I will try to better explain what I mean: to my know, CB allows external user to create entity and its attributes,  for sake of simplicity I report the JSON object you have to post to do it:

    "contextElements": [
        {
            "type": "Room",
            "isPattern": "false",
            "id": "Room1",
            "attributes": [
            {
                "name": "temperature",
                "type": "float",
                "value": "23"
            },
            {
                "name": "pressure",
                "type": "integer",
                "value": "720"
            }
            ]
        }
    ],
    "updateAction": "APPEND"

I consider FIROS an external user from CB perspective, correct me if I'm wrong, so FIROS it's able to create, publish to CB (e.g. example above) and being notified when something change (i.e. the pressure of room named Room1). In order to project Robot Clone to CB, FIROS creates an entity, named as the Robot Clone, with attributes reporting the ROS messages in the format above, i.e.:

    "contextElements": [
        {
            "type": "Robot",
            "isPattern": "false",
            "id": "Turtlebot",
            "attributes": [
            {
                "name": "/cmd_vel",
                "type": "geometry_msgs/Twist",
                "value": "{linear : { x : 0, y : 0, z : 0 },
                           angular : { x : 0, y : 0, z : 0, w : 0}
                       }"
            },
            {
                "name": "/odom",
                "type": "nav_msgs/odometry",
                "value": "{ ... }"
            }
            ]
        }
    ],
    "updateAction": "APPEND"

So CB accepts, let's say, JSON object to be configured, if I want to move the robot I have to update object above by simply changing some values in /cmd_vel attribute, i.e. :

"contextElements": [
        {
            "type": "Robot",
            "isPattern": "false",
            "id": "Turtlebot",
            "attributes": [
            {
                "name": "/cmd_vel",
                "type": "geometry_msgs/Twist",
                "value": "{linear : { x : 0.3, y : 0, z : 0 },
                           angular : { x : 0, y : 0, z : 0, w : 0}
                       }"
            },
            ]
        }
    ],
    "updateAction": "APPEND"

In this way the robot will be moved along x axis with  a velocity of 30 cm/s.
The /odom attribute instead notify me, as FIWARE user, with robot position estimate with a rate of 10 or 20 Hz, in this case FIROS subscribes /odom topic and publishes its value to CB in order to update the value for FIWARE user benefit.

Starting from the examples above, could you please clarify to us which are the CB limitations? I suppose they are more related to something like /odom dynamic  and particularly the value update frequency, in that case 10 or 20 Hz, is it correct?

Thanks in advance,
Roberto
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 Jose Jaime Ariza
Inviato: mercoledì 29 aprile 2015 16:03
A: fiware-robotics at lists.fi-ware.org<mailto:fiware-robotics at lists.fi-ware.org>
Oggetto: [Fiware-robotics] Interesting topics

Hi all,

Just as commented in the last call, here you have some of the topics which contextBroker can manage and are interesting enough to be sent "outside ROS":
Topic

Message type

cmd_vel

geometry_msgs.msg.Twist

cmd_vel_mux/input/teleop

geometry_msgs.msg.Twist

move_base/cancel

actionlib_msgs.msg.GoalID

move_base/goal

move_base_msgs.msg.MoveBaseActionGoal

move_base/result

move_base_msgs.msg.MoveBaseActionResult


BR,
Pepe



--

José Jaime Ariza

R&D Engineer

+34 696604288

Ikergune, Etxe-Tar group
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/20150505/62f6d1bc/attachment.html>