A new directory called cmake/toolchains has been added to allow for
setting up a cross-compilation toolchain. Additonally, a convenience deploy
target has been added that assumes, you are deploying the deb files created
from the package target and that you will deploy via scp. These deployment
assumptions will likely need to be revisited to make them more generally
useful, however, in the near-term, lets consider them a proof-of-concept for
automating the deployment of cross-compiled code. The following cmake
variables can be set on the command line to control how the deploy occurs:
- TARGET_IP (ip address of your embedded system)
- TARGET_USER (user to login to the embedded system as)
- TARGET_DIR (directory on the embedded system to copy the debs to)
Currently cross compiling makes the assumption you are deploying to an embedded
Linux system (i.e., not cross compiling for Windows or Mac) and to that end,
turns off the building of o3d3xx-viewer.
It should also be noted that when cross compiling, unit tests are still built
(by default) but you cannot run make check. You can deploy the code and run
the unit tests as an executeable on the embedded system.
Initial cross-compilers tested include Linaro and ELDK from Denx.
Options to conditionally build parts of the code have been added:
- BUILD_TESTS
- BUILD_VIEWER
- BUILD_SHARED_LIBS
- BUILD_STATIC_LIBS
- BUILD_EXE_VIEWER
- BUILD_EXE_VERSION
- BUILD_EXE_RESET
- BUILD_EXE_LS
- BUILD_EXE_DUMP
- BUILD_EXE_CONFIG
- BUILD_EXE_RM
- BUILD_EXE_REBOOT
- BUILD_EXE_HZ
- BUILD_EXE_IMAGER_TYPES
- BUILD_EXE_IFM_IMPORT
- BUILD_EXE_IFM_EXPORT
These are all turned ON by default but can be switched off on the cmake command
line. For example: $ cmake -DBUILD_TESTS=OFF ..
Static libraries (in addition to the shared libraries) are being built by default. Provisions have been made to compile the library code once then link twice (shared and static).
See also:
The raw amplitude data is now available on the ImageBuffer object via the
RawAmplitudeImage() accessor. This is the non-normalized (wrt the exposure
time) amplitude data.
The bottom right image on the 2D image window has the raw amplitude image replace what was historically the amplitude histogram.
The o3d3xx::Camera::FromJSON(...) function is fundamental to how tools like
o3d3xx-config work. This function, including the ones on which it depends
(namely the FromJSON() calls on the XXXConfig value objects), has been
overhauled in this release. The idea was to allow for better "one-liners"
(i.e., partial JSON configurations) to be specified on the command line.
See also:
Changed default for the ServiceReportFailedBuffer and ServiceReportPassedBuffer default values from 15 to 5. For reasoning, please see:
The handling of setting the camera's network configuration has been modified to try to avoid reboots where possible. For example, please see:
Fixed a bug in how the OpenCV image encoding was specified for the XYZImage.
A new XYZImage is avialable on the ImageBuffer class via the XYZImage()
accessor. This image is a 3-channel OpenCV image encoding of the point cloud
where the three channels are spatial planes (x, y, z). It should be noted that
while this encoding of the point cloud contains the same data as the PCL encoded
point cloud the data are kept in mm (as opposed to meters) and the data
type is int16_t as opposed to float. This was motivated by efficiency needs on
embedded systems. However, the coord frame for this point cloud data is
consistent with the coord frame on the PCL point cloud.
See also:
The 0.1.8 frame grabber had issues when run in connection with the ROS code in
o3d3xx-ros. Retrieving, mutating, and restoring the TCP result schema via the
XML-RPC interface proved to be fragile. Per suggestion by @graugans (IFM) we
now use the c command on the PCIC interface.
See comments/discussion at the end of this commit
The implementation of FromJSON was very fragile due to how 0.1.8 made changes
to JSON comparisons. This fragility caused problems with heavily used
command line tools like o3d3xx-config. This release has better error trapping
while maintaining the network efficiency intentions of the 0.1.8 FromJSON(..)
implementation.
Per suggestion by @graugans (IFM), the FrameGrabber will now apply a known
schema at runtime in the event the configured schema for the active application
is different than what is expected. Additionally, the configured schema gets
restored once the FrameGrabber is destroyed. This allows for compatibility with
other computing environments that may expect the configured schema to be
returned.
IFM's software provides the means to import/export applications to/from the
camera where the files have an IFM-specific serialization (zip-compressed JSON
as of this writing). o3d3xx::Camera now has an ImportIFMApp and
ExportIFMApp method to enable passing data to/from the camera in a way that
is compatible with Vision Assistant. Additionally, two new command line tools
have been provided (o3d3xx-ifm-import and o3d3xx-ifm-export) that exploits
the new camera methods to move data to/from files employing the IFM
serialization scheme.
Unlocking the 100K pixel support on the O3D303 is not yet (as of this writing)
officially supported by IFM and you should only use this feature at your own
risk. However, if you like to live on the edge, you can play with this feature
now. We have provided an application, test/data/100k.o3d3xxapp, that unlocks
this feature into a new application on your camera. You can import this
application using o3d3xx-ifm-import and then mark it active using
o3d3xx-config.