iml130 / firos

Firos helps to connect ROS-based robots to the Fiware Ecosystem...
MIT License
12 stars 9 forks source link

Sending std_msgs.msg.Bool always receives True #4

Closed marija185 closed 5 years ago

marija185 commented 5 years ago

Hi all, I have tested sending a standard Bool ros msg through firos and I noticed that on the other side value true is always received even if I send 0 (or False). When I switch back to the original firos from Ikergune sending and receiving of 0 works. This is how I tested it: On machine 1: robots.json has topic: "map":{ "topics": { "do_serve": { "msg": "std_msgs.msg.Bool", "type": "subscriber" } } } On machine 2 is the same but the "type" is publisher. On machine 1 whitelist.json has: "subscriber": ["do_serve"] on machine 2 it is "publisher".

And by starting rosrun firos core.py on both machines and starting publishing on machine 1 and doing echo on machine 2 I got the following: machine 1: $ rostopic pub /map/do_serve std_msgs/Bool '{data: 0}' publishing and latching message. Press ctrl-C to terminate $ rostopic pub /map/do_serve std_msgs/Bool '{data: 1}'

machine 2: $ rostopic echo /map/do_serve data: True


data: True


When I switch back to version of https://github.com/Ikergune/firos.git and repeat this test on machine 2 I got the right result: $ rostopic echo /map/do_serve data: False


data: True


This is the only issue I noticed. Sending more complicated data like float64, int8, ... work. Best regards, Marija

iml-dlux commented 5 years ago

Hi Marija,

Sorry, but i am not able to reproduce this on branch development. The content published to the Context Broker is in both cases correct and looks (at least for me) like:

[
   {
      "id":"map",
      "type":"ROBOT",
      "do_serve":{
         "type":"std_msgs.Bool",
         "value":{
            "data":{
               "type":"boolean",
               "value":true
            }
         },
         "metadata":{... }
      }
   }
]

for command rostopic pub /map/do_serve std_msgs/Bool '{data: 1}' and:

[
   {
      "id":"map",
      "type":"ROBOT",
      "do_serve":{
         "type":"std_msgs.Bool",
         "value":{
            "data":{
               "type":"boolean",
               "value":false
            }
         },
         "metadata":{... }
      }
   }
]

for the command rostopic pub /map/do_serve std_msgs/Bool '{data: 0}' On the way back, i just sent the corresponding json strings back and firos translated them as follows:

CONSOLE:~$ rostopic echo /map/do_serve 
data: True
---
data: True
---
data: True
---
data: False
---
data: False
---
data: False
---

Did you also used the development-Branch? If so, then there might be other problems in firos i currently cannot think of.

Best regards, Dominik

marija185 commented 5 years ago

Thanks Dominik, I will try development branch. I used master. That might be the problem. I will repeat the test and come to you back. best regards, Marija

marija185 commented 5 years ago

Hi Dominik, I tried development branch and I can not send data at all. Then I tested one more time master branch so I can paste you the difference of the firos output in terminal: development branch: terminal of computer 1 after rostopic pub:

Serving HTTP on 0.0.0.0 port 10100 ...
Cannot update attributes in Contextbroker for topic: descriptions
Cannot update attributes in Contextbroker for topic: do_serve
Cannot update attributes in Contextbroker for topic: do_serve

terminal of computer 2 after rostopic pub: (nothing happens)

Serving HTTP on 0.0.0.0 port 10100 ...

master branch: terminal of computer 1 after rostopic pub:

Serving HTTP on 0.0.0.0 port 10100 ...

terminal of computer 2 after rostopic pub:

Serving HTTP on 0.0.0.0 port 10100 ...
172.19.0.5 - - [09/Jan/2019 13:13:47] "POST /firos HTTP/1.1" 200 -
[WARN] [1547036054.935254]: Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.
172.19.0.5 - - [09/Jan/2019 13:14:38] "POST /firos HTTP/1.1" 200 -
172.19.0.5 - - [09/Jan/2019 13:14:43] "POST /firos HTTP/1.1" 200 -
172.19.0.5 - - [09/Jan/2019 13:14:48] "POST /firos HTTP/1.1" 200 -
172.19.0.5 - - [09/Jan/2019 13:14:56] "POST /firos HTTP/1.1" 200 -

I restarted docker-compose to be sure to have a clean context broker but it doesn't help. Do you know what could be the problem? best regards Marija

iml-dlux commented 5 years ago

Hi Marija,

I have added additional Information which we get from the Context-Broker (on 'development') to the Error-Messages like:

Cannot update attributes in Contextbroker for topic: do_serve

There are a lot of changes currently between the Master- and Development-Branch, which will be (hopefully soon) merged together on some day. In commit e4093cee4cec9493409149eb98ed83d4c9d98654 , i have completely changed to NGSIv2 and also adjusted the content, which is sent to the Context-Broker. (Also the firosstamp is omitted).

If there is still 'old' content left on the Context-Broker from the master-Branch, there might be problems updating attributes due to the adjustment of the content.

You are using the docker-compose, i assume you are using this Fiware/Orion with a docker-compose.yml. As for all i know: if you run docker-compose down in this folder, all contents should be removed from it. (Also check if CONTEXT_BROKER:PORT/v2/subscriptions/ is empty, since the master-Branch sets an Expiration-Date of a whole Day, which could also lead to other problems)

It would also be helpful to share the content of the Context-Broker (if possible) and Message-Types so that i could reproduce it and make sure firos is even getting to that Point where it should update the attributes on Context-Broker (and by success computer 2 should receive the updates via the Context-Broker and send them back to ROS).

I hope it helps! Best Regards Dominik

marija185 commented 5 years ago

Hi Dominik, it seems like the syntax has changed for json files? I am just guessing. I did stop and down for docker-compose and everything was empty. After starting rosrun firos core.py again on both computers I got this as the result in context broker (http://161.53.68.95:1026/v2/entities)

[{"id":"dictad2fc4a5-727b-4ff0-9f47-4bc6b6909ba8","type":"dict"}]

and in terminal:

Cannot update attributes in Contextbroker for topic: descriptions :
{"error":"NotFound","description":"The requested entity has not been found. Check type and id"}
Cannot update attributes in Contextbroker for topic: do_serve :
{"error":"NotFound","description":"The requested entity has not been found. Check type and id"}

I am attaching my json files for computer 1 and computer 2. config_files_computer1.zip config_files_computer2.zip

iml-dlux commented 5 years ago

Hello Marija,

Sorry for the late reply.. Your example with your config files is working fine on my computer.

Is the git-submodule also at the latest version? There might be an old Object-Converter used in your local repo because the Id and Type are set wrong.

You can check the git-submodule-'Version' via: git submodule status. It should currently print the following:

66b290234ed1eed1c8935da295068d2e1264a844 scripts/include/FiwareObjectConverter (heads/master)

You can also check which 'Version' is used in the development branch via this Link (Github is highlightning the submodule with @).

To update the FiwareObjectConverter-Submodule to the version (which the Firos-Repo expects) you can use git submodule update.

This should solve your Problem.

Best Regards, Dominik

Luxxii commented 5 years ago

I am closing this Issue. The changes mentioned in this Issue are already pushed into master. Also, i was not able to reproduce this behavior.

If there are similar/other Problems regarding conversion please feel free to create a new Issue

Best Regards, Dominik