osrf-migration
commented
4 years ago Open osrf-migration opened 4 years ago
osrf-migration
commented
4 years ago osrf-migration
commented
4 years ago Original comment by Alfredo Bencomo (Bitbucket: bencomo).
osrf-migration
commented
4 years ago Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
This looks like a good idea. Would you be okay with this change taking place after the tunnel circuit competition is complete? Changing the API now would affect all teams, and could cause unwanted disruptions in a team's testing and development.
osrf-migration
commented
4 years ago Original comment by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).
Let’s see if we can get enough of thumbs up from the other teams for this. Since the final date has been postponed there is now much more time. The thing is that it should simplify building solution images for everyone so it would be a pity not to have it already for this round.
osrf-migration
commented
4 years ago Original comment by Sophisticated Engineering (Bitbucket: sopheng).
It is still unclear to me how the solution container has to be build (a how-to for this would be nice). So, if this proposal makes it easier, I would agree to take some additional effort to change the communication. But before this decision is made I would like to get a better understand what will has to be changed. (Maybe a short example would help.)
osrf-migration
commented
4 years ago Original comment by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).
Currently you need to include this subt workspace in your solution and you need to be able to build it so you also need to be able to install all its dependencies. If this proposal is accepted you will no longer need to do this. The only requirement afterwards will be to be able to talk to rosmaster in the bridge container. All of this https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/api would become ROS-based - especially this https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/api#markdown-header-communications would change to topics.
osrf-migration
commented
4 years ago Original comment by Sarah Kitchen (Bitbucket: snkitche).
As of right now, we do not feel a need to transition to a ROS API for comms. We’d prefer to not to duplicate the effort of redeveloping the comms interface. Though, the caveat there is that we haven’t finished transitioning yet, so there could be undiscovered issues that will make me regret this claim...
However, a streamlined workflow with respect to the docker containers and more clarity on integration and solution presentation would be appreciated. The subt_shell docker (which I believe is still the same as the built image?) has the full subt repository. A “solution container” only needs tunnel_circuit, and doesn’t need everything in the catkin_ws install - such as the docker directory. So there could be potentially a lot of clean-up and subsequent reduction in dependencies that could be done.
osrf-migration
commented
4 years ago Original comment by Hector Escobar (Bitbucket: hector_escobar).
We think that transitioning to a ROS API would be beneficial after the tunnel circuit event as our efforts were focused towards using the current implementation.
osrf-migration
commented
4 years ago Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
osrf-migration
commented
4 years ago Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
We can consider this for the final event. Changes to the API between Circuit events is problematic due to the short development time frames.
nkoenig
commented
3 years ago This was closed on bitbucket, and was re-opened during migration to github.
zwn
commented
3 years ago It has not been closed on bitbucket. The status on bitbucket is NEW. The last response there was:
We can consider this for the final event. Changes to the API between Circuit events is problematic due to the short development time frames.
nkoenig
commented
3 years ago You're right, I misread the history.
peci1
commented
3 years ago There has long been the ROS API.
It is "described" and serviced by SubtRosRelay:
These are the registration, binding and sendto services... To receive messages, just create a ROS service server on topic /<robot>, and if you bind an endpoint, you will start receiving messages to this service.
However, without #625, there's no real benefit in using this API directly. If you want to go the hacker way, you can create your own fake subt_ros package containing just the message definitions. That should allow you to build solution containers without the subt workspace.
Original report (archived issue) by Zbyněk Winkler (Bitbucket: Zbyněk Winkler (robotika)).
I propose to replace CommsClient API with the following ROS based API.
Each robot would have /<ROBOT_NAME/comms/receive ROS topic where it would receive messages that the communication model decides are to be received (replacing the current Bind(callback, address, port)).
Additionally each robot would publish its own messages it wants to send to a topic /<ROBOT_NAME>/comms/send. The communication model would listen on this topic and do its thing (model the communication) and decide who receives it, replacing current SendTo().
The message would have two fields - address and data. Both topics would be of the same type.
Effectively, this moves CommsClient inside the Bridge Container and overall simplifies https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/cloudsim_architecture.
The main advantage of this proposal is to decouple subt repository and teams Solution Container. The teams would be free to base they docker images on whatever they need/want and the only requirement would be to “talk ROS”. It has the potential to further simplify OSRF SubT release workflow since the prebuilt docker images on DockerHub could now be the only release channel.
The ROS based API could be further tuned/improved, the main point of this proposal is the decoupling.