Merge pull request #11 from hamishwillee/hgw_fix_broken_fact_system_l…

…ink_and_other_minor_tidy

Fix broken fact system link

en/SUMMARY.md

@@ -8,7 +8,7 @@
   * [Multi-Device Design Pattern](ui_design/multi_device_pattern.md)
   * [Font and Colour Palette](ui_design/font_palette.md)
   * [UI Controls](ui_design/controls.md)
-* [Fact System](FactSystem.md)
+* [Fact System](fact_system.md)
 * [Top Level Views](views/README.md)
   * [Settings View](views/settings.md)
   * [Setup View](views/setup.md)

en/classes/README.md

@@ -4,15 +4,15 @@
 
 A "Link" in QGC is a specific type of communication pipe with the vehicle such as a serial port or UDP over WiFi. The base class for all links is LinkInterface. Each link runs on it's own thread and sends bytes to MAVLinkProtocol.
 
-The LinkManager object keeps track of all open links in the system. LinkManager also manages automatic connections through serial and udp links.
+The `LinkManager` object keeps track of all open links in the system. `LinkManager` also manages automatic connections through serial and UDP links.
 
 ## MAVLinkProtocol
 
-There is a single MAVLinkProtocol object in the system. It's job is to take incoming bytes from a link and translate them into mavlink messages. Mavlink HEARTBEAT messages are routed to MultiVehicleManager. All mavlink messages are routed to Vehicle's which are associated with the link.
+There is a single `MAVLinkProtocol` object in the system. It's job is to take incoming bytes from a link and translate them into MAVLink messages. MAVLink HEARTBEAT messages are routed to ``MultiVehicleManager``. All MAVLink messages are routed to Vehicle's which are associated with the link.
 
 ## MultiVehicleManager
 
-There is a single MultiVehicleManager object within the system. When it receives a HEARTBEAT on a link which has not been previsouly seen it creates a Vehicle object. MultiVehicleManager also keeps tracks of all Vehicles in the system and handles switching from one active vehicle to another and correctly handling a vehicle being removed.
+There is a single `MultiVehicleManager` object within the system. When it receives a HEARTBEAT on a link which has not been previously seen it creates a Vehicle object. ``MultiVehicleManager` also keeps tracks of all Vehicles in the system and handles switching from one active vehicle to another and correctly handling a vehicle being removed.
 
 ## Vehicle
 
@@ -22,8 +22,8 @@ Note: There is also a UAS object associated with each Vehicle which is a depreca
 
 ## FirmwarePlugin, FirmwarePluginManager
 
-The FirmwarePlugin class is used an the base class for firmware plugins. A firmware plugin contains the firmware specific code, such that the Vehicle object is clean with respect to it supporting a single standard interface to the ui.
+The FirmwarePlugin class is used an the base class for firmware plugins. A firmware plugin contains the firmware specific code, such that the Vehicle object is clean with respect to it supporting a single standard interface to the UI.
 
 FirmwarePluginManager is a factory class which creates a FirmwarePlugin instance based on the MAV_AUTOPILOT/MAV_TYPE combination for the Vehicle.
 
-Note: AutoPilotPlugin and AutoPilotPluginManager are deprecated class which also contains firmware specific code. All functionality in these are being moved to the newer FirmwarePlugin and FirmwarePluginManager implementations. No new code should be added here.
+> **Note** AutoPilotPlugin and AutoPilotPluginManager are deprecated class which also contains firmware specific code. All functionality in these are being moved to the newer FirmwarePlugin and FirmwarePluginManager implementations. No new code should be added here.

en/communication_flow.md

@@ -4,11 +4,11 @@ Description of the high level communication flow which takes place during a vehi
 
 * LinkManager always has a UDP link open waiting for a Vehicle heartbeat
 * LinkManager detects a new known device (Pixhawk, SiK Radio, PX4 Flow) connected to computer
-	* Creates a new SerialLink connected to the device
+    * Creates a new SerialLink connected to the device
 * Bytes comes through Link and are sent to MAVLinkProtocol
 * MAVLinkProtocol converts the bytes into a MAVLink message
-* If the message is a ```HEARTBEAT``` the MultiVehicleManager is notified
-* MultiVehicleManager is notifed of the ```HEARTBEAT``` and creates a new Vehicle object based on the information in the ```HEARTBEAT``` message
+* If the message is a `HEARTBEAT` the MultiVehicleManager is notified
+* MultiVehicleManager is notifed of the ```HEARTBEAT``` and creates a new Vehicle object based on the information in the `HEARTBEAT` message
 * The Vehicle instantiates the plugins which match the vehicle type
 * The ParameterLoader associated with the vehicle sends a ```PARAM_REQUEST_LIST``` to the vehicle to load params using the parameter protocol
 * Once parameter load is complete, the MissionManager associated with the Vehicle requests the mission items from the Vehicle using the mission item protocol

en/fact_system.md

@@ -8,10 +8,10 @@ A Fact represents a single value within the system.
 
 ## FactMetaData
 
-There is FactMetaData associated with each fact. It provides details on the Fact in order to drive automatic user interface generation and validation.
+There is `FactMetaData` associated with each fact. It provides details on the Fact in order to drive automatic user interface generation and validation.
 
 ## Fact Controls
 
-A Fact Control is a Qml user interface control which connects to a Fact and it's FactMetaData to provide a control to the user to modify/display the value associated with the Fact.
+A Fact Control is a QML user interface control which connects to a Fact and it's `FactMetaData` to provide a control to the user to modify/display the value associated with the Fact.
 
 ## FactGroup

en/file_formats/README.md

@@ -1,3 +1,3 @@
 # File Formats
 
-This section contains topics about the file formats used/supported by QGroundControl.
+This section contains topics about the file formats used/supported by *QGroundControl*.

en/file_formats/mission.md

@@ -6,7 +6,7 @@ Note: All values unless otherwise specified are in meters.
     "firmwareType": 3,
     "groundStation": "QGroundControl",
     "items": [ 
-    	... 
+        ... 
     ],
     "plannedHomePosition": [
         47.633033699999999,
@@ -21,11 +21,11 @@ Above you can see the top level format of a mission file. Mission files are stor
 
 The following values are required:
 
-* ```firmwareType ``` The firmware type that this mission was created for using the ```MAV_AUTOPILOT_*``` MAVLink enum values. This allows you to distinguish between a mission which was created for PX4 or ArduPilot firmware. This can be important since each firmware handles mission command slightly differently.
-* ```groundStation``` The name of the ground station which created this file.
-* ```items``` The list of mission item objects associated with this mission. The format of these is described below.
-* ```plannedHomePosition``` The planned home position to show on the map when you are editing this mission. Values with array are latitude, longitude and altitude.
-* ```version``` The version for this file. Current version is 2.
+* `firmwareType` The firmware type that this mission was created for using the `MAV_AUTOPILOT_*` MAVLink enum values. This allows you to distinguish between a mission which was created for PX4 or ArduPilot firmware. This can be important since each firmware handles mission command slightly differently.
+* `groundStation` The name of the ground station which created this file.
+* `items` The list of mission item objects associated with this mission. The format of these is described below.
+* `plannedHomePosition` The planned home position to show on the map when you are editing this mission. Values with array are latitude, longitude and altitude.
+* `version` The version for this file. Current version is 2.
 
 ## Mission Items
 The ```items`` values contains an array of mission item objects. 
@@ -36,9 +36,9 @@ The ```items`` values contains an array of mission item objects.
     ...
 },
 ```
-The ```type``` value within a mission item specifies the type of the item. There are two types of mission items: ```SimpleItem``` and ```ComplexItem```.
+The `type` value within a mission item specifies the type of the item. There are two types of mission items: `SimpleItem` and `ComplexItem`.
 
-## Mission Item - ```SimpleItem```
+## Mission Item - `SimpleItem`
 A simple item represents a single MAVLink [MISSION_ITEM](http://mavlink.org/messages/common#MISSION_ITEM). It contains all the values needed to store a [MISSION_ITEM](http://mavlink.org/messages/common#MISSION_ITEM).
 
 ```
@@ -61,7 +61,7 @@ A simple item represents a single MAVLink [MISSION_ITEM](http://mavlink.org/mess
 },
 ```
 
-The values in a ```SimpleItem``` map directly to the values in [MISSION_ITEM](http://mavlink.org/messages/common#MISSION_ITEM):
+The values in a `SimpleItem` map directly to the values in [MISSION_ITEM](http://mavlink.org/messages/common#MISSION_ITEM):
 
 * ```autoContinue``` MISSION_ITEM.autoContinue
 * ```command``` MISSION_ITEM.command
@@ -92,12 +92,12 @@ First you must assign an identifier to the mission item you want to jump to:
 
 ```
 {
-	...
-	"doJumpId": 100
+    ...
+    "doJumpId": 100
 }
 ```
 
-The ```doJumpId``` can be any value greater than 0 and must uniquely identify a DO_JUMP target.
+The `doJumpId` can be any value greater than 0 and must uniquely identify a DO_JUMP target.
 
 Then in the actual DO_JUMP mission item you reference this unique id in the MISSION_ITEM.param1 value:
 

en/file_formats/parameters.md

@@ -12,14 +12,14 @@
 
 Above is an example of a parameter file with four parameters. The file can include as many parameters as needed.
 
-Comments are preceded with a ```#```.
+Comments are preceded with a `#`.
 
-This header: ```# MAV ID  COMPONENT ID  PARAM NAME  VALUE``` describes the format for each row:
+This header: `# MAV ID  COMPONENT ID  PARAM NAME  VALUE` describes the format for each row:
 
-* ```Vehicle-Id``` Vehicle id
-* ```Component-Id``` Component id for parameter
-* ```Name`` Parameter name
-* ```Value``` Parameter value
-* ```Type``` Parameter type using MAVLink ```MAV_PARAM_TYPE_*``` enum values
+* `Vehicle-Id` Vehicle id
+* `Component-Id` Component id for parameter
+* `Name` Parameter name
+* `Value` Parameter value
+* `Type` Parameter type using MAVLink `MAV_PARAM_TYPE_*` enum values
 
 A parameter file contains the parameters for a single Vehicle. It can contain parameters for multiple components within that Vehicle.

en/file_formats/survey.md

@@ -1,7 +1,8 @@
 # Complex Item - Survey
+
 A survey creates a flight path over a polygonal area in a mission.
 
-Note: All values unless otherwise specified are in meters.
+> **Note** All values unless otherwise specified are in meters.
 
 ```
 {
@@ -50,18 +51,20 @@ Note: All values unless otherwise specified are in meters.
 
 A Survey is represented as a JSON object which is stored within the ```items``` array. It stores all the meta data associated with a Survey. It does not store the individual waypoints within the Survey. Those are generated when the mission is loaded by QGroundControl. The following values are supported:
 
-* ```camera``` Object which specifies the values associated with the camera being used for the survey. Only required if ```manualGrid``` is ```false```.
-* ```cameraTrigger``` Specifies whether the camera should be triggered at the specified ```cameraTriggerDistance``` intervals.
-* ```complexItemType``` Identifies this complex missin item as a ```survey```.
-* ```fixedValueIsAltitude``` Specifies whether Altitude should be kept constant when modifying other values from the Survey user interface. Only used by the QGroundControl ui.
-* ```grid ``` Object which specifies the values associated with the survey grid.
-* ```manualGrid``` ```true```: Grid values were specified manually by the user, ```false```: Grid values are based on camera settings specified by the ```camera``` object.
-* ```polygon``` The polygon array which represents the polygonal survey area. Each point is a latitude, longitude pair for a polygon vertex.
-* ```type``` Specifies that this item is a ```ComplexItem```.
-* ```version``` Version number for the Survey Complex Mission Item format. Current version is 3.
+* `camera` Object which specifies the values associated with the camera being used for the survey. Only required if `manualGrid` is `false`.
+* `cameraTrigger` Specifies whether the camera should be triggered at the specified `cameraTriggerDistance` intervals.
+* `complexItemType` Identifies this complex mission item as a `survey`.
+* `fixedValueIsAltitude` Specifies whether Altitude should be kept constant when modifying other values from the Survey user interface. Only used by the QGroundControl UI.
+* `grid` Object which specifies the values associated with the survey grid.
+* `manualGrid` `true`: Grid values were specified manually by the user, `false`: Grid values are based on camera settings specified by the `camera` object.
+* `polygon` The polygon array which represents the polygonal survey area. Each point is a latitude, longitude pair for a polygon vertex.
+* `type` Specifies that this item is a `ComplexItem`.
+* `version` Version number for the Survey Complex Mission Item format. Current version is 3.
+
 
 ## Grid Object
-The ```grid``` object specifies the values associated with the survey grid.
+
+The `grid` object specifies the values associated with the survey grid.
 
 ```
 "grid": {
@@ -73,14 +76,16 @@ The ```grid``` object specifies the values associated with the survey grid.
 },
 ```
 
-* ```altitude``` The altitude for all transect waypoints within the grid.
-* ```angle``` The angle in degrees for the transect paths.
-* ```relativeAltitude``` ```true```: ```altitude``` is relative to home, ```false```: ```altitude``` is AMSL
-* ```spacing``` The spacing in between each transect.
-* ```turnAroundDistance``` The distance to fly past the polygon edge prior to turning for the next transect.
+* `altitude` The altitude for all transect waypoints within the grid.
+* `angle` The angle in degrees for the transect paths.
+* `relativeAltitude` `true`: `altitude` is relative to home, `false`: `altitude` is AMSL
+* `spacing` The spacing in between each transect.
+* `turnAroundDistance` The distance to fly past the polygon edge prior to turning for the next transect.
+
 
 ## Camera Object
-The ```camera``` object specifies the values associated with the camera being used for the survey. This object is only required if ```manualGrid``` is ```false```.
+
+The `camera` object specifies the values associated with the camera being used for the survey. This object is only required if `manualGrid` is `false`.
 
 ```
 "camera": {
@@ -97,11 +102,11 @@ The ```camera``` object specifies the values associated with the camera being us
 },
 ```
 
-* ```focalLength``` Focal length of camera lens in millimeters.
-* ```groundResolution``` Target ground resolution in cm/px.
-* ```imageFrontalOverlap``` Percentage of frontal image overlap.
-* ```imageSideOverlap``` Percentage of side image overlap.
-* ```name``` Name of camera being used. Should correspond to one of the cameras known to QGroundControl. Use ```"Custom Camera Grid"``` for custom camera specifications,
-* ```orientationLandscape``` ```true```: Camera installed in landscape orientation on vehicle, ```false```: Camera installed in portrait orientation on vehicle
-* ```resolutionHeight```, ```resolutionWidth``` Image pixel resolution.
-* ```sensorHeight```, ```sensorWidth``` Sensor dimensions in millimeters.
+* `focalLength` Focal length of camera lens in millimeters.
+* `groundResolution` Target ground resolution in cm/px.
+* `imageFrontalOverlap` Percentage of frontal image overlap.
+* `imageSideOverlap` Percentage of side image overlap.
+* `name` Name of camera being used. Should correspond to one of the cameras known to QGroundControl. Use `"Custom Camera Grid"` for custom camera specifications,
+* `orientationLandscape` `true`: Camera installed in landscape orientation on vehicle, `false`: Camera installed in portrait orientation on vehicle
+* `resolutionHeight`, `resolutionWidth` Image pixel resolution.
+* `sensorHeight`, `sensorWidth` Sensor dimensions in millimeters.

en/firmware_plugin.md

@@ -1,10 +1,10 @@
 # Firmware Plugins
 
-Although the MAVLink spec defines a standard communication protocol to communicate with a vehicle. There are many aspects of that spec that at up for interpretation by the firmware developers. Because of this there are many cases where communication with a vehicle running one firmware must be slightly different to communication with a vehicle running a different firmware in order to accomplich the same task. Also each firmware may implement a subset of the MAVLink command set.
+Although the MAVLink spec defines a standard communication protocol to communicate with a vehicle. There are many aspects of that spec that at up for interpretation by the firmware developers. Because of this there are many cases where communication with a vehicle running one firmware must be slightly different to communication with a vehicle running a different firmware in order to accomplish the same task. Also each firmware may implement a subset of the MAVLink command set.
 
-Another major issue is that the MAVLink spec does not cover vehicle configuration or a common parameter set. Due to this all code which relates to vehicle config ends up beind firmware specific. Also any code which must refer to a specific parameter is also firmware specific.
+Another major issue is that the MAVLink spec does not cover vehicle configuration or a common parameter set. Due to this all code which relates to vehicle config ends up being firmware specific. Also any code which must refer to a specific parameter is also firmware specific.
 
-Given all of these differences between firmware implemenations it can be quite tricky to create a single ground station application that can support each without having the codebase degrade into a massive pile of if/then/else statements peppered everywhere based on the firmware the vehicle is using.
+Given all of these differences between firmware implementations it can be quite tricky to create a single ground station application that can support each without having the codebase degrade into a massive pile of if/then/else statements peppered everywhere based on the firmware the vehicle is using.
 
 QGC uses a plugin architecture to isolate the firmware specific code from the code which is generic to all firmwares.
 

en/ui_design/README.md

@@ -1,10 +1,10 @@
 # User Interface Design
 
-The main pattern for UI design in QGC is a UI page written in Qml, many times communicated with a custom "Controller" written in C++. This follows a somewhat hacked variant of the MVC design pattern. 
+The main pattern for UI design in QGC is a UI page written in QML, many times communicated with a custom "Controller" written in C++. This follows a somewhat hacked variant of the MVC design pattern. 
 
-The Qml code binds to information associated with the system through the following mechanisms:
+The QML code binds to information associated with the system through the following mechanisms:
 * The custom controller
-* The global QGroundControl object which provides access to things like the active Vehicle
+* The global ``QGroundControl`` object which provides access to things like the active Vehicle
 * The FactSystem which provides access to parameters and in some cases custom Facts.
 
-Note: Due to the complexity of the Qml used in QGC as well as it's reliance on communication with C++ objects to drive the ui it is not possible to use the Qml Designer provided by Qt to edit Qml.
+Note: Due to the complexity of the QML used in QGC as well as it's reliance on communication with C++ objects to drive the ui it is not possible to use the QML Designer provided by Qt to edit QML.