Flourish (644227) Deliverable D9.6  
  
<table>  
<tr>  
<th>

uint8[] data

</th>  
<th>

# Actual point data, size is (row_step ***** height)

</th> </tr>  
<tr>  
<td>

bool is_dense

</td>  
<td>

# True if there are no invalid points

</td> </tr> </table>

sensormsgs/PointCloud2 contains the message type sensormsgs/PointField, which
is detailed below.

sensormsgs/PointField  
  
<table>  
<tr>  
<th>

# This message holds the description of one point entry in the # PointCloud2
message format.

uint8 INT8 = 1 uint8 UINT8 = 2 uint8 INT16 = 3 uint8 UINT16 = 4 uint8 INT32 =
5 uint8 UINT32 = 6 uint8 FLOAT32 = 7 uint8 FLOAT64 = 8

string name # Name of field uint32 offset # Offset from start of point struct
uint8 datatype # Datatype enumeration, see above uint32 count # How many
elements in the field

</th> </tr> </table>

Cameras: sensormsgs/Image  
  
<table>  
<tr>  
<th>

# This message contains an uncompressed image

# (0, 0) is at top-left corner of image

#

Header header # Header timestamp should be acquisition time of image

# Header frame_id should be optical frame of camera

# origin of frame should be optical center of cameara

# +x should point to the right in the image

# +y should point down in the image

# +z should point into to plane of the image

# If the frame_id here and the frame_id of the CameraInfo

# message associated with the image conflict # the behavior is undefined

uint32 height # image height, that is, number of rows uint32 width # image
width, that is, number of columns

# The legal values for encoding are in file src/image_encodings.cpp

# If you want to standardize a new string format, join

# ros-users@lists.sourceforge.net and send an email proposing a new encoding.

string encoding # Encoding of pixels -- channel meaning, ordering, size

# taken from the list of strings in

# include/sensor_msgs/image_encodings.h

uint8 is_bigendian # is this data bigendian? uint32 step # Full row length in
bytes uint8[] data # actual matrix data, size is (step ***** rows)

</th> </tr> </table>

GPS: sensormsgs/NavSatFix  
  
<table>  
<tr>  
<th>

# Navigation Satellite fix for any Global Navigation Satellite System #

# Specified using the WGS 84 reference ellipsoid

# header.stamp specifies the ROS time for this measurement (the

# corresponding satellite time may be reported using the #
sensor_msgs/TimeReference message).

#

# header.frame_id is the frame of reference reported by the satellite

# receiver, usually the location of the antenna. This is a

# Euclidean frame relative to the vehicle, not a reference # ellipsoid.

Header header

# satellite fix status information

NavSatStatus status

# Latitude [degrees]. Positive is north of equator; negative is south. float64
latitude

# Longitude [degrees]. Positive is east of prime meridian; negative is west.
float64 longitude

# Altitude [m]. Positive is above the WGS 84 ellipsoid # (quiet NaN if no
altitude is available). float64 altitude

# Position covariance [mˆ2] defined relative to a tangential plane # through
the reported position. The components are East, North, and # Up (ENU), in row-
major order.

</th> </tr> </table>

4

Flourish (644227) Deliverable D9.6  
  
<table>  
<tr>  
<th>

#

# Beware: this coordinate system exhibits singularities at the poles.
float64[9] position_covariance

# If the covariance of the fix is known, fill it in completely. If the

# GPS receiver provides the variance of each measurement, put them

# along the diagonal. If only Dilution of Precision is available, # estimate
an approximate covariance from that.

uint8 COVARIANCE_TYPE_UNKNOWN = 0 uint8 COVARIANCE_TYPE_APPROXIMATED = 1 uint8
COVARIANCE_TYPE_DIAGONAL_KNOWN = 2 uint8 COVARIANCE_TYPE_KNOWN = 3 uint8
position_covariance_type

</th> </tr> </table>

Inertial measurement unit: sensormsgs/Imu  
  
<table>  
<tr>  
<th>

# This is a message to hold data from an IMU (Inertial Measurement Unit) #

# Accelerations should be in m/sˆ2 (not in g’s), and rotational # velocity
should be in rad/sec.

# If the covariance of the measurement is known, it should be filled in

# (if all you know is the variance of each measurement, e.g. from the

# datasheet, just put those along the diagonal). A covariance matrix of

# all zeros will be interpreted as "covariance unknown", and to use the

# data a covariance will have to be assumed or gotten from some other source #

# If you have no estimate for one of the data elements (e.g. your

# IMU doesn’t produce an orientation estimate), please set element 0

# of the associated covariance matrix to -1. If you are interpreting # this
message, please check for a value of -1 in the first element of each #
covariance matrix, and disregard the associated estimate. Header header

geometry_msgs/Quaternion orientation float64[9] orientation_covariance # Row
major about x, y, z axes

geometry_msgs/Vector3 angular_velocity float64[9] angular_velocity_covariance
# Row major about x, y, z axes

geometry_msgs/Vector3 linear_acceleration float64[9]
linear_acceleration_covariance # Row major x, y z

</th> </tr> </table>

Thermometer: sensormsgs/Temperature  
  
<table>  
<tr>  
<th>

# Single temperature reading.

Header header # timestamp is the time the temperature was measured

# frame_id is the location of the temperature reading

float64 temperature # Measurement of the Temperature in Degrees Celsius
float64 variance # 0 is interpreted as variance unknown

</th> </tr> </table>

#  Conclusion

This deliverable reports on the FLOURISH projects data management plan. We
provided a detailed description of the types of data the project will
generate, the data format in which we will log and store data, and how we will
share data among FLOURISH partners and make relevant data available to the
public.

5