Merge branch 'feature/doc_theme' of https://github.com/microROS/microros.github.io into feature/doc_theme

Author: iluetkeb

_data/authors.yml

@@ -1,2 +1,2 @@
-lui3si:
-  twitter: ingoluetkebohle
+iluetkeb:
+  twitter: ingoluetkebohle

_docs/FIROS2/index.md

@@ -1,13 +1,13 @@
 ---
-title: micro-ROS & FIWARE
+title: microROS & FIWARE
 permalink: /docs/FIROS2/
 redirect_from: /FIROS2/
 ---
 
 
 ## Interoperability
 
-This subsection will explain all the design alternatives for the interoperability of FIROS2 with micro-ROS.
+This subsection will explain all the design alternatives for the interoperability of FIROS2 with microROS.
 
 ### Mechanisms for the deserialisation of incoming data in the transformation library
 
@@ -25,7 +25,7 @@ For solving this issue, various methods to get it are proposed:
 
 #### Use serialisation/deserialisation method provided by the middleware layer
 
-This is currently the method used in micro-ROS - FIROS 2 integration.
+This is currently the method used in microROS - FIROS 2 integration.
 
 In this case, the transformation library will use user selected middleware interface to serialise/deserialise the bridged ROS2 messages.
 This method requires to get the message typesupport for the bridged message type.
@@ -63,25 +63,25 @@ Note the call to ROS 2 interface __rosidl_typesupport_cpp::get_message_type_supp
 #### Use serialisation/deserialisation method for an specific type support
 
 In this case, the transformation library will use one specific type support to serialise/deserialise the bridged ROS2 messages.
-In micro-ROS case, the implementation to be used will be rosidl_typesupport_microxrcedds.
+In microROS case, the implementation to be used will be rosidl_typesupport_microxrcedds.
 This method is trivial to develop as it does not require additional source code on the micro-ROS side.
 
-In the case of micro-ROS, the transformation library should use the serialisation/deserialisation API exposed by its typesupport, rosidl_typesupport_microxrcedds.
+In the case of microROS, the transformation library should use the serialisation/deserialisation API exposed by its typesupport, rosidl_typesupport_microxrcedds.
 This mechanism requires the user to have access to the typesupport API, which sometimes is not always possible.
 
 #### Used serialisation/deserialisation method generated from IDL file
 
 In this case, transformation library will use generated code to serialise/deserialise the bridged ROS2 messages.
 The generated code may be made using an IDL parser tool.
-In the micro-ROS case, Micro XRCE-DDS provides with Micro XRCE-DDS code generator, which accepts an IDL file as input and generates type code.
+In the microROS case, Micro XRCE-DDS provides with Micro XRCE-DDS code generator, which accepts an IDL file as input and generates type code.
 This IDL files should correspond with those messages types the transformation is wanted.
 This is the [integration service](https://github.com/eProsima/Integration-Service) native method.
 Integration services uses this method, but it makes the development of the library slower as it needs to be generated per each message to be bridged.
 
 ![image](http://www.plantuml.com/plantuml/svg/bP8_2y8m4CNtV8f7tOIArd-R2DR1GGTT70eIqciRQ1D8qkzl4sr1iA0t11xlxjsF97lhk75jKxEQ2WUdOMHPEUJIa71IAwPqJeZGLQOoTPR2QDolXsESfZS8RvQao72dZM_mZH6unIbzB32XENN52baF8GrPoql20ZAluPtFgGIiGv855mvHfcwwDO9UcmfjC8ptsp2TYH1Z1rtrEbDzwX9V8P8HYDLl4Cb_4Ell49SHYCrl49V_8BPWZ8LxZkFTwvbOEDzo6UHgn5q7kHbnk-mzgTp_foS0)
 
-In the case of ROS2/micro-ROS workspaces, there are tools which generate those IDL files.
-The rosidl_gen package is the package micro-ROS/ROS2 could use to create IDL from ROS2 interfaces.
+In the case of ROS2/microROS workspaces, there are tools which generate those IDL files.
+The rosidl_gen package is the package microROS/ROS2 could use to create IDL from ROS2 interfaces.
 
 ### Integration proposals
 
@@ -90,7 +90,7 @@ This section presents all the integrations possibilities.
 
 #### Direct integration
 
-In this case, micro-ROS Agent will act as a bridge between DDS-XRCE and NGSIv2.
+In this case, microROS Agent will act as a bridge between DDS-XRCE and NGSIv2.
 
 Selected bridged topics and their corresponding transformations must be configured on the micro-ROS Agent node.
 
@@ -106,7 +106,7 @@ This proposal requires micro-ROS Agent changes, but it is the direct native inte
 
 #### Indirect integration with a single FIROS2 node
 
-In this case, micro-ROS nodes will publish the configured topics on DDS, and a FIROS2 node will subscribe to those topics and convert them into NGSIv2 protocol.
+In this case, microROS nodes will publish the configured topics on DDS, and a FIROS2 node will subscribe to those topics and convert them into NGSIv2 protocol.
 Selected bridged topics must be configured on that single FIROS2 node.
 Each ROS 2 topic type should have a corresponding transformation library configured on that FIROS2 node.
 
@@ -124,11 +124,11 @@ This proposal requires transformation library development, but the integration w
 
 #### Indirect integration with multiple FIROS2 nodes
 
-In this case, micro-ROS nodes will publish the configured topic on DDS and multiple FIROS2 nodes, one for each set topic, will subscribe to those topics and convert them into NGSIv2 protocol.
+In this case, microROS nodes will publish the configured topic on DDS and multiple FIROS2 nodes, one for each set topic, will subscribe to those topics and convert them into NGSIv2 protocol.
 
 This approach would require more nodes on the network and individual configurations.
 
-This approach is the one followed by micro-ROS, and it is limited due to current FIROS 2 implementation.
+This approach is the one followed by microROS, and it is limited due to current FIROS 2 implementation.
 
 This proposal requires transformation library development, but the integration will be the same as a regular ROS2 node, so no micro-ROS specific development should be expected.
 
@@ -142,7 +142,7 @@ This proposal requires transformation library development, but the integration w
 
 ## Demonstration
 
-This section explains how to demonstrate the interoperability of FIROS2 with Micro-ROS.
+This section explains how to demonstrate the interoperability of FIROS2 with microROS.
 The purpose is to demonstrate the interoperability, although the final design is not closed.
 
 To run the demonstration a step by step guide is presented in this document.
@@ -233,7 +233,7 @@ docker pull microros/client_linux
 docker run  -it --rm  --privileged --net=host microros/client_linux
 ```
 
-Once in the docker run the micro-ROS Client.
+Once in the docker run the microROS Client.
 
 ```shell
 int32_publisher_c
@@ -271,4 +271,4 @@ In a Linux terminal execute the below sub-shell script
 )
 ```
 
-For further information please refer to the official FIROS2 documentation: [FIROS2 documentation](https://github.com/eProsima/FIROS2)
+For further information please refer to the official FIROS2 documentation: [FIROS2 documentation](https://github.com/eProsima/FIROS2)

_docs/index.md

@@ -3,21 +3,20 @@ permalink: /docs/home/
 title: Overview
 ---
 
-[micro-ROS](https://cordis.europa.eu/project/rcn/213167_en.html) puts ROS2 onto microcontrollers, making them first class participants of the ROS 2 environment.
+[microROS](https://cordis.europa.eu/project/rcn/213167_en.html) puts ROS2 onto microcontrollers, making them first class participants of the ROS 2 environment.
 
 ## Tutorials
 
 See [Tutorial List](/docs/tutorials/).
 
 ## Architecture
 
-We're basically following the ROS2 architecture and make use of its middleware pluggability to use DDS-XRCE, which is suitable for micro-controllers. Moreover, we use an RTOS (NuttX) instead of Linux. On micro-controllers many different RTOS's are used, so we also add an RTOS abstraction layer (AL), to make porting to other RTOS possible.
+We're basically following the ROS2 architecture and make use of its middleware pluggability to use [DDS-XRCE](https://www.omg.org/spec/DDS-XRCE/), which is suitable for microcontrollers. Moreover, we use an RTOS (NuttX) instead of Linux. On microcontrollers many different RTOS's are used, so we also add an RTOS abstraction layer (AL), to make porting to other RTOS possible.
 
 ![](/img/micro-ROS_architecture.png)
 
 ## Concept Documentation
 
- - Library to support the implementation of language-specific ROS Client Libraries: [rcl](https://github.com/microROS/rcl)
  - Predictable scheduling and execution:  [real-time_executor](real-time_executor/)
  - System modes and system hierarchy: [system_modes](system_modes/)
  - Embedded transform (tf) library: [embedded_tf](embedded_tf/)
@@ -28,7 +27,7 @@ We're basically following the ROS2 architecture and make use of its middleware p
 ## Source Code Repositories
 
  - Middleware
-  -  RMW layer [rmw-microxrcedds](https://github.com/microROS/rmw-microxrcedds)
+  -  RMW adapter for Micro-XRCE-DDS [rmw-microxrcedds](https://github.com/microROS/rmw-microxrcedds)
   - Type Support [rosidl_typesupport_microxrcedds](https://github.com/microROS/rosidl_typesupport_microxrcedds)
   - "Agent" (bridge) [micro-ROS-Agent](https://github.com/microROS/micro-ROS-Agent)
  - RTOS