You can get started working with MIRO using just the simulator, no physical robot at all. The simulator can support multiple robots, so that you may never need a physical robot for some types of project. Alternatively, you can develop control software for a physical MIRO to run either off-board or on-board (or, for more advanced use, some combination of the two). These use cases we refer to as "profiles". Each profile has advantages and disadvantages which, largely, are common to all work in robotics.

In the end, your choice of profile will be based on the nature of the work you intend to do. You may, in practice, move between these profiles as your work proceeds.


Simulation is a straightforward way to get started. Broadly, simulation has the advantage that the robots are free; not only to create, but to repair (real robots can wear out or, more likely, become damaged whilst their control software is still imperfect). The primary downside of simulation is that simulators can never exactly represent the real world; collision dynamics, including friction interactions, are typically rather coarsely approximated, to give one key example.


On-board development has the key advantage that there is no reliance on the network once the software is installed and running. This can be particularly helpful for experiments with multiple robots and/or in the field. Moreover, on-board software has access to the platform at lower latency and with higher bandwidth. On the downside, the speed of the development cycle is limited by the network and/or the power of the on-board processor to run the compiler, and monitoring of internals may be more limited unless significant time is invested in configuring debug infrastructure.


Off-board development is a touch trickier to set up (there's that network to configure...) but, once operational, gives great flexibility (the software runs on your workstation), offers very rapid deployment (compile/link/execute can be effectively instantaneous using some development systems), extensible compute power, and great access to internals through your every-day workstation. Running control software off-board on your workstation means all data must be exchanged with the robot over the wireless network, however, and bandwidth and quality of service on that network can be limiting factors. The interface exposed is based on the ROS (Robot Operating System) service discovery and message exchange layer that is very popular in robotics R&D.


The different ways of working with MIRO