Addressed changes suggested by Ralph in PR #261

FranFin · FranFin · commit 168dbd049cdc · 2020-12-22T16:03:41.000+01:00
diff --git a/_docs/concepts/rtos/comparison/index.md b/_docs/concepts/rtos/comparison/index.md
@@ -5,13 +5,13 @@ permalink: /docs/concepts/rtos/comparison/
 
 In this section, we present a techincal comparison between the three RTOSes supported by micro-ROS:
 * [NuttX](https://nuttx.apache.org/)
-* [FreeRTOS](https://www.freertos.org/index.html)
+* [FreeRTOS](https://www.freertos.org/)
 * [Zephyr](https://www.zephyrproject.org/)
 
 The comparison regards the features listed below:
-* Standardized API to Application level
+* Standardized API to application level
 * Maturity
-* Supported Hardware
+* Supported hardware
 * Scheduling options
 * IO Support (native or vendor-specific module needed)
 * Networking stack
diff --git a/_docs/concepts/rtos/index.md b/_docs/concepts/rtos/index.md
@@ -3,13 +3,13 @@ title: Why a Real-Time Operating System?
 permalink: /docs/concepts/rtos/
 ---
 
-The use of Real-Time Operating Systems (RTOSes) is a general practice in nowadays embedded systems. These devices typically consist of a resource-constrained microcontroller that executes an application which requires an interaction with external components. In many cases, this application contains a time-critical task where a strict time deadline or deterministic response is required.
+The use of Real-Time Operating Systems (RTOSes) is a general practice in nowadays embedded systems. These systems typically consist of a resource-constrained microcontroller that executes an application which requires an interaction with external components. In many cases, this application contains a time-critical task where a strict time deadline or deterministic response is required.
 
 Bare-metal applications are also used nowadays, but require very low-level programming skills and lack of the hardware abstraction layers that RTOSes offers. On the other hand, RTOSes typically use hardware abstraction layers (HAL) that ease the use of hardware resources, such us timers and communication buses, lightening the development and allowing the reuse of code. In addition, they offer threads and tasks entities which, together with the use of schedulers, provide the necessary tools to implement determinism in the applications. The scheduling consists of different algorithms, among which users can choose the ones that better fits their applications. Another feature that RTOSes normally offer is the stack management, helping in the correct memory usage of the MCU resources, a valuable good in embedded systems.
 
 ## RTOS in micro-ROS
 
-Due to the benefits presented above, micro-ROS integrates RTOSes in its software stack. The use of such a tool enhances micro-ROS' capabilities and allows reusing all the tools and functions they provide. As the micro-ROS software stack is modular, the exchange of software entities is expected and desired at all levels, including the RTOS layer.
+Due to the benefits presented above, micro-ROS integrates RTOSes in its software stack. This enhances the capabilities of micro-ROS and allows reusing all the tools and functions provided by the RTOSes. As the micro-ROS software stack is modular, the exchange of software entities is expected and desired at all levels, including the RTOS layer.
 
 Like the Operating Systems (OSes) available for computers, the RTOSes also have different support for standard interfaces. This is established in a family of standards named [POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/). As we aim to port or reuse code of ROS 2 that was natively coded in Linux (a mostly POSIX-compliant OS), the use of RTOSes that comply with these standards is beneficial, as the porting effort of the code is minimal. Both NuttX and Zephyr comply to a good degree with POSIX standards, making the porting effort minimal, whereas FreeRTOS provides a plugin, *FreeRTOS+POSIX*, thanks to which an existing POSIX compliant application can be easily ported to FreeRTOS ecosystem, and therefore leverage all its functionality.
 
diff --git a/_docs/overview/rtos/index.md b/_docs/overview/rtos/index.md
@@ -65,7 +65,7 @@ FreeRTOS is distributed under the MIT license. It is know particularly for is si
         </ul>  
         <b>FreeRTOS resources:</b>
         <ul>
-            <li><a href="https://www.freertos.org/index.html">Official FreeRTOS website</a></li>
+            <li><a href="https://www.freertos.org/">Official FreeRTOS website</a></li>
             <li><a href="https://www.freertos.org/a00104.html">Download</a></li>
             <li><a href="https://www.freertos.org/Documentation/RTOS_book.html">Documentation</a></li>
         </ul>
@@ -122,7 +122,7 @@ Zephyr is a fairly new open-source RTOS, developed in a Linux Foundation Project
 
 ### **NuttX**
 
-NuttX emphasizes its compliance with standards - including POSIX - and small footprint. It can be fit on 8- to 32-bit microcontrollers. The use of POSIX and ANSI standards, together with the mimic it does to UNIX APIs, makes it friendly to the developers that are used to Linux. NuttX is licensed under BSD license and makes use of the GNU toolchain.
+NuttX emphasizes its compliance with standards - including POSIX - and small footprint. It can be fit on 8- to 32-bit microcontrollers. The use of POSIX and ANSI standards, together with the mimic it does to UNIX APIs, makes it friendly to the developers that are used to Linux. NuttX is licensed under BSD license and makes use of the GNU toolchain. Please note that the uClib++ library used with NuttX comes under the stricter GNU LGPL Version 3 license.
 
 <div class="rtoscontainer">
   <div class="rtositem_description">
