Clarify units in OPTICAL_FLOW

[jlecoeur]

The units in OPTICAL_FLOW are off. The message now reads:

Field Name | Type | Units | Description
-- | -- | -- | --
time_usec | uint64_t | us | Timestamp  (UNIX Epoch time or time since system boot). The receiving end can  infer timestamp format (since 1.1.1970 or since system boot) by checking  for the magnitude the number.
sensor_id | uint8_t |   | Sensor ID
flow_x | int16_t | dpix | Flow in x-sensor direction
flow_y | int16_t | dpix | Flow in y-sensor direction
flow_comp_m_x | float | m | Flow in x-sensor direction, angular-speed compensated
flow_comp_m_y | float | m | Flow in y-sensor direction, angular-speed compensated
quality | uint8_t |   | Optical flow quality / confidence. 0: bad, 255: maximum quality
ground_distance | float | m | Ground distance. Positive value: distance known. Negative value: Unknown distance
flow_rate_x ** | float | rad/s | Flow rate about X axis
flow_rate_y ** | float | rad/s | Flow rate about Y axis

The issue is that flow_comp_m_x and flow_comp_m_y should be in m/s and not in m.

Optical flow is usually expressed in rad/s:

• The raw OF measurement is in pixels/frame (what is sent in flow_x and flow_y) but that is not really useful alone.
• Once corrected with frame rate, we obtain OF in pixels/s, and once corrected with focal length we obtain OF in rad/s (what is sent in flow_rate_x and flow_rate_y)
• For visual odometry, optical flow in rad/s is not useful either. It needs to be scaled using a distance sensor to obtain a speed measurement in m/s.

In PX4Flow Firmware, flow_comp_m_x/y contains values in m/s.

Possible solutions:

• modify the unit in the message description
• add an integration time-frame field (similar to OPTICAL_FLOW_RAD)

[hamishwillee]

@auturgy Hi, does ArduPilot implement OPTICAL_FLOW, and if it does, how does it handle flow_comp_m_x and flow_comp_m_y?
@jlecoeur says these are incorrectly set with units as m rather than m/s. I'm hoping that you say that is how they are used so just updating the unit on the message becomes the logical thing to do.

If not, do you have a preference on this? Changing to m/s sounds reasonable, but I don't know enough about why another integration time-frame might be better to really comment. I suspect that end users would just like m/s