Gazebo | Ignition | Community
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working. But after studying the tutorial and trying the example Publisher/Subscriber:

http://ignition-transport.readthedocs.io/en/latest/messages/messages.html

Thing is it seems that there is a linking problem to the proto file, although both CMakeLists are copied from source, same for the rest.

Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working. But after studying the tutorial and trying the example Publisher/Subscriber:

http://ignition-transport.readthedocs.io/en/latest/messages/messages.html

Publisher/Subscriber: http://ignition-transport.readthedocs.io/en/latest/messages/messages.html Thing is it seems that there is a linking problem to the proto file, although both CMakeLists are copied from source, same for the rest.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings 0MQ is perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Maastricht

Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working. But after studying the tutorial and trying the example Publisher/Subscriber: http://ignition-transport.readthedocs.io/en/latest/messages/messages.html Thing is it seems that there is a linking problem to the proto file, although both CMakeLists are copied from source, same for the rest.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ. 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings bindings, 0MQ is & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Maastricht

Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working. But after studying the tutorial and trying the example Publisher/Subscriber: http://ignition-transport.readthedocs.io/en/latest/messages/messages.html Thing is it seems that there is a linking problem to the proto file, although both CMakeLists are copied from source, same for the rest.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Maastricht

Aachen

Thanks *Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working. But after studying the tutorial and trying the example Publisher/Subscriber: http://ignition-transport.readthedocs.io/en/latest/messages/messages.html Thing is it seems that there is a linking problem to the proto file, although both CMakeLists are copied from source, same for the rest.working.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Aachen

*Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Aachen

Here some snippets. I'm always open for improvements: socket_com.hpp, socket_com.cpp

Deps: libzmq3-dev & includes are {zhelpers.hpp, zmq.hpp}

*Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Aachen

Here some snippets. I'm always open for improvements: socket_com.hpp, socket_com.cpp

Deps: libzmq3-dev & includes are {zhelpers.hpp, zmq.hpp}

*Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Aachen

Here some snippets. I'm always open for improvements: improvements, the plugin is causing an error when the model is deleted from the world: socket_com.hpp, socket_com.cpp

Deps: libzmq3-dev & includes are {zhelpers.hpp, zmq.hpp}

*Thanks for the reply! After a more detailed research I also started with Ignition Transport. Awesome approach and would totally fit my requirements when the windows side is also working.

[UPDATE]

Hi everyone,

I thought that it's maybe interesting how I worked out my Solution. So here my update:

In the end I decided to work with 0MQ in combination with protobuf. I have to communicate on the windows side with multiple programs, some written in c++(the robot controller) and some written in C#(database and other stuff). Because of multiple language bindings, 0MQ & protobuf are perfect for that and easy to implement. The learning curve is pretty high because of the well written api and very good documentation. I used mainly the pub/sub pattern because I have to deal with continuously changing data and that is working basically out of the box. So for me it worked out pretty good, thanks again for all advices.

Greets from Aachen

Here some snippets. I'm always open for improvements, the plugin is causing an error when the model is deleted from the world: world:

[ Bug Fixes :]

  • Model is now deletable without crashing gazebo
  • Threads are joined when plugin is detached
  • Signals are working now

socket_com.hpp, socket_com.cpp

Deps: libzmq3-dev & includes are {zhelpers.hpp, zmq.hpp}