Toby Schneider edited this page May 26, 2016 · 4 revisions

MCCI: Distribution Schemas

A "Distribution Schema" describes the data that will be shared over the MCCI network.



The single greatest reason for a distribution schema is to save bandwidth and processing time. Rather than using variable-length strings, fixed-length integer IDs are sent in messages and converted to their string equivalents when needed for logging or debugging.

Rather than compute variable names into integers on a per-host basis, we ensure the same name-to-ID mapping on all vehicles by specifying it in advance and placing that exact schema on all vehicles. (It is reasonable to assume that the set of data names understood by a system of vehicles can be agreed upon before deployment.)


The current trend in robotics development is increased collaboration -- separate components being designed by separate groups and later integrated to form a single system. An important part of this process is to ensure that all relevant interfaces are producing appropriately-named data, and in the proper units (recall the Mars Climate Orbiter crash).

MCCI cannot (necessarily) validate that the proper units are being sent in messages from the clients. However, reporting proper units in debugging tools provides developers with a "first line of defense" against false assumptions.


The data distribution is implemented as an SQLite database with the following tables:

Variable (implemented as 'var' due to reserved words)
var_id unsigned integer
name string
enabled boolean
category_id unsigned integer category.category_id
protobuf (identifier) Pointer to protobuf definition
unit (identifier) OPTIONAL Pointer to UnitsML (or equivalent) definition of units

The Variable table is the only part of the distribution schema that is used by the MCCI server. Only the first 3 fields are used in server operation ("enable" being used to allow elements of a master schema to be turned on and off as desired). Protobuf and unit need not be present in a MCCI schema, although they may be of inestimable value to other system components.

category_id unsigned integer
name string
parent_category_id unsigned integer category.category_id
unsigned integer category.category_id
(identifier) Pointer to protobuf definition
(identifier) OPTIONAL Pointer to UnitsML (or equivalent) definition of units

The Category table is used to provide a hierarchy of organization for a given variable (such as Sensors->External->Ocean->CTD->Salinity, Sensors->Internal->Navigation->Velocity->DVL->DVL_X). This would be used by various debugging tools to help visually organize the data.

tag_id unsigned integer
name string
Variable_Tag (implemented as var_tag for consistency)
var_id unsigned_integer var.var_id
tag_id unsigned integer tag.tag_id

The Tag and Variable_Tag tables can also be used by debugging tools to name arbitrary collections of variables. For example, all inputs and outputs in a chain of navigation-related processes.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.