Replace CommsClient by ROS topic(s)?

[osrf-migration]

Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).

---

Is there any plan to replace CommsClient with ROS interface, i.e. that we could "publish" detected artifacts instead of creation of C++proxy?? We are using ROS from Python "externally", which is probably not very common use case :(. Thank you.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

The CommsClient cannot be replaced by ROS. All robot-to-robot communication must go through the CommsClient, which adds an RF modeling.

During the competition, ROS communication will be blocked.

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

OK - but reporting of detected artifacts is not limited by RF or is it?

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

I am sorry for misunderstanding - I read the "SubT_Challenge_Competition_Rules_Tunnel_Circuit.pdf" now, so the RF communication to the base station is also limited (in the extreme case the robot has to return from tunnel in order to transmit position of detected artifacts). Nevertheless I suppose that there could be "a device" attached to the robot, talking via ROS messages and sending/failing to transmit data depending on the robot location/orientation?

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

I don't quite understand your question. What would the "device" on the robot be talking to?

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

The device could be implemented via CommsClient - the idea is that it could be "attachable device" like simulated camera or LIDAR, providing ROS topic(s). Another point is that if you use standard ROS API/topics then it should be possible to submit Python only code too.

p.s. I am not sure if there is a plan that similarly to System Track you could drop some "communication beacon" - maybe it could be simulated this way??

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

We will likely support a device like a beacon, but the communication between the beacon and robots will still happen through the communication model and not through ROS.

ROS does not provide an RF propagation model, and is therefore not allowed for communication between simulated devices or robots.

[osrf-migration]

Original comment by Martin Dlouhy (Bitbucket: robotikacz).

---

I am still not sure if we understand each other. I do not meat to communicate via ROS topic directly robot2robot. I mean to talk to a device "mounted on each robot". This device can be maybe simulated in Gazebo??

Another issue is what to do, if we use Python code and not C/C++. For the first experiment we compiled small C code which communicated to the base, where Python code saves a file and C-code reports it ... but accidentally in the example setup there are 4 robots & 4 controllers, so the report was actually invalidly reported by all robots, including the once waiting in start area.

Any suggestion how to integrate Python code? We can have multiple different instances of C-code reporters, but maybe there is better solution??

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Is the "device" you are referring to designed to be dropped from the vehicle?

I don't fully understand your question about python. Can you create a separate issue, and include sample code along with how to run it?

[osrf-migration]

Original comment by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).

---

Our robot controller is written in python. CommsClient provides API only in C++. So in order to use CommsClient we need to create some dummy C++ warpper just to expose it to python. If the communication used standard ROS API, we wouldn’t have to do that. Also if ign transport had some python API, it would help. Or if we had executable like rostopic that could be executed to report the artefact, it would help. That’s all.

ROS does not provide an RF propagation model, and is therefore not allowed for communication between simulated devices or robots.

That is besides the point. The comms model is implemented inside gazebo anyway. We were just asking for it to be exposed in a more accessible way to python (see above for suggestions).

Is it more understandable now?

[osrf-migration]

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

---

• changed state from "new" to "wontfix"

During the competition, ROS communication will be blocked.

[osrf-migration]

Original comment by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).

---

From the comment I am still not sure you guys understand what we are talking about. We are not talking about ROS communication (what ever you picture under that term). The question is/was: Is C++ CommsClient the only way to interface to the RF propagation model implemented inside Gazebo? Can there be something more accessible from python?

During the competition, ROS communication will be blocked.

Strictly speaking, this is not true. ROS communication is the main mechanism to talk to the simulation. It is basic building stone to the whole thing. What you probably meant to say is that only allowed topics are part of the API to the simulation and we cannot add our own? If that is the case, again, that is not what we were asking for.

I am ok with wontfix. I just want to make sure we are on the same page.

[osrf-migration]

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

---

@zbyněk Winkler, feel free to open a new proposal ticket explaining in more details what we don’t understand and your specific technical needs.

It might also help if you take a look at this documentation: https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/cloudsim_architecture

[osrf-migration]

Original comment by Jon Fink (Bitbucket: jonfink-arl).

---

I think I understand what Zbynek is asking for - effectively a node that will run inside each robot’s docker container, create an instance of the subt CommsClient and then provide an interface to that client via ROS topics.

I have a general idea of how to accomplish this in C++ via the ROS ShapeShifter class for arbitrary topics, but I’m not sure that a solution will be good to go in the timeline of the tunnel circuit.

For accessing the CommsClient from Python in the tunnel circuit, I would suggest one of the following two approaches:

1. Something like https://cython.org/ might be a good choice to build a python wrapper around the existing API.
2. (similar to my generic approach above) Write a very simple C++ node that creates a CommsClient and sets up exactly the ROS subscribers and publishers you want to use to manage communication from Python.

[osrf-migration]

Original comment by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).

---

Jon Fink (jonfink) Thank you! I was starting to think there is something wrong with me since nobody understands what I am talking about 😃

[peci1]

Well, there actually already is a ROS-only API provided by subt_ros_relay. I think it'd satisfy everything you need to successfully communicate via the comms plugin. It's only missing the automatic neighbor discovery via beacon packets and querying the list of neighbors.

When I list the services created by subt_ros_relay, I see:

/address/register
/address/unregister
/broker
/end_point/register

The missing piece is IMO what I found in #638: to listen for incoming data on address, you create a subt_msgs/DatagramRos service server name /address. Of course, this still suffers from the inability to create multiple listening nodes, but you can create a "demux" relaying the service calls to a topic as I'm suggesting in #638.

/broker is a weird name, but it is the thing you want to call when sending messages to the comms interface.