Comments (15)
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.
from subt.
Original comment by Martin Dlouhy (Bitbucket: robotikacz).
OK - but reporting of detected artifacts is not limited by RF or is it?
from subt.
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?
from subt.
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?
from subt.
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??
from subt.
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.
from subt.
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??
from subt.
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?
from subt.
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?
from subt.
Original comment by Alfredo Bencomo (Bitbucket: bencomo).
- changed state from "new" to "wontfix"
During the competition, ROS communication will be blocked.
from subt.
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.
from subt.
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
from subt.
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:
- Something like https://cython.org/ might be a good choice to build a python wrapper around the existing API.
- (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.
from subt.
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
from subt.
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.
from subt.
Related Issues (20)
- AWS prelim worlds HOT 5
- Very incorrect ranges from lidar HOT 9
- Question - What time on the 26th are submissions due? HOT 1
- Comms TCP/IP failure
- How to use Mapping Server HOT 4
- Prelim World 1 Violates Artifact Specification For Gas HOT 3
- Finals World 8 visualization HOT 1
- REST API for final worlds? HOT 2
- [GUI] [Dbg] [Gui.cc:151] GUI requesting list of world names. The server may be busy downloading resources. Please be patient. HOT 6
- Error when using ctu_cras_norlab_spot_sensor_config_1 HOT 8
- Can not move the spot HOT 13
- Unable to create the rendering window HOT 2
- [ERROR]:Cant get transform for distance traveled counter "darpa" passed to lookupTransform argument source_frame does not exist. HOT 1
- terminate called after throwing an instance of 'Ogre::InvalidParametersException' what(): OGRE EXCEPTION(2:InvalidParametersException): All framebuffer formats with this texture internal format unsupported in GL3PlusFrameBufferObject::initialise at /var/lib/jenkins/workspace/ogre-2.1-debbuilder/repo/RenderSystems/GL3Plus/src/OgreGL3PlusFrameBufferObject.cpp (line 229)
- an undefined reference mistake, and I have already installed curl 7.55.1 HOT 1
- Dynamic obstacles in ignition (e.g. walking pedestrian) HOT 1
- rendering issue in simulation (blue, red stuff)
- How to make the robot start from the specified position HOT 1
- Help needed visualizing mapping server
- Network range simulation HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from subt.