Node development

Every component of the simulator should be a separate node. The nodes have to publish a HEARTBEAT message according to Heartbeat/Connection Protocol. There are additional simulator-specific values defined for type field, in the MARSH_TYPE enum, which occupy a currently unused region of the standard MAV_TYPE (and one day might clash). Correctly assigning types for each node makes it easier to identify them in the manager, and troubleshoot problems in simulation.

Component ids can be allocated any value other than zero. Historically the component id was also used to determine the component type, for example MAV_COMP_ID_CAMERA6. With that in mind, the default component id is still determined from the type to reduce the risk of collisions, according to this formula:

component_id = MAV_COMP_ID_USER1 + (marsh_type - MARSH_TYPE_MANAGER)

This assigns consecutive definitions starting with MAV_COMP_ID_USER1, and is used throughout the authors' code.

Warning

Even though we have used the types to define our component IDs, your code must not make any assumption about the type from the id used (type is determined from HEARTBEAT.type, as stated in the MAVLink documentaton

If someone were to make a mistake and use MARSH_TYPE directly as component id, they would show up as CAMERA to CAMERA6

Example repository

There are multiple examples of ready-made nodes and utility functions in the marsh-sim/sim-nodes repository.

The names of scripts should hint at the type of component from MARSH_TYPE. These are at the end of the name, and the beginning something unique, to make running a given script easier from terminal with Tab-completion.

Message choice

For communicating any node-specific feature the workflow is as follows:

  1. Check if there is already a relevant convention for a feature in Microservices section of Dev Guide
  2. Read documentation for the service: e.g. Parameter Protocol
  3. Read documentation for specific messages: e.g. SIM_STATE (#108)