Choices... and patterns.
The BPMN (model) groups together and describe business function by setting boundaries around and relationship between one or more tasks. Tasks are related to other tasks and roles(workers/robots). Good fit for telling a robot what to do in terms of task-driven, or originating, event instructions. And these robots naturally conserve effort/energy - goal oriented.
So a process model organizes tasks. And, as each task receives tokens (context), their underlying java components get called. These java-based services are then free to assemble event payloads (JSON) before posting them to various middle-ware channels such as messaging, etc.. For critical activities, I prefer messaging infrastructure supporting transaction services.
Since you're orchestrating robots - I'd lean towards a more data-centric view.
1) Camunda orchestrates the tasks into meaningfully aligned, goal-oriented, activities such as "build a car".
2) Tasks, and their java implementations, then assemble and send messages into the event-stream, middle-ware channels, etc.
3) While Camunda is handling the long-running business-transactions, the middle-ware handles traditional transaction services (alongside event-processing). Thinking in terms of message-based, event-oriented systems.
4) Services (SOA) listen for and react to these events. For example, the robot does X because it was told to do so via certain event types and payloads.