Robocop aims at imposing a strict methodology to build up robot control applications. The methodology relies on a pipeline described in the figure below:

development cycles

The figures show in a very simple and abstract way the development cycles of a robocop application.

  • First step consist in developping with robocop is to provide a description of the robotic system. This system description should be decomposed as logically as possible, starting from the application package, that agregates all needed descriptions : robots ; environmental sensors ; objects in the environment. The description is performed using URDF and YAML models and tested using simulators.

  • Second step consists in selecting adequate drivers for the robot(s) described. The drivers should refer either the entire robot description or only a subpart of it. If the description refers to a really new system for which no driver is available, then you have to write a driver for it. If your system become too complex you may also want to create a driver that simply agregate other drivers to provide a more simple interface for the application developper. Same logic apply for controller and related utilities. If the controller you need or want for controlling the robot(s) is not available you have to write a new controller or maybe you just have to create new tasks and constraints for an existing controller.

  • Once you get all these elements you can start developping your application, by:

    • interfacing controller(s) in use with robot(s) driver(s)
    • defining tasks and constraints that will apply in your scenario.
    • control the (de)activation of tasks and constraints depending on the application execution context (for instance using a kind of state machine).

Once application has been tested and bugs or possible improvements have been found, development cycle start a nex iteration: descriptions used may need to be fixed or adapted, then drivers, controllers or other utilities may also need adaptation or fixes, etc.