Add ORB_QUEUE_LENGTH info

docs/en/middleware/uorb.md

@@ -61,12 +61,12 @@ For example the [VelocityLimits](../msg_docs/VelocityLimits.md) message definiti
 ```text
 # Velocity and yaw rate limits for a multicopter position slow mode only
 
-uint64 timestamp # time since system start (microseconds)
+uint64 timestamp # [us] Time since system start.
 
 # absolute speeds, NAN means use default limit
-float32 horizontal_velocity # [m/s]
-float32 vertical_velocity # [m/s]
-float32 yaw_rate # [rad/s]
+float32 horizontal_velocity # [m/s] Horizontal velocity.
+float32 vertical_velocity # [m/s] Vertical velocity.
+float32 yaw_rate # [rad/s] Yaw rate.
 ```
 
 By default this message definition will be compiled to a single topic with an id `velocity_limits`, a direct conversion from the CamelCase name to a snake_case version.
@@ -92,15 +92,34 @@ To nest a message, simply include the nested message type in the parent message
 
 ```text
 # Global position setpoint triplet in WGS84 coordinates.
+#
 # This are the three next waypoints (or just the next two or one).
 
-uint64 timestamp		# time since system start (microseconds)
+uint64 timestamp # [us] Time since system start.
 
 PositionSetpoint previous
 PositionSetpoint current
 PositionSetpoint next
 ```
 
+### uORB Buffer Length (ORB_QUEUE_LENGTH)
+
+uORB messages have a single-message buffer by default, which may be overwritten if the message publication rate is too high.
+In most cases this does not matter: either we are only interested in the latest sample of a topic, such as a sensor value or a setpoint, or losing a few samples is not a particular problem.
+For relatively few cases, such as vehicle commands, it is important that we don't drop topics.
+
+In order to reduce the chance that messages will be dropped we can use named constant `ORB_QUEUE_LENGTH` to create a buffer of the specified length.
+For example, to create a four-message queue, add the following line to your message definition:
+
+```sh
+uint8 ORB_QUEUE_LENGTH = 4
+```
+
+As long as subscribers are able to read messages out of the buffer quickly enough than it isn't ever fully filled to the queue length (by publishers), they will be able to get all messages that are sent.
+Messages will still be lost they are published when the queue is filled.
+
+Note that the queue length value must be a power of 2 (so 2, 4, 8, ...).
+
 ### Message/Field Deprecation {#deprecation}
 
 As there are external tools using uORB messages from log files, such as [Flight Review](https://github.com/PX4/flight_review), certain aspects need to be considered when updating existing messages: