Fix notes tips warnings in docs (#2501)

* fix notes

* Fix tips

* Fix warning

* catch a few outliers

docs/en/cpp/api_changes.md

@@ -17,7 +17,9 @@ Individual parts of the number are iterated when the:
 
 This means that breaking changes to the API result in a bump of the major version number (e.g. 1.4.3 to 2.0.0).
 
-> **note**: bumping of the major version is unrelated to the stability of the library. E.g. v2.0.0 is not by definition more stable than v1.4.18. It just means that the API has changed with v2. As development is carried on, stability is likely increasing whenever the minor or patch versions increase as incremental fixes are added.
+::: info
+Bumping of the major version is unrelated to the stability of the library. E.g. v2.0.0 is not by definition more stable than v1.4.18. It just means that the API has changed with v2. As development is carried on, stability is likely increasing whenever the minor or patch versions increase as incremental fixes are added.
+:::
 
 ## v2
 
@@ -37,8 +39,9 @@ New instantiation:
 Mavsdk mavsdk{Mavsdk::Configuration{Mavsdk::ComponentType::GroundStation}};
 ```
 
-**Note:**
+::: info
 It is still possible to change the configuration later (although not recommended) using `Mavsdk::set_configuration(...)`.
+:::
 
 **Rationale:**
 
@@ -48,9 +51,9 @@ For instance, in the case where MAVSDK is used on the companion computer, the au
 
 Also, having to set the default makes it less likely to misconfigure the overall integration and end up with several components that conflict.
 
-**Note:**
+::: info
 It is also possible to set the sysid/compid directly, just check out the API of [Mavsdk::Configuration](cpp/api_reference/classmavsdk_1_1_mavsdk_1_1_configuration.md).
-
+:::
 
 ### Subscription API
 

docs/en/cpp/contributing/documentation.md

@@ -4,7 +4,9 @@ Making quick fixes to existing text or raising issues is very easy.
 More complicated changes will require you to set up the [Gitbook toolchain](https://github.com/GitbookIO/gitbook/blob/master/docs/setup.md).
 If you want to help, [get in touch](../../index.md#getting-help).
 
-> **Tip** You will need a [Github](https://github.com/) login to make and submit changes to this guide.
+::: tip
+You will need a [Github](https://github.com/) login to make and submit changes to this guide.
+:::
 
 ## Overview
 

docs/en/cpp/contributing/plugins.md

@@ -122,10 +122,12 @@ message SetReturnToLaunchAltitudeResponse {
 }
 ```
 
-> **Note** Requests can defined SYNC, ASYNC, or BOTH using `option (mavsdk.options.async_type) = ...;`.
-  The choice depends on the functionality that is being implemented and how it would generally be used.
-  There are no hard rules, it's something that makes sense to be discussed one by one in a pull request.
-  The default implementation is `BOTH`.
+::: info
+Requests can defined SYNC, ASYNC, or BOTH using `option (mavsdk.options.async_type) = ...;`.
+The choice depends on the functionality that is being implemented and how it would generally be used.
+There are no hard rules, it's something that makes sense to be discussed one by one in a pull request.
+The default implementation is `BOTH`.
+:::
 
 #### Subscriptions:
 
@@ -144,11 +146,15 @@ message PositionResponse {
 }
 ```
 
-> **Note** Subscriptions also can defined SYNC, ASYNC, or BOTH using `option (mavsdk.options.async_type) = ...;`.
-  The sync implementation of a subscription is just a getter for the last received value.
+::: info
+Subscriptions also can defined SYNC, ASYNC, or BOTH using `option (mavsdk.options.async_type) = ...;`.
+The sync implementation of a subscription is just a getter for the last received value.
+:::
 
-> **Note** Subscriptions can be defined finite using `option (mavsdk.options.is_finite) = true;`.
-  This means that the stream of messages will end at some point instead of continuing indefinitely. An example would be progress updates about a calibration which eventually finishes.
+::: info
+Subscriptions can be defined finite using `option (mavsdk.options.is_finite) = true;`.
+This means that the stream of messages will end at some point instead of continuing indefinitely. An example would be progress updates about a calibration which eventually finishes.
+:::
 
 ### Add API to proto
 
@@ -191,10 +197,12 @@ Once the proto file has been created, you can generate all files required for th
    tools/fix_style.sh .
    ```
 
-> **Note** the files `my_new_plugin.h` and `my_new_plugin.cpp` are generated and overwritten every time the script is run.
-  However, the files `my_new_plugin_impl.h` and `my_new_plugin_impl.cpp` are only generated once.
-  To re-generate them, delete them and run the script again.
-  This approach is used to prevent the script from overwriting your local changes.
+::: info
+The files `my_new_plugin.h` and `my_new_plugin.cpp` are generated and overwritten every time the script is run.
+However, the files `my_new_plugin_impl.h` and `my_new_plugin_impl.cpp` are only generated once.
+To re-generate them, delete them and run the script again.
+This approach is used to prevent the script from overwriting your local changes.
+:::
 
 ### Actually implement MAVLink messages
 
@@ -277,7 +285,9 @@ Most of the existing plugins do not have unit tests,
 because we do not yet have the ability to [mock MAVLink communications](https://github.com/mavlink/MAVSDK/issues/148) (needed to test most plugins).
 Unit tests are therefore considered optional!
 
-> **Tip** Comprehensive integration tests should be written instead, with the simulator providing appropriate MAVLink messages.
+::: tip
+Comprehensive integration tests should be written instead, with the simulator providing appropriate MAVLink messages.
+:::
 
 #### Adding Unit Tests {#adding_unit_tests}
 
@@ -308,9 +318,9 @@ All tests in a file should share the same test-case name (the first argument to
 
 MAVSDK provides the `integration_tests_runner` application for running the integration tests and some helper code to make it easier to log tests and run them against the simulator.
 
-> **Tip** Check out the [Google Test Primer](https://google.github.io/googletest/primer.html)
-> and the [integration_tests](https://github.com/mavlink/MAVSDK/tree/main/src/integration_tests)
-> for our existing plugins to better understand how to write your own!
+::: tip
+Check out the [Google Test Primer](https://google.github.io/googletest/primer.html) and the [integration_tests](https://github.com/mavlink/MAVSDK/tree/main/src/integration_tests) for our existing plugins to better understand how to write your own!
+:::
 
 
 #### Adding Integration Tests
@@ -342,15 +352,19 @@ add_executable(integration_tests_runner
 The main MAVSDK-specific functionality is provided by [integration_test_helper.h](https://github.com/mavlink/MAVSDK/blob/main/src/integration_tests/integration_test_helper.h).
 This provides access to the [Plugin/Test Logger](../guide/dev_logging.md) and a shared test class `SitlTest` for setting up and tearing down the PX4 simulator.
 
-> **Note** All tests running against SITL can be declared using `TEST_F` and have a first argument `SitlTest` as shown.
-  This is required in order to use the shared class to set up and tear down the simulator between tests.
+::: info
+All tests running against SITL can be declared using `TEST_F` and have a first argument `SitlTest` as shown.
+This is required in order to use the shared class to set up and tear down the simulator between tests.
+:::
 
 For reference inspect the [existing integration tests](https://github.com/mavlink/MAVSDK/blob/main/src/integration_tests).
 
 ## Example Code
 
-> **Note** It is quicker and easier to write and modify [integration tests](#integration_tests) than examples.
-> Do not write example code until the plugin has been accepted!
+::: info
+It is quicker and easier to write and modify [integration tests](#integration_tests) than examples.
+Do not write example code until the plugin has been accepted!
+:::
 
 A simple example should be written that demonstrates basic usage of its API by 3rd parties.
 The example need not cover all functionality, but should demonstrate enough that developers can see how it is used and how the example might be extended.
@@ -364,8 +378,10 @@ Where possible examples should demonstrate realistic use cases such that the cod
 
 The public API must be fully documented using the proto files.
 
-> **Tip** The in-source comments will be compiled to markdown and included in the [API Reference](../api_reference/index.md).
-> The process is outlined in [Documentation > API Reference](documentation.md#api-reference).
+::: tip
+The in-source comments will be compiled to markdown and included in the [API Reference](../api_reference/index.md).
+The process is outlined in [Documentation > API Reference](documentation.md#api-reference).
+:::
 
 Internal/implementation classes need not be documented, but should be written using expressive naming of variables and functions to help the reader.
 Anything unexpected or special however warrants an explanation as a comment.

docs/en/cpp/contributing/release.md

@@ -2,7 +2,9 @@
 
 These are the instructions on how to get a release out the door.
 
-> **Note** The idea is of course to automate this as much as possible!
+::: info
+The idea is of course to automate this as much as possible!
+:::
 
 ## MAVSDK part
 

docs/en/cpp/examples/autopilot_server.md

@@ -3,8 +3,10 @@
 The [Autopilot Server](https://github.com/mavlink/MAVSDK/tree/main/examples/autopilot_server) example creates two instances of MAVSDK, representing a client (GCS) and a server (Vehicle).
 The MAVSDK instances communicates with each other via UDP transmitting telemetry, publishing parameters, missions and takeoff commands.
 
-> **Note** This example shows how to use [MAVSDK Server Plugins](../server_plugins.md)!
-> This is a good starting point if you are looking to implement MAVLink services to a non-MAVLink compatible system.
+::: info
+This example shows how to use [MAVSDK Server Plugins](../server_plugins.md)!
+This is a good starting point if you are looking to implement MAVLink services to a non-MAVLink compatible system.
+:::
 
 
 ## Running the Example {#run_example}
@@ -13,8 +15,10 @@ The example is built and run in the normal way ([as described here](../examples/
 
 The example terminal output should be similar to that shown below:
 
-> **Note** This is from a debug build of the SDK.
-  A release build will omit the "Debug" messages.
+::: info
+This is from a debug build of the SDK.
+A release build will omit the "Debug" messages.
+:::
 
 ```
 $ ./autopilot_server

docs/en/cpp/examples/fly_mission.md

@@ -11,8 +11,10 @@ The example is built and run in the normal way ([as described here](../examples/
 
 The example terminal output should be similar to that shown below:
 
-> **Note** This is from a debug build of the SDK.
-  A release build will omit the "Debug" messages.
+::: info
+This is from a debug build of the SDK.
+A release build will omit the "Debug" messages.
+:::
 
 ```
 $ ./fly_mission udp://:14540

docs/en/cpp/examples/follow_me.md

@@ -5,9 +5,11 @@ It shows how to send the drone both the current position of the target (`FollowM
 
 ![Follow Me QGC Screenshot](../../../assets/examples/follow_me/follow_me_example_qgc.jpg)
 
-> **Note** A real application using this API will get the position information from the underlying operating system.
-  The example uses a fake position source (`FakeLocationProvider`) to enable it to be run on computers that do not have position information.
-  The `FakeLocationProvider` emulates the typical usage of common positioning APIs used in Android, Linux and iPhone.
+::: info
+A real application using this API will get the position information from the underlying operating system.
+The example uses a fake position source (`FakeLocationProvider`) to enable it to be run on computers that do not have position information.
+The `FakeLocationProvider` emulates the typical usage of common positioning APIs used in Android, Linux and iPhone.
+:::
 
 
 ## Running the Example {#run_example}
@@ -25,8 +27,10 @@ Otherwise the example is built and run in the normal way ([as described here](..
 
 The example terminal output should be similar to that shown below:
 
-> **Note** This is from a debug build of the SDK.
-  A release build will omit the "Debug" messages.
+::: info
+This is from a debug build of the SDK.
+A release build will omit the "Debug" messages.
+:::
 
 ```
 $ ./follow_me udp://:14540

docs/en/cpp/examples/index.md

@@ -1,6 +1,8 @@
 # C++ Examples
 
-> **Tip** Information about *writing* example code is covered in the [Contributing > Writing Plugins](../contributing/plugins.md) (*plugin developers* should initially create [integration tests](../contributing/plugins.md#integration_tests) rather than examples for new code).
+::: tip
+Information about *writing* example code is covered in the [Contributing > Writing Plugins](../contributing/plugins.md) (*plugin developers* should initially create [integration tests](../contributing/plugins.md#integration_tests) rather than examples for new code).
+:::
 
 This section contains examples showing how to use MAVSDK.
 
@@ -23,25 +25,31 @@ Example | Description
 
 The examples are "largely" built and run in the same way, as described in the following section (any exceptions are covered in the page for the associated example).
 
-> **Warning** Some of the examples define flight behaviour relative to the default home position in the simulator (e.g. [Fly Mission](../examples/fly_mission.md)).
-  Care should be taken if using them on a real vehicle.
+::: warning
+Some of the examples define flight behaviour relative to the default home position in the simulator (e.g. [Fly Mission](../examples/fly_mission.md)).
+Care should be taken if using them on a real vehicle.
+:::
 
 ## Trying the Examples {#trying_the_examples}
 
 The easiest way to test the examples is to use a [simulated PX4 vehicle](https://docs.px4.io/master/en/simulation/) that is running on the same computer.
 First start PX4 in SITL (Simulation), optionally start *QGroundControl* to observe the vehicle, then build and run the example code.
 
-> **Note** The simulator broadcasts to the standard PX4 UDP port for connecting to offboard APIs (14540).
-  The examples connect to this port using either [add_any_connection()](../api_reference/classmavsdk_1_1_mavsdk.md#classmavsdk_1_1_mavsdk_1a405041a5043c610c86540de090626d97) or [add_udp_connection()](../api_reference/classmavsdk_1_1_mavsdk.md#classmavsdk_1_1_mavsdk_1aa43dfb00d5118d26ae5aabd0f9ba56b2).
+::: info
+The simulator broadcasts to the standard PX4 UDP port for connecting to offboard APIs (14540).
+The examples connect to this port using either [add_any_connection()](../api_reference/classmavsdk_1_1_mavsdk.md#classmavsdk_1_1_mavsdk_1a405041a5043c610c86540de090626d97) or [add_udp_connection()](../api_reference/classmavsdk_1_1_mavsdk.md#classmavsdk_1_1_mavsdk_1aa43dfb00d5118d26ae5aabd0f9ba56b2).
+:::
 
 
 ### Setting up a Simulator
 
 PX4 supports a [number of simulators](https://docs.px4.io/master/en/simulation/).
 In order to set up the [jMAVSim](https://docs.px4.io/master/en/simulation/jmavsim.html) or [Gazebo](https://docs.px4.io/master/en/simulation/gazebo.html) simulator, you can simply follow the standard PX4 toolchain setup instructions for [macOS](https://docs.px4.io/master/en/dev_setup/dev_env_mac.html) or [Ubuntu Linux](https://docs.px4.io/master/en/dev_setup/dev_env_linux_ubuntu.html).
 
-> **Note** JMAVSim can only be used to simulate multicopters.
-  Gazebo additionally supports a number of [other vehicles](https://docs.px4.io/master/en/simulation/gazebo.html#html#running-the-simulation) (e.g. VTOL, Rovers, fixed-wing etc.).
+::: info
+JMAVSim can only be used to simulate multicopters.
+Gazebo additionally supports a number of [other vehicles](https://docs.px4.io/master/en/simulation/gazebo.html#html#running-the-simulation) (e.g. VTOL, Rovers, fixed-wing etc.).
+:::
 
 After running a standard installation, a simulation can be started from the PX4 **/Firmware** directory using the command:
 * Multicopter (jMAVSim): `make px4_sitl jmavsim`
@@ -71,10 +79,13 @@ cmake -Bbuild -H.
 cmake --build build -j4
 ```
 
-> **Note** if MAVSDK is installed locally (e.g. on Windows) you need to pass the location to cmake:
-> ```
-> cmake -Bbuild -DCMAKE_PREFIX_PATH=wherever_mavsdk_is_locally_installed
-> ```
+::: info
+if MAVSDK is installed locally (e.g. on Windows) you need to pass the location to cmake:
+
+```
+cmake -Bbuild -DCMAKE_PREFIX_PATH=wherever_mavsdk_is_locally_installed
+```
+:::
 
 ### Running the Examples {#running_the_examples}
 
@@ -91,8 +102,10 @@ For Windows you would run the following (from the **\build\Debug\** directory):
 build\Debug\takeoff_and_land.exe udp://:14540
 ```
 
-> **Tip** Most examples will create a binary with the same name as the example.
-> The name that is used is specified in the **CMakeLists.txt** file as the first value in the call to `add_executable()`.
+::: tip
+Most examples will create a binary with the same name as the example.
+The name that is used is specified in the **CMakeLists.txt** file as the first value in the call to `add_executable()`.
+:::
 
 If you have already started the simulation the example code should connect to PX4,
 and you will be able to observe behaviour through the SDK terminal, SITL terminal, and/or *QGroundControl*.

docs/en/cpp/examples/offboard_velocity.md

@@ -11,8 +11,10 @@ The example is built and run [as described here](../examples/index.md#trying_the
 
 The example terminal output should be similar to that shown below:
 
-> **Note** This is from a debug build of the SDK.
-  A release build will omit the "Debug" messages.
+::: info
+This is from a debug build of the SDK.
+A release build will omit the "Debug" messages.
+:::
 
 ```
 $ ./offboard udp://:14540

docs/en/cpp/examples/takeoff_and_land.md

@@ -6,16 +6,20 @@ It sets up a UDP connection, waits for a vehicle (system) to appear, arms it, an
 After a short wait the vehicle lands.
 While flying the vehicle receives telemetry. The example is implemented in C++ (only).
 
-> **Tip** The full source code for the example [can be found here](https://github.com/mavlink/MAVSDK/tree/main/examples/takeoff_land).
+::: tip
+The full source code for the example [can be found here](https://github.com/mavlink/MAVSDK/tree/main/examples/takeoff_land).
+:::
 
 ## Running the Example {#run_example}
 
 The example is built and run [as described here](../examples/index.md#trying_the_examples) (the standard way).
 
 The example terminal output should be similar to that shown below:
 
-> **Note** This is from a debug build of the SDK.
-  A release build will omit the "Debug" messages.
+::: info
+This is from a debug build of the SDK.
+A release build will omit the "Debug" messages.
+:::
 
 ```sh
 $ ./takeoff_and_land udp://:14540
@@ -57,7 +61,9 @@ Finished...
 
 ## Source code {#source_code}
 
-> **Tip** The full source code for the example [can be found on Github here](https://github.com/mavlink/MAVSDK/tree/main/examples/takeoff_and_land).
+::: tip
+The full source code for the example [can be found on Github here](https://github.com/mavlink/MAVSDK/tree/main/examples/takeoff_and_land).
+:::
 
 - [CMakeLists.txt](https://github.com/mavlink/MAVSDK/blob/main/examples/takeoff_and_land/CMakeLists.txt)
 - [takeoff_and_land.cpp](https://github.com/mavlink/MAVSDK/blob/main/examples/takeoff_and_land/takeoff_and_land.cpp)

docs/en/cpp/examples/transition_vtol_fixed_wing.md

@@ -10,8 +10,10 @@ This example shows how you can use the SDK [Action](../api_reference/classmavsdk
 The example must be run against a VTOL aircraft (simulated or otherwise).
 Otherwise the example is built and run [in the standard way](../examples/index.md#trying_the_examples).
 
-> **Tip** Instructions for running the Gazebo simulator for a standard VTOL can be found here: [PX4 Development Guide > Gazebo Simulation](https://docs.px4.io/master/en/simulation/gazebo.html#standard-vtol).
-  jMAVSim does not support VTOL simulation.
+::: tip
+Instructions for running the Gazebo simulator for a standard VTOL can be found here: [PX4 Development Guide > Gazebo Simulation](https://docs.px4.io/master/en/simulation/gazebo.html#standard-vtol).
+jMAVSim does not support VTOL simulation.
+:::
 
 The example terminal output for a debug build of the SDK should be similar to that shown below (a release build will omit the "Debug" messages):