Test migration to vitepress (#551)

* Add package/.vitepress folders - more work to be done

* Fix up config and add site/favicons

* Update styles for wide tables

* Rename English files from README.md to index.md

* Add root home page

* Update .gitignore for vitepress

* Delete unused: travis, book, redirects

* Fix up all Notes

* Warnings and notes - convert to github format

* Add running workflow

* Add yarn lock file

* Fix up links README.md to index.md

* Add lock files

.github/workflows/docs_deploy.yml

@@ -1,6 +1,16 @@
 name: Docs
 
 on:
+  push:
+    branches:
+      - master
+    tags:
+      - 'v*'
+    paths:
+      - './**'
+  pull_request:
+    paths:
+      - './**'
 
   workflow_dispatch:
 

.gitignore

@@ -7,13 +7,12 @@
 ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git
 node_modules
 
-# Book build output
-_book
-
-# eBook build output
-*.epub
-*.mobi
-*.pdf
 
 # Temp files
-*.bak
+*.bak
+
+
+# vitepress - user guide
+node_modules/
+.vitepress/cache/
+.vitepress/dist/

.travis.yml

@@ -1,28 +0,0 @@
-language: ruby
-rvm:
-- 2.2.2
-
-addons:
-  apt:
-    packages:
-    - libcurl4-openssl-dev # required to avoid SSL errors
-
-install:
-- npm install gitbook-cli -g
-- gitbook install
-- gitbook build
-- gem install html-proofer
-
-script: 
-
-- htmlproofer ./_book --empty-alt-ignore true --check-external-hash true --url-ignore 'https://utm.arc.nasa.gov/,https://groups.google.com/forum/#!forum/uavcan'
-
-
-env:
-  global:
-  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true   # speeds up installation of html-proofer
-
-## Allow links to fail any time and be displayed as warnings.
-matrix:
-  allow_failures:
-    - rvm: 2.2.2

.vitepress/config.mjs

@@ -0,0 +1,178 @@
+import { defineConfig } from "vitepress";
+const getSidebar = require("./get_sidebar.js");
+
+// Tabs: https://github.com/Red-Asuka/vitepress-plugin-tabs
+import tabsPlugin from "@red-asuka/vitepress-plugin-tabs";
+
+// https://vitepress.dev/reference/site-config
+export default defineConfig({
+  title: "MAVLink Guide",
+  description: "MAVLink Developer Guide",
+  base: process.env.BRANCH_NAME ? "/" + process.env.BRANCH_NAME + "/" : "",
+
+  srcExclude: [
+    "de/**/*.md",
+    "ja/**/*.md",
+    "ru/**/*.md",
+    "tr/**/*.md",
+    //"ko/**/*.md",
+    //"zh/**/*.md",
+    "uk/**/*.md",
+    "**/_*.md", //Remove source docs that start with "_" (included/not rendered)
+  ],
+  ignoreDeadLinks: true,
+  markdown: {
+    math: true,
+    config: (md) => {
+      // use more markdown-it plugins!
+      tabsPlugin(md); //https://github.com/Red-Asuka/vitepress-plugin-tabs
+    },
+  },
+  locales: {
+    en: {
+      label: "English",
+      // other locale specific properties...
+      themeConfig: {
+        sidebar: getSidebar.sidebar("en"),
+
+        editLink: {
+          pattern: ({ filePath, frontmatter }) => {
+            if (frontmatter.newEditLink) {
+              //newEditLink defines a frontmatter key you can use to append a path to main
+              return `https://github.com/mavlink/mavlink-devguide/edit/master/${frontmatter.newEditLink}`;
+            } else {
+              return `https://github.com/mavlink/mavlink-devguide/edit/master/${filePath}`;
+            }
+          },
+          text: "Edit on GitHub",
+        },
+      },
+    },
+
+    zh: {
+      label: "中文 (Chinese)",
+      lang: "zh-CN", // optional, will be added  as `lang` attribute on `html` tag
+      themeConfig: {
+        sidebar: getSidebar.sidebar("zh"),
+      },
+      // other locale specific properties...
+    },
+    ko: {
+      label: "한국어 (Korean)",
+      lang: "ko-KR", // optional, will be added  as `lang` attribute on `html` tag
+      themeConfig: {
+        sidebar: getSidebar.sidebar("ko"),
+      },
+
+      // other locale specific properties...
+    },
+  },
+  //Logs every page loaded on build. Good way to catch errors not caught by other things.
+  async transformPageData(pageData, { siteConfig }) {
+    console.log(pageData.filePath);
+  },
+
+  //
+
+  themeConfig: {
+    // https://vitepress.dev/reference/default-theme-config
+    siteTitle: false,
+    logo: {
+      light: "/assets/site/logo_mavlink_header_lightmode.png",
+      dark: "/assets/site/logo_mavlink_header_darkmode.png",
+      alt: "",
+    },
+    sidebar: getSidebar.sidebar("en"),
+    externalLinkIcon: true,
+
+    editLink: {
+      pattern: "https://crowdin.com/project/mavlink",
+      text: "Edit translation on Crowdin",
+    },
+
+    search: {
+      provider: "local",
+    },
+
+    nav: [
+      {
+        text: "Messages",
+        link: "/en/messages/common.md",
+      },
+      {
+        text: "FAQ",
+        link: "/en/about/faq.md",
+      },
+      {
+        text: "Implementations",
+        items: [
+          {
+            text: "ArduPilot",
+            link: "http://ardupilot.org/",
+          },
+          {
+            text: "PX4",
+            link: "http://px4.io/",
+          },
+          {
+            text: "Other",
+            link: "/en/about/implementations.md",
+          },
+        ],
+      },
+      {
+        text: "Languages",
+        items: [
+          {
+            text: "C (mavgen)",
+            link: "/en/mavgen_c/",
+          },
+          {
+            text: "Python (Pymavlink)",
+            link: "/en/mavgen_python/",
+          },
+          {
+            text: "Other",
+            link: "/en/#supported_languages",
+          },
+        ],
+      },
+
+      {
+        text: "Support",
+        link: "/en/about/support.md",
+      },
+    ],
+
+    socialLinks: [
+      { icon: "github", link: "https://github.com/mavlink/mavlink" },
+    ],
+  },
+
+  head: [
+    ["link", { rel: "icon", href: "/en/favicon.ico" }],
+    [
+      "script",
+      {
+        async: "",
+        src: "https://www.googletagmanager.com/gtag/js?id=G-91EWVWRQ93",
+      },
+    ],
+    [
+      "script",
+      {},
+      `window.dataLayer = window.dataLayer || [];
+      function gtag(){dataLayer.push(arguments);}
+      gtag('js', new Date());
+      gtag('config', 'G-91EWVWRQ93');`,
+    ],
+  ],
+
+  vue: {
+    template: {
+      compilerOptions: {
+        isCustomElement: (tag) => tag === "lite-youtube",
+      },
+    },
+  },
+});

.vitepress/get_sidebar.js

@@ -0,0 +1,267 @@
+// .vuepress/get_sidebar.js
+
+import path from "path";
+import fs from "fs";
+import readline from "readline";
+
+function getEntryArray(parent) {
+  let returnEntryArray = null;
+  //console.log("getEntryArray(): parent");
+  //console.log(parent);
+  //Gets returns the child array
+  //if (parent === "undefined") {
+  //  return [];
+  //}
+
+  if (Array.isArray(parent)) {
+    //This parent is an array, so return it (it is the sidebar top level)
+    returnEntryArray = parent;
+    //console.log("isArray");
+  }
+  parent.items = parent?.items ? parent.items : [];
+  //console.log("isNotArray");
+  //console.log("returnEntryArray:");
+  returnEntryArray = parent.items;
+  //console.log(returnEntryArray);
+  return returnEntryArray;
+}
+
+function parseGitbookSidebarToVuepress(sidebarContent, lang) {
+  const lines = sidebarContent.split("\n");
+
+  const newSidebar = [];
+
+  let first_iteration = true;
+  let indent_divider = 0;
+
+  const parents = [];
+  //console.log("parents - empty after creaton");
+  //console.log(parents);
+
+  const topLevelParent = {
+    title: "DUMMY",
+    path: "DUMMY",
+    //level: "0",
+    //items: [],
+  };
+  topLevelParent.items = [];
+  //console.log("topLevelParent - empty after creaton");
+  //console.log(topLevelParent);
+
+  parents.push(topLevelParent); // So last item is always the sidebar
+  //console.log("parents after pushing topLevelParent:");
+  //console.log(parents);
+
+  let current_parent;
+
+  let lastlevel = 0;
+  let last_item;
+
+  //let currentSection;
+  //let currentLevel = 0;
+
+  lines.forEach((line) => {
+    if (line.startsWith("#") || line.trim() === "") {
+      // Ignore lines that start with "#" or are empty
+      // Note, we should perhaps create sections for these. TBD.
+      return;
+    }
+
+    //console.log("DEBUG: Line: " + line);
+
+    let regex = /(\s*?)[\*-]\s\[(.*?)\]\((.*?)\)/g;
+
+    let indent_level = "";
+    let link_title = "";
+    let link_url = "";
+    let link_path = "";
+
+    try {
+      //console.log(`DEBUG: Lastitem at start:  ${JSON.stringify(last_item)}`);
+      let match = regex.exec(line);
+      //console.log('0: '+ match[0])
+      indent_level = match[1].length;
+      link_title = match[2];
+      link_url = match[3].trim();
+      link_path = link_url;
+    } catch (err) {
+      //Just skip empty lines that don't match
+      console.log(err);
+      console.log("DEBUG: Couldn't match line, skip line using return");
+      return;
+    }
+
+    try {
+      /*
+      if (link_url.endsWith("README.md")) {
+        link_url = link_url.replace("README.md", "");
+      }
+      */
+      if (link_url.endsWith(".md")) {
+        link_url = link_url.replace(".md", ".html");
+        //link_path = link_path.replace(".md", ".html");
+      }
+
+      if (!link_url.startsWith("http")) {
+        if (lang) {
+          link_url = `/${lang}/${link_url}`;
+        } else {
+          link_url = `/${link_url}`;
+        }
+      }
+
+      //Tidy up some of the title escaping that isn't used by VuePress
+      link_title = link_title.replace("\\(", "(");
+      link_title = link_title.replace("\\)", ")");
+      link_title = link_title.replace("\\_", "_");
+
+      //set indent_divider level (easier to think in levels, numbers of zero prefixes)
+      if ((indent_divider == 0) & (indent_level > 0.0)) {
+        indent_divider = indent_level;
+      }
+      if (indent_divider > 0) {
+        indent_level = indent_level / indent_divider;
+      }
+
+      let entry = {
+        text: link_title,
+        link: link_url,
+        //collapsed: true,
+        //link_path,
+        //level: indent_level,
+        //collapsible: true,
+      };
+      //console.log("entry:");
+      //console.log(entry);
+
+      //console.log("parents:");
+      //console.log(parents);
+      //console.log("current_parent - before pop");
+      //console.log(current_parent);
+      current_parent = parents.pop();
+      //console.log("current_parent - after pop");
+      //console.log(current_parent);
+
+      //console.log(`XX ST: indent: ${indent_level} lastlevel: ${lastlevel}`);
+      if (indent_level == lastlevel) {
+        //console.log(`XX EQ:`);
+        //console.log(current_parent);
+        const parentArray = getEntryArray(current_parent);
+        parentArray.push(entry);
+        //console.log("current_parent after pushing last entry");
+        //console.log(current_parent);
+
+        //console.log("eq parents before pushing back current parent");
+        //console.log(parents);
+        parents.push(current_parent);
+        //console.log("EQ parents after pushing current parent");
+        //console.log(parents);
+
+        //console.log("XX EQ3");
+      } else if (indent_level > lastlevel) {
+        //console.log("XX NEST");
+        //console.log(
+        //  `  DEBUG:NEST: lastlev: ${lastlevel}/indent lev: ${indent_level}`
+        // );
+        // This is a child of the last element added to current parent
+
+        //console.log(current_parent);
+        //console.log("NEST: current_parent - after pop");
+        //console.log("NEST: parents before");
+        //console.log(parents);
+
+        const parentArray = getEntryArray(current_parent);
+
+        //console.log(
+        //  "parentArray - we want to add entry to last entry in this array."
+        //);
+        //console.log(parentArray);
+
+        //Get the last element
+        //console.log(`how many elements in array ${parentArray.length}`);
+        //
+        const lastElement = parentArray.pop();
+        lastElement.collapsed = true;
+        //console.log(`NEST: last element in array:`);
+        //console.log(lastElement);
+        const lastElementArray = getEntryArray(lastElement);
+        //console.log(`NEST: last element array:`);
+        lastElementArray.push(entry);
+        //console.log(`NEST: last element after pushing event:`);
+        //console.log(lastElement);
+        // Push the last element back on to the parentArray
+        parentArray.push(lastElement);
+        //push current parent onto the parents array
+        parents.push(current_parent);
+        // push the element we just edited back onto the array so it can be current parent.
+        parents.push(lastElement);
+        //console.log("NEST: parents after");
+        //console.log(parents);
+      } else if (indent_level < lastlevel) {
+        // gone up a level
+        //console.log(`XX UP`);
+        while (indent_level < lastlevel--) {
+          //console.log(`pop ${lastlevel}`);
+          //Here we have no item. Group has finished (with a group)
+          //So add the current parent (finished) to its parent.
+          //console.log('DEBUG: Gone UP from level: '+ indent_level + ' TO: ' + lastlevel)
+
+          current_parent = parents.pop();
+        }
+        const parentArray = getEntryArray(current_parent);
+        parentArray.push(entry);
+        //console.log("current_parent after pushing last entry");
+        //console.log(current_parent);
+
+        //console.log("eq parents before pushing back current parent");
+        //console.log(parents);
+        parents.push(current_parent);
+      }
+
+      //console.log("AFTER ADDING Entry:");
+      //console.log("entry:");
+      //console.log(entry);
+      //console.log("parents:");
+      //console.log(parents);
+    } catch (err) {
+      console.log(err);
+      console.log(` DEBUG SOME ACTUAL PROBLEMXX2: ${err}`);
+    }
+
+    //last_item = entry;
+
+    lastlevel = indent_level; //reset
+    //console.log(`END OF ONE LINE:${indent_level} lastlevel: ${lastlevel}`);
+    //console.log("PARENTS");
+    //console.log(JSON.stringify(parents));
+  });
+
+  //all lines done
+  //console.log("All lines done parents:");
+  //console.log(JSON.stringify(parents));
+
+  //console.log("topLevelParent");
+  //console.log(topLevelParent);
+  return topLevelParent.items;
+}
+
+module.exports = {
+  sidebar: function (lang) {
+    const summaryfile_path = path.resolve(__dirname, "..", lang, "SUMMARY.md");
+    //console.log("DEBUG: summaryfile_path: " + summaryfile_path);
+    let data = "";
+
+    try {
+      // read contents of the file
+      data = fs.readFileSync(summaryfile_path, "UTF-8");
+    } catch (err) {
+      console.log(`DEBUG: ${lang} - SIDEBAR  DEFINITION NOT FOUND`);
+    }
+
+    const module_sidebar = parseGitbookSidebarToVuepress(data, lang);
+    //console.log(`DEBUG: Before`);
+    //console.log(`DEBUG: ${JSON.stringify(module_sidebar)}`);
+    //console.log(`DEBUG: After`);
+    return module_sidebar;
+  },
+};

.vitepress/theme/components/Redirect.vue

@@ -0,0 +1,19 @@
+<template>
+</template>
+
+
+<script>
+    /** Redirects to the given 'to' url, which is relative to the current location. Originates from https://github.com/vuejs/vuepress/issues/239#issuecomment-632567115 */
+    export default {
+        name: 'Redirect',
+        props: {
+            to: {
+                type: String,
+                required: true
+            }
+        },
+        beforeMount() {
+            document.location.replace(this.to);
+        }
+    }
+</script>

.vitepress/theme/index.js

@@ -0,0 +1,58 @@
+// https://vitepress.dev/guide/custom-theme
+import { h } from "vue";
+
+import DefaultTheme from "vitepress/theme";
+import "./style.css";
+
+// To support medium-zoom - like setup()
+import { onMounted, watch, nextTick } from "vue";
+import { useRoute } from "vitepress";
+import mediumZoom from "medium-zoom";
+
+// For https://www.npmjs.com/package/lite-youtube-embed
+import { inBrowser } from "vitepress";
+import "lite-youtube-embed/src/lite-yt-embed.css";
+if (inBrowser) {
+  // @ts-ignore
+  import("lite-youtube-embed");
+}
+
+// Support redirect plugin
+import Redirect from "./components/Redirect.vue";
+
+// Tabs: https://github.com/Red-Asuka/vitepress-plugin-tabs
+import { Tab, Tabs } from "vue3-tabs-component";
+import "@red-asuka/vitepress-plugin-tabs/dist/style.css";
+
+/** @type {import('vitepress').Theme} */
+export default {
+  extends: DefaultTheme,
+  Layout: () => {
+    return h(DefaultTheme.Layout, null, {
+      // https://vitepress.dev/guide/extending-default-theme#layout-slots
+    });
+  },
+  enhanceApp({ app, router, siteData }) {
+    app.component("Redirect", Redirect); //Redirect plugin
+    //Tabs: https://github.com/Red-Asuka/vitepress-plugin-tabs
+    app.component("Tab", Tab);
+    app.component("Tabs", Tabs);
+  },
+
+  // to support medium zoom: https://github.com/vuejs/vitepress/issues/854
+  setup() {
+    const route = useRoute();
+    const initZoom = () => {
+      //mediumZoom("[data-zoomable]", { background: "var(--vp-c-bg)" });
+      mediumZoom(".main img", { background: "var(--vp-c-bg)" });
+    };
+    onMounted(() => {
+      initZoom();
+    });
+    watch(
+      () => route.path,
+      () => nextTick(() => initZoom())
+    );
+  },
+  //end to support medium zoom
+};

.vitepress/theme/style.css

@@ -0,0 +1,202 @@
+/**
+ * Customize default theme styling by overriding CSS variables:
+ * https://github.com/vuejs/vitepress/blob/main/src/client/theme-default/styles/vars.css
+ */
+
+/**
+ * Colors
+ *
+ * Each colors have exact same color scale system with 3 levels of solid
+ * colors with different brightness, and 1 soft color.
+ *
+ * - `XXX-1`: The most solid color used mainly for colored text. It must
+ *   satisfy the contrast ratio against when used on top of `XXX-soft`.
+ *
+ * - `XXX-2`: The color used mainly for hover state of the button.
+ *
+ * - `XXX-3`: The color for solid background, such as bg color of the button.
+ *   It must satisfy the contrast ratio with pure white (#ffffff) text on
+ *   top of it.
+ *
+ * - `XXX-soft`: The color used for subtle background such as custom container
+ *   or badges. It must satisfy the contrast ratio when putting `XXX-1` colors
+ *   on top of it.
+ *
+ *   The soft color must be semi transparent alpha channel. This is crucial
+ *   because it allows adding multiple "soft" colors on top of each other
+ *   to create a accent, such as when having inline code block inside
+ *   custom containers.
+ *
+ * - `default`: The color used purely for subtle indication without any
+ *   special meanings attched to it such as bg color for menu hover state.
+ *
+ * - `brand`: Used for primary brand colors, such as link text, button with
+ *   brand theme, etc.
+ *
+ * - `tip`: Used to indicate useful information. The default theme uses the
+ *   brand color for this by default.
+ *
+ * - `warning`: Used to indicate warning to the users. Used in custom
+ *   container, badges, etc.
+ *
+ * - `danger`: Used to show error, or dangerous message to the users. Used
+ *   in custom container, badges, etc.
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-c-default-1: var(--vp-c-gray-1);
+  --vp-c-default-2: var(--vp-c-gray-2);
+  --vp-c-default-3: var(--vp-c-gray-3);
+  --vp-c-default-soft: var(--vp-c-gray-soft);
+
+  --vp-c-brand-1: var(--vp-c-indigo-1);
+  --vp-c-brand-2: var(--vp-c-indigo-2);
+  --vp-c-brand-3: var(--vp-c-indigo-3);
+  --vp-c-brand-soft: var(--vp-c-indigo-soft);
+
+  --vp-c-tip-1: var(--vp-c-brand-1);
+  --vp-c-tip-2: var(--vp-c-brand-2);
+  --vp-c-tip-3: var(--vp-c-brand-3);
+  --vp-c-tip-soft: var(--vp-c-brand-soft);
+
+  --vp-c-warning-1: var(--vp-c-yellow-1);
+  --vp-c-warning-2: var(--vp-c-yellow-2);
+  --vp-c-warning-3: var(--vp-c-yellow-3);
+  --vp-c-warning-soft: var(--vp-c-yellow-soft);
+
+  --vp-c-danger-1: var(--vp-c-red-1);
+  --vp-c-danger-2: var(--vp-c-red-2);
+  --vp-c-danger-3: var(--vp-c-red-3);
+  --vp-c-danger-soft: var(--vp-c-red-soft);
+}
+
+/**
+ * Component: Button
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-button-brand-border: transparent;
+  --vp-button-brand-text: var(--vp-c-white);
+  --vp-button-brand-bg: var(--vp-c-brand-3);
+  --vp-button-brand-hover-border: transparent;
+  --vp-button-brand-hover-text: var(--vp-c-white);
+  --vp-button-brand-hover-bg: var(--vp-c-brand-2);
+  --vp-button-brand-active-border: transparent;
+  --vp-button-brand-active-text: var(--vp-c-white);
+  --vp-button-brand-active-bg: var(--vp-c-brand-1);
+}
+
+/**
+ * Component: Home
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-home-hero-name-color: transparent;
+  --vp-home-hero-name-background: -webkit-linear-gradient(
+    120deg,
+    #bd34fe 30%,
+    #41d1ff
+  );
+
+  --vp-home-hero-image-background-image: linear-gradient(
+    -45deg,
+    #bd34fe 50%,
+    #47caff 50%
+  );
+  --vp-home-hero-image-filter: blur(44px);
+}
+
+@media (min-width: 640px) {
+  :root {
+    --vp-home-hero-image-filter: blur(56px);
+  }
+}
+
+@media (min-width: 960px) {
+  :root {
+    --vp-home-hero-image-filter: blur(68px);
+  }
+}
+
+/**
+ * Component: Custom Block
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-custom-block-tip-border: transparent;
+  --vp-custom-block-tip-text: var(--vp-c-text-1);
+  --vp-custom-block-tip-bg: var(--vp-c-brand-soft);
+  --vp-custom-block-tip-code-bg: var(--vp-c-brand-soft);
+}
+
+/**
+ * Component: Algolia
+ * -------------------------------------------------------------------------- */
+
+.DocSearch {
+  --docsearch-primary-color: var(--vp-c-brand-1) !important;
+}
+
+/**
+ * Component: Medium Zoom: https://github.com/vuejs/vitepress/issues/854
+ * -------------------------------------------------------------------------- */
+
+.medium-zoom-overlay {
+  z-index: 20;
+}
+
+.medium-zoom-image {
+  z-index: 21;
+}
+
+/**
+ * Override styles as needed
+ * -------------------------------------------------------------------------- */
+
+.vp-doc img {
+  display: inline; /* block by default set by vitepress */
+}
+
+/* Make content area a little wider to improve tables */
+.content-container {
+  max-width: 100% !important;
+}
+@media (min-width: 1280px) {
+  .content {
+    min-width: 940px !important;
+  }
+}
+
+/* Make page width larger  */
+@media (min-width: 1440px) {
+  .VPSidebar {
+    padding-left: 32px !important;
+    width: var(--vp-sidebar-width) !important;
+  }
+  .VPContent.has-sidebar {
+    padding-left: var(--vp-sidebar-width) !important;
+    padding-right: 0 !important;
+  }
+
+  .VPNavBar.has-sidebar .title {
+    padding-left: 32px !important;
+  }
+
+  .VPNavBar.has-sidebar .content {
+    padding-left: var(--vp-sidebar-width) !important;
+    padding-right: 32px !important;
+  }
+}
+
+/* Make content area a little wider to improve tables
+- Disabled version, that is OK but not quite as good as one above */
+/*
+.content-container {
+  max-width: 100% !important;
+}
+@media (min-width: 1280px) {
+  .content {
+    min-width: 940px !important;
+  }
+}
+*/

book.json

@@ -1,123 +0,0 @@
-{
-    "gitbook": ">= 3.2.2",
-    "title": "MAVLink Developer Guide",
-    "variables": {
-        "logo": "./assets/site/logo_mavlink_small.png"
-    },
-    "plugins": [
-        "theme-api",
-        "youtube",
-        "anchors",
-        "collapsible-menu",
-        "page-toc-button",
-        "language-picker",
-        "custom-favicon",
-        "richquotes@git+https://github.com/Dronecode/gitbook-plugin-richquotes.git",
-        "bulk-redirect@git+https://github.com/Dronecode/gitbook-plugin-bulk-redirect.git",
-        "toolbar@git+https://github.com/hamishwillee/gitbook-plugin-toolbar.git",
-        "-mermaid",
-        "theme-dronecode@git+https://github.com/dronecode/theme-dronecode.git",
-        "html-minifier"
-    ],
-    "pluginsConfig": {
-        "theme-api": {
-            "languages": [
-                {
-                    "lang": "c",
-                    "name": "C/C++",
-                    "default": true
-                },
-                {
-                    "lang": "python",
-                    "name": "Python"
-                },
-                {
-                    "lang": "js",
-                    "name": "JavaScript"
-                },
-                {
-                    "lang": "go",
-                    "name": "Go"
-                }
-            ]
-        },
-        "theme-dronecode": {
-
-                 "menu": [
-
-                       {
-                         "url": "https://mavlink.io/en/messages/common.html",
-                         "text": "Messages",
-                         "text_small" : "Messages"
-                       },
-                       {
-                         "url": "https://mavlink.io/en/about/faq.html",
-                         "text": "FAQ",
-                         "text_small" : "FAQ"
-                       },
-                       {
-                         "url": "https://mavlink.io/en/about/implementations.html",
-                         "text": "Implementations",
-                         "text_small" : "Implementations"
-                       },
-                       {
-                         "url": "https://mavlink.io/en/mavgen_c/examples.html",
-                         "text": "Examples",
-                         "text_small" : "Examples"
-                       },
-                       {
-                         "url": "https://mavlink.io/en/about/support.html",
-                         "text": "Support",
-                         "text_small" : "Help"
-                       }
-                 ],
-                 
-                 "logo": {
-                     "logo_large": "../assets/site/logo_mavlink_header.png",
-                     "logo_small": "../assets/site/logo_mavlink_header.png",
-                     "url": "https://mavlink.io/en/"
-                 }
-
-             },
-        "richquotes":
-        {
-            "tip": {
-                "alert": "success",
-                "picto": "fa-thumbs-o-up"
-            }
-
-        },
-        "toolbar": {
-            "buttons":
-            [
-                {
-                    "label": "Bug tracker",
-                    "icon": "fa fa-bug",
-                    "position" : "left",
-                    "url": "https://github.com/mavlink/mavlink-devguide/issues/new?title=Doc+Bug:+{{title}}&body=DESCRIBE+PROBLEM+WITH+DOCS+HERE%0A%0ABug+Page:+[{{title}}]({{url}})"
-                    
-                },
-                {
-                    "label": "GitHub",
-                    "icon": "fa fa-github",
-                    "url": "https://github.com/mavlink/mavlink-devguide"
-                },
-                {
-                    "label": "Edit page on github",
-                    "icon": "fa fa-pencil-square-o",
-                    "position" : "left",
-                    "url": "https://github.com/mavlink/mavlink-devguide/edit/master/{{filepath_lang}}"
-                }
-            ]
-        },
-        "favicon": "favicon.ico",
-        "bulk-redirect": {
-            "basepath": "/",
-            "redirectsFile": "redirects.json"
-        },
-        "html-minifier": {
-          "removeEmptyElements": false
-        }
-        
-    }
-}

en/SUMMARY.md

@@ -1,25 +1,25 @@
 # Summary
 
-* [Introduction](README.md)
+* [Introduction](index.md)
   * [Overview](about/overview.md)
   * [FAQ](about/faq.md)
   * [Implementations](about/implementations.md)
-* [Getting Started](getting_started/README.md)
+* [Getting Started](getting_started/index.md)
   * [Install MAVLink](getting_started/installation.md)
   * [Generate MAVLink Libraries](getting_started/generate_libraries.md)
   * [Generate Source Files for ROS](getting_started/ros.md)
 * [Using MAVLink Libraries](getting_started/use_libraries.md)
-  * [C (mavgen)](mavgen_c/README.md)
+  * [C (mavgen)](mavgen_c/index.md)
     * [Message Signing](mavgen_c/message_signing_c.md)
     * [Examples](mavgen_c/examples.md)
       * [UART Interface (C)](mavgen_c/example_c_uart.md)
       * [UDP Example (C)](mavgen_c/example_c_udp.md)
-  * [Pymavlink (Python-mavgen)](mavgen_python/README.md)
+  * [Pymavlink (Python-mavgen)](mavgen_python/index.md)
     * [How to Request Messages/Set Message Rates](mavgen_python/howto_requestmessages.md)
     * [Message Signing](mavgen_python/message_signing.md)
     * [Examples](mavgen_python/examples.md)
 
-* [Guide](guide/README.md)
+* [Guide](guide/index.md)
   * [MAVLink Versions](guide/mavlink_version.md)
   * [MAVLink 2](guide/mavlink_2.md)
   * [Message Signing](guide/message_signing.md)
@@ -28,14 +28,14 @@
   * [Redundancy/Message De-duplication](guide/redundancy_deduplication.md)
   * [Packet Loss Calculation](guide/packet_loss.md)
   * [General Telemetry](guide/general_telemetry.md)
-  * [File Formats](file_formats/README.md)
+  * [File Formats](file_formats/index.md)
   * [UAVCAN Interaction](guide/uavcan_interaction.md)
   * [Scripts](guide/scripts.md)
   * [MAVLink XML Schema](guide/xml_schema.md)
   * [Defining XML Enums/Messages](guide/define_xml_element.md)
   * [MAVLink CRC](guide/crc.md)
   * [Debugging with Wireshark](guide/wireshark.md)
-  * [Dialects](messages/README.md)
+  * [Dialects](messages/index.md)
     * [ASLUAV.xml](messages/ASLUAV.md)
     * [all.xml](messages/all.md)
     * [ardupilotmega.xml](messages/ardupilotmega.md)
@@ -50,7 +50,7 @@
     * [uAvionix.xml](messages/uAvionix.md)
     * [ualberta.xml](messages/ualberta.md)
 * [Messages (common)](messages/common.md)
-* [Microservices](services/README.md)
+* [Microservices](services/index.md)
   * [Heartbeat/Connection Protocol](services/heartbeat.md)
   * [Mission Protocol](services/mission.md)
   * [Parameter Protocol](services/parameter.md)

en/about/faq.md

@@ -31,7 +31,7 @@
   <ul>
     <li>The underlying over-the-wire format is rarely updated (we're only up to <em>MAVLink 2</em>, which was introduced in 2017).
     </li>
-    <li>New <a href="../messages/common.md">messages</a>/<a href="../services/README.md">microservices</a> are frequently added. This is a backwards compatible change, and users are expected to regularly update their libraries to support new messages.</li>
+    <li>New <a href="../messages/common.md">messages</a>/<a href="../services/index.md">microservices</a> are frequently added. This is a backwards compatible change, and users are expected to regularly update their libraries to support new messages.</li>
     <li>Messages are rarely modified (or removed) such that they would become incompatible. If this is needed the project will update the MAVLink minor version number and notify users through the <a href="https://groups.google.com/forum/#!forum/mavlink">mailing list</a> (users can also query the version in code).</li>
   </ul>
   </dd>
@@ -42,7 +42,7 @@
 
 <dl>
   <dt>Can I use MAVLink in a closed source application without copyright issues?</dt>
-  <dd>Yes, without any limitations. The generated MAVLink library headers are made available under the *MIT license* (for more information see: <a href="../README.md#license">Introduction > License</a>).
+  <dd>Yes, without any limitations. The generated MAVLink library headers are made available under the *MIT license* (for more information see: <a href="../index.md#license">Introduction > License</a>).
   </dd>
 
   <dt>How does MAVLink detect and decode messages in the byte stream?</dt>
@@ -67,7 +67,7 @@
 
   <dt>I would like to help improve the decoding/encoding routines or other features. Can MAVLink be changed?</dt>
   <dd>Yes, but only very, very carefully with safety testing. 
-  <br>MAVLink is used as a safety-critical component in many autopilot systems and has undergone many years of testing. Please suggest new features on the MAVLink <a href="../README.md#support">support channels</a>.</dd>
+  <br>MAVLink is used as a safety-critical component in many autopilot systems and has undergone many years of testing. Please suggest new features on the MAVLink <a href="../index.md#support">support channels</a>.</dd>
 
   <dt>How can I further reduce the generated C library size?</dt>
   <dd>On extremely resource-constrained systems you may be able to reduce the size of the generated library by setting <code>MAVLINK_COMM_NUM_BUFFERS=1</code> and <code>MAVLINK_MAX_PAYLOAD_LEN</code>="size of your largest buffer" (assuming only one comm link and that your payload is less than the maximum supported by MAVLink).

en/about/implementations.md

@@ -30,7 +30,7 @@ The following autopilots are known to support MAVLink and are actively being dev
 ## MAVLink Wrapper/Developer APIs
 
 A number of higher level APIs have been written to simplify interacting with MAVLink autopilots, cameras, ground stations, etc. (MAVLink is a relatively low-level API).
-These wrappers typically provide implementations of the main [microservices](../services/README.md) and simple/specific interfaces for sending commands and accessing vehicle information.
+These wrappers typically provide implementations of the main [microservices](../services/index.md) and simple/specific interfaces for sending commands and accessing vehicle information.
 
 The list here contains actively maintained implementations:
 

en/about/overview.md

@@ -28,7 +28,8 @@ uint16_t checksum;          ///< CRC-16/MCRF4XX
 uint8_t signature[13];      ///< Signature which allows ensuring that the link is tamper-proof (optional)
 ```
 
-> **Note** The [MAVLink 1 packet format](../guide/serialization.md#v1_packet_format) is similar, but omits `incompat_flags`, `compat_flags` and `signature`, and only has a single byte for the message address.
+> [!NOTE]
+> The [MAVLink 1 packet format](../guide/serialization.md#v1_packet_format) is similar, but omits `incompat_flags`, `compat_flags` and `signature`, and only has a single byte for the message address.
 > For more information see [Serialization > Packet Format](../guide/serialization.md#packet_format).
 
 ## Serialization

en/about/support.md

@@ -14,7 +14,8 @@ If directed by the development team, issues may be raised on [Github here](https
 
 MAVLink developers, adopting companies and the surrounding community of users meet regularly to help define the direction of the project, discuss RFCs, Issues and have a Q&A session.
 
-> **Tip** The call is open to anyone who wants to contribute to the ongoing development of the project (not just the dev team).
+> [!TIP]
+> The call is open to anyone who wants to contribute to the ongoing development of the project (not just the dev team).
 > This is a great opportunity to meet the team.
 
 #### Who should attend: {#who-should-attend}

en/contributing/contributing.md

@@ -61,7 +61,8 @@ Primarily this means that the team developing the generator must provide suffici
    git checkout -b mydescriptivebranchname
    ```
 
-   > **Note** _Always_ branch off master for new features.
+   > [!NOTE]
+   > _Always_ branch off master for new features.
 
 3. Commit your changes with a descriptive commit message.
 

en/file_formats/index.md

@@ -5,7 +5,8 @@ Often the information is defined on one system and used on another (e.g. logs fr
 
 There is a _defacto_ standard used in many GCS systems and developer APIs for storing _mission_ information: [plain-text file format](#mission_plain_text_file).
 
-> **Note** At time of writing there are no MAVLink standards (defacto or otherwise) for: geofence, rally points, parameters etc.
+> [!NOTE]
+> At time of writing there are no MAVLink standards (defacto or otherwise) for: geofence, rally points, parameters etc.
 > There is a discussion about standardising file formats in [Issue #989](https://github.com/mavlink/mavlink/issues/989).
 
 ## Mission Plain-Text File Format {#mission_plain_text_file}
@@ -21,7 +22,8 @@ QGC WPL <VERSION>
 <INDEX> <CURRENT WP> <COORD FRAME> <COMMAND> <PARAM1> <PARAM2> <PARAM3> <PARAM4> <PARAM5/X/LATITUDE> <PARAM6/Y/LONGITUDE> <PARAM7/Z/ALTITUDE> <AUTOCONTINUE>
 ```
 
-> **Note** The spaces between the numbers/fields above are `<tab>` (i.e. `\t` in most programming languages).
+> [!NOTE]
+> The spaces between the numbers/fields above are `<tab>` (i.e. `\t` in most programming languages).
 
 For example:
 

en/getting_started/generate_libraries.md

@@ -1,31 +1,34 @@
 # Generating MAVLink Libraries
 
-Language-specific MAVLink libraries can be created from [XML Message Definitions](../messages/README.md) using _code generator_ tools.
+Language-specific MAVLink libraries can be created from [XML Message Definitions](../messages/index.md) using _code generator_ tools.
 
 This page shows how to use the following two code generators provided with the MAVLink project:
 
 - GUI tool: [mavgenerate](#mavgenerate)
 - Command line tool: [mavgen](#mavgen), which is the backend tool used also by mavgenerate
 
-> **Note** These generators can build MAVLink 2 and MAVLink 1 libraries for the following programming languages: C, C++11, Python, Typescript, Java, and WLua. The following programming languages are supported for MAVLink 1 libraries only: C#, JavaScript, ObjC, Swift.
+> [!NOTE]
+> These generators can build MAVLink 2 and MAVLink 1 libraries for the following programming languages: C, C++11, Python, Typescript, Java, and WLua. The following programming languages are supported for MAVLink 1 libraries only: C#, JavaScript, ObjC, Swift.
 
-<span></span>
-
-> **Tip** Generators for other programming languages are supported and documented in independent projects.
-> For more information see [Supported Languages](../README.md#supported_languages).
+> [!TIP]
+> Generators for other programming languages are supported and documented in independent projects.
+> For more information see [Supported Languages](../index.md#supported_languages).
 
 ## Pre-requisites
 
-1. You must already have [Installed the MAVLink toolchain](../getting_started/installation.md), which includes the mavgenerate and mavgen tools used below as well as the [XML Message Definitions](../messages/README.md).
-1. If you are generating messages for a [custom dialect](../messages/README.md#dialects), copy the dialect [XML definition file(s)](../messages/README.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
-   > **Note** _mavgen_ can handle dialects that have relative paths for included XML files (e.g typically [common.xml](../messages/common.md)), but other generators may not.
+1. You must already have [Installed the MAVLink toolchain](../getting_started/installation.md), which includes the mavgenerate and mavgen tools used below as well as the [XML Message Definitions](../messages/index.md).
+1. If you are generating messages for a [custom dialect](../messages/index.md#dialects), copy the dialect [XML definition file(s)](../messages/index.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
+
+   > [!NOTE]
+   > _mavgen_ can handle dialects that have relative paths for included XML files (e.g typically [common.xml](../messages/common.md)), but other generators may not.
    > We recommend putting custom dialects in the same folder as the ones that come with the [mavlink/mavlink](https://github.com/mavlink/mavlink) repository.
 
 ## Building MAVLink libraries using the Mavgenerate GUI {#mavgenerate}
 
 **mavgenerate.py** is GUI code generator for MAVLink, written in Python.
 
-> **Note** _Mavgenerate_ provides a GUI front end to the [mavgen](#mavgen) command line code generator, and supports the same [options](#mavgen_options).
+> [!NOTE]
+> _Mavgenerate_ provides a GUI front end to the [mavgen](#mavgen) command line code generator, and supports the same [options](#mavgen_options).
 
 The GUI can be launched from anywhere using Python's `-m` argument:
 
@@ -39,7 +42,8 @@ Steps for generating the MAVLink library code:
 
 1. Choose the target XML file (typically in [mavlink/message_definitions/1.0](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0)).
 
-   > **Note** If using a custom dialect, first copy it into the above directory (if the dialect is dependent on **common.xml** it must be located in the same directory).
+   > [!NOTE]
+   > If using a custom dialect, first copy it into the above directory (if the dialect is dependent on **common.xml** it must be located in the same directory).
 
 1. Choose an output directory (e.g. **mavlink/include**).
 1. Select the target output programming language.
@@ -54,7 +58,7 @@ Steps for generating the MAVLink library code:
 
 1. Select the target MAVLink protocol version. Ideally use 2.0 if the generator supports it.
 
-   > **Caution** Generation will fail if the protocol is not [supported](../README.md#supported_languages) by the selected programming language.
+   > **Caution** Generation will fail if the protocol is not [supported](../index.md#supported_languages) by the selected programming language.
 
 1. Optionally check _Validate_ and/or _Validate Units_, which validates XML specifications.
 
@@ -65,7 +69,9 @@ Steps for generating the MAVLink library code:
 **mavgen.py** is a command line tool for generating MAVLink libraries for various programming languages.
 You can run mavgen from the `mavlink` directory. However, if you are outside of the mavlink directory, you need to add the `mavlink` directory to the `PYTHONPATH` environment variable.
 
-> **Tip** Mavgen is the backend used by [mavgenerate](#mavgenerate). The documentation below explains all the options for both tools.
+> [!TIP]
+> Mavgen is the backend used by [mavgenerate](#mavgenerate).
+> The documentation below explains all the options for both tools.
 
 Below is an example for how to generate _MAVLink 2_ libraries for the C programming language using a dialect named **your_custom_dialect.xml**:
 
@@ -73,7 +79,8 @@ Below is an example for how to generate _MAVLink 2_ libraries for the C programm
 python3 -m pymavlink.tools.mavgen --lang=C --wire-protocol=2.0 --output=generated/include/mavlink/v2.0 message_definitions/v1.0/your_custom_dialect.xml
 ```
 
-> **Note** The syntax for for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
+> [!NOTE]
+> The syntax for for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
 
   <!-- https://github.com/ArduPilot/pymavlink/issues/203 -->
 

en/getting_started/index.md

@@ -1,14 +1,14 @@
 # Getting Started
 
-Download or Generate MAVLink source files for your [dialect](../messages/README.md#dialects):
+Download or Generate MAVLink source files for your [dialect](../messages/index.md#dialects):
 
-- **Download the [pre-built MAVLink source files](../README.md#prebuilt_libraries)** if you're working in a C/C++ project and using standard dialects.
-- **Generate the MAVLink source files** to use any other [supported language](../README.md#supported_languages), add/modify messages or dialects, or use the example scripts:
+- **Download the [pre-built MAVLink source files](../index.md#prebuilt_libraries)** if you're working in a C/C++ project and using standard dialects.
+- **Generate the MAVLink source files** to use any other [supported language](../index.md#supported_languages), add/modify messages or dialects, or use the example scripts:
   1.  [Install MAVLink](../getting_started/installation.md)
   1.  [Generate Language-Specific Source Files](../getting_started/generate_libraries.md).
 
 The following topics explain how to include the files in your project and use MAVLink:
 
 - [Use the MAVLink Source Files](../getting_started/use_libraries.md) explains how to include the source files in your project and send messages.
-- [Message Definitions](../messages/README.md) contains human-readable explanations of the messages.
-- [Microservices](../services/README.md) explains the main sub-protocols for working with missions, cameras, images, parameters etc.
+- [Message Definitions](../messages/index.md) contains human-readable explanations of the messages.
+- [Microservices](../services/index.md) explains the main sub-protocols for working with missions, cameras, images, parameters etc.

en/getting_started/installation.md

@@ -1,9 +1,10 @@
 # Installing MAVLink Toolchain
 
-This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/README.md) as well as the the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
+This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/index.md) as well as the the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
 
-> **Tip** You do not need to install or generate the source files if you are using the C programming language and a standard [dialect](../messages/README.md#dialects).
-> Just get the [prebuilt libraries](../README.md#prebuilt_libraries) and then jump to [Using C Libraries](../mavgen_c/README.md).
+> [!TIP]
+> You do not need to install or generate the source files if you are using the C programming language and a standard [dialect](../messages/index.md#dialects).
+> Just get the [prebuilt libraries](../index.md#prebuilt_libraries) and then jump to [Using C Libraries](../mavgen_c/index.md).
 
 ## Prerequisites
 

en/getting_started/ros.md

@@ -1,8 +1,8 @@
 # Generate Source Files for ROS
 
-To add MAVlink [messages/dialects](../messages/README.md) while working with ROS:
+To add MAVlink [messages/dialects](../messages/index.md) while working with ROS:
 
-1. Follow the [MAVROS source install instructions](https://github.com/mavlink/mavros/blob/master/mavros/README.md#source-installation) to install the mavlink-gbp-release which is the MAVlink library released for ROS.
+1. Follow the [MAVROS source install instructions](https://github.com/mavlink/mavros/blob/master/mavros/index.md#source-installation) to install the mavlink-gbp-release which is the MAVlink library released for ROS.
 1. Uninstall the MAVlink package for ROS if previously installed.
 
    ```sh

en/getting_started/use_libraries.md

@@ -2,13 +2,14 @@
 
 The linked documents explain how to use the MAVLink libraries for different programming languages (and from different code generators).
 
-> **Note** Not all of the libraries are documented.
+> [!NOTE]
+> Not all of the libraries are documented.
 > If you have experience with the other libraries, please help us update those sections!
 
 - Mavgen
 
-  - [C](../mavgen_c/README.md)
-  - [Python ("Pymavlink")](../mavgen_python/README.md)
+  - [C](../mavgen_c/index.md)
+  - [Python ("Pymavlink")](../mavgen_python/index.md)
   - C++11
   - C-Sharp
   - Java

en/guide/crc.md

@@ -2,12 +2,12 @@
 
 MAVLink services that need to use a Cyclic Redundancy Check (CRC) should choose the CRC32 algorithm described below.
 
-> **Note** Using the same CRC implementation for all cases means that only one implementation is required.
+> [!NOTE]
+> Using the same CRC implementation for all cases means that only one implementation is required.
 > Do not introduce another unless there without a compelling technical reason.
 
-<span></span>
-
-> **Note** This CRC is [used for higher level services](#implementations) (it is not related to the CRC16 used for the checksum in [MAVLink serialization](serialization.md#checksum)).
+> [!NOTE]
+> This CRC is [used for higher level services](#implementations) (it is not related to the CRC16 used for the checksum in [MAVLink serialization](serialization.md#checksum)).
 
 ## CRC32 Algorithm
 

en/guide/define_xml_element.md

@@ -1,14 +1,14 @@
 # How to Define MAVLink Messages & Enums
 
-MAVLink enums, messages, commands, and other elements are [defined within XML files](../messages/README.md) and then converted to libraries for [supported programming languages](../README.md#supported_languages) using a _code generator_.
+MAVLink enums, messages, commands, and other elements are [defined within XML files](../messages/index.md) and then converted to libraries for [supported programming languages](../index.md#supported_languages) using a _code generator_.
 
 This topic provides practical guidance for defining and extending MAVLink XML elements, including conventions and best-practice.
 
-> **Note** For detailed information about the file format see [MAVLink XML Schema](../guide/xml_schema.md) (you can also inspect [common.xml](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0/common.xml) and other dialect files).
+> [!NOTE]
+> For detailed information about the file format see [MAVLink XML Schema](../guide/xml_schema.md) (you can also inspect [common.xml](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0/common.xml) and other dialect files).
 
-<span></span>
-
-> **Tip** Before submitting a pull request for a change to a [dialect xml file](../messages/README.md), you should first [regenerate the dialect library](../getting_started/generate_libraries.md) _with validation enabled_, and then run the [./scripts/format_xml.sh](https://github.com/mavlink/mavlink/blob/master/scripts/format_xml.sh) script.
+> [!TIP]
+> Before submitting a pull request for a change to a [dialect xml file](../messages/index.md), you should first [regenerate the dialect library](../getting_started/generate_libraries.md) _with validation enabled_, and then run the [./scripts/format_xml.sh](https://github.com/mavlink/mavlink/blob/master/scripts/format_xml.sh) script.
 
 ## Messages vs Commands
 
@@ -44,11 +44,11 @@ The "official" project XML files are stored in the Github repo [mavlink/mavlink]
 
 MAVLink systems typically fork and maintain a copy of this repo (e.g. [ArduPilot/mavlink](https://github.com/ArduPilot/mavlink)). The downstream repo should pull **common.xml** changes (see next section) down from the main repo and push dialect-specific changes back to it.
 
-> **Tip** The official repo is forked and/or cloned into your environment when you [Install MAVLink](../getting_started/installation.md).
+> [!TIP]
+> The official repo is forked and/or cloned into your environment when you [Install MAVLink](../getting_started/installation.md).
 
-<span></span>
-
-> **Note** A project/dialect doesn't _have to_ push changes back to MAVLink.
+> [!NOTE]
+> A project/dialect doesn't _have to_ push changes back to MAVLink.
 > However this makes sense if you want to publish your messages more widely, and potentially get them moved into the **common.xml** message set.
 
 ## Where Should MAVLink Elements be Created?
@@ -57,7 +57,8 @@ The enums and messages that are generally useful for many flight stacks and grou
 The MAVLink elements supported by a particular autopilot system or protocol are referred to as _dialects_.
 The _dialects_ are stored in separate XML files, which typically `include` (import) **common.xml** and define just the elements needed for system-specific functionality.
 
-> **Note** When a MAVLink library is generated from a dialect file, code is created for all messages in both the dialect and any included files (e.g. **common.xml**), and entries for a particular enum are merged.
+> [!NOTE]
+> When a MAVLink library is generated from a dialect file, code is created for all messages in both the dialect and any included files (e.g. **common.xml**), and entries for a particular enum are merged.
 > The generator reports errors if there are name or id clashes between imported messages or enum entries.
 
 Where you define an element depends on whether it is common or a dialect, and whether the project is public or private.
@@ -112,13 +113,18 @@ To create a new dialect file:
 1. Update the `include`(s):
     - if the dialect is not based on **common.xml** remove the existing `include` line
     - Add additional `<include> </include>` elements to import additional files/dialects.
-      > **Note** Includes in nested files are ignored.
+
+      > [!NOTE]
+      > Includes in nested files are ignored.
+
 1. Update the `version`:
     - Most dialects should leave the version commented out (i.e. all dialects that include **common.xml**).
     - Dialects that are _not_ based on **common.xml** can uncomment the `<version>6</version>` line and use whatever version is desired.
 
-      > **Note** The `version` specified in the top level file is used by default, if present.
-          If it is not present in the file, then a `version` from an included file is used.
+      > [!NOTE]
+      > The `version` specified in the top level file is used by default, if present.
+      > If it is not present in the file, then a `version` from an included file is used.
+
 1. Update the `<dialect>8</dialect>` line to replace `8` with the next-largest unused dialect number (based on the other files in the folder).
 1. Optionally remove the `enums` or `messages` sections if you don't plan on declaring any elements of these types.
 1. Add enums or messages as described in the following sections.
@@ -155,7 +161,8 @@ A typical message ([SAFETY_SET_ALLOWED_AREA](../messages/common.md#SAFETY_SET_AL
 Messages must be declared between the `<messages></messages>` tags in either **common.xml** or _dialect_ files.
 Each message is defined using `<message id="" name="LIBRARY_UNIQUE_NAME"> ... </message>` tags (with unique `id` and `name` attributes).
 
-> **Tip** The only only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
+> [!TIP]
+> The only only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
 
 The main rules for messages are:
 
@@ -176,7 +183,8 @@ The main rules for messages are:
     Each field should only have **one** or no units.
   - _should_ use the `enum` attribute where possible results are finite/well understood.
 
-> **Warning** You cannot rely on generators to fully test for compliance with the above rules.
+> [!WARNING]
+> You cannot rely on generators to fully test for compliance with the above rules.
 > The _mavgen_ code generator tests for duplicate message ids, duplicate field names, messages with no fields, and messages with more than 64 fields.
 > It does not check for other issues (e.g. duplicate names, or over-size payloads).
 > Other generators may provide better validation
@@ -200,7 +208,8 @@ Allocated ranges are listed below (a more complete list is provided in the comme
 | ArduPilotMega.xml | 11000 - 11999 |
 | icarous.xml       | 42000 - 42999 |
 
-> **Tip** If you are creating a new public dialect, [create an issue](https://github.com/mavlink/mavlink/issues/new) to request your own message id range. For private dialects, you can use whatever range you like.
+> [!TIP]
+> If you are creating a new public dialect, [create an issue](https://github.com/mavlink/mavlink/issues/new) to request your own message id range. For private dialects, you can use whatever range you like.
 
 You should not create messages with ids in the "MAVLink 1" range (MAVLink v1 only has 8 bit message IDs, and hence can only support messages with ids 0 - 255).
 
@@ -212,7 +221,8 @@ Changing the name or id of a message will make it incompatible with older versio
 
 Adding or removing a field, or changing the name or type of a field, will make a message incompatible with older versions of the generated library (the generated message decoding method is hard coded with the field number, [order](../guide/serialization.md#crc_extra), type and position at build time - if these change, decoding will fail).
 
-> **Tip** [Message Extensions](#message_extensions) (see below) allow you to add new fields to a MAVLink 2 message without breaking compatibility for a receiver that has not been updated. Note that you can only add messages, not modify or delete them using this mechanism.
+> [!TIP]
+> [Message Extensions](#message_extensions) (see below) allow you to add new fields to a MAVLink 2 message without breaking compatibility for a receiver that has not been updated. Note that you can only add messages, not modify or delete them using this mechanism.
 
 If a message needs to be changed in these ways then there are several options:
 
@@ -226,7 +236,8 @@ For a message in **common.xml** either change requires the agreement of major st
 
 - Create a PR and discuss in the MAVLink developer meeting.
 
-  > **Tip** Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
+  > [!TIP]
+  > Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
 
 It is possible to change the message and field descriptions without breaking binary compatibility.
 Care should still be taken to ensure that any changes that alter the way that the field is interpreted are agreed by stakeholders, and handled with proper version control.
@@ -328,7 +339,8 @@ A typical enum ([LANDING_TARGET_TYPE](../messages/common.md#LANDING_TARGET_TYPE)
 Enums must be declared between the `<enums></enums>` tags in **common.xml** and/or _dialect_ files.
 Each enum is defined using `<enum name="SOME_NAME"> ... </enum>` tags (with a `name` attribute).
 
-> **Tip** There is no difference between enums defined in **common.xml** or _dialect_ files (other than management of the namespace).
+> [!TIP]
+> There is no difference between enums defined in **common.xml** or _dialect_ files (other than management of the namespace).
 
 The main rules for enums are:
 
@@ -344,12 +356,16 @@ The main rules for enums are:
     - By _convention_, the `name` should be prefixed with the enum name (e.g. enum `LANDING_TARGET_TYPE` has entry `LANDING_TARGET_TYPE_LIGHT_BEACON`).
   - _should_ have a `value` attribute, and if assigned this must be unique within the (merged) enum.
     Missing values will automatically be sequentially assigned (starting from 1, if the first value is not assigned).
-    > **Tip** We recommend you assign values because then new entries can be added within the range without breaking compatibility.
+
+    > [!TIP]
+    > We recommend you assign values because then new entries can be added within the range without breaking compatibility.
+
   - _should_ (very highly recommended) include a `description` element.
   - may represent bitmasks, in which case values will increase by a power of 2.
   - _may_ be marked as deprecated.
 
-> **Warning** You cannot rely on specific generators to fully test for compliance with the above rules.
+> [!WARNING]
+> You cannot rely on specific generators to fully test for compliance with the above rules.
 > _mavgen_ tests for duplicate names in enums, duplicate names for (merged) enum entries, duplicate values for enum entries.
 
 ### Modifying an Enum
@@ -370,7 +386,8 @@ If an enum needs to be changed then there are several options:
 
 For either case, all users of the enum will need to be updated with new generated libraries.
 
-> **Tip** Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
+> [!TIP]
+> Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
 
 For an enum in **common.xml** either change requires the agreement of major stakeholders
 
@@ -386,7 +403,8 @@ Enums are very rarely deleted, as this may break compatibility with legacy MAVLi
 MAVLink commands are defined as entries in the [MAV_CMD](../messages/common.md#mav_commands) enum.
 They are used to define operations used in autonomous missions (see [Mission Protocol](../services/mission.md)) or to send commands in any mode (see [Command Protocol](../services/command.md)).
 
-> **Tip** The schema for commands is documented [here](../guide/xml_schema.md#MAV_CMD).
+> [!TIP]
+> The schema for commands is documented [here](../guide/xml_schema.md#MAV_CMD).
 
 A typical mission command is ([MAV_CMD_NAV_WAYPOINT](../messages/common.md#MAV_CMD_NAV_WAYPOINT)) is shown below:
 
@@ -430,7 +448,8 @@ The allocated ranges are listed below (a more complete list is provided in the c
 | ArduPilotMega.xml | 42000 - 42999 |
 | slugs.xml         | 10001 - 11999 |
 
-> **Tip** If you are creating a new public dialect, [create an issue](https://github.com/mavlink/mavlink/issues/new) to request your own command id range. For private dialects, you can use whatever range you like.
+> [!TIP]
+> If you are creating a new public dialect, [create an issue](https://github.com/mavlink/mavlink/issues/new) to request your own command id range. For private dialects, you can use whatever range you like.
 
 There are a number of common and ArduPilot commands that are outside the ranges (e.g. 16, 200, etc.).
 Generally you would only use these these ranges in order to give a new command an id that is close to related to that of related commands.
@@ -446,7 +465,8 @@ In addition, there are some other "standard" prefixes which are used for common
 - `MAV_CMD_CONDITION_`: `CONDITION_` commands are used to define conditions before the mission state machine will move to the next item (e.g. a time after reaching a waypoint before taking a picture).
 - `MAV_CMD_REQUEST_`: For requesting information from a system.
 
-> **Tip** The rules for the above prefixes are flexible; some DO commands might reasonably be NAV commands.
+> [!TIP]
+> The rules for the above prefixes are flexible; some DO commands might reasonably be NAV commands.
 > Ins some cases a request for information might be a `MAV_CMD_REQUEST_` and in others it might be a stand alone message.
 
 ### Parameters (param) {#param}
@@ -482,7 +502,8 @@ These unused parameters can be treated as _reserved_, allowing them to be reused
 A reserved `param` **must** always be sent with a (default) value of _either_ `0` or `NaN` (which will be interpreted by recipient as "no action" or "not supported").
 If the param is reused the original default value must still mean "no action", so that an updated system can still interact with a system that has not been updated.
 
-> **Note** Unfortunately this means that a reserved `param` must have its default value decided when the command is declared!
+> [!NOTE]
+> Unfortunately this means that a reserved `param` must have its default value decided when the command is declared!
 > The default value cannot later be changed from `NaN` to `0` (or visa versa) without potential compatibility issues.
 
 To declare a `param` as `reserved` with `default` value of `NaN` you should use the following syntax.
@@ -491,7 +512,8 @@ To declare a `param` as `reserved` with `default` value of `NaN` you should use
 <param index="3" reserved="true" default="NaN" />
 ```
 
-> **Warning** Params with index values `5` and `6` should not be given a `default` of `NaN` , because if these are sent in a `COMMAND_INT` or `MISSION_INT` these parameters are integers (and hence there is no way to represent an `NaN`).
+> [!WARNING]
+> Params with index values `5` and `6` should not be given a `default` of `NaN` , because if these are sent in a `COMMAND_INT` or `MISSION_INT` these parameters are integers (and hence there is no way to represent an `NaN`).
 
 To declare a param as `reserved` with `default` value of `0` simply omit the `param` from the definition. This is the default - it is equivalent to:
 

en/guide/index.md

@@ -1,12 +1,12 @@
 # Guide
 
-This section contains guide material for understanding and using MAVLink, including the different [versions](../guide/mavlink_version.md) and [microservices](../services/README.md).
+This section contains guide material for understanding and using MAVLink, including the different [versions](../guide/mavlink_version.md) and [microservices](../services/index.md).
 
 The topics linked from the sidebar (and listed below):
 
 - [MAVLink Versions](../guide/mavlink_version.md)
 - [MAVLink 2](../guide/mavlink_2.md)
-- [Microservices](../services/README.md) (sub-protocols)
+- [Microservices](../services/index.md) (sub-protocols)
 - [Message Signing](../guide/message_signing.md)
 - [Serialization](../guide/serialization.md)
 - [Routing](../guide/routing.md)
@@ -19,4 +19,4 @@ The topics linked from the sidebar (and listed below):
 - [MAVLink XML Schema](../guide/xml_schema.md)
 - [Defining XML Enums/Messages](../guide/define_xml_element.md)
 - [MAVLink CRCs](../guide/crc.md)
-- [Dialects](../messages/README.md)
+- [Dialects](../messages/index.md)

en/guide/mavlink_2.md

@@ -1,7 +1,7 @@
 # MAVLink 2
 
 _MAVLink 2_ is a backward-compatible update to the MAVLink protocol that has been designed to bring more flexibility and security to MAVLink communication.
-_MAVLink 2_ bindings have been developed for C, C++11 and Python (see [Supported Languages](../README.md#supported_languages)).
+_MAVLink 2_ bindings have been developed for C, C++11 and Python (see [Supported Languages](../index.md#supported_languages)).
 
 This topic provides links to the main new features in MAVLink 2 and how it is used.
 
@@ -15,7 +15,8 @@ The key new features of _MAVLink 2_ are:
 - [Empty-byte payload truncation](../guide/serialization.md#payload_truncation) - Empty (zero-filled) bytes at the end of the serialized payload must be removed before sending (All bytes were sent in _MAVLink 1_, regardless of content).
 - [Compatibility Flags](../guide/serialization.md#compat_flags)/[Incompatibility Flags](../guide/serialization.md#incompat_flags) - Allow for backwards compatible evolution of the protocol by indicating frames that must be handled in a special/non-standard way (packets with compatibility flags can still be handled in the standard way, while packets with incompatibility flags must be dropped if the flage is not supported).
 
-> **Tip** The _MAVLink 2_ [design document](https://docs.google.com/document/d/1XtbD0ORNkhZ8eKrsbSIZNLyg9sFRXMXbsR2mp37KbIg/edit?usp=sharing) provides additional background information about the changes.
+> [!TIP]
+> The _MAVLink 2_ [design document](https://docs.google.com/document/d/1XtbD0ORNkhZ8eKrsbSIZNLyg9sFRXMXbsR2mp37KbIg/edit?usp=sharing) provides additional background information about the changes.
 
 ## Upgrading to MAVLink 2
 
@@ -26,4 +27,4 @@ The key new features of _MAVLink 2_ are:
 ### C Implementation
 
 The MAVLink 2 C library is backwards compatible with MAVLink 1.
-Information on how to upgrade the library and work with MAVLink 1 is covered in [Using C MAVLink Libraries (mavgen)](../mavgen_c/README.md).
+Information on how to upgrade the library and work with MAVLink 1 is covered in [Using C MAVLink Libraries (mavgen)](../mavgen_c/index.md).

en/guide/mavlink_version.md

@@ -8,7 +8,8 @@ MAVLink has been deployed in a number of versions:
 The _MAVLink 2.0_ C/C++ and Python libraries are backwards compatible with MAVLink 1.0 (support both protocols).
 [Version Handshaking](#version_handshaking) and [Negotiating Versions](#negotiating_versions) explain how to choose which version is used.
 
-> **Note** _MAVLink v0.9_ is a pre-release version that is no longer supported.
+> [!NOTE]
+> _MAVLink v0.9_ is a pre-release version that is no longer supported.
 > The associated message set deleted in August 2018.
 > Legacy code may be present in generator and test code.
 
@@ -19,16 +20,18 @@ A library's MAVLink support can be determined in a number of ways:
 - [AUTOPILOT_VERSION](../messages/common.md#AUTOPILOT_VERSION)`.capabilities` can be checked against the [MAV_PROTOCOL_CAPABILITY_MAVLINK2](../messages/common.md#MAV_PROTOCOL_CAPABILITY_MAVLINK2) flag to verify MAVLink 2 support.
 - [PROTOCOL_VERSION](../messages/common.md#PROTOCOL_VERSION).`version` contains the MAVLink version number multiplied by 100: v1.0 is 100, <!-- v2.0 is 200, --> v2.3 is 203 etc.
 - [HEARTBEAT](../messages/common.md#HEARTBEAT)`.mavlink_version` field contains the minor version number.
-  This is the `<version>` field defined in the [Message Definitions](../messages/README.md) (`version` in [common.xml](../messages/common.md) for dialects that depend on the common message set).
+  This is the `<version>` field defined in the [Message Definitions](../messages/index.md) (`version` in [common.xml](../messages/common.md) for dialects that depend on the common message set).
 - The major version can be determined from the packet start marker byte:
 
   - MAVLink 1: `0xFE`
   - MAVLink 2: `0xFD`
 
-  > **Note** A MAVLink library that does not support a protocol version will not recognise the protocol start marker;
+  > [!NOTE]
+  > A MAVLink library that does not support a protocol version will not recognise the protocol start marker;
   > so no messages will even be detected (see [Serialization](../guide/serialization.md)).
 
-> **Tip** While messages do not contain version information, an extra CRC is used to ensure that a library will only process compatible messages (see [Serialization > CRC_EXTRA](../guide/serialization.md)).
+> [!TIP]
+> While messages do not contain version information, an extra CRC is used to ensure that a library will only process compatible messages (see [Serialization > CRC_EXTRA](../guide/serialization.md)).
 
 ## Version Handshaking {#version_handshaking}
 
@@ -71,7 +74,8 @@ The supported MAVLink library implementations enable different MAVLink versions
 
 As a result, all [connections](../services/heartbeat.md) to other components over a particular channel must share the same MAVLink version. If a system is using signing, then all connections via the same channel must also be signing messages with the same key.
 
-> **Note** A system cannot use a single channel to connect to signed MAVLink 2 systems, unsigned MAVLink 2 systems, and/or MAVLink 1 components.
+> [!NOTE]
+> A system cannot use a single channel to connect to signed MAVLink 2 systems, unsigned MAVLink 2 systems, and/or MAVLink 1 components.
 
 Currently most MAVLink networks are configured to use unsigned MAVLink 2 messages.
 MAVLink 1 is primarily used to allow autopilots to connect to legacy MAVLink peripherals, and this is done via a separate channel.

en/guide/message_signing.md

@@ -8,7 +8,7 @@ It explains how a system can determine if a message is signed and whether the si
 More detailed information for developers using existing MAVLink libraries can be found here:
 
 - [C Message Signing](../mavgen_c/message_signing_c.md) (mavgen)
-- [Pymavlink Message Signing](../mavgen_python/README.md#message_signing) (mavgen)
+- [Pymavlink Message Signing](../mavgen_python/index.md#message_signing) (mavgen)
 <!-- Others?  -->
 
 ## Frame Format
@@ -18,7 +18,8 @@ The signed packet format is shown below.
 
 ![MAVLink 2 Signed](../../assets/packets/packet_mavlink_v2_signing.png)
 
-> **Note** The [incompatibility flags](../guide/mavlink_2.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
+> [!NOTE]
+> The [incompatibility flags](../guide/mavlink_2.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
 > In other words, a MAVLink library that does not support signing must drop signed packets.
 > The C library uses [MAVLINK_IFLAG_SIGNED](../guide/mavlink_2.md#MAVLINK_IFLAG_SIGNED) to represent the "supports message signing" bit.
 
@@ -43,7 +44,8 @@ The monotonically increasing [timestamp](#timestamp) rule is applied separately
 (SystemID,ComponentID,LinkID)
 ```
 
-> **Note** For more information see [C Message Signing > Handling Link IDs](../mavgen_c/message_signing_c.md#handling_link_ids).
+> [!NOTE]
+> For more information see [C Message Signing > Handling Link IDs](../mavgen_c/message_signing_c.md#handling_link_ids).
 
 ### Signature {#signature}
 
@@ -60,7 +62,8 @@ signature = sha256_48(secret_key + header + payload + CRC + link-ID + timestamp)
 
 The timestamp is a 48 bit number with units of 10 microseconds since 1st January 2015 GMT. For systems where the time since 1/1/1970 is available (the unix epoch) you can use an offset in seconds of 1420070400.
 
-> **Note** This is a loose definition, as the various update mechanisms detailed below may result in the timestamp being significantly different from actual GMT time.
+> [!NOTE]
+> This is a loose definition, as the various update mechanisms detailed below may result in the timestamp being significantly different from actual GMT time.
 
 All timestamps generated must be at least 1 more than the previous timestamp sent in the same session for the same link/`(SystemID, ComponentID, LinkID)` tuple.
 The timestamp may get ahead of GMT time if there is a burst of packets at a rate of more than 100 thousand packets per second.
@@ -74,11 +77,15 @@ Systems should implement the following rules to obtain a reliable timestamp:
 - If the system does not have an RTC mechanism then it should update its timestamp when GPS lock is achieved. The maximum of the timestamp from the GPS and the stored timestamp should be used.
 - The timestamp should be incremented by one on each message sent from a particular link.
 - When a correctly signed message is decoded the timestamp should be replaced by the timestamp of the incoming message if that timestamp is greater than the current timestamp.
-  > **Note** The link timestamp must never be updated with the timestamp from an incorrectly signed packet (even if these are being [accepted](#accepting_incorrectly_signed_packets)).
+
+  > [!NOTE]
+  > The link timestamp must never be updated with the timestamp from an incorrectly signed packet (even if these are being [accepted](#accepting_incorrectly_signed_packets)).
+
 - The timestamp on incoming signed messages should be checked against the previous timestamp for the incoming `(linkID,srcSystem,SrcComponent)` tuple and the message rejected if it is smaller.
 - If there is no previous message with the given `(linkID,srcSystem,SrcComponent)` then the timestamp should be accepted if it not more than 6 million (one minute) behind the current timestamp.
 
-> **Tip** For devices that store the timestamp in persistent storage, implementations can prevent race conditions by storing two timestamp values.
+> [!TIP]
+> For devices that store the timestamp in persistent storage, implementations can prevent race conditions by storing two timestamp values.
 > On write the smaller of the two values should be updated. On read the larger of the two values should be used.
 
 ## Accepting Signed Packets {#accept_signed_packets}
@@ -95,7 +102,8 @@ MAVLink libraries should provide a mechanism that allows a system to conditional
 
 The rules for accepting these packets will be implementation specific, but could be based on a combination of a parameter setting, transport type, message type, (in)compatibility flags etc.
 
-> **Note** All packets that do not meet the system-specific unsigned packet acceptance rules must be rejected
+> [!NOTE]
+> All packets that do not meet the system-specific unsigned packet acceptance rules must be rejected
 > (otherwise there is no benefit gained from signing/authentication).
 
 Some suggestions for when to accept unsigned packets:
@@ -112,7 +120,8 @@ MAVLink libraries should provide a mechanism that allows a system to conditional
 
 This feature might be useful for finding a lost vehicle with a corrupted secret key (the GCS could choose to still display position information, albeit ideally with a different "untrusted" icon).
 
-> **Note** A system that is accepting incorrectly signed packets should provide a highly conspicuous indication that the connection is _unsafe_/_insecure_. Malformed signed packets indicate a bad configuration, transport failure, protocol failure, or hostile manipulation.
+> [!NOTE]
+> A system that is accepting incorrectly signed packets should provide a highly conspicuous indication that the connection is _unsafe_/_insecure_. Malformed signed packets indicate a bad configuration, transport failure, protocol failure, or hostile manipulation.
 
 ## Secret Key Management {#secret_key}
 
@@ -120,7 +129,8 @@ A secret key is 32 bytes of binary data that are used to create message signatur
 The key should be created on one system in the network (often a GCS) and shared to other trusted devices via secure channels.
 Systems must have a shared key in order to be able to communicate.
 
-> **Note** The _mavgen_ [C](../mavgen_c/message_signing_c.md) and [Python](../mavgen_python/README.md#message_signing) libraries support only one key per link.
+> [!NOTE]
+> The _mavgen_ [C](../mavgen_c/message_signing_c.md) and [Python](../mavgen_python/index.md#message_signing) libraries support only one key per link.
 > This is a choice of the library and not a limit/requirement of the protocol.
 > An implementation might instead store a pool of keys, and/or manage keys on a per-connection basis.
 
@@ -144,7 +154,8 @@ This is to avoid the case where a key received over a secure link (e.g. USB) is
 
 Autopilots that don't offer MAVLink over USB might create a module that can set the secret key from a command line interface (e.g. the NSH Shell).
 
-> **Tip** We recommend that GCS implementations should generate the secret key and share this with connected systems over a secure link (e.g. USB).
+> [!TIP]
+> We recommend that GCS implementations should generate the secret key and share this with connected systems over a secure link (e.g. USB).
 > The receiving system may be configured to ignore message signatures on the secure channel (i.e. accept all [signed](#accept_signed_packets), [unsigned](#accepting_unsigned_packets) or [incorrectly signed](#accepting_incorrectly_signed_packets) packets), so that it is possible to reset a key that has been lost or corrupted.
 
 ## Logging
@@ -162,4 +173,5 @@ The [Message Signing Proposal](https://docs.google.com/document/d/1ETle6qQRcaNWA
 - Evaluation of security effectiveness, including resistance to replay and offline attacks.
 - Assumptions.
 
-> **Note** Much of this content is derived from the [Message Signing Proposal](https://docs.google.com/document/d/1ETle6qQRcaNWAmpG2wz0oOpFKSF_bcTmYMQvtTGI8ns/edit?usp=sharing) (Google Doc).
+> [!NOTE]
+> Much of this content is derived from the [Message Signing Proposal](https://docs.google.com/document/d/1ETle6qQRcaNWAmpG2wz0oOpFKSF_bcTmYMQvtTGI8ns/edit?usp=sharing) (Google Doc).

en/guide/routing.md

@@ -26,11 +26,11 @@ Broadcast messages are forwarded to all channels that haven't seen the message.
 Addressed messages are resent on a new channel _iff_ the system has previously seen a message from the target on that channel
 (messages are not resent if the addressee is not known or is on the original/incoming channel).
 
-> **Warning** Forwarded messages must not be changed/repackaged by the forwarding system (the original message is passed to the new link).
+> [!WARNING]
+> Forwarded messages must not be changed/repackaged by the forwarding system (the original message is passed to the new link).
 
-<span></span>
-
-> **Note** Systems should, where possible, forward messages according to the routing rules _even if they are unable to process them_ (e.g. signed messages that cannot be authenticated). Messages that are not supported/understood by the library should be forwarded as though they were broadcast messages (in this case the target system/component ids cannot be read).
+> [!NOTE]
+> Systems should, where possible, forward messages according to the routing rules _even if they are unable to process them_ (e.g. signed messages that cannot be authenticated). Messages that are not supported/understood by the library should be forwarded as though they were broadcast messages (in this case the target system/component ids cannot be read).
 
 ## Routing Detail
 
@@ -47,11 +47,11 @@ Systems should forward messages to another link if any of these conditions hold:
 - The `target_system` does not match the system id _and_ the system knows the link of the target system (i.e. it has previously seen a message from `target_system` on the link).
 - The `target_system` matches its system id and has a `target_component` field, and the system has seen a message from the `target_system`/`target_component` combination on the link.
 
-> **Note** Non-broadcast messages must only be sent (or forwarded) to known destinations (i.e. a system must previously have received a message from the target system/component).
+> [!NOTE]
+> Non-broadcast messages must only be sent (or forwarded) to known destinations (i.e. a system must previously have received a message from the target system/component).
 
-<span></span>
-
-> **Note** Systems should also check for `SYSTEM_TIME` messages with a decrease in `time_boot_ms`, as this indicates that the system has rebooted.
+> [!NOTE]
+> Systems should also check for `SYSTEM_TIME` messages with a decrease in `time_boot_ms`, as this indicates that the system has rebooted.
 > In this case it should clear stored routing information (and might perform other actions that are useful following a reboot - e.g. re-fetching parameters and home position etc.).
 
 ## Library Support

en/guide/scripts.md

@@ -7,7 +7,7 @@ The scripts have the following requirements:
 - Python 2.7+ and 3.3+
 - `PYTHONPATH` specifies the directory path that contains the `mavlink` repository.
 - Write access to the entire **mavlink** folder.
-- Your [dialect](../messages/README.md#dialects)'s XML file is in `message_definitions/*/`
+- Your [dialect](../messages/index.md#dialects)'s XML file is in `message_definitions/*/`
 
 The scripts can be executed by running Python with the `-m` switch, which indicates that the given script exists on the `PYTHONPATH`. The following code runs **mavlogdump.py** in **/pymavlink/tools/** on the recorded MAVLink stream `test_run.mavlink` (other scripts in **/tools** and **/scripts** can be run in a similar fashion):
 
@@ -15,4 +15,5 @@ The scripts can be executed by running Python with the `-m` switch, which indica
 python -m pymavlink.tools.mavlogdump test_run.mavlink
 ```
 
-> **Note** Using the `-m` switch is the proper way to run Python scripts that are part of a library as per PEP-328 (and the rejected PEP-3122).
+> [!NOTE]
+> Using the `-m` switch is the proper way to run Python scripts that are part of a library as per PEP-328 (and the rejected PEP-3122).

en/guide/serialization.md

@@ -4,7 +4,8 @@ This topic provides detailed information about about MAVLink packet serializatio
 
 It is primarily intended for developers who are creating/maintaining a MAVLink generator
 
-> **Tip** MAVLink users do not typically need to understand the serialization format, as encoding/decoding is handled by the MAVLink libraries.
+> [!TIP]
+> MAVLink users do not typically need to understand the serialization format, as encoding/decoding is handled by the MAVLink libraries.
 
 ## Packet Format {#packet_format}
 
@@ -60,7 +61,8 @@ Below is the over-the-wire format for a MAVLink 1 packet (the in-memory represen
 Incompatibility flags are used to indicate features that a MAVLink library must support in order to be able to handle the packet.
 This includes any feature that affects the packet format/ordering.
 
-> **Note** A MAVLink implementation **must discard** a packet if it does not understand any flag in the `incompat_flags` field.
+> [!NOTE]
+> A MAVLink implementation **must discard** a packet if it does not understand any flag in the `incompat_flags` field.
 
 Supported incompatibility flags include (at time of writing):
 
@@ -84,13 +86,14 @@ Messages are encoded within the MAVLink packet:
 
 - The `msgid` (message id) field identifies the specific message encoded in the packet.
 - The `payload` field contains the message data.
-  - MAVLink [reorders the message fields](#field_reordering) in the payload for over-the-wire transmission (from the order in the original [XML Message Definitions](../messages/README.md)).
+  - MAVLink [reorders the message fields](#field_reordering) in the payload for over-the-wire transmission (from the order in the original [XML Message Definitions](../messages/index.md)).
   - MAVLink 2 [truncates](../guide/mavlink_2.md#packet_truncation) any zero-filled bytes at the end of the payload before the message is sent and sets the packet `len` field appropriately (MAVLink 1 always sends all bytes).
 - The `len` field contains the length of the payload data.
 - A [CRC_EXTRA](#crc_extra) byte is added to the message [checksum](#checksum).
   A receiver can use this to confirm that it is compatible with the payload message format/definition.
 
-  > **Tip** A MAVLink library should notify a bad CRC during decoding if a message specification is incompatible (e.g. the C library [mavlink_parse_char()](../getting_started/use_libraries.md#receiving) gives a status `MAVLINK_FRAMING_BAD_CRC`).
+  > [!TIP]
+  > A MAVLink library should notify a bad CRC during decoding if a message specification is incompatible (e.g. the C library [mavlink_parse_char()](../getting_started/use_libraries.md#receiving) gives a status `MAVLINK_FRAMING_BAD_CRC`).
 
 ### Field Reordering {#field_reordering}
 
@@ -111,7 +114,8 @@ The only exception to the above reordering is for [MAVLink 2 extension fields](.
 Extension fields are sent in XML-declaration order and are not included in the [CRC_EXTRA](#crc_extra) calculation.
 This allows new extension fields to be appended to the end of a message without breaking binary compatibility.
 
-> **Warning** This ordering is unique and can be easily implemented in a protocol generator by using a stable sorting algorithm.
+> [!WARNING]
+> This ordering is unique and can be easily implemented in a protocol generator by using a stable sorting algorithm.
 > The alternative to using sorting would be either to use inefficient alignment, which is bad for the target architectures for typical MAVLink applications, or to have function calls in the order of the variable size instead of the application context.
 > This would lead to very confusing function signatures of serialization functions.
 
@@ -127,18 +131,19 @@ An implementation that receives a (non compliant) MAVLink 2 message with zero-fi
 The actual fields affected/bytes saved depends on the message and its content
 (MAVLink [field reordering](../guide/serialization.md#field_reordering) means that all we can say is that any truncated fields will typically be those with the smallest data size, or extension fields).
 
-> **Note** The first byte of the payload is never truncated, even if the payload consists entirely of zeros.
+> [!NOTE]
+> The first byte of the payload is never truncated, even if the payload consists entirely of zeros.
 
-<span></span>
-
-> **Note** The protocol only truncates empty bytes at the end of the serialized message payload;
+> [!NOTE]
+> The protocol only truncates empty bytes at the end of the serialized message payload;
 > any null bytes/empty fields within the body of the payload are not affected.
 
 ### CRC_EXTRA Calculation {#crc_extra}
 
 The `CRC_EXTRA` CRC is used to verify that the sender and receiver have a shared understanding of the over-the-wire format of a particular message.
 
-> **Tip** Changes in [message specifications](../messages/README.md) that might make the over-the-wire format incompatible include: new/removed fields, or changes to field name, data type, order, or array length.
+> [!TIP]
+> Changes in [message specifications](../messages/index.md) that might make the over-the-wire format incompatible include: new/removed fields, or changes to field name, data type, order, or array length.
 
 When the MAVLink code generator runs, it takes a checksum of the XML structure for each message and creates an array define `MAVLINK_MESSAGE_CRCS`.
 This is used to initialise the `mavlink_message_crcs[]` array in the C/C++ implementation, and is similarly used in the Python (or any other, such as the C# and JavaScript) implementation.
@@ -153,7 +158,8 @@ If you are doing your own implementation of MAVLink you can get this checksum in
 
 As MAVLink internally reorders the message fields according to their size to prevent word / halfword alignment issues (see [Data structure alignment](http://en.wikipedia.org/wiki/Data%20structure%20alignment) (Wikipedia) for further reference), and a wrongly implemented reordering potentially can cause inconsistencies as well, the `CRC_EXTRA` is calculated based on the over-the-air message layout rather than the XML order.
 
-> **Note** [MAVLink 2 extension fields](../guide/define_xml_element.md#message_extensions) are not included in the `CRC_EXTRA` calculation.
+> [!NOTE]
+> [MAVLink 2 extension fields](../guide/define_xml_element.md#message_extensions) are not included in the `CRC_EXTRA` calculation.
 
 This is the Python code that calculates the `CRC_EXTRA` seed:
 
@@ -178,7 +184,8 @@ def message_checksum(msg):
 
 <!-- From https://github.com/mavlink/pymavlink/blob/master/generator/mavparse.py#L385 -->
 
-> **Note** This uses the same CRC-16/MCRF4XX checksum that is used at runtime.
+> [!NOTE]
+> This uses the same CRC-16/MCRF4XX checksum that is used at runtime.
 > It calculates a CRC over the message name (such as “RAW_IMU”) followed by the type and name of each field, space separated.
 > The order of the fields is the order they are sent over the wire. For arrays, the array length is also added.
 

en/guide/wireshark.md

@@ -12,7 +12,8 @@ The benefits of using _Wireshark_ over other alternatives are:
 This topic shows how to generate a Wireshark plugin for a particular dialect file and install it on Wireshark, and how to perform basic filtering.
 It also provides an overview of how you can use _tcpdump_ for collecting traffic on a linux computer (for later analysis).
 
-> **Note** You will need to regenerate and reimport the plugin (as shown below) if your dialect changes.
+> [!NOTE]
+> You will need to regenerate and reimport the plugin (as shown below) if your dialect changes.
 
 ## Generate MAVLink Lua Plugin for Wireshark
 
@@ -92,7 +93,8 @@ Below you can see the payload and the header details for an `ATTITUDE_TARGET` me
 
 In addition to using filters for the usual _Wireshark_ things (e.g. ips and ports) you can also use the new MAVLink filters.
 
-> **Note** This works the same way for live view and for a _pcapng_ file loaded into _Wireshark_
+> [!NOTE]
+> This works the same way for live view and for a _pcapng_ file loaded into _Wireshark_
 
 We already saw you can filter for MAVLink packets using `mavlink_proto`.
 The following is a filter example:
@@ -133,7 +135,8 @@ wireshark -k -i /tmp/mavlink &
 ssh root@10.41.1.1 -p 33333 "tcpdump -s 0 -U -n -w - -i lo not port 33333" > /tmp/mavlink;
 ```
 
-> **Note** Username, IP and port above have to be adjusted to the configuration on the remote machine.
+> [!NOTE]
+> Username, IP and port above have to be adjusted to the configuration on the remote machine.
 
 1. `mkfifo /tmp/mavlink` Creates a named pipe that is used to stream the data.
 1. `wireshark -k -i /tmp/mavlink &` Start _Wireshark_, open the named pipe as input and start the capture immediately.

en/guide/xml_schema.md

@@ -8,7 +8,8 @@ While this is the canonical reference, it is easier to understand the XML file b
 
 The broad structure for MAVLink XML files is given below.
 
-> **Note** If you're creating a custom dialect file your file structure should be similar to the one below (but may omit any/all sections).
+> [!NOTE]
+> If you're creating a custom dialect file your file structure should be similar to the one below (but may omit any/all sections).
 
 ```xml
 <?xml version="1.0"?>
@@ -85,7 +86,8 @@ The main `enum` tags/fields are:
 - `entry` (optional): An entry (zero or more entries can be specified for each enum)
 - [deprecated](#deprecated) (optional): A tag indicating that the enum is deprecated.
 
-> **Tip** [MAVLink Commands](#mav_cmd) are defined in the [MAV_CMD](../messages/common.md#mav_commands) enum.
+> [!TIP]
+> [MAVLink Commands](#mav_cmd) are defined in the [MAV_CMD](../messages/common.md#mav_commands) enum.
 
 ### entry {#entry}
 
@@ -96,7 +98,8 @@ The "normal" enum `entry` tags/fields are:
 - `description` (optional): A description of the entry.
 - [deprecated](#deprecated) / [wip](#wip) (optional): A tag indicating that the enum is deprecated or "work in progress".
 
-> **Note** An `entry` may also define the optional elements: `param`, `hasLocation`, `isDestination`, `missionOnly`.
+> [!NOTE]
+> An `entry` may also define the optional elements: `param`, `hasLocation`, `isDestination`, `missionOnly`.
 > In practice these should only be used in the `enum` named [MAV_CMD](#MAV_CMD) (described below).
 
 ## MAVLink Commands (enum MAV_CMD) {#MAV_CMD}
@@ -104,7 +107,8 @@ The "normal" enum `entry` tags/fields are:
 Individual `entry` values in the `enum` named [MAV_CMD](#MAV_CMD) are use to define _MAVLink Commands_.
 Each command has a `value` (its "command number") and specifies up to 7 parameters.
 
-> **Note** These parameters are encoded in [MISSION_ITEM](../messages/common.md#MISSION_ITEM) or [MISSION_ITEM_INT](../messages/common.md#MISSION_ITEM_INT) messages ([Mission Protocol](../services/mission.md)), or [COMMAND_INT](../messages/common.md#COMMAND_INT) or [COMMAND_LONG](../messages/common.md#COMMAND_LONG) messages ([Command Protocol](../services/command.md)).
+> [!NOTE]
+> These parameters are encoded in [MISSION_ITEM](../messages/common.md#MISSION_ITEM) or [MISSION_ITEM_INT](../messages/common.md#MISSION_ITEM_INT) messages ([Mission Protocol](../services/mission.md)), or [COMMAND_INT](../messages/common.md#COMMAND_INT) or [COMMAND_LONG](../messages/common.md#COMMAND_LONG) messages ([Command Protocol](../services/command.md)).
 
 For example, see [MAV_CMD_NAV_PAYLOAD_PLACE](../messages/common.md#MAV_CMD_NAV_PAYLOAD_PLACE):
 
@@ -161,7 +165,10 @@ A `param` **should** also include the following optional attributes where approp
 - `multiplier` - Multiply by this value to get the unscaled original value.
   This is primarily intended for specifying any scaling applied to unitless values, where scaling is not encoded in the `units`.
 - `reserved` - Boolean indicating whether param is reserved for future use. If the attributes is not declared, then implicitly `reserved="False"`.
-  > **Tip** See [Defining XML Enums/Messages > Reserved/Undefined Parameters](../guide/define_xml_element.md#reserved) for more information.
+
+  > [!TIP]
+  > See [Defining XML Enums/Messages > Reserved/Undefined Parameters](../guide/define_xml_element.md#reserved) for more information.
+
 - `default` - Default value for the `param`
   (primarily used for `reserved` params, where the value is `0` or `NaN`).
 
@@ -205,7 +212,10 @@ The main message tags/fields are:
     - For [MAVLink 2](../guide/mavlink_2.md):
       - Valid numbers range from 0 to 16777215.
       - All numbers below 255 should be considered reserved unless messages are also intended for MAVLink 1.
-        > **Note** IDs are precious in MAVLink 1!
+
+        > [!NOTE]
+        > IDs are precious in MAVLink 1!
+
   - `name`: The name attribute provides a human readable form for the message (ie "BATTERY_STATUS"). It is used for naming helper functions in generated libraries, but is not sent over the wire.
 - `description`: Human readable description of message, shown in user interfaces and in code comments.
   This should contain all information (and hyperlinks) to fully understand the message.
@@ -231,7 +241,8 @@ The main message tags/fields are:
   - `maxValue` - Maximum value for the field.
   - `instance`: If `true`, this indicates that the message contains the information for a particular sensor or battery (e.g. Battery 1, Battery 2, etc.) and that this field indicates which sensor. Default is `false`.
 
-    > **Note** This field allows a recipient automatically associate messages for a particular sensor and plot them in the same series.
+    > [!NOTE]
+    > This field allows a recipient automatically associate messages for a particular sensor and plot them in the same series.
 
   - `invalid`: Specifies a value that can be set on a field to indicate that the data is _invalid_: the recipient should ignore the field if it has this value.
     For example, `BATTERY_STATUS.current_battery` specifies `invalid="-1"`, so a battery that does not measure supplied _current_ should set `BATTERY_STATUS.current_battery` to `-1`.
@@ -266,7 +277,8 @@ The tag attributes indicates the time of deprecation and the replacement item, w
 
 The generator toolchain can be configured to conditionally build messages omitting the `deprecated` entries.
 
-> **Tip** An entity should be marked as deprecated only when the main users have had an opportunity to update to the new method.
+> [!TIP]
+> An entity should be marked as deprecated only when the main users have had an opportunity to update to the new method.
 
 As a concrete example, below we see that [SET_MODE](../messages/common.md#SET_MODE) is deprecated and replaced by [MAV_CMD_DO_SET_MODE](../messages/common.md#MAV_CMD_DO_SET_MODE) on `2015-12`.
 

en/index.md

@@ -6,14 +6,15 @@ MAVLink is a very lightweight messaging protocol for communicating with drones (
 
 MAVLink follows a modern hybrid publish-subscribe and point-to-point design pattern: Data streams are sent / published as **topics** while configuration sub-protocols such as the [mission protocol](services/mission.md) or [parameter protocol](services/parameter.md) are point-to-point with retransmission.
 
-Messages are [defined within XML files](messages/README.md).
+Messages are [defined within XML files](messages/index.md).
 Each XML file defines the message set supported by a particular MAVLink system, also referred to as a "dialect".
 The reference message set that is implemented by _most_ ground control stations and autopilots is defined in [common.xml](messages/common.md) (most dialects _build on top of_ this definition).
 
 [Code generators](getting_started/generate_libraries.md) create software libraries for [specific programming languages](#supported_languages) from these XML message definitions, which can then be used by drones, ground control stations, and other MAVLink systems to communicate.
 The generated libraries are typically MIT-licensed, and can therefore be _used_ without limits in any closed-source application without publishing the source code of the closed-source application.
 
-> **Note** The C reference implementation is a header-only library that is highly optimized for resource-constrained systems with limited RAM and flash memory.
+> [!NOTE]
+> The C reference implementation is a header-only library that is highly optimized for resource-constrained systems with limited RAM and flash memory.
 > It is field-proven and deployed in many products where it serves as interoperability interface between components of different manufacturers.
 
 MAVLink was first released early 2009 by Lorenz Meier and has now a [significant number of contributors](https://github.com/mavlink/mavlink/graphs/contributors).
@@ -78,12 +79,12 @@ The following generators are delivered by independent projects (and supported by
 
 ## Prebuilt MAVLink C Libraries {#prebuilt_libraries}
 
-_C_ MAVLink Source Files (only) are auto-generated for the latest versions of all message [specifications/dialects](messages/README.md) (for both MAVLink 1 and 2):
+_C_ MAVLink Source Files (only) are auto-generated for the latest versions of all message [specifications/dialects](messages/index.md) (for both MAVLink 1 and 2):
 
 - [c_library_v2](https://github.com/mavlink/c_library_v2) (MAVLink 2)
 - [c_library_v1](https://github.com/mavlink/c_library_v1) (MAVLink 1)
 
-[Using C Libraries](mavgen_c/README.md) explains how to use these libraries.
+[Using C Libraries](mavgen_c/index.md) explains how to use these libraries.
 
 ## Support {#support}
 

en/mavgen_c/example_c_udp.md

@@ -3,7 +3,8 @@
 The [MAVLink UDP Example](https://github.com/mavlink/mavlink/tree/master/examples/linux) is a simple C example that sends some data to _QGroundControl_ using MAVLink over UDP.
 _QGroundControl_ responds with heartbeats and other messages, which are then printed by this program.
 
-> **Note** The example should work on any Unix-like system (Linux, MacOS, BSD, etc.).
+> [!NOTE]
+> The example should work on any Unix-like system (Linux, MacOS, BSD, etc.).
 > These instructions were tested on a clean _Ubuntu LTS 20.04_ installation using the default version of _gcc_ (9.3.0).
 
 ## Building/Running the Example
@@ -17,15 +18,14 @@ The following instructions show how to build and run the example.
    python3 -m pymavlink.tools.mavgen --lang=C --wire-protocol=2.0 --output=./include/ message_definitions/v1.0/common.xml
    ```
 
-   > **Tip** Alternatively you can clone the [mavlink/mavlink](https://github.com/mavlink/mavlink/) repository and [Download prebuilt headers](../README.md#prebuilt_libraries) to the same location.
+   > [!TIP]
+   > Alternatively you can clone the [mavlink/mavlink](https://github.com/mavlink/mavlink/) repository and [Download prebuilt headers](../index.md#prebuilt_libraries) to the same location.
 
-   <span></span>
+   > [!NOTE]
+   > The example will not work with MAVLink 1 because it uses a message that includes extension fields which do not exist in MAVLink 1 (`SYS_STATUS`).
 
-   > **Note** The example will not work with MAVLink 1 because it uses a message that includes extension fields which do not exist in MAVLink 1 (`SYS_STATUS`).
-
-   <span></span>
-
-   > **Note** You can put/generate the library wherever you like, but the build command below assumes they are located in directory named **include** below the MAVLink root directory.
+   > [!NOTE]
+   > You can put/generate the library wherever you like, but the build command below assumes they are located in directory named **include** below the MAVLink root directory.
 
 1. Open a terminal and navigate to [examples/linux](https://github.com/mavlink/mavlink/tree/master/examples/linux)
 1. Compile with GCC using the following command:
@@ -34,7 +34,8 @@ The following instructions show how to build and run the example.
    gcc -std=c99 -I ../../include/common -o mavlink_udp mavlink_udp.c
    ```
 
-   > **Note** The MAVLink header directory must be added to the include path.
+   > [!NOTE]
+   > The MAVLink header directory must be added to the include path.
    > The path here assumes you are building the code from the example directory, and that have installed the headers in **mavlink/include**.
 
 1. Run the executable from the terminal:
@@ -50,7 +51,8 @@ The following instructions show how to build and run the example.
 
    _QGroundControl_ immediately starts broadcasting its `HEARTBEAT` on port 14551.
 
-   > **Note** _QGroundControl_ returns data, but will not actually "connect" to the example (it will continue to display the message _Waiting for Vehicle Connection_).
+   > [!NOTE]
+   > _QGroundControl_ returns data, but will not actually "connect" to the example (it will continue to display the message _Waiting for Vehicle Connection_).
 
 1. The example should start displaying the received data in the terminal:
 

en/mavgen_c/index.md

@@ -7,9 +7,10 @@ This topic explains how to get and use the library.
 
 ## Getting the C MAVLink Library {#get_libraries}
 
-If you are using a [standard dialect](../messages/README.md#dialects) then download the _MAVLink 2_ library from Github: [c_library_v2](https://github.com/mavlink/c_library_v2).
+If you are using a [standard dialect](../messages/index.md#dialects) then download the _MAVLink 2_ library from Github: [c_library_v2](https://github.com/mavlink/c_library_v2).
 
-> **Tip** The MAVLink 2 library supports both MAVLink 2 and MAVLink 1, and is rebuilt for all the _standard dialects_ whenever any of the definitions in the _mavlink/mavlink_ repo change.
+> [!TIP]
+> The MAVLink 2 library supports both MAVLink 2 and MAVLink 1, and is rebuilt for all the _standard dialects_ whenever any of the definitions in the _mavlink/mavlink_ repo change.
 > It supersedes the MAVLink 1 library ([c_library_v1](https://github.com/mavlink/c_library_v1)), and should be used by preference.
 
 If you need libraries for a custom dialect then you will need to [install mavgen](../getting_started/installation.md) and [generate](../getting_started/generate_libraries.md) them yourself.
@@ -29,12 +30,12 @@ To use MAVLink in your C project, include the **mavlink.h** header file for your
 
 This will automatically add the header files for all messages in your dialect, and for any dialect files that it includes.
 
-> **Warning** Only include the header file for a single dialect.
+> [!WARNING]
+> Only include the header file for a single dialect.
 > If you need to support messages from a _number of dialects_ then create a new "parent" dialect XML file that includes them (and use its generated header as shown above).
 
-<span></span>
-
-> **Tip** _Do not include the individual message files_.
+> [!TIP]
+> _Do not include the individual message files_.
 > If you generate your own headers, you will have to add their output location to your C compiler's search path.
 
 When compiling the project, make sure to add the include directory:
@@ -94,7 +95,8 @@ The _MAVLink 1_ pre-built library [mavlink/c_library_v1](https://github.com/mavl
 
 The _MAVLink 2_ C library offers the same range of APIs as was offered by _MAVLink 1_.
 
-> **Note** The major change from an API perspective is that you don't need to provide a message CRC table any more, or message length table.
+> [!NOTE]
+> The major change from an API perspective is that you don't need to provide a message CRC table any more, or message length table.
 > These have been folded into a single packed table, replacing the old table which was indexed by `msgId`.
 > That was necessary to cope with the much larger 24 bit namespace of message IDs.
 
@@ -161,7 +163,8 @@ while(serial.bytesAvailable > 0)
 }
 ```
 
-> **Tip** The [mavlink_helpers.h](https://github.com/mavlink/c_library_v2/blob/master/mavlink_helpers.h) include other parser functions: `mavlink_frame_char()` and `mavlink_frame_char_buffer()`.
+> [!TIP]
+> The [mavlink_helpers.h](https://github.com/mavlink/c_library_v2/blob/master/mavlink_helpers.h) include other parser functions: `mavlink_frame_char()` and `mavlink_frame_char_buffer()`.
 > Generally you will want to use `mavlink_parse_char()` (which calls those functions internally), but reviewing the other methods can give you a better understanding of the parsing process.
 
 ### Decoding the Payload {#decode_payload}
@@ -205,7 +208,8 @@ if (mavlink_parse_char(chan, byte, &msg, &status)) {
 The decoder/encoder functions and ids for each message in a dialect can be found in separate header files under the dialect folder.
 The headers are named with a format including the message name (**mavlink_msg\__message_name_.h**)
 
-> **Tip** Individual message definitions for the dialect are pulled in when you include **mavlink.h** for your dialect, so you don't need to include these separately.
+> [!TIP]
+> Individual message definitions for the dialect are pulled in when you include **mavlink.h** for your dialect, so you don't need to include these separately.
 
 The most useful decoding function is named with the pattern **mavlink_msg\__message_name_\_decode()**, and extracts the whole payload into a C struct (with fields mapping to the original XML message definition).
 There are also separate decoder functions to just get the values of individual fields.
@@ -244,7 +248,8 @@ A [MAVLink Command](../services/command.md) encodes a command defined in a [MAV_
 
 Command packets are parsed and decoded in the same way as [any other payload](#decode_payload) - i.e. you switch on message id of `MAVLINK_MSG_ID_COMMAND_INT`/`MAVLINK_MSG_ID_COMMAND_LONG` and call the decoder functions `mavlink_msg_command_int_decode()`/`mavlink_msg_command_long_decode()` (respectively) to get a C struct mapping the original message.
 
-> **Note** The message types differ in that `COMMAND_INT` has `int32` types for parameter fields 6 and 7 (instead of `float`) and also includes a field for the geometric frame of reference of any positional information in the command.
+> [!NOTE]
+> The message types differ in that `COMMAND_INT` has `int32` types for parameter fields 6 and 7 (instead of `float`) and also includes a field for the geometric frame of reference of any positional information in the command.
 
 To decode the specific command you then switch on the value of the `mavlink_command_int_t.command` or `mavlink_command_long_t.command` field, which contains the particular `MAV_CMD` id.
 
@@ -280,7 +285,7 @@ The topic [C Message Signing](../mavgen_c/message_signing_c.md) explains the rem
 
 The sections above explain how you can send and receive messages.
 What messages are sent/received depends on the systems that you're working with.
-The set of messages that most systems can send are documented in [common.xml](../messages/common.md) and there are various microservices [microservices](../services/README.md) that you may want to use.
+The set of messages that most systems can send are documented in [common.xml](../messages/common.md) and there are various microservices [microservices](../services/index.md) that you may want to use.
 
 Minimally MAVLink components should implement the [HEARTBEAT/Connection protocol](../services/heartbeat.md) as this is used by other systems as proof-of-life for the component, and also for [routing](../guide/routing.md).
 
@@ -314,7 +319,8 @@ if (msg->magic == MAVLINK_STX_MAVLINK1) {
 
 In most cases this should not be necessary as the XML message definition files for _MAVLink 1_ and _MAVLink 2_ are the same, so you can treat incoming _MAVLink 1_ messages the same as _MAVLink 2_ messages.
 
-> **Note** _MAVLink 1_ is restricted to message IDs less than 256, so any messages with a higher message ID won't be received as _MAVLink 1_.
+> [!NOTE]
+> _MAVLink 1_ is restricted to message IDs less than 256, so any messages with a higher message ID won't be received as _MAVLink 1_.
 
 It is advisable to switch to _MAVLink 2_ when the communication partner sends _MAVLink 2_ (see [Version Handshaking](../guide/mavlink_version.md#version_handshaking)). The minimal solution is to watch incoming packets using code similar to this:
 

en/mavgen_python/index.md

@@ -7,13 +7,13 @@ The library can be used with Python 3.5+ and supports both MAVLink 1 and MAVLink
 
 This topic explains how to get and use the _Pymavlink_ MAVLink Python libraries (generated using [mavgen](../getting_started/generate_libraries.md#mavgen)).
 
-> **Note** Pymavlink is developed in its own [project](https://github.com/ArduPilot/pymavlink), which includes the command line MAVLink generator (mavgen), Python bindings to create _Pymavlink_, and other useful tools and utilities.
+> [!NOTE]
+> Pymavlink is developed in its own [project](https://github.com/ArduPilot/pymavlink), which includes the command line MAVLink generator (mavgen), Python bindings to create _Pymavlink_, and other useful tools and utilities.
 > MAVLink includes the [Pymavlink](https://github.com/ArduPilot/pymavlink) repository as a submodule.
 > While you can work with that project directly, this documentation explains how to work with _pymavlink_ _**using the MAVLink project**_.
 
-<span></span>
-
-> **Tip** If you are writing a MAVLink application to communicate with an autopilot you may prefer to use a higher level library like [MAVSDK-Python](https://github.com/mavlink/MAVSDK-Python#mavsdk-python) or [DroneKit-Python](http://python.dronekit.io/).
+> [!TIP]
+> If you are writing a MAVLink application to communicate with an autopilot you may prefer to use a higher level library like [MAVSDK-Python](https://github.com/mavlink/MAVSDK-Python#mavsdk-python) or [DroneKit-Python](http://python.dronekit.io/).
 > These implement a number of [MAVLink microservices](../about/overview.md).
 
 ## Getting the Python MAVLink Libraries
@@ -24,13 +24,14 @@ For custom dialects the library needs to be generated first.
 
 ### Get the Standard MAVLink Dialect
 
-If you need a [standard dialect](../messages/README.md#dialects) then you can install these (for both MAVLink 1 and 2) with _pymavlink_ using _pip_:
+If you need a [standard dialect](../messages/index.md#dialects) then you can install these (for both MAVLink 1 and 2) with _pymavlink_ using _pip_:
 
 ```sh
 pip install pymavlink
 ```
 
-> **Tip** The [PyPi](https://pypi.org/project/pymavlink/) repository takes message definitions from the [ArduPilot/mavlink](https://github.com/ArduPilot/mavlink) fork, which may diverge slightly from _MAVLink/mavlink_.
+> [!TIP]
+> The [PyPi](https://pypi.org/project/pymavlink/) repository takes message definitions from the [ArduPilot/mavlink](https://github.com/ArduPilot/mavlink) fork, which may diverge slightly from _MAVLink/mavlink_.
 
 ### Generate a Custom MAVLink Dialect
 
@@ -78,14 +79,15 @@ There are several main caveats to be aware of when using **mavutil**:
   If you need a multi-vehicle network see [source-system-filtering](https://github.com/peterbarker/dronekit-python/tree/source-system-filtering/examples/multivehicle).
 - The module is optimised for ArduPilot and some functions may not work properly on other autopilots.
 - **mavutil** is still a relatively low-level MAVLink API.
-  It has limited support for even the most common [MAVLink microservices](../services/README.md).
+  It has limited support for even the most common [MAVLink microservices](../services/index.md).
 
-> **Tip** You don't have to use **mavutil** but it includes a lot of useful code that you might otherwise have to write from scratch.
+> [!TIP]
+> You don't have to use **mavutil** but it includes a lot of useful code that you might otherwise have to write from scratch.
 > In particular the connection code and methods to filter incoming messages are useful for any autopilot.
 
 The set of modules in the _pymavlink_ package are listed below:
 
-- **\dialects\v20\\\*** and **\dialects\v10\\\***: Dialect modules corresponding to each source XML [message definition](../messages/README.md) for MAVLink v2 and v1, respectively.
+- **\dialects\v20\\\*** and **\dialects\v10\\\***: Dialect modules corresponding to each source XML [message definition](../messages/index.md) for MAVLink v2 and v1, respectively.
   Each dialect module contains:
   - constants for all enums and enum values defined in the XML file.
   - a set of constants for message identifiers.
@@ -116,7 +118,8 @@ You can change this by setting environment variables:
 - `MAVLINK20`: Set to 1 (if unset then default to MAVLink 1)
 - `MDEF`: Location of message definition libraries
 
-> **Tip** You can also change the dialect by passing its name to `mavutil.mavlink_connection()` when [setting up a connection](#setting_up_connection).
+> [!TIP]
+> You can also change the dialect by passing its name to `mavutil.mavlink_connection()` when [setting up a connection](#setting_up_connection).
 
 If you are not using _mavutil_ then you can import the dialect file that you want to use directly:
 
@@ -133,7 +136,8 @@ from pymavlink.dialects.v20 import common as mavlink2
 The **mavutil** module provides the `mavlink_connection()` method for setting up communication links to MAVLink systems over serial ports, tcp, or udp channels.
 It can also connect to a file object, which is useful when working with telemetry logs.
 
-> **Warning** The method returns an object that represents a single system, but will collect messages from multiple systems on the link.
+> [!WARNING]
+> The method returns an object that represents a single system, but will collect messages from multiple systems on the link.
 > This is OK for two-system networks, but if you need to connect over a multi-vehicle IP network see [source-system-filtering](https://github.com/peterbarker/dronekit-python/tree/source-system-filtering/examples/multivehicle).
 
 The `mavlink_connection()` method takes a [connection string](#connection_string) defining the channel, and some optional arguments for setting the baud rate and other properties of the link (the format of the connection string automatically sets, and may override, some optional arguments).
@@ -154,7 +158,8 @@ print("Heartbeat from system (system %u component %u)" % (the_connection.target_
 # Once connected, use 'the_connection' to get and send messages
 ```
 
-> **Note** The `udpin` prefix used above creates a socket to _listen for_ a UDP connection on the specified port.
+> [!NOTE]
+> The `udpin` prefix used above creates a socket to _listen for_ a UDP connection on the specified port.
 > This is the normal way to connect an autopilot simulator).
 > The complementary `udpout` prefix creates a socket that _initiates_ an IP connection:
 
@@ -201,12 +206,13 @@ Some of the strings you can use for different types of connections are listed be
 | Windows computer connected to the vehicle via USB (in this case on COM14)        | `com14`                                                                  |
 | Windows computer connected to the vehicle using a 3DR Telemetry Radio on `COM14` | `com14` (also set `baud=57600`)                                          |
 
-> **Note** While MAVLink does not define the UDP ports used for different purposes, there is a _defacto_ standard that MAVLink APIs should listen for SITL connections on UDP port `14540` while a GCS should listen for connections on UDP `14550`.
+> [!NOTE]
+> While MAVLink does not define the UDP ports used for different purposes, there is a _defacto_ standard that MAVLink APIs should listen for SITL connections on UDP port `14540` while a GCS should listen for connections on UDP `14550`.
 
 ### Sending Messages {#sending}
 
 `MAVLink` is the main protocol handling class.
-It is defined in each dialect module, and includes a `<message_name>_send()` method for all messages in the dialect's [message definition](../messages/README.md).
+It is defined in each dialect module, and includes a `<message_name>_send()` method for all messages in the dialect's [message definition](../messages/index.md).
 
 The message field values are passed as arguments to the function. Fields that are the same for all messages are defined in the class - e.g. source system, source component. Each message is documented in the dialect source code, even when it was [automatically generated](../getting_started/generate_libraries.md).
 
@@ -232,7 +238,8 @@ the_connection.mav.system_time_send(time_unix_usec, time_boot_ms)
 
 Other examples can be seen in [Publishing a Heartbeat](#heartbeat) and [Requesting Specific Messages](#specific_messages) below.
 
-> **Note** If you are not using **mavutil** you will need to create and set up the `MAVLink` object yourself so it knows about the channel that it should use for sending messages, which is represented by the `file` attribute.
+> [!NOTE]
+> If you are not using **mavutil** you will need to create and set up the `MAVLink` object yourself so it knows about the channel that it should use for sending messages, which is represented by the `file` attribute.
 
 ### Receiving Messages
 
@@ -307,7 +314,8 @@ For more information see [How to request messages](../mavgen_python/howto_reques
 All MAVLink components should periodically broadcast a [HEARTBEAT](../messages/common.md#HEARTBEAT) message and listen for heartbeats from other systems.
 Systems consider themselves [connected](../services/heartbeat.md) to another system as long as they regularly receive a `HEARTBEAT` from it.
 
-> **Note** [Sending Messages](#sending) explains how messages are sent.
+> [!NOTE]
+> [Sending Messages](#sending) explains how messages are sent.
 
 The `HEARTBEAT` message can be sent using `MAVLink.heartbeat_send()` message in the generated Python dialect file.
 The method definition is provided below:
@@ -342,7 +350,8 @@ the_connection.mav.heartbeat_send(mavutil.mavlink.MAV_TYPE_ONBOARD_CONTROLLER,
                                                 mavutil.mavlink.MAV_AUTOPILOT_INVALID, 0, 0, 0)
 ```
 
-> **Note** The various types used above come from `enum` in the dialect file.
+> [!NOTE]
+> The various types used above come from `enum` in the dialect file.
 
 The rate at which the heartbeat should be sent depends on the channel, but is normally 1Hz.
 

en/mavgen_python/message_signing.md

@@ -7,7 +7,8 @@ All you need to do is provide a secret key and initial timestamp, optionally spe
 
 The way you do this depends on whether you are using **mavutil** to manage the connection or using a `MAVLink` object directly.
 
-> **Note** While not covered in this topic, you should also write code to:
+> [!NOTE]
+> While not covered in this topic, you should also write code to:
 >
 > - Save and load the key and last-timestamp from permanent storage
 > - Implement a mechanism to create and share the key. For more information see [Message Signing > Secret Key Management](../guide/message_signing.md#secret_key).
@@ -29,7 +30,8 @@ if signing:
     mav.signing.sign_outgoing = True
 ```
 
-> **Note** The `MAVLink` class does not ensure that your `link_id` or _initial_ `timestamp` are appropriate.
+> [!NOTE]
+> The `MAVLink` class does not ensure that your `link_id` or _initial_ `timestamp` are appropriate.
 > The initial timestamp should be based on current system time.
 > For more information see [Message Signing](../guide/message_signing.md#timestamp).
 

en/messages/all.md

@@ -3,7 +3,7 @@
 
 # Dialect: all
 
-This dialect is intended to `include` all other [dialects](../messages/README.md) in the [mavlink/mavlink](https://github.com/mavlink/mavlink) repository (including [external dialects](https://github.com/mavlink/mavlink/tree/master/external/dialects#mavlink-external-dialects)).
+This dialect is intended to `include` all other [dialects](../messages/index.md) in the [mavlink/mavlink](https://github.com/mavlink/mavlink) repository (including [external dialects](https://github.com/mavlink/mavlink/tree/master/external/dialects#mavlink-external-dialects)).
 
 Dialects that are in **all.xml** are guaranteed to not have clashes in messages, enums, enum ids, and MAV_CMDs.
 This ensure that:

en/messages/common.md

@@ -5,7 +5,7 @@
 
 The MAVLink *common* message set contains *standard* definitions that are managed by the MAVLink project.
 The definitions cover functionality that is considered useful to most ground control stations and autopilots.
-MAVLink-compatible systems are expected to use these definitions where possible (if an appropriate message exists) rather than rolling out variants in their own [dialects](../messages/README.md).
+MAVLink-compatible systems are expected to use these definitions where possible (if an appropriate message exists) rather than rolling out variants in their own [dialects](../messages/index.md).
 
 The original definitions are defined in [common.xml](https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/common.xml).
 

en/services/battery.md

@@ -7,7 +7,8 @@ MAVLink provides a number of messages for providing battery information:
   - Emitted at around 0.5 Hz (for each battery).
   - Some batteries may provide [fault](#MAV_BATTERY_FAULT) and [mode](#MAV_BATTERY_MODE) information in this message.
 
-  > **Note** `BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.html#BATTERY_STATUS_V2).
+  > [!NOTE]
+  > `BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.html#BATTERY_STATUS_V2).
   > For more information see [RFC 0018 - Improved Battery Status Reporting](https://github.com/mavlink/rfcs/pull/19).
 
 - [BATTERY_INFO](#BATTERY_INFO): Battery information that changes rarely, if ever (e.g. device name):
@@ -17,7 +18,8 @@ MAVLink provides a number of messages for providing battery information:
 The messages should be sent individually for each battery in the system (the messages have an instance `id` field that is used to identify the corresponding battery).
 It is up to the GCS to provide an appropriate mechanism that allows the user to assess the aggregate battery status on systems that have multiple batteries.
 
-> **Note** There is no standardized mechanism to report the "aggregate" battery state on a multi-battery system.
+> [!NOTE]
+> There is no standardized mechanism to report the "aggregate" battery state on a multi-battery system.
 > A GCS is expected to provide enough information from the individual battery reports to allow a user to make a reasonable assessment of vehicle battery status.
 
 ## Message/Enum Summary
@@ -44,7 +46,8 @@ Batteries that are distinct components on the MAVLink network must:
   [MAV_COMP_ID_BATTERY](../messages/common.md#MAV_COMP_ID_BATTERY) and [MAV_COMP_ID_BATTERY2](../messages/common.md#MAV_COMP_ID_BATTERY2) should be used by default for the first two battery instances.
   Subsequent instances can use any spare/unused ID.
 
-> **Note** Ground stations (and other components) that are interested in battery messages should differentiate batteries based on `BATTERY_STATUS.id`/`BATTERY_INFO.id`.
+> [!NOTE]
+> Ground stations (and other components) that are interested in battery messages should differentiate batteries based on `BATTERY_STATUS.id`/`BATTERY_INFO.id`.
 
 ## A Note on SYS_STATUS
 
@@ -55,5 +58,6 @@ On a single-battery system these usually provide the same information as the `BA
 On multi-battery systems the values are not standardised, and depend on the flight stack and/or flight stack configuration.
 For example, a system may report the same information as the first `BATTERY_STATUS`, allow the user to configure which battery is reported (i.e. with a parameter), report the battery with the lowest remaining capacity.
 
-> **Note** GCS should not rely on the value of `SYS_STATUS`.
+> [!NOTE]
+> GCS should not rely on the value of `SYS_STATUS`.
 > However it cannot be removed because it is used for battery reporting on many legacy systems (e.g. On-screen displays).

en/services/camera.md

@@ -4,12 +4,12 @@ The camera protocol v2 is used to configure camera payloads and request their st
 It provides basic methods for photo capture, video capture and streaming, setting zoom and focus, querying and configuring camera storage, and selecting multiple cameras.
 It also defines a camera definition file format that allows a GCS to generate a configuration UI for setting any property of the camera using parameters.
 
-> **Note** This protocol supersedes [Camera Protocol v1 (Simple Trigger Protocol)](../services/camera_v1.md).
+> [!NOTE]
+> This protocol supersedes [Camera Protocol v1 (Simple Trigger Protocol)](../services/camera_v1.md).
 > The older protocol enables camera triggering, but does not support other features or querying camera capabilities.
 
-<span></span>
-
-> **Warning** We are transitioning from specific request commands to a single generic requestor.
+> [!WARNING]
+> We are transitioning from specific request commands to a single generic requestor.
 > GCS and MAVLink SDKs/apps should support both approaches as we migrate to exclusive use of the new method (documented here).
 > For more information see [Migration Notes for GCS & Camera Servers](#migration-notes-for-gcs--mavlink-sdks).
 
@@ -68,7 +68,8 @@ When processing a camera item in a mission the autopilot should:
 - For other `Target Camera ID` values, re-emit the `MAV_CMD` using the command protocol, setting the target component id to the `id` set in the camera mission item.
   It should also log any errors from the returned `COMMAND_ACK`.
 
-> **Note** Flight stacks that predate using a camera id typically re-emit the mission command addressed either to the broadcast component id (`0`) or to [MAV_COMP_ID_CAMERA](../messages/common.md#MAV_COMP_ID_CAMERA).
+> [!NOTE]
+> Flight stacks that predate using a camera id typically re-emit the mission command addressed either to the broadcast component id (`0`) or to [MAV_COMP_ID_CAMERA](../messages/common.md#MAV_COMP_ID_CAMERA).
 > The former triggers all cameras on the system, while the later provides better command handling because there is only one `COMMAND_ACK`.
 
 ## Camera Discovery
@@ -85,12 +86,12 @@ A GCS should start the [Camera Identification](#camera_identification) process t
 - MAVLink camera component.
 - Autopilot, in order to detect autopilot-connected cameras.
 
-> **Note** If a receiving system stops receiving heartbeats from the camera it is assumed to be _disconnected_, and should be removed from the list of available cameras.
+> [!NOTE]
+> If a receiving system stops receiving heartbeats from the camera it is assumed to be _disconnected_, and should be removed from the list of available cameras.
 > If heartbeats are again detected, the _camera identification_ process below must be restarted from the beginning.
 
-<span></span>
-
-> **Note** If a vehicle has more than one MAVLink camera, each camera will have a different component ID and send its own heartbeat.
+> [!NOTE]
+> If a vehicle has more than one MAVLink camera, each camera will have a different component ID and send its own heartbeat.
 > The vehicle autopilot might also have directly connected cameras, which are separately addressed by a camera device id.
 > The GCS should create multiple instances of a camera controller based on the component ID of each camera, and also the component ID of the autopilot and each of its attached camera devices.
 > All commands are sent to a specific camera by addressing the command to a specific component ID, and additionally the camera device id for autopilots.
@@ -104,7 +105,8 @@ The process involves requesting the [CAMERA_INFORMATION](../messages/common.md#C
 `CAMERA_INFORMATION.flags` provides information about camera capabilities.
 It contains a bitmap of [CAMERA_CAP_FLAGS](../messages/common.md#CAMERA_CAP_FLAGS) values that tell the GCS if the camera supports still image capture, video capture, or video streaming, and if it needs to be in a certain mode for capture, etc.
 
-> **Tip** Camera identification must be carried out before all other camera operations!
+> [!TIP]
+> Camera identification must be carried out before all other camera operations!
 
 The first time a heartbeat is received from a new camera component ([HEARTBEAT.type=MAV_TYPE_CAMERA](../messages/common.md#MAV_TYPE_CAMERA)), the GCS should send it a [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) message asking for [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) (message id 259).
 The camera will then respond with the a [COMMAND_ACK](../messages/common.md#COMMAND_ACK) message containing a result.
@@ -158,7 +160,8 @@ If this URI exists, the GCS will request it, parse it and prepare the UI for the
 The `CAMERA_INFORMATION.cam_definition_version` field should provide a version for the definition file, allowing the GCS to cache it.
 Once downloaded, it would only be requested again if the version number changes.
 
-> **Note** A GCS that implements this protocol is expected to support both HTTP (`http://`) and [MAVLink FTP](../services/ftp.md) (`mftp://`) URIs for download of the camera definition file.
+> [!NOTE]
+> A GCS that implements this protocol is expected to support both HTTP (`http://`) and [MAVLink FTP](../services/ftp.md) (`mftp://`) URIs for download of the camera definition file.
 > If the camera provides an HTTP or MAVLink FTP interface, the definition file can be hosted on the camera itself.
 > Otherwise, it can be _hosted_ anywhere (on any reachable server).
 
@@ -193,7 +196,8 @@ sequenceDiagram;
     Camera->>GCS: CAMERA_SETTINGS
 -->
 
-> **Note** Command acknowledgment and message resending is handled in the same way as for [camera identification](#camera_identification)
+> [!NOTE]
+> Command acknowledgment and message resending is handled in the same way as for [camera identification](#camera_identification)
 > (if a successful ACK is received the camera will expect the `CAMERA_SETTINGS` message, and repeat the cycle - up to 3 times - until it is received).
 
 To set the camera to a specific mode, the GCS would send the [MAV_CMD_SET_CAMERA_MODE](../messages/common.md#MAV_CMD_SET_CAMERA_MODE) command with the appropriate mode.
@@ -212,7 +216,8 @@ sequenceDiagram;
     Note over Camera,GCS: If MAV_RESULT_ACCEPTED, mode was changed.
 -->
 
-> **Note** The operation follows the normal [Command Protocol](../services/command.md) rules for command/acknowledgment.
+> [!NOTE]
+> The operation follows the normal [Command Protocol](../services/command.md) rules for command/acknowledgment.
 
 ### Storage Status
 
@@ -237,7 +242,8 @@ The camera immediately returns the normal command acknowledgment ([MAV_RESULT](.
 Each time an image is captured, the camera _broadcasts_ a [CAMERA_IMAGE_CAPTURED](../messages/common.md#CAMERA_IMAGE_CAPTURED) message.
 This message not only tells the GCS the image was captured, it is also intended for geo-tagging.
 
-> **Note** The camera must iterate `CAMERA_IMAGE_CAPTURED.image_index` and the counter used in `CAMERA_CAPTURE_STATUS.image_count` for every _new_ image capture (these values iterate until explicitly cleared using [MAV_CMD_STORAGE_FORMAT](#MAV_CMD_STORAGE_FORMAT)).
+> [!NOTE]
+> The camera must iterate `CAMERA_IMAGE_CAPTURED.image_index` and the counter used in `CAMERA_CAPTURE_STATUS.image_count` for every _new_ image capture (these values iterate until explicitly cleared using [MAV_CMD_STORAGE_FORMAT](#MAV_CMD_STORAGE_FORMAT)).
 > The index and total image count can be used to [re-request missing images](#missing_images) (e.g. images captured when the vehicle was out of telemetry range).
 
 The [MAV_CMD_IMAGE_STOP_CAPTURE](../messages/common.md#MAV_CMD_IMAGE_STOP_CAPTURE) command can optionally be sent to stop an image capture sequence (this is needed if image capture has been set to continue forever).
@@ -316,7 +322,8 @@ To stop recording, the GCS uses the [MAV_CMD_VIDEO_STOP_CAPTURE](../messages/com
 
 ### Video Streaming {#video_streaming}
 
-> **Note** The GCS should already have identified all connected cameras by their heartbeat and followed the [Camera Identification](#camera_identification) steps to get [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) for every camera.
+> [!NOTE]
+> The GCS should already have identified all connected cameras by their heartbeat and followed the [Camera Identification](#camera_identification) steps to get [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) for every camera.
 
 A camera is capable of streaming video if it sets the [CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM](../messages/common.md#CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM) bit set in [CAMERA_INFORMATION.flags](../messages/common.md#CAMERA_INFORMATION).
 
@@ -343,10 +350,14 @@ The steps are:
 1. GCS follows the [Camera Identification](#camera_identification) steps to get [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) for every camera.
 1. GCS checks if [CAMERA_INFORMATION.flags](../messages/common.md#CAMERA_INFORMATION) contains the [CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM](../messages/common.md#CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM) flag.
 1. If so, the GCS sends the [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) message to the camera requesting the video streaming configuration (`param1=269`) for all streams (`param2=0`).
-   > **Note** A GCS can also request information for a _particular stream_ by setting its id in `param2`.
+
+   > [!NOTE]
+   > A GCS can also request information for a _particular stream_ by setting its id in `param2`.
+
 1. Camera returns a [VIDEO_STREAM_INFORMATION](../messages/common.md#VIDEO_STREAM_INFORMATION) message for the specified stream or all streams it supports.
 
-> **Note** If your camera only provides video streaming and nothing else (no camera features), the [CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM](../messages/common.md#CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM) flag is the only flag you need to set.
+> [!NOTE]
+> If your camera only provides video streaming and nothing else (no camera features), the [CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM](../messages/common.md#CAMERA_CAP_FLAGS_HAS_VIDEO_STREAM) flag is the only flag you need to set.
 > The GCS will then provide video streaming support and skip camera control.
 
 ### Video Metadata
@@ -367,7 +378,8 @@ The [CAMERA_THERMAL_RANGE](#CAMERA_THERMAL_RANGE) message can be streamed alongs
 The message includes the associated stream and camera id, along with the position and value of the maximum and minimum temperature in the video frame.
 That is sufficient to overlay the hottest and coldest points on a video, and in theory to determine the absolute temperature of all pixels.
 
-> **Note** The message is streamed alongside the video stream, but there is no precise mechanism to synchronize values to frames.
+> [!NOTE]
+> The message is streamed alongside the video stream, but there is no precise mechanism to synchronize values to frames.
 > The information is therefore an estimate/approximate.
 
 The message can be requested for a particular camera and stream using the [MAV_CMD_SET_MESSAGE_INTERVAL](#MAV_CMD_SET_MESSAGE_INTERVAL), when the associated [VIDEO_STREAM_STATUS.flag](#VIDEO_STREAM_STATUS) for the stream has bit [VIDEO_STREAM_STATUS_FLAGS_THERMAL_RANGE_ENABLED](#VIDEO_STREAM_STATUS_FLAGS_THERMAL_RANGE_ENABLED) set.
@@ -393,7 +405,8 @@ After stopping tracking you should call `MAV_CMD_SET_MESSAGE_INTERVAL` to stop s
 
 #### Camera tracking message sequence
 
-> **Note** The GCS should already have identified all connected cameras by their heartbeat and followed the [Camera Identification](#camera_identification) steps to get [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) for every camera.
+> [!NOTE]
+> The GCS should already have identified all connected cameras by their heartbeat and followed the [Camera Identification](#camera_identification) steps to get [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION) for every camera.
 
 The sequence for tracking a point is shown below (tracking a rectangle is the same sequence but a different tracking command).
 

en/services/camera_def.md

@@ -9,18 +9,19 @@ In addition, it may contain localisations of GUI strings for display to the user
 
 At the bottom of this page, you can find a [full example](#full_example) of a _Camera Definition File_.
 
-> **Note** A _Camera Definition File_ is required because the camera options differ so greatly between cameras.
+> [!NOTE]
+> A _Camera Definition File_ is required because the camera options differ so greatly between cameras.
 > It is not reasonable to create specific MAVLink messages for each and every possible option and to tell the GCS the valid options for each camera setting.
 
 ## File Compression
 
 Camera definition files may be **.xz** compressed (this is recommended for files that are hosted on the camera component/device).
 
-> **Warning** Systems that _request_ camera definition files **must** support extraction of **.xz**-compressed definition files.
+> [!WARNING]
+> Systems that _request_ camera definition files **must** support extraction of **.xz**-compressed definition files.
 
-<span></span>
-
-> **Tip** The [Tukaani Project XZ Embedded](https://tukaani.org/xz/embedded.html) library is an easy-to-use XZ compression library for embedded systems.
+> [!TIP]
+> The [Tukaani Project XZ Embedded](https://tukaani.org/xz/embedded.html) library is an easy-to-use XZ compression library for embedded systems.
 
 ## Schema
 
@@ -49,7 +50,8 @@ They will also have a description that is displayed to the user and the set of p
 
 Parameters can be simple or quite complex, depending on the behavior they change.
 
-> **Note** The parameter `CAM_MODE` must be part of the parameter list.
+> [!NOTE]
+> The parameter `CAM_MODE` must be part of the parameter list.
 > It maps to the command [MAV_CMD_SET_CAMERA_MODE](../messages/common.md#MAV_CMD_SET_CAMERA_MODE).
 > It enables exposure of different settings based on the mode, so photo settings in photo mode and video settings in video mode.
 
@@ -109,7 +111,8 @@ The `name` field is used for display only. In other words, using the example abo
 
 _Common Parameters_ are reserved parameter names for which the GCS can build specific UI controls (if found in a camera definition).
 
-> **Note** These parameters are common to many cameras (though their valid options vary considerably).
+> [!NOTE]
+> These parameters are common to many cameras (though their valid options vary considerably).
 
 | Parameter        | Description                                                            |
 | ---------------- | ---------------------------------------------------------------------- |
@@ -307,12 +310,13 @@ When the user makes a selection, the GCS will send the new option using the [PAR
 
 When the GCS requires a current option for a given parameter, it will use the [PARAM_EXT_REQUEST_READ](../messages/common.md#PARAM_EXT_REQUEST_READ) message and it will expect in response a [PARAM_EXT_VALUE](../messages/common.md#PARAM_EXT_VALUE) message.
 
-> **Note** For more detailed information about the protocol see: [Extended Parameter Protocol](../services/parameter_ext.md).
+> [!NOTE]
+> For more detailed information about the protocol see: [Extended Parameter Protocol](../services/parameter_ext.md).
 
 ## Full Camera Definition File Example {#full_example}
 
-An example camera defintition file is listed below.
-This can be downloaded from github here: [camera_definition_example.xml](https://raw.githubusercontent.com/mavlink/mavlink-devguide/master/en/services/camera_definition_example.xml).
+An example camera definition file is listed below.
+This can be downloaded from GitHub here: [camera_definition_example.xml](https://raw.githubusercontent.com/mavlink/mavlink-devguide/master/en/services/camera_definition_example.xml).
 
 ```XML
 <?xml version="1.0" encoding="UTF-8" ?>

en/services/camera_v1.md

@@ -3,7 +3,8 @@
 The MAVLink Camera Protocol v1 defines a set of commands for configuring a camera to capture images at a particular time or distance interval, and to start/stop/pause/reset triggering.
 It also includes commands to configure/control a video camera.
 
-> **Note** This API has been superseded by [Camera Protocol v2](../services/camera.md), which provides a more natural set of commands for using a camera, along with a comprehensive API for querying camera capabilities.
+> [!NOTE]
+> This API has been superseded by [Camera Protocol v2](../services/camera.md), which provides a more natural set of commands for using a camera, along with a comprehensive API for querying camera capabilities.
 > This API is used by some older MAVLink cameras, and can be supported in parallel with the new protocol.
 
 The protocol can be used to control cameras attached to autopilot outputs or standalone MAVLink cameras that support this protocol

en/services/component_information.md

@@ -1,6 +1,7 @@
 # Component Metadata Protocol (WIP)
 
-> **Warning** This service is still marked as "work in progress", and should not be relied upon in production.
+> [!WARNING]
+> This service is still marked as "work in progress", and should not be relied upon in production.
 > It has also evolved since first created as the "Component Information Protocol".
 
 The _Component Metadata Protocol_ is a MAVLink service for requesting metadata from (and about) MAVLink components.
@@ -32,7 +33,8 @@ There is no mechanism, for example, to provide an update if the set of supported
 | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | <a id="COMP_METADATA_TYPE"></a>[COMP_METADATA_TYPE](../messages/common.md#COMP_METADATA_TYPE) | Types of component metadata supported by the protocol - e.g. general information, parameter metadata, supported commands, events, peripherals, etc. The type identifiers are used in the "general" metadata file to identify the sections that provide information about each supported type of metadata. |
 
-> **Note** [COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by thie service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
+> [!NOTE]
+> [COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by thie service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
 
 ## Component Information File Format (Schema) {#schema_files}
 
@@ -64,7 +66,8 @@ The location of these files is returned in the [COMPONENT_METADATA](#COMPONENT_M
 
 Other component information files may be hosted on either the device or on the internet.
 
-> **Note** Where permitted by memory constraints you should host component information on the device (so that it is always available and cannot get out of sync).
+> [!NOTE]
+> Where permitted by memory constraints you should host component information on the device (so that it is always available and cannot get out of sync).
 
 Files on the device are downloaded using [MAVLink FTP](../services/ftp.md).
 The URI format is defined in [MAVLink FTP URL Scheme](../services/ftp.md#mavlink-ftp-url-scheme).
@@ -84,16 +87,15 @@ It will also include [CRC32](../crc.md#crc32-algorithm) values any files that co
 
 Component information files may be **.xz** compressed (this is recommended for files that are hosted on the device).
 
-> **Note** The prototype implementation generates and compresses component information files at build time.
+> [!NOTE]
+> The prototype implementation generates and compresses component information files at build time.
 > No compression library is required within the flight stack itself.
 
-<span></span>
+> [!WARNING]
+> Systems that _request_ component information **must** support extraction of **.xz**-compressed JSON files.
 
-> **Warning** Systems that _request_ component information **must** support extraction of **.xz**-compressed JSON files.
-
-<span></span>
-
-> **Tip** The [Tukaani Project XZ Embedded](https://tukaani.org/xz/embedded.html) library is an easy-to-use XZ compression library for embedded systems and cross-platform C/C++ projects.
+> [!TIP]
+> The [Tukaani Project XZ Embedded](https://tukaani.org/xz/embedded.html) library is an easy-to-use XZ compression library for embedded systems and cross-platform C/C++ projects.
 
 ## Sequences
 
@@ -111,7 +113,8 @@ A system can query whether another component supports the protocol by sending th
 The component will respond with `COMPONENT_METADATA.uri` containing a valid URI if the protocol is supported.
 If the protocol is not supported the component will ACK that the message with `MAV_RESULT_UNSUPPORTED`, `MAV_RESULT_DENIED` or `MAV_RESULT_FAILED`, or return a `null` value in `uri`.
 
-> **Note** A component that supports this service must return a general metadata file URI _that is hosted on the vehicle_ (accessed using MAVLink FTP).
+> [!NOTE]
+> A component that supports this service must return a general metadata file URI _that is hosted on the vehicle_ (accessed using MAVLink FTP).
 
 ### Get MetaData
 
@@ -141,7 +144,8 @@ In summary:
 
 The actuators metadata allows a GCS to create a UI to configure and test actuators, and configure vehicle geometries, without having to understand anything about the underlying flight stack.
 
-> **Note** The mechanism works similarly to [camera definition files](../services/camera_def.md).
+> [!NOTE]
+> The mechanism works similarly to [camera definition files](../services/camera_def.md).
 > It can be used for flight stacks that allow outputs and geometry definition to be configured using parameters.
 > If flight stack outputs or geometries cannot be configured using parameters, the mechanism can still be used to display the current geometry and output mappings, and to test outputs.
 

en/services/events.md

@@ -1,6 +1,7 @@
 # Events Interface (WIP)
 
-> **Warning** The Events Interface is a work in progress and may change.
+> [!WARNING]
+> The Events Interface is a work in progress and may change.
 > It has an initial implementation in PX4 and QGroundControl and is planned for ArduPilot.
 >
 > The information below is just an overview.
@@ -12,7 +13,8 @@ For example, the interface might be used notifying of arming readiness, calibrat
 The interface provides for both common events that are shared by flight stacks or other components, and events that are specific to an implementation.
 MAVLink "common" events are defined in [mavlink/libevents/events/common.json](https://github.com/mavlink/libevents/blob/master/events/common.json).
 
-> **Note** The events interface is intended to replace the widespread use of [STATUSTEXT](../messages/common.md#STATUSTEXT) messages, which are not really fit for purpose.
+> [!NOTE]
+> The events interface is intended to replace the widespread use of [STATUSTEXT](../messages/common.md#STATUSTEXT) messages, which are not really fit for purpose.
 
 ## Key features
 

en/services/ftp.md

@@ -3,7 +3,8 @@
 The File Transfer Protocol (FTP) enables file transfer over MAVLink.
 It supports common FTP operations like: reading, truncating, writing, removing and creating files, listing and removing directories.
 
-> **Note** MAVLink FTP implementation closely follows the design of the original internet [FTP protocol](https://en.wikipedia.org/wiki/File_Transfer_Protocol) in terms of the message structure, sequences, and the supported opcodes/operations.
+> [!NOTE]
+> MAVLink FTP implementation closely follows the design of the original internet [FTP protocol](https://en.wikipedia.org/wiki/File_Transfer_Protocol) in terms of the message structure, sequences, and the supported opcodes/operations.
 > Developers can read the Internet protocol RFCs to understand MAVLink FTP.
 
 The protocol follows a client-server pattern, where all commands are sent by the GCS (client),
@@ -23,7 +24,8 @@ FTP (v1) is supported if the [AUTOPILOT_VERSION.capability](../messages/common.m
 
 This flag should only be set by a MAVLink component that supports the specific version of the protocol defined in this document.
 
-> **Note** The encoding and content of the `FILE_TRANSFER_PROTOCOL` payload field are not mandated by the specification, and other encoding schemes might be used, for example, in private networks.
+> [!NOTE]
+> The encoding and content of the `FILE_TRANSFER_PROTOCOL` payload field are not mandated by the specification, and other encoding schemes might be used, for example, in private networks.
 > If you have implemented a private encoding or different version you **must not** set the [MAV_PROTOCOL_CAPABILITY_FTP](../messages/common.md#MAV_PROTOCOL_CAPABILITY_FTP) flag.
 
 ## Payload Format {#payload}
@@ -32,7 +34,8 @@ The `FILE_TRANSFER_PROTOCOL` payload is encoded with the information required fo
 This includes fields for holding the command that is being sent, the sequence number of the current FTP message (for multi-message data transfers),
 the size of information in the data part of the message etc.
 
-> **Tip** Readers will note that the FTP payload format is very similar to the packet format used for serializing MAVLink itself.
+> [!TIP]
+> Readers will note that the FTP payload format is very similar to the packet format used for serializing MAVLink itself.
 
 Below is the over-the-wire format for the payload part of the [FILE_TRANSFER_PROTOCOL](../messages/common.md#FILE_TRANSFER_PROTOCOL) message on PX4/_QGroundControl_.
 
@@ -98,7 +101,8 @@ If the error code is `FailErrno`, then `data[1]` must additionally contain an er
 
 The payload `size` field must be set to either 1 or 2, depending on whether or not `FailErrno` is specified.
 
-> **Note** These are **errors**. Normally if the GCS receives an error it should not attempt to continue the FTP operation, but instead return to an idle state.
+> [!NOTE]
+> These are **errors**. Normally if the GCS receives an error it should not attempt to continue the FTP operation, but instead return to an idle state.
 
 <!--  uint8_t enum ErrorCode: https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_ftp.h -->
 
@@ -120,7 +124,8 @@ The payload `size` field must be set to either 1 or 2, depending on whether or n
 
 The GCS (client) starts a timeout after most commands are sent (these are cleared if an ACK/NAK is received).
 
-> **Note** Timeouts may not be set for some messages. For example, a timeout need not set for [ResetSessions](#ResetSessions) as the message should always succeed.
+> [!NOTE]
+> Timeouts may not be set for some messages. For example, a timeout need not set for [ResetSessions](#ResetSessions) as the message should always succeed.
 
 If a timeout activates either the command or its response is assumed to have been lost,
 and the command should be re-sent with the same sequence number etc.
@@ -144,7 +149,8 @@ After opening a file session, [ReadFile](#ReadFile) is called to request a messa
 The process is repeated at different offsets until the whole file has been retrieved.
 The file session is then closed.
 
-> **Note** [Burst reading a file](#reading-a-file-burstreadfile) is a (generally) faster alternative to this approach.
+> [!NOTE]
+> [Burst reading a file](#reading-a-file-burstreadfile) is a (generally) faster alternative to this approach.
 
 The sequence of operations for downloading (reading) a file using [ReadFile] is shown below.
 This assumes that there are no timeouts and all operations/requests succeed.
@@ -199,7 +205,8 @@ The last message in the burst is indicated by setting `burst_complete=1` (withou
 The client tracks the recieved chunks.
 On completion of the burst (or the file), if there are any missing parts of the file it can request them using either another burst or using [ReadFile](#reading-a-file-readfile).
 
-> **Note** Burst read is a (generally) faster alternative to using [ReadFile](#ReadFile) to [read a file](#reading-a-file-readfile).
+> [!NOTE]
+> Burst read is a (generally) faster alternative to using [ReadFile](#ReadFile) to [read a file](#reading-a-file-readfile).
 > This is because fewer messages are sent and need to be waited on.
 
 The sequence of operations for a burst read is shown below (assuming there are no timeouts and all operations/requests succeed).
@@ -298,7 +305,8 @@ The sequence of operations is:
 The GSC should create a timeout after `CreateFile` and `WriteFile` commands are sent, and resend the messages as needed (and [described above](#timeouts)).
 A timeout is not set for `TerminateSession` (the server may ignore failure of the command or the ACK).
 
-> **Warning** PX4 and _QGroundControl_ implement this slightly differently than outlined above.
+> [!WARNING]
+> PX4 and _QGroundControl_ implement this slightly differently than outlined above.
 > The implementation only has a single session (id=0) so only a single operation can be active at a time.
 > As a result, this operation should only be started if no other operation is active.
 > The drone expects that the session id will be set to zero by the sender of `CreateFile`.
@@ -307,7 +315,8 @@ A timeout is not set for `TerminateSession` (the server may ignore failure of th
 
 ### Remove File
 
-> **Note** `RemoveFile` handling is implemented in PX4 but not in _QGroundControl_.
+> [!NOTE]
+> `RemoveFile` handling is implemented in PX4 but not in _QGroundControl_.
 > GCS behaviour is therefore not fully defined/tested.
 
 The sequence of operations for removing a file is shown below (assuming there are no timeouts and all operations/requests succeed).
@@ -337,7 +346,8 @@ The GSC should create a timeout after the `RemoveFile` command is sent and resen
 
 The sequence of operations for truncating a file is shown below (assuming there are no timeouts and all operations/requests succeed).
 
-> **Note** `TruncateFile` handling is implemented in PX4 but not in _QGroundControl_.
+> [!NOTE]
+> `TruncateFile` handling is implemented in PX4 but not in _QGroundControl_.
 > GCS behaviour is therefore not fully defined/tested.
 
 [![Mermaid Sequence: Truncate file](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6ICBUcnVuY2F0ZUZpbGUgPGJyPiggZGF0YVswXT1wYXRoLCBzaXplPWxlbihwYXRoKSwgb2Zmc2V0PW9mZnNldCB0byB0cnVuY2F0ZSApXG4gICAgRHJvbmUtLT4-R0NTOiBBQ0soc2l6ZT0wKSIsIm1lcm1haWQiOnsidGhlbWUiOiJkZWZhdWx0In0sInVwZGF0ZUVkaXRvciI6ZmFsc2V9)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6ICBUcnVuY2F0ZUZpbGUgPGJyPiggZGF0YVswXT1wYXRoLCBzaXplPWxlbihwYXRoKSwgb2Zmc2V0PW9mZnNldCB0byB0cnVuY2F0ZSApXG4gICAgRHJvbmUtLT4-R0NTOiBBQ0soc2l6ZT0wKSIsIm1lcm1haWQiOnsidGhlbWUiOiJkZWZhdWx0In0sInVwZGF0ZUVkaXRvciI6ZmFsc2V9)
@@ -401,7 +411,10 @@ The sequence of operations is:
        For example, given five files named _TestFile1.xml_ to _TestFile5.xml_, the entries returned at offset 2 might look like: `FTestFile3.xml\t223\0FTestFile4.xml\t755568\0FTestFile5.xml\t11111\0`
      - `size` = The size of the `data`.
 1. The operation is then repeated at different offsets to download the whole directory listing.
-   > **Note** The offset for each request will depend on how many entries were returned by the previous request(s).
+
+   > [!NOTE]
+   > The offset for each request will depend on how many entries were returned by the previous request(s).
+
 1. The operation completes when the GCS requests an entry index (`offset`) greater than or equal to the number of entries.
    In this case the drone responds with a [NAK](#error_codes) containing [EOF](#EOF) (end of file).
 
@@ -438,7 +451,8 @@ The GSC should not create timeouts or handle the NAK case (other than to report
 
 ### Remove Directory
 
-> **Note** `RemoveDirectory` handling is implemented in PX4 but not in _QGroundControl_.
+> [!NOTE]
+> `RemoveDirectory` handling is implemented in PX4 but not in _QGroundControl_.
 > GCS behaviour is therefore not fully defined/tested.
 
 The sequence of operations for removing a directory is shown below (assuming there are no timeouts and all operations/requests succeed).

en/services/gimbal.md

@@ -1,6 +1,7 @@
 # Gimbal Configuration Protocol (v1)
 
-> **Warning** This service defintion has been superseded by [Gimbal Protocol v2](../services/gimbal.md) (gimbal manufacturers/GCSs/autopilots are expected to use the new API, but the old API is still in broad use, and there is no plan to for it to be removed).
+> [!WARNING]
+> This service defintion has been superseded by [Gimbal Protocol v2](../services/gimbal.md) (gimbal manufacturers/GCSs/autopilots are expected to use the new API, but the old API is still in broad use, and there is no plan to for it to be removed).
 
 The gimbal configuration message set uses a number of commands and few special-purpose messages to configure a payload mount.
 
@@ -26,7 +27,8 @@ The commands to use mavlink gimbals are
 
 To reboot or shut down a gimbal send the command [MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN](../messages/common.md#MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN). The options to be set for the gimbal are found in `param4`.
 
-> **Note** This is the same message/process as for autopilot systems.
+> [!NOTE]
+> This is the same message/process as for autopilot systems.
 
 ## Telemetry from Gimbal
 

en/services/gimbal_v2.md

@@ -1,6 +1,7 @@
 # Gimbal Protocol (v2)
 
-> **Note** This version supersedes [Gimbal Protocol v1](../services/gimbal.md)
+> [!NOTE]
+> This version supersedes [Gimbal Protocol v1](../services/gimbal.md)
 > Existing functionality is now fixed, but compatible changes may still be added.
 
 ## Introduction
@@ -13,7 +14,8 @@ It additionally provides ways to assign control to different sources.
 
 The protocol supports a number of hardware setups, and enables gimbals with varying capabilities.
 
-> **Note** The original protocol design document [can be found here](https://docs.google.com/document/d/16pekKRXLN2FhlL9YNFP983cjfBKAsDwN0gOSks8USo4/edit?usp=sharing).
+> [!NOTE]
+> The original protocol design document [can be found here](https://docs.google.com/document/d/16pekKRXLN2FhlL9YNFP983cjfBKAsDwN0gOSks8USo4/edit?usp=sharing).
 
 ## Concepts
 
@@ -28,7 +30,8 @@ The _Gimbal Manager_ and _Gimbal Device_ expose respective _message sets_ that c
 
 The key concept to understand is that a _Gimbal Manager_ has a 1:1 relationship with a particular _Gimbal Device_, and is the only party on the MAVLink network that is allowed to directly command that device - it does so using the _Gimbal Device message set_.
 
-> **Note** The _Gimbal Device_ must act only upon messages that come from the associated _Gimbal Manager_!
+> [!NOTE]
+> The _Gimbal Device_ must act only upon messages that come from the associated _Gimbal Manager_!
 > The device will however _broadcast_ its status to all parties on the network (not just its manager).
 
 MAVLink applications (ground stations, developer APIs like the MAVSDK, etc.), and any other software that wants to control a particular gimbal, must do so via its _Gimbal Manager_, using the _Gimbal Manager message set_.
@@ -139,7 +142,8 @@ For example, a companion computer with an attached gimbal would appear as two MA
 The gimbal component would identify as a type `MAV_TYPE_GIMBAL` and assert that it implements the gimbal manager protocol.
 As with autopilot-attached cameras it would need to respond as a gimbal manager, and also stream required gimbal device messages.
 
-> **Note** Implementing each attached camera as a separate MAVLink component allows cameras attached to a companion computer to be separately addressed in missions executed on the autopilot.
+> [!NOTE]
+> Implementing each attached camera as a separate MAVLink component allows cameras attached to a companion computer to be separately addressed in missions executed on the autopilot.
 
 ## Implementation and Messages
 
@@ -156,7 +160,8 @@ If the `capabilities` field of the above message(s) has the flag [MAV_PROTOCOL_C
 
 The `GIMBAL_MANAGER_INFORMATION` contains important information a particular gimbal, such as its capabilities ([GIMBAL_MANAGER_CAP_FLAGS](#GIMBAL_MANAGER_CAP_FLAGS)), maximum angles and angle rates, as well as the `gimbal_device_id` which identifies the specific gimbal device controlled by a particular _Gimbal Manager_.
 
-> **Warning** A GCS should always request `GIMBAL_MANAGER_INFORMATION` from autopilot components prior to: PX4 v1.16, ArduPilot-4.5 (when the protocol bit was added).
+> [!WARNING]
+> A GCS should always request `GIMBAL_MANAGER_INFORMATION` from autopilot components prior to: PX4 v1.16, ArduPilot-4.5 (when the protocol bit was added).
 
 #### Gimbal Manager Status
 
@@ -177,10 +182,12 @@ To be co-operative entails the following rules:
 - Check the [GIMBAL_MANAGER_STATUS](#GIMBAL_MANAGER_STATUS) about who is in control first and - if possible - warn user about planned action. For example, if the autopilot is in control of the gimbal as part of a mission, the ground station should ask the user first (i.e. via a pop-up) if they really want to take over manual control.
 - Don't forget to release control when an action/task is finished and set the sysid/compid to 0.
 
-> **Note** It is possible to assign control to another component too, not just to itself.
+> [!NOTE]
+> It is possible to assign control to another component too, not just to itself.
 > For example, a smart shot running on a companion computer can set itself to be in primary control but assign a ground station for secondary control to e.g. nudge during the smart shot.
 
-> **Note** The implementation of how primary and secondary control are combined or mixed is not defined by the protocol but up to the implementation.
+> [!NOTE]
+> The implementation of how primary and secondary control are combined or mixed is not defined by the protocol but up to the implementation.
 > This allows flexibility for different use cases.
 
 #### Manual Gimbal Control using MAVLink
@@ -278,7 +285,8 @@ The [GIMBAL_DEVICE_ATTITUDE_STATUS.flags](#GIMBAL_DEVICE_ATTITUDE_STATUS) field
 For older devices, if neither of the flags above are set, the yaw frame must be inferred from the `GIMBAL_DEVICE_FLAGS_YAW_LOCK`.
 If it is set, the yaw is relative to North, otherwise to the front of the vehicle.
 
-> **Note** Manufacturers working on new gimbal devices should set either `GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME` or `GIMBAL_DEVICE_FLAGS_YAW_IN_EARTH_FRAME`.
+> [!NOTE]
+> Manufacturers working on new gimbal devices should set either `GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME` or `GIMBAL_DEVICE_FLAGS_YAW_IN_EARTH_FRAME`.
 > Components recieving the message should also handle `GIMBAL_DEVICE_FLAGS_YAW_LOCK` for backwards compatibility with older devices.
 
 ## Message/Command/Enum Summary
@@ -416,7 +424,8 @@ In this case the gimbal manager is implemented by the autopilot which "sends" th
 
 Below is a short summary of all messages that a gimbal device should implement.
 
-> **Note** A _Gimbal Device_ can be tested by connecting it to an autopilot with a _Gimbal Manager_.
+> [!NOTE]
+> A _Gimbal Device_ can be tested by connecting it to an autopilot with a _Gimbal Manager_.
 > To avoid having to do a full setup including autopilot, a [direct test using MAVSDK](https://github.com/mavlink/MAVSDK/tree/develop/examples/gimbal_device_tester) is available.
 
 ### Messages to Send
@@ -427,7 +436,8 @@ The messages listed should be broadcast on the network/on all connections (sent
 
 Heartbeats should always be sent (usually at 1 Hz).
 
-> **Note** Gimbals that set their `sysid` from the autopilot will need to wait for the autopilot's heartbeat before emitting their own (note that if the gimbal can receive heartbeats from multiple autopilots then the `sysid` must be explicitly/statically configured).
+> [!NOTE]
+> Gimbals that set their `sysid` from the autopilot will need to wait for the autopilot's heartbeat before emitting their own (note that if the gimbal can receive heartbeats from multiple autopilots then the `sysid` must be explicitly/statically configured).
 
 - `sysid`: the same sysid as the autopilot (this can either be done by configuration, or by listening to the autopilot's heartbeat first and then copying the sysid, default: 1)
 - `compid`: [MAV_COMP_ID_GIMBAL](../messages/common.md#MAV_COMP_ID_GIMBAL)

en/services/heartbeat.md

@@ -42,7 +42,8 @@ The `HEARTBEAT` may also used by GCS (or Developer API) to determine if it **can
 For example, _QGroundControl_ will only connect to a vehicle system (i.e. not another GCS, gimbal, or onboard controller), and also checks that it has a non-zero system ID before displaying the vehicle connected message.
 QGC also uses the specific type of vehicle and other heartbeat information to control layout of the GUI.
 
-> **Note** The specific code for connecting to _QGroundControl_ can be found in [MultiVehicleManager.cc](https://github.com/mavlink/qgroundcontrol/blob/master/src/Vehicle/MultiVehicleManager.cc) (see `void MultiVehicleManager::_vehicleHeartbeatInfo`).
+> [!NOTE]
+> The specific code for connecting to _QGroundControl_ can be found in [MultiVehicleManager.cc](https://github.com/mavlink/qgroundcontrol/blob/master/src/Vehicle/MultiVehicleManager.cc) (see `void MultiVehicleManager::_vehicleHeartbeatInfo`).
 
 ## Component Identity
 
@@ -51,17 +52,20 @@ The _type_ of a component is obtained from its [`HEARTBEAT.type`](#HEARTBEAT) ([
 - A flight controller component must use a `MAV_TYPE` corresponding to a particular vehicle (e.g. `MAV_TYPE_FIXED_WING`, `MAV_TYPE_QUADROTOR` etc.), and set `HEARTBEAT.autopilot` to a valid flight stack.
 - All other components must use a `MAV_TYPE` corresponding to the actual type (e.g.: `MAV_TYPE_GIMBAL`, `MAV_TYPE_BATTERY`, etc.), and should set `HEARTBEAT.autopilot` to `MAV_AUTOPILOT_INVALID`.
 
-> **Tip** The recommended way to recognise an autopilot component is to check that `HEARTBEAT.autopilot` is not `MAV_AUTOPILOT_INVALID`.
+> [!TIP]
+> The recommended way to recognise an autopilot component is to check that `HEARTBEAT.autopilot` is not `MAV_AUTOPILOT_INVALID`.
 
 Every component must have a system-unique component id, which is used for routing and for identifying multiple instances of a particular component type.
 
-> **Warning** Historically the component id was also used to determine the component type.
+> [!WARNING]
+> Historically the component id was also used to determine the component type.
 > New code must not make any assumption about the type from the id used (type is determined from `HEARTBEAT.type`).
 
 MAVLink recommends that _by default_ components use a type-appropriate component id from [MAV_COMPONENT](../messages/common.md#MAV_COMPONENT), and provide an interface to change the component id if needed.
 For example, a camera component might use any of the [MAV_COMP_ID_CAMERA`n`](../messages/common.md#MAV_COMP_ID_GIMBAL) ids, and should not use `MAV_COMP_ID_GPS2`.
 
-> **Tip** Using type-specific component ids:
+> [!TIP]
+> Using type-specific component ids:
 >
 > - makes id clashes less likely "out of the box" (unless two components of the same type are present on the same system).
 > - reduces the impact on legacy code that determines component type from the id.

en/services/high_latency.md

@@ -20,8 +20,11 @@ Typically the initial connection with a GCS is made over a low latency link (oft
 In order to reduce traffic to the bare minimum, some of the fundamental assumptions of MAVLink are explicitly broken:
 
 - [HEARTBEAT](../messages/common.md#HEARTBEAT) messages are not emitted on the channel (either by the autopilot or GCS).
-  > **Note** The heartbeat is used to build MAVLink routing tables between channels.
+
+  > [!NOTE]
+  > The heartbeat is used to build MAVLink routing tables between channels.
   > Commands addressed specifically to the high latency component may not be routed from another channel (i.e. you can connect to the component from a GCS directly, but not via a MAVLink router).
+
 - Only the [command protocol](../services/command.md) service messages and [HIGH_LATENCY2](#HIGH_LATENCY2) message should be sent over the high latency channel.
 
 The other rules are essentially the same but there are some implications of the above changes:

en/services/image_transmission.md

@@ -1,6 +1,7 @@
 # Image Transmission Protocol
 
-> **Warning** The [Camera Protocol](../services/camera.md) and [MAVLink FTP](../services/ftp.md) are recommended for sending images, video and files.
+> [!WARNING]
+> The [Camera Protocol](../services/camera.md) and [MAVLink FTP](../services/ftp.md) are recommended for sending images, video and files.
 >
 > This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transfering small images over a low bandwidth channel from an optical flow sensor to a GCS).
 
@@ -57,7 +58,8 @@ sequenceDiagram;
    Every new image comes with a new `DATA_TRANSMISSION_HANDSHAKE` ACK packet with updated image `size`, `packets` and `payload` fields.
    After this ACK packet, the new image arrives as a series of `ENCAPSULATED_DATA` packets.
 
-   > **Note** The sequence number starts at 0 for every new image of the stream.
+   > [!NOTE]
+   > The sequence number starts at 0 for every new image of the stream.
 
 1. To stop an image stream a GSC must send a new `DATA_TRANSMISSION_HANDSHAKE` request packet, with all 0 values.
    The MAVLink node will acknowledge this by sending back `DATA_TRANSMISSION_HANDSHAKE` also containing 0 values.

en/services/landing_target.md

@@ -12,7 +12,8 @@ Radio beacons and different types of visual markers and tags are also supported.
 The message used by this protocol is [LANDING_TARGET](../messages/common.md#LANDING_TARGET).
 This is _broadcast_ by the positioning system to indicate the position of a particular target at a particular time.
 
-> **Note** The required broadcast rate depends on the landing speed and desired accuracy;
+> [!NOTE]
+> The required broadcast rate depends on the landing speed and desired accuracy;
 > start with rates between 10 Hz and 50 Hz and tune performance as needed.
 
 The original MAVLink 1 message was designed with the assumption that the target is captured from a downward facing camera, and provides fields that are relative to the captured image.
@@ -47,7 +48,8 @@ Otherwise the receiver of the message would need to know the camera field of vie
 The sizes in x and y direction are analogous (`size_x`/`size_y`).
 They describe the angle between the smallest and biggest pixel in x/y direction respectively of the target as seen in the image.
 
-> **Tip** ArduPilot supports messages with these fields if position_valid is `0`.
+> [!TIP]
+> ArduPilot supports messages with these fields if position_valid is `0`.
 
 ## Target as Position/Quaternion (MAVLink 2 and later) {#positional}
 
@@ -64,8 +66,7 @@ Field meaning and use is clear from the description.
 | type           | uint8_t  |       | [LANDING_TARGET_TYPE](../messages/common.md#LANDING_TARGET_TYPE) | Type of landing target                                                                                                                                                                                                                                                  |
 | position_valid | uint8_t  |       |                                                                  | Boolean indicating whether these position field values are populated with valid position target information (1: valid, 0: invalid). The default is '0', so that if the fields are not populated the default-zero values are not interpreted as a valid target position. |
 
-> **Tip**
->
+> [!TIP]
 > - PX4 supports this form of positioning in [MAV_FRAME_LOCAL_NED](../messages/common.md#MAV_FRAME_LOCAL_NED) (only).
 >   The original (MAVLink 1) fields are ignored.
 > - ArduPilot supports this form of positioning in [MAV_FRAME_BODY_FRD](../messages/common.md#MAV_FRAME_BODY_FRD) (only).

en/services/mavlink_id_assignment.md

@@ -22,7 +22,8 @@ The following section suggests a process to allow MAVLink components to automati
 First change the system ID of the autopilot component.
 This is usually done with a flight-stack specific parameter such as [MAV_SYS_ID](https://docs.px4.io/main/en/advanced_config/parameter_reference.html#MAV_SYS_ID) (PX4) or [SYSID_THISMAV](https://ardupilot.org/copter/docs/parameters.html#sysid-thismav-mavlink-system-id-of-this-vehicle) (ArduCopter).
 
-> **Note** [MAV_CMD_DO_SET_SYS_CMP_ID](../messages/development.md#MAV_CMD_DO_SET_SYS_CMP_ID) is a work-in-progress command for setting and changing system and command ids.
+> [!NOTE]
+> [MAV_CMD_DO_SET_SYS_CMP_ID](../messages/development.md#MAV_CMD_DO_SET_SYS_CMP_ID) is a work-in-progress command for setting and changing system and command ids.
 
 Then reboot the vehicle off-network, so that the only autopilot visible to components should be the one on the vehicle (you can disconnect your telemetry radio, for example).
 

en/services/mission.md

@@ -20,13 +20,15 @@ Mission protocol messages include the type of associated mission in the `mission
 The field takes one of the [MAV_MISSION_TYPE](../messages/common.md#MAV_MISSION_TYPE) enum values:
 [MAV_MISSION_TYPE_MISSION](../messages/common.md#MAV_MISSION_TYPE_MISSION), [MAV_MISSION_TYPE_FENCE](../messages/common.md#MAV_MISSION_TYPE_FENCE), [MAV_MISSION_TYPE_RALLY](../messages/common.md#MAV_MISSION_TYPE_RALLY).
 
-> **Note** MAVLink 1 supports only "regular" flight-plan missions (this is implied/not explicitly set).
+> [!NOTE]
+> MAVLink 1 supports only "regular" flight-plan missions (this is implied/not explicitly set).
 
 ## Mission Items (MAVLink Commands) {#mavlink_commands}
 
 Mission items for all the [mission types](#mission_types) are defined in the [MAV_CMD](../messages/common.md#mav_commands) enum.
 
-> **Note** [MAV_CMD](../messages/common.md#mav_commands) is used to define commands that can be used in missions ("mission items") and commands that can be sent outside of a mission context (using the [Command Protocol](../services/command.md)).
+> [!NOTE]
+> [MAV_CMD](../messages/common.md#mav_commands) is used to define commands that can be used in missions ("mission items") and commands that can be sent outside of a mission context (using the [Command Protocol](../services/command.md)).
 > Some `MAV_CMD` can be used with both mission and command protocols.
 > Not all commands/mission items are supported on all systems (or for all flight modes).
 
@@ -127,20 +129,19 @@ A number of local frames are also specified.
 Local frame position values that are sent in integer field parameters must be encoded as _position in meters x 1E4_ (e.g. 5m would be encoded and sent as 50000).
 If sent in messages `float` parameter fields the value should be sent as-is.
 
-> **Note** Don't use the non-INT _global frames_ in mission items (e.g. `MAV_FRAME_GLOBAL_RELATIVE_ALT`).
+> [!NOTE]
+> Don't use the non-INT _global frames_ in mission items (e.g. `MAV_FRAME_GLOBAL_RELATIVE_ALT`).
 > These are intended to be used with messages that have `float` fields for positional information, e.g.: `MISSION_ITEM` (deprecated), `COMMAND_LONG`.
 > If these frames are used, position values should be sent unencoded (i.e. no need to multiply by 1E7).
 
-<span></span>
-
-> **Note** As above, in theory if a global _non-INT_ frame variant is set for a `MISSION_ITEM_INT` the position value should be sent as-is (not encoded).
+> [!NOTE]
+> As above, in theory if a global _non-INT_ frame variant is set for a `MISSION_ITEM_INT` the position value should be sent as-is (not encoded).
 > This will result in the value being rounded when it is sent in the integer value, which will make the value unusable.
 > In practice, many systems will assume you have encoded the value, but you should test this for your particular flight stack.
 > Better just to use the correct frames!
 
-<span></span>
-
-> **Warning** Don't use [MAV_FRAME_MISSION](../messages/common.md#MAV_FRAME_MISSION) for mission items that contain positional data; this does not correspond to any particular real frame, and so will be ambiguous.
+> [!WARNING]
+> Don't use [MAV_FRAME_MISSION](../messages/common.md#MAV_FRAME_MISSION) for mission items that contain positional data; this does not correspond to any particular real frame, and so will be ambiguous.
 > `MAV_FRAME_MISSION` should be used for mission items that use params5 and param6 for other purposes.
 
 ## Param 5, 6 For Non-Positional Data
@@ -177,12 +178,12 @@ It can then monitor `MISSION_CURRENT`, and check its cached values against the c
 
 The diagram below shows the communication sequence to upload a mission to a drone (assuming all operations succeed).
 
-> **Warning** Mission update must be robust!
+> [!WARNING]
+> Mission update must be robust!
 > A new mission should be fully uploaded and accepted before the old mission is replaced/removed.
 
-<span></span>
-
-> **Note** Mission upload/download can be bandwidth intensive and time consuming
+> [!NOTE]
+> Mission upload/download can be bandwidth intensive and time consuming
 > [Check for plan changes](#detecting-missionplan-changes) before uploading (or downloading) a mission.
 
 [![Mission Upload Sequence](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IE1JU1NJT05fQ09VTlRcbiAgICBHQ1MtPj5HQ1M6IFN0YXJ0IHRpbWVvdXRcbiAgICBEcm9uZS0-PkdDUzogTUlTU0lPTl9SRVFVRVNUX0lOVCAoMClcbiAgICBEcm9uZS0-PkRyb25lOiBTdGFydCB0aW1lb3V0XG4gICAgR0NTLS0-PkRyb25lOiBNSVNTSU9OX0lURU1fSU5UICgwKVxuICAgIE5vdGUgb3ZlciBHQ1MsRHJvbmU6IC4uLiBpdGVyYXRlIHRocm91Z2ggaXRlbXMgLi4uXG4gICAgRHJvbmUtPj5HQ1M6IE1JU1NJT05fUkVRVUVTVF9JTlQgKGNvdW50LTEpXG4gICAgRHJvbmUtPj5Ecm9uZTogU3RhcnQgdGltZW91dFxuICAgIEdDUy0tPj5Ecm9uZTogTUlTU0lPTl9JVEVNX0lOVCAoY291bnQtMSlcbiAgICBEcm9uZS0-PkdDUzogTUlTU0lPTl9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IE1JU1NJT05fQ09VTlRcbiAgICBHQ1MtPj5HQ1M6IFN0YXJ0IHRpbWVvdXRcbiAgICBEcm9uZS0-PkdDUzogTUlTU0lPTl9SRVFVRVNUX0lOVCAoMClcbiAgICBEcm9uZS0-PkRyb25lOiBTdGFydCB0aW1lb3V0XG4gICAgR0NTLS0-PkRyb25lOiBNSVNTSU9OX0lURU1fSU5UICgwKVxuICAgIE5vdGUgb3ZlciBHQ1MsRHJvbmU6IC4uLiBpdGVyYXRlIHRocm91Z2ggaXRlbXMgLi4uXG4gICAgRHJvbmUtPj5HQ1M6IE1JU1NJT05fUkVRVUVTVF9JTlQgKGNvdW50LTEpXG4gICAgRHJvbmUtPj5Ecm9uZTogU3RhcnQgdGltZW91dFxuICAgIEdDUy0tPj5Ecm9uZTogTUlTU0lPTl9JVEVNX0lOVCAoY291bnQtMSlcbiAgICBEcm9uZS0-PkdDUzogTUlTU0lPTl9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)
@@ -232,7 +233,8 @@ Notes:
 
 ### Download a Mission from the Vehicle {#download_mission}
 
-> **Note** Mission upload/download can also be bandwidth intensive and time consuming.
+> [!NOTE]
+> Mission upload/download can also be bandwidth intensive and time consuming.
 > [Check for plan changes](#detecting-missionplan-changes) before downloading (or uploading) a mission.
 
 The diagram below shows the communication sequence to download a mission from a drone (assuming all operations succeed).
@@ -381,7 +383,7 @@ Note:
 
 ## Mission File Formats
 
-The _defacto_ standard file format for exchanging missions/plans is discussed in: [File Formats > Mission Plain-Text File Format](../file_formats/README.md#mission_plain_text_file).
+The _defacto_ standard file format for exchanging missions/plans is discussed in: [File Formats > Mission Plain-Text File Format](../file_formats/index.md#mission_plain_text_file).
 
 ## Mission Command Detail
 
@@ -413,7 +415,8 @@ The location and fixed-wing loiter radius parameters are common to all commands:
 The loiter time and turns are set in param 1 for the respective messages.
 The direction of loiter for `MAV_CMD_NAV_LOITER_UNLIM` can be set using `param4` (Yaw).
 
-> **Note** The remaining parameters (xtrack and heading) apply only to forward flying aircraft (not multicopters!)
+> [!NOTE]
+> The remaining parameters (xtrack and heading) apply only to forward flying aircraft (not multicopters!)
 
 Xtrack and heading define the location at which a forward flying (fixed wing) vehicle will _exit the loiter circle, and its path to the next waypoint_ (these apply only to apply to only `MAV_CMD_NAV_LOITER_TIME` and `MAV_CMD_NAV_LOITER_TURNS`).
 
@@ -502,7 +505,8 @@ Source:
 
 Mission upload, download, clearing missions, and monitoring progress are supported.
 
-> **Note** ArduPilot implements also partial mission upload using `MISSION_WRITE_PARTIAL_LIST`, but not partial mission download (`MISSION_REQUEST_PARTIAL_LIST`).
+> [!NOTE]
+> ArduPilot implements also partial mission upload using `MISSION_WRITE_PARTIAL_LIST`, but not partial mission download (`MISSION_REQUEST_PARTIAL_LIST`).
 > Partial mission upload/download is not an official/standardised part of the mission service.
 
 ArduPilot's implementation differs from this specification (non-exhaustively):

en/services/opendroneid.md

@@ -59,7 +59,8 @@ The ASTM, ASD-STAN and MAVLink messages are listed below.
 | \_                                                      | \_                       | [OPEN_DRONE_ID_ARM_STATUS](../messages/common.md#OPEN_DRONE_ID_ARM_STATUS)         | Sent by RID transmitter/receiver components to indicate that the RID system is "ready to use". This should be used as an arming condition for the flight stack. Note that this differs from the [HEARTBEAT](#heartbeat) which indicates that the component is "alive" but not necessarily ready to use.                                                                                                                                                                    |
 | \_                                                      | \_                       | [OPEN_DRONE_ID_SYSTEM_UPDATE](../messages/common.md#OPEN_DRONE_ID_SYSTEM_UPDATE)   | A subset of the [OPEN_DRONE_ID_SYSTEM](#OPEN_DRONE_ID_SYSTEM) message, containing only the fields that must be updated at a high rate. Typically sent from the GCS to provide data to the RID transmitter component. If both `OPEN_DRONE_ID_SYSTEM` and `OPEN_DRONE_ID_SYSTEM_UPDATE` are used, the more efficient `OPEN_DRONE_ID_SYSTEM_UPDATE` will be used at a high rate and the full `OPEN_DRONE_ID_SYSTEM` at a low rate, to reduce the traffic on the control link. |
 
-> **Note** The raw byte layout of the MAVLink messages is not exactly the same as what a RID Bluetooth/Wi-Fi transmitter component will broadcast over the air.
+> [!NOTE]
+> The raw byte layout of the MAVLink messages is not exactly the same as what a RID Bluetooth/Wi-Fi transmitter component will broadcast over the air.
 > Slight compression is applied.
 > Example code for this conversion can be found in the project: [Open Drone ID Core C Library](https://github.com/opendroneid/opendroneid-core-c).
 
@@ -139,7 +140,8 @@ Similarly, the autopilot must listen to the [ARM_STATUS](#OPEN_DRONE_ID_ARM_STAT
 During flight, if the arm status indicates a failure, similar action must be taken as for a lack of `HEARTBEAT` messages from the RemoteID.
 The [ARM_STATUS](#OPEN_DRONE_ID_ARM_STATUS) message must also be routed to a GCS, if present, allowing it to provide more detailed information about RemoteID arming failures.
 
-> **Note** In addition to the above, there are multiple additional different scenarios that must result in the Location status field being set to Emergency or Remote ID System Failure.
+> [!NOTE]
+> In addition to the above, there are multiple additional different scenarios that must result in the Location status field being set to Emergency or Remote ID System Failure.
 > The exact strategy on how to avoid having multiple MAVLink components overwriting each-others emergency declarations is not yet fully defined.
 > Some preliminary discussion can be found [here](https://github.com/ArduPilot/ArduRemoteID/issues/34).
 

en/services/parameter.md

@@ -37,7 +37,8 @@ Support for the parameter protocol is indicated if either [MAV_PROTOCOL_CAPABILI
 
 These protocol bits indicate different bytewise and C-style [parameter value encoding](#parameter-encoding) respectively.
 
-> **Note** The protocol may still be supported even if neither protocol bit is set.
+> [!NOTE]
+> The protocol may still be supported even if neither protocol bit is set.
 > To use the protocol in this case, a connected system would need to have prior knowledge of connected component.
 
 ## Parameter Names
@@ -105,7 +106,8 @@ A GCS or other component may choose to maintain a cache of parameter values for
 
 The cache can be populated initially by first [reading the full parameter list](#read_all) at least once, and then updated by monitoring for [PARAM_VALUE](../messages/common.md#PARAM_VALUE) messages (which are emitted whenever a parameter is [written](#write) or otherwise changed).
 
-> **Note** Cache synchronisation is not guaranteed; a component may [miss update messages](#monitoring_unreliable) due to parameter changes by other components.
+> [!NOTE]
+> Cache synchronisation is not guaranteed; a component may [miss update messages](#monitoring_unreliable) due to parameter changes by other components.
 
 ## Multi-System and Multi-Component Support
 
@@ -116,7 +118,8 @@ To get a complete parameter list from a system, send the request parameter messa
 
 All components must respond to parameter request messages addressed to their ID or the ID `MAV_COMP_ID_ALL`.
 
-> **Tip** _QGroundControl_ by default queries all components of the currently connected system (it sends ID `MAV_COMP_ID_ALL`).
+> [!TIP]
+> _QGroundControl_ by default queries all components of the currently connected system (it sends ID `MAV_COMP_ID_ALL`).
 
 ## Limitations {#limitations}
 
@@ -208,7 +211,8 @@ The sequence of operations is:
 
 The drone may restart the sequence if the `PARAM_VALUE` acknowledgment is not received within the timeout.
 
-> **Note** There is no formal way for the drone to signal when an invalid parameter is requested (i.e. for a parameter name or id that does not exist).
+> [!NOTE]
+> There is no formal way for the drone to signal when an invalid parameter is requested (i.e. for a parameter name or id that does not exist).
 > In this case the drone _should_ emit [STATUS_TEXT](../messages/common.md#STATUS_TEXT).
 > The GCS may monitor for the specific notification, but will otherwise fail the request after any timeout/resend cycle completes.
 
@@ -235,12 +239,16 @@ The sequence of operations is:
 1. GCS (client) sends [PARAM_SET](../messages/common.md#PARAM_VALUE) specifying the param name to update and its new value (also target system/component and the param type).
 1. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message).
 1. Drone writes parameter and responds by _broadcasting_ a `PARAM_VALUE` containing the updated parameter value to all components/systems.
-   > **Note** The Drone must acknowledge the `PARAM_SET` by broadcasting a `PARAM_VALUE` even if the write operation fails.
+
+   > [!NOTE]
+   > The Drone must acknowledge the `PARAM_SET` by broadcasting a `PARAM_VALUE` even if the write operation fails.
    > In this case the `PARAM_VALUE` will be the current/unchanged parameter value.
+
 1. GCS should update the [parameter cache](#parameter_caching) (if used) with the new value.
 1. The GCS may restart the sequence if the expected `PARAM_VALUE` is not received within the timeout, or if the write operation fails (the value returned in `PARAM_VALUE` does not match the value set).
 
-> **Note** The command [MAV_CMD_DO_SET_PARAMETER](../messages/common.md#MAV_CMD_DO_SET_PARAMETER) is not part of the parameter protocol.
+> [!NOTE]
+> The command [MAV_CMD_DO_SET_PARAMETER](../messages/common.md#MAV_CMD_DO_SET_PARAMETER) is not part of the parameter protocol.
 > If implemented it can be used to set the value of a parameter using the _enumeration_ of the parameter within the remote system is known (rather than the id).
 > This has no particular advantage over the parameter protocol methods.
 

en/services/parameter_ext.md

@@ -7,7 +7,8 @@ The protocol shares most of the same benefits and limitations of the original pr
 The main difference is that when [writing a parameter](#write) the system emits one or more [PARAM_EXT_ACK](#PARAM_EXT_ACK) messages (rather than [PARAM_EXT_VALUE](#PARAM_EXT_VALUE), as you would expect from the original protocol).
 This allows the _Extended Parameter Protocol_ to differentiate between the case where a write fails (or is in progress) and the case where the value update simply went missing.
 
-> **Note** The extensions were invented for the [Camera Protocol](../services/camera.md), which uses them to request/set parameter values specified in a [Camera Definition File](../services/camera_def.md).
+> [!NOTE]
+> The extensions were invented for the [Camera Protocol](../services/camera.md), which uses them to request/set parameter values specified in a [Camera Definition File](../services/camera_def.md).
 > At time of writing the protocol is supported by _QGroundControl_ for this purpose, but is not otherwise supported by flight stacks.
 
 ## Message/Enum Summary
@@ -31,7 +32,8 @@ Parameters names/ids are set in the `param_id` field of messages where they are
 The `param_id` string can store up to 16 characters.
 The string is terminated with a NULL (`\0`) character if there are less than 16 human-readable chars, and without a null termination byte if the length is exactly 16 chars.
 
-> **Note** Names (as above) are the same as for the [Parameter Protocol](../services/parameter.md#parameter_encoding).
+> [!NOTE]
+> Names (as above) are the same as for the [Parameter Protocol](../services/parameter.md#parameter_encoding).
 
 Values are byte-wise encoded _within_ the `param_value` field, which is a `char[128]`.
 The `param_type` ([MAV_PARAM_EXT_TYPE](#MAV_PARAM_EXT_TYPE)) is used to indicate the actual type of the data so that it can be decoded by the recipient.
@@ -121,7 +123,8 @@ The cache can be populated initially by first [reading the full parameter list](
 
 A system may also monitor for [PARAM_EXT_VALUE](#PARAM_EXT_VALUE) originating from other components/systems requesting parameter values.
 
-> **Note** Cache synchronisation is not guaranteed; a component may [miss parameter update messages](#monitoring_unreliable) due to changes by other components.
+> [!NOTE]
+> Cache synchronisation is not guaranteed; a component may [miss parameter update messages](#monitoring_unreliable) due to changes by other components.
 
 ## Limitations {#limitations}
 

en/services/payload.md

@@ -3,7 +3,8 @@
 MAVLink defines a number of commands for directly controlling [particular types of payloads](#payload-specific-commands) like winches and grippers, and for controlling [generic payloads](#generic-payload-commands).
 In addition there are commands for [payload placement in missions](#payload-deployment-commands).
 
-> **Note** [Camera](camera.md) and [Gimbal](gimbal_v2.md) payloads are covered in their own topics.
+> [!NOTE]
+> [Camera](camera.md) and [Gimbal](gimbal_v2.md) payloads are covered in their own topics.
 
 ## Payload-Specific Commands
 
@@ -23,7 +24,8 @@ They should be used (where supported) in preference to [generic payload commands
 MAVLink has a number of commands for setting actuator outputs.
 These can be used to control arbitrary/generic payloads.
 
-> **Tip** Use the [commands for known payload types](#payload-specific-commands) where possible as they are more intuitive for users, and in logs.
+> [!TIP]
+> Use the [commands for known payload types](#payload-specific-commands) where possible as they are more intuitive for users, and in logs.
 
 | Message                                                                                                      | Description                                                                                                                                                                                                     |
 | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -32,13 +34,14 @@ These can be used to control arbitrary/generic payloads.
 | <a id="MAV_CMD_DO_SET_RELAY"></a>[MAV_CMD_DO_SET_RELAY](../messages/common.md#MAV_CMD_DO_SET_RELAY)          | Set a specified relay instance on or off.                                                                                                                                                                       |
 | <a id="MAV_CMD_DO_REPEAT_RELAY"></a>[MAV_CMD_DO_REPEAT_RELAY](../messages/common.md#MAV_CMD_DO_REPEAT_RELAY) | Cycle a relay on and off for a desired number of cycles with a desired period.                                                                                                                                  |
 
-> **Note** **Implementations:**
-
-- `MAV_CMD_DO_SET_ACTUATOR` is more recent than `MAV_CMD_DO_SET_SERVO`, but has not yet been widely adopted.
-  - Only implemented only on PX4 (June 2021).
-    For more information see the [PX4 User Guide](https://docs.px4.io/master/en/payloads/#mission-triggering).
-- `MAV_CMD_DO_SET_SERVO` is impemented on both ArduPilot and PX4 (Missions only).
-  In both cases instance numbers map to corresponding AUX outputs.
+> [!NOTE]
+> **Implementations:**
+>
+> - `MAV_CMD_DO_SET_ACTUATOR` is more recent than `MAV_CMD_DO_SET_SERVO`, but has not yet been widely adopted.
+>  - Only implemented only on PX4 (June 2021).
+>    For more information see the [PX4 User Guide](https://docs.px4.io/master/en/payloads/#mission-triggering).
+> - `MAV_CMD_DO_SET_SERVO` is implemented on both ArduPilot and PX4 (Missions only).
+>  In both cases instance numbers map to corresponding AUX outputs.
 
 ## Payload Deployment Commands
 
@@ -48,8 +51,9 @@ These commands can be used to deploy a payload at a specfic location, controllin
 | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------- |
 | <a id="MAV_CMD_NAV_PAYLOAD_PLACE"></a>[MAV_CMD_NAV_PAYLOAD_PLACE](../messages/common.md#MAV_CMD_NAV_PAYLOAD_PLACE) | Move to target location, descend and release payload. |
 
-> **Note** **Implementations:**
-
-- [MAV_CMD_NAV_PAYLOAD_PLACE](#MAV_CMD_NAV_PAYLOAD_PLACE) is implemented in ArduPilot only, and can be used in missions.
-- [MAV_CMD_PAYLOAD_PREPARE_DEPLOY](../messages/common.md#MAV_CMD_PAYLOAD_PREPARE_DEPLOY) and [MAV_CMD_PAYLOAD_CONTROL_DEPLOY](../messages/common.md#MAV_CMD_PAYLOAD_PREPARE_DEPLOY) are not supported on any known flight stack.
-  They are deprecated and should not be used.
+> [!NOTE]
+> **Implementations:**
+>
+> - [MAV_CMD_NAV_PAYLOAD_PLACE](#MAV_CMD_NAV_PAYLOAD_PLACE) is implemented in ArduPilot only, and can be used in missions.
+> - [MAV_CMD_PAYLOAD_PREPARE_DEPLOY](../messages/common.md#MAV_CMD_PAYLOAD_PREPARE_DEPLOY) and [MAV_CMD_PAYLOAD_CONTROL_DEPLOY](../messages/common.md#MAV_CMD_PAYLOAD_PREPARE_DEPLOY) are not supported on any known flight stack.
+>  They are deprecated and should not be used.

en/services/ping.md

@@ -38,8 +38,11 @@ All ping**ed** systems should respond with another `PING` message where:
 The original ping**ing** system:
 
 - Receives a `PING` message with `target_system` and `target_component` matching its address.
-  > **Tip** Any non-zero target system/component indicates a response message.
+
+  > [!TIP]
+  > Any non-zero target system/component indicates a response message.
   > The matching ids inform the system that it is the intended recipient.
+
 - The system calculates the latency from the current system time and the time in the response `PING` for the matching sequence number.
 - A system that is sending a single `PING` can use a timeout to detect a dropped packet.
   A system that is streaming (multiple) `PING` messages should not start detecting dropped packets until after the first responses have been received (to ensure that dropped packets are not just "late").

en/services/standard_modes.md

@@ -1,6 +1,7 @@
 # Standard Modes Protocol (WIP)
 
-> **Warning** This protocol is a work in progress and may change.
+> [!WARNING]
+> This protocol is a work in progress and may change.
 > It has an initial implementation in PX4 and QGroundControl (daily).
 
 The MAVLink standard modes protocol allows a GCS to construct a UI allowing selection and display of available flight modes without prior knowledge of the connected flight stack.
@@ -132,7 +133,8 @@ This will ACK with `MAV_RESULT_ACCEPTED` if the mode can change, and `MAV_RESULT
 
 Custom modes must be set with [MAV_CMD_DO_SET_MODE](../messages/common.md#MAV_CMD_DO_SET_MODE).
 
-> **Note** If both `standard_mode` and `custom_mode` are set you can determine the mapping between modes and might therefore use [MAV_CMD_DO_SET_MODE](../messages/common.md#MAV_CMD_DO_SET_MODE) to set a standard mode.
+> [!NOTE]
+> If both `standard_mode` and `custom_mode` are set you can determine the mapping between modes and might therefore use [MAV_CMD_DO_SET_MODE](../messages/common.md#MAV_CMD_DO_SET_MODE) to set a standard mode.
 > `MAV_CMD_DO_SET_STANDARD_MODE` is preferred for setting standard modes.
 
 ### Getting Current Active Mode

en/services/terrain.md

@@ -4,7 +4,8 @@ The _Terrain Protocol_ provides a mechanism for a vehicle to get terrain informa
 
 Support for this protocol is indicated by `AUTOPILOT_VERSION.capabilities` by the [MAV_PROTOCOL_CAPABILITY_TERRAIN](../messages/common.md#MAV_PROTOCOL_CAPABILITY_TERRAIN) flag.
 
-> **Note** A vehicle that supports this capability must also support terrain following in missions using the data.
+> [!NOTE]
+> A vehicle that supports this capability must also support terrain following in missions using the data.
 > Note however that a vehicle may also support terrain handling in missions using a distance sensor, even if this protocol is not supported and capability flag is not set.
 
 ## Message/Enum Summary
@@ -59,4 +60,5 @@ In summary, the sequence is:
    If it does not have tile information for the specified location, then the request is ignored.
 1. GCS can verify that the terrain report matches a terrain check by comparing the latitude/longitude fields for both messages.
 
-> **Note** The protocol does not define how the ground station handles the case if no `TERRAIN_REPORT` is received (although it might resend the request after a timeout).
+> [!NOTE]
+> The protocol does not define how the ground station handles the case if no `TERRAIN_REPORT` is received (although it might resend the request after a timeout).

en/services/timesync.md

@@ -9,7 +9,8 @@ The original system can use this information to determine the round-trip time, a
 
 This sequence is run multiple times and filtered/averaged to reduce the transient effects of the channel and processor usage on the offset calculation.
 
-> **Note** This version replaces [Time Synchronization Protocol v1](#time-synchronization-protocol-v1).
+> [!NOTE]
+> This version replaces [Time Synchronization Protocol v1](#time-synchronization-protocol-v1).
 
 ## Message/Enum Summary
 
@@ -33,7 +34,8 @@ The sequence is:
    - determine the round trip time (by comparing its current timestamp with the original stamp that was returned in the message in `ts1`).
    - estimate the offset between system timestamps, using the round trip time and the timestamp sent back by the remote system.
 
-   > **Note** `TIMESYNC` responses to the broadcast address indicate that the remote system supports [Time Synchronization Protocol v1](#time-synchronization-protocol-v1).
+   > [!NOTE]
+   > `TIMESYNC` responses to the broadcast address indicate that the remote system supports [Time Synchronization Protocol v1](#time-synchronization-protocol-v1).
    > Synchronization may be unreliable if there are multiple sychronising components on the network (report/log an error and upgrade the remote system).
    > The component should ignore responses to all other addresses.
 
@@ -51,12 +53,12 @@ Version 1 of the timesync protocol uses the same message and sequences as versio
 The difference is the `TIMESYNC` message in version 1 did not have `target_system` and `target_component` fields, and so the message was always broadcast.
 This could result in unreliable timesync if there are multiple synchronizing components on the network, because there is no way for a component to know whether a `TIMESYNC` response is to its request.
 
-> **Note** ArduPilot encodes the system id in `TIMESYNC.ts1` of the request.
+> [!NOTE]
+> ArduPilot encodes the system id in `TIMESYNC.ts1` of the request.
 > This allows filtering of the response to a particular system (but not component), reducing the risk of clashes.
 
-<span></span>
-
-> **Note** Version 2 makes adds the target address, so a syncing system can filter on just the responses to its requests.
+> [!NOTE]
+> Version 2 makes adds the target address, so a syncing system can filter on just the responses to its requests.
 
 ## Implementations
 

en/services/traffic_management.md

@@ -12,13 +12,16 @@ There are two main traffic management systems supported by MAVLink:
 
 - [Unmanned Aircraft System Traffic Management (UTM)](https://www.faa.gov/uas/research_development/traffic_management/) - an avoidance system focussing on UAVs.
 - [Automatic Dependent Surveillance–Broadcast (ADS-B](https://en.wikipedia.org/wiki/Automatic_Dependent_Surveillance%E2%80%93Broadcast) - an avoidance system developed for manned aircraft and extended to UAVs.
-  > **Note** Flarm is a transponder-based system that integrates with MAVLink using the ADS-B messages.
 
-The two systems share sigificant overlap and have very similar messages.
+  > [!NOTE]
+  > FLARM is a transponder-based system that integrates with MAVLink using the ADS-B messages.
+
+The two systems share significant overlap and have very similar messages.
 Both have a single message that encapsulates the vehicle position and trajectory: [UTM_GLOBAL_POSITION](#UTM_GLOBAL_POSITION) and [ADSB_VEHICLE](#ADSB_VEHICLE).
 A flight controller will typically recieve these messages from the appropriate transponder or service, and may also publish them to a transponder or service.
 
-> **Note** The [Open Drone ID](https://mavlink.io/en/services/opendroneid.html) service provides additional information about vehicle identity.
+> [!NOTE]
+> The [Open Drone ID](https://mavlink.io/en/services/opendroneid.html) service provides additional information about vehicle identity.
 > This is still a "work in progress", and there are no known MAVLink implementations,
 
 ## Message/Enum Summary

en/services/trajectory.md

@@ -23,7 +23,8 @@ sequenceDiagram;
 
 When path planning is active, autopilots are expected to navigate using the most recent setpoint from the companion computer (and should have sensible behaviour if setpoints "run out").
 
-> **Note** The path planning system might send setpoints all the time, or only when a desired trajectory cannot be achieved (this depends on the specific service implementation).
+> [!NOTE]
+> The path planning system might send setpoints all the time, or only when a desired trajectory cannot be achieved (this depends on the specific service implementation).
 
 The protocol defines two messages:
 

en/services/tunnel.md

@@ -2,7 +2,8 @@
 
 The _Tunnel Protocol_ allows MAVLink to be used as a "dumb channel" to pass data in any format across, through or into a MAVLink network.
 
-> **Warning** **Tunnels use is highly discouraged**, as they lose most of the benefits of MAVLink in terms of efficiently and interoperability.
+> [!WARNING]
+> **Tunnels use is highly discouraged**, as they lose most of the benefits of MAVLink in terms of efficiently and interoperability.
 > You should almost always create "dedicated" MAVLink messages for communicating in a MAVLink system.
 
 An example where this protocol is useful is connecting a _STorM32 gimbal_ to a computer for configuration/debugging (via a USB connection to the autopilot and using MAVLink to carry the native serial protocol between it and the gimbal).
@@ -30,7 +31,8 @@ For wider distribution they should [register the payload type](#register).
 The format of the tunnel message data is indicated by the value of `TUNNEL.payload_type`.
 Vendors can register their own formats in [MAV_TUNNEL_PAYLOAD_TYPE](#MAV_TUNNEL_PAYLOAD_TYPE) by creating a PR to update the enum in [common.xml](https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/common.xml).
 
-> **Tip** If you register an enum value in **common.xml** the MAVLink toolchain will generate an error if other dialect attempts to define the same value (if the dialect includes **common.xml**).
+> [!TIP]
+> If you register an enum value in **common.xml** the MAVLink toolchain will generate an error if other dialect attempts to define the same value (if the dialect includes **common.xml**).
 
 The rules for adding new `MAV_TUNNEL_PAYLOAD_TYPE` values are:
 

index.md

@@ -0,0 +1,41 @@
+---
+layout: home
+
+hero:
+  name: "MAVLink Guide"
+  tagline: Lightweight messaging protocol for drones and onboard drone components.
+  actions:
+    - theme: brand
+      text: Introduction
+      link: /en/index.md
+    - theme: brand
+      text: Messages
+      link: /en/messages/common.md
+    - theme: brand
+      text: Services
+      link: /en/services/index.md
+    - theme: brand
+      text: Guide
+      link: /en/guide/index.md
+    - theme: brand
+      text: Contributing
+      link: /en/contributing/contributing.md
+    - theme: alt
+      text: Source code (GitHub)
+      link: https://github.com/mavlink/mavlink
+
+
+features:
+  - title: Efficient
+    details: MAVLink 2 has just 14 bytes of overhead
+  - title: Reliable
+    details: Works on high latency/noisy channels. Used in many different systems since 2009.
+  - title: Multiple languages/platforms
+    details: Multipole language support generated from XML definitions runs on numerous OS and systems 
+  - title: Many concurrent systems
+    details: Up to 255 devices on a network
+  - title: Multiple vehicles
+    details: Manage multiple vehicles and different types of vehicles
+  - title: Onboard and offboard support
+    details: Used for communication between drones, and also for integrating components in drones.
+---

package.json

@@ -0,0 +1,26 @@
+{
+  "name": "mavlink_guide",
+  "version": "1.0.1",
+  "repository": "https://github.com/mavlink/mavlink-devguide",
+  "license": "CC-BY-4.0",
+  "scripts": {
+    "docs:dev": "vitepress dev .",
+    "docs:build": "yarn docs:build_ubuntu",
+    "docs:buildwin": "set NODE_OPTIONS=--max_old_space_size=8192 && vitepress build .",
+    "docs:build_ubuntu": "NODE_OPTIONS='--max-old-space-size=8192' vitepress build .",
+    "docs:preview": "vitepress preview .",
+    "docs:sitemap": "python3 ./scripts/gen_sitemap.py",
+    "docs:gen_alt_sidebar_ubuntu": "python3 ./scripts/gen_alt_sidebar.py",
+    "docs:get_alt_sidebar_windows": "python ./scripts/gen_alt_sidebar.py",
+    "start": "yarn docs:dev",
+    "linkcheck": "markdown_link_checker_sc -d en -i assets"
+  },
+  "dependencies": {
+    "@red-asuka/vitepress-plugin-tabs": "^0.0.3",
+    "lite-youtube-embed": "^0.3.2",
+    "markdown-it-mathjax3": "^4.3.2",
+    "medium-zoom": "^1.1.0",
+    "vitepress": "^1.3.4",
+    "vue3-tabs-component": "^1.3.7"
+  }
+}

redirects.json

@@ -1,54 +0,0 @@
-{
-    "redirects": [
-
-            {
-                "from": "en/protocol/overview.html",
-                "to": "en/about/overview.html"
-            },
-            {
-                "from": "en/protocol/heartbeat.html",
-                "to": "en/services/heartbeat.html"
-            },
-            {
-                "from": "en/protocol/mission.html",
-                "to": "en/services/mission.html"
-            },
-            {
-                "from": "en/protocol/parameter.html",
-                "to": "en/services/parameter.html"
-            },
-            {
-                "from": "en/protocol/command.html",
-                "to": "en/services/command.html"
-            },
-            {
-                "from": "en/protocol/camera.html",
-                "to": "en/services/camera.html"
-            },
-            {
-                "from": "en/protocol/camera_def.html",
-                "to": "en/services/camera_def.html"
-            },
-            {
-                "from": "en/protocol/gimbal.html",
-                "to": "en/services/gimbal.html"
-            },
-            {
-                "from": "en/protocol/arm_authorization.html",
-                "to": "en/services/arm_authorization.html"
-            },
-            {
-                "from": "en/protocol/image_transmission.html",
-                "to": "en/services/image_transmission.html"
-            },
-            {
-                "from": "en/protocol/ftp.html",
-                "to": "en/services/ftp.html"
-            },
-            {
-                "from": "en/protocol/landing_target.html",
-                "to": "en/services/landing_target.html"
-            }
-
-        ]
-}