Article directory
1 basic structure of mavlink XML file
The following code block is the xml data document defined by the mavlink message
<?xml version="1.0"?> <mavlink> <version>3</version> <dialect>0</dialect> <enums> <enum name="aaaa"> </enum> <enum name="bbbb"> </enum> </enums> <messages> <message id='1' name="somename"> </message> <message id="2" name="anothername"> </message> </messages> </mavlink>
xml structure can be divided into version information block, enums data definition block and messages message definition block. The version information block is as follows
<version>3</version> <dialect>0</dialect>
Enums enumeration data definition block is the content of < enums > < enums > tag, which includes a lot of data defined by < enums > < enums > tag.
The messages definition block is the content of the < messages > < messages > tag, which includes a lot of data defined by < message > < message >.
The specific structure of < enum > < enum > and < message > < message > is as follows: mavschema.xsd Defined in. Here we focus on the analysis of common.xml, skipping mavschema.xsd will not affect our understanding of common.xml.
Next, we analyze the structure of < enum > < enum > and < message > < message > respectively. Because < message > < message > contains the content in < enum > < enum >, here we first analyze < message > < message >.
2 message
Here we take the message named SYS_STATUS for analysis
<message id="1" name="SYS_STATUS"> <description>The general system state. If the system is following the MAVLink standard, the system state is mainly defined by three orthogonal states/modes: The system mode, which is either LOCKED (motors shut down and locked), MANUAL (system under RC control), GUIDED (system with autonomous position control, position setpoint controlled manually) or AUTO (system guided by path/waypoint planner). The NAV_MODE defined the current flight state: LIFTOFF (often an open-loop maneuver), LANDING, WAYPOINTS or VECTOR. This represents the internal navigation state machine. The system status shows whether the system is currently active or not and if an emergency occurred. During the CRITICAL and EMERGENCY states the MAV is still considered to be active, but should start emergency procedures autonomously. After a failure occurred it should first move from active to critical to allow manual intervention and then move to emergency after a certain timeout.</description> <field type="uint32_t" name="onboard_control_sensors_present" enum="MAV_SYS_STATUS_SENSOR" display="bitmask" print_format="0x%04x">Bitmap showing which onboard controllers and sensors are present. Value of 0: not present. Value of 1: present.</field> <field type="uint32_t" name="onboard_control_sensors_enabled" enum="MAV_SYS_STATUS_SENSOR" display="bitmask" print_format="0x%04x">Bitmap showing which onboard controllers and sensors are enabled: Value of 0: not enabled. Value of 1: enabled.</field> <field type="uint32_t" name="onboard_control_sensors_health" enum="MAV_SYS_STATUS_SENSOR" display="bitmask" print_format="0x%04x">Bitmap showing which onboard controllers and sensors have an error (or are operational). Value of 0: error. Value of 1: healthy.</field> <field type="uint16_t" name="load" units="d%">Maximum usage in percent of the mainloop time. Values: [0-1000] - should always be below 1000</field> <field type="uint16_t" name="voltage_battery" units="mV">Battery voltage, UINT16_MAX: Voltage not sent by autopilot</field> <field type="int16_t" name="current_battery" units="cA">Battery current, -1: Current not sent by autopilot</field> <field type="int8_t" name="battery_remaining" units="%">Battery energy remaining, -1: Battery remaining energy not sent by autopilot</field> <field type="uint16_t" name="drop_rate_comm" units="c%">Communication drop rate, (UART, I2C, SPI, CAN), dropped packets on all links (packets that were corrupted on reception on the MAV)</field> <field type="uint16_t" name="errors_comm">Communication errors (UART, I2C, SPI, CAN), dropped packets on all links (packets that were corrupted on reception on the MAV)</field> <field type="uint16_t" name="errors_count1">Autopilot-specific errors</field> <field type="uint16_t" name="errors_count2">Autopilot-specific errors</field> <field type="uint16_t" name="errors_count3">Autopilot-specific errors</field> <field type="uint16_t" name="errors_count4">Autopilot-specific errors</field> </message>
It can be seen that the structure of message is relatively simple, mainly composed of < description > section and < field >. < description > is the description of the message, < field > is the specific description of each field of the data contained in the message, including the data type (type), data name (name) of the field, and the description of the field data (text embedded in the < field > < field > label). You can see that there are enum, display, print_format, units and other attributes in < field >. The content of the enum attribute is the enumeration data type defined by the < enum > < enum > label above. For example, the name referenced in the onboard control sensors present is the MAV sys status sensor enumeration data type. Display defines the field to display to users, and print ﹣ format specifies the print format. This message is actually the specific structure of the data in the transmission. Each field defined in the message must exist in the data, and the size is consistent with the data type specified by its type field.
3 enum
Next, we will analyze the enum node, which is illustrated by the example of MAV sys status sensor mentioned in the previous section.
<enum name="MAV_SYS_STATUS_SENSOR"> <description>These encode the sensors whose status is sent as part of the SYS_STATUS message.</description> <entry value="1" name="MAV_SYS_STATUS_SENSOR_3D_GYRO"> <description>0x01 3D gyro</description> </entry> <entry value="2" name="MAV_SYS_STATUS_SENSOR_3D_ACCEL"> <description>0x02 3D accelerometer</description> </entry> <entry value="4" name="MAV_SYS_STATUS_SENSOR_3D_MAG"> <description>0x04 3D magnetometer</description> </entry> <entry value="8" name="MAV_SYS_STATUS_SENSOR_ABSOLUTE_PRESSURE"> <description>0x08 absolute pressure</description> </entry> <entry value="16" name="MAV_SYS_STATUS_SENSOR_DIFFERENTIAL_PRESSURE"> <description>0x10 differential pressure</description> </entry> <entry value="32" name="MAV_SYS_STATUS_SENSOR_GPS"> <description>0x20 GPS</description> </entry> <entry value="64" name="MAV_SYS_STATUS_SENSOR_OPTICAL_FLOW"> <description>0x40 optical flow</description> </entry> <entry value="128" name="MAV_SYS_STATUS_SENSOR_VISION_POSITION"> <description>0x80 computer vision position</description> </entry> <entry value="256" name="MAV_SYS_STATUS_SENSOR_LASER_POSITION"> <description>0x100 laser based position</description> </entry> <entry value="512" name="MAV_SYS_STATUS_SENSOR_EXTERNAL_GROUND_TRUTH"> <description>0x200 external ground truth (Vicon or Leica)</description> </entry> <entry value="1024" name="MAV_SYS_STATUS_SENSOR_ANGULAR_RATE_CONTROL"> <description>0x400 3D angular rate control</description> </entry> <entry value="2048" name="MAV_SYS_STATUS_SENSOR_ATTITUDE_STABILIZATION"> <description>0x800 attitude stabilization</description> </entry> <entry value="4096" name="MAV_SYS_STATUS_SENSOR_YAW_POSITION"> <description>0x1000 yaw position</description> </entry> <entry value="8192" name="MAV_SYS_STATUS_SENSOR_Z_ALTITUDE_CONTROL"> <description>0x2000 z/altitude control</description> </entry> <entry value="16384" name="MAV_SYS_STATUS_SENSOR_XY_POSITION_CONTROL"> <description>0x4000 x/y position control</description> </entry> <entry value="32768" name="MAV_SYS_STATUS_SENSOR_MOTOR_OUTPUTS"> <description>0x8000 motor outputs / control</description> </entry> <entry value="65536" name="MAV_SYS_STATUS_SENSOR_RC_RECEIVER"> <description>0x10000 rc receiver</description> </entry> <entry value="131072" name="MAV_SYS_STATUS_SENSOR_3D_GYRO2"> <description>0x20000 2nd 3D gyro</description> </entry> <entry value="262144" name="MAV_SYS_STATUS_SENSOR_3D_ACCEL2"> <description>0x40000 2nd 3D accelerometer</description> </entry> <entry value="524288" name="MAV_SYS_STATUS_SENSOR_3D_MAG2"> <description>0x80000 2nd 3D magnetometer</description> </entry> <entry value="1048576" name="MAV_SYS_STATUS_GEOFENCE"> <description>0x100000 geofence</description> </entry> <entry value="2097152" name="MAV_SYS_STATUS_AHRS"> <description>0x200000 AHRS subsystem health</description> </entry> <entry value="4194304" name="MAV_SYS_STATUS_TERRAIN"> <description>0x400000 Terrain subsystem health</description> </entry> <entry value="8388608" name="MAV_SYS_STATUS_REVERSE_MOTOR"> <description>0x800000 Motors are reversed</description> </entry> <entry value="16777216" name="MAV_SYS_STATUS_LOGGING"> <description>0x1000000 Logging</description> </entry> <entry value="33554432" name="MAV_SYS_STATUS_SENSOR_BATTERY"> <description>0x2000000 Battery</description> </entry> <entry value="67108864" name="MAV_SYS_STATUS_SENSOR_PROXIMITY"> <description>0x4000000 Proximity</description> </entry> <entry value="134217728" name="MAV_SYS_STATUS_SENSOR_SATCOM"> <description>0x8000000 Satellite Communication </description> </entry> <entry value="268435456" name="MAV_SYS_STATUS_PREARM_CHECK"> <description>0x10000000 pre-arm check status. Always healthy when armed</description> </entry> <entry value="536870912" name="MAV_SYS_STATUS_OBSTACLE_AVOIDANCE"> <description>0x20000000 Avoidance/collision prevention</description> </entry> </enum>
It can be seen that each < enum > < enum > includes many < entry > < entry >, each < entry > < entry > can be regarded as a value of enumeration, the value attribute corresponds to the specific size of the value, and the name can be regarded as the alias of the value.
It can be seen that enum type is just ordinary data type data, so why define these data types separately. One reason is that each value has a definite meaning. Suppose that two systems communicate with each other. Although the same protocol is used, if the agreement on the value is different, one represents four rotors here, and one represents fixed wing there. Obviously, there is no match. Another reason is that the agreement should be self consistent, and try to include the content of the agreement in the agreement document, so as to avoid ambiguity and ambiguity. Therefore, the agreement on the meaning of numerical value is also an important part of the agreement, which can be listed separately to make the structure of the agreement clearer.
