Relation with the midleware ROS


#1

Hello,

Is there a way to connect camunda platform with the ROS midleware if working with C ++ or java languages.

Thank you,
Cordially.


#2

With bindings for C, C++, Python, and Java… it doesn’t sound like you’d bump into a problem.
Assuming you’re referencing ROSOSGI.

However, not sure about your actual response/latency constraints.

I’d recommend integration via an event-based infrastructure. Specifically thinking of Kafka (or similar).


#3

@garysamuelson excuse me but I do not know too much. can you explain to me with more details please, how can I connect Camunda with the ROS midleware and what are the ways that I need to use?

thank you.


#4

I was thinking of the following patterns/concepts:

  1. Setting up orchestration and collaboration (recommend a collaboration approach - based on early assumptions): segmenting command/communication channels into… command and feedback/monitoring, based on performance constraints.
  2. Feedback/monitoring may likely end up flowing into msg infrastructure (i.e. topic), goal is offloading as much non-process information/control away from the dedicated Camunda host/container. Letting Camunda focus on process while allowing other, dedicated services help wrangle messaging between “control” and “feedback/monitoring”.
  3. An API gateway framework manages the ReST/API interfaces into Camunda - this maybe needed to help manage session and reliability. The API provided via both ReST and Msg services
  4. Because a “Robot” likely has built-in process (set of commands per activity) implies a critical feedback requirement, meaning that we’re potentially looking at some latency (though brief) between command and follow-through monitoring. Implies robust correlation with a conservative use of session (reasonably brief context). This drives a balanced approach to monitoring in-flight process instances between systems. So, thinking specially about managing and sharing sessions between interested/dependent sub-systems (parallel monitoring and recovery).
  5. Communication options: OSGI: ReST, EJB, Kafka (assuming Kafka+OSGI viable), ReST (Jax-RS, etc.). Or, direct integration (short-circuit OSGI) into middleware services. Meaning, we have a lessor-weight bridge between systems (i.e. C/C++ to Middleware)

#5

thank you very much for your answer sir.