C++ Examples
To facilitate working with the Ouster C++ SDK, we provide these examples of common operations. The
examples explained below are compiled into executables which print to screen to demonstratre
behavior. Build with BUILD_EXAMPLES
and print to screen to demonstrate behavior.
Sensor Configuration
In this example we show various ways to work with the sensor configuration
interface. The ouster::sensor::sensor_config
struct can be found
defined in types.h
. get_config
and set_config
are in client.h
.
To run this example:
config_example $SENSOR_HOSTNAME
If there are no errors, you should see a printout in five parts.
Let’s look at the first step, where we get the configuration of the sensor as it starts:
sensor::sensor_config original_config;
if (!sensor::get_config(sensor_hostname, original_config)) {
std::cerr << "..error: could not connect to sensor!" << std::endl;
return EXIT_FAILURE;
}
The function get_config
takes a sensor_config
so we must declare it first. It returns true
if it succesfully retrieves the config, and false if an error occurs in connecting to the sensor and
setting the config. The function set_config
works similarly, returning true if it successfully
sets the config, and false otherwise.
In the second step, we create a new config:
sensor::sensor_config config;
config.azimuth_window = std::make_pair<int>(90000, 270000);
config.ld_mode = sensor::lidar_mode::MODE_512x10;
// If relevant, use config_flag to set udp dest automatically
uint8_t config_flags = 0;
const bool udp_dest_auto = true; // whether or not to use auto destination
const bool persist =
false; // whether or not we will persist the settings on the sensor
if (udp_dest_auto) config_flags |= ouster::sensor::CONFIG_UDP_DEST_AUTO;
if (persist) config_flags |= ouster::sensor::CONFIG_PERSIST;
The sensor_config
struct consists of several std::optional
members, which can be set
directly. Members which are not set will not set sensor configuration parameters when sent to the
sensor. In addition, there are two config flags, for automatic udp destination setting and config
persistence which can be set as above. The automatic udp destination flag cannot be set when
config.udp_dest
is set, as those conflict.
Working with LidarScans
The ouster::LidarScan
is explained in depth conceptually in the LidarScan reference. Here we cover some specifics that will be useful for C++ developers.
LidarScan constructors
Of foremost interest when using a LidarScan
is constructing a LidarScan
which suits
your needs.
The simplest (and most common) method is to construct one to contain all data coming from your
sensor. You can do this by specifying the udp_proflie_lidar
in your sensor_info
, or by
directly specifying the profile you care about.
For example, see the two snippets below:
auto profile_scan = ouster::LidarScan(w, h, info.format.udp_profile_lidar);
auto dual_returns_scan = ouster::LidarScan(
w, h, UDPProfileLidar::PROFILE_RNG19_RFL8_SIG16_NIR16_DUAL);
But suppose you don’t care about some of the data, such as the ambient and signal fields. You can also specify to your LidarScan to only batch the relevant fields like so:
// Finally, you can construct by specifying fields directly
static const std::array<std::pair<ChanField, ChanFieldType>, 2>
reduced_slots{{{ChanField::RANGE, ChanFieldType::UINT32},
{ChanField::NEAR_IR, ChanFieldType::UINT16}}};
auto reduced_fields_scan =
ouster::LidarScan(w, h, reduced_slots.begin(), reduced_slots.end());
To see this in action, you can run the example executable lidar_scan_example
:
$ lidar_scan_example $SAMPLE_DUAL_RETURNS_PCAP $SAMPLE_DUAL_RETURNS_JSON
The source code of lidar_scan_example
is available here.
2D Representations and 3D representations
The core destaggering and projection to 3D capabilities are demonstrated in the
representations_example
executable.
Here we will cover slightly more sophisticated ways of working with the data also demonstrated in that example.
To run this example:
representations_example $SAMPLE_DUAL_RETURNS_PCAP $SAMPLE_DUAL_RETURNS_JSON
The source code of representations_example
is available on the github.
Reshaping XYZ to 2D
Users may find that they wish to access the x
, y
, and z
coordinates of a single return
in a similar way. As the conversiton to cartesian coordinates returns an Eigen::Array
n x 3
,
with n = w * h
, reshaping the resulting array is necessary.
We can combine our knowledge in projecting into cartesian coordinates and destaggering using the following function:
img_t<double> get_x_in_image_form(const LidarScan& scan, bool destaggered,
const sensor::sensor_info& info) {
// For convenience, save w and h to variables
const size_t w = info.format.columns_per_frame;
const size_t h = info.format.pixels_per_column;
// Get the XYZ in ouster::Points (n x 3 Eigen array) form
XYZLut lut = make_xyz_lut(info);
auto cloud = cartesian(scan.field(sensor::ChanField::RANGE), lut);
// Access x and reshape as needed
// Note that the values in cloud.col(0) are ordered
auto x = Eigen::Map<const img_t<double>>(cloud.col(0).data(), h, w);
auto x_destaggered = destagger<double>(x, info.format.pixel_shift_by_row);
// Apply destagger if desired
if (!destaggered) return x;
return x_destaggered;
}
This demonstrates the functionality with x
, but it can be easily expanded to cover y
and
z
as well.
Adjusting XYZLut With External Matrix
Users may find that they wish to apply an extra transform while projecting to cartesian coordinates.
Such a transform, likely an extrinsics matrix of some sort, can be baked into the
ouster::XYZLut
created with ouster::make_xyz_lut()
.
In the following code, transformation
represents the extrinsincs transform:
auto lut_extrinsics = make_xyz_lut(
w, h, sensor::range_unit, info.lidar_origin_to_beam_origin_mm,
transformation, info.beam_azimuth_angles, info.beam_altitude_angles);
std::cerr << "Calculating 3d Points of with special transform provided.."
<< std::endl;
auto cloud_adjusted = cartesian(range, lut_extrinsics);