New scenarios demonstrating the scene graph and
providing examples for the platform coordiante frame orientation.
scenario-arm: demonstrates a robotic arm like linkage built using
the scene graph
scenario-transforms: provides a structured set of planes demonstrating
the effects of various tranforms
With the support for transforms using links, a
stream name can now have an entry in primitives and
poses and must be stored separately.
- add 'scenario-orbit' to the server docs.
Support for converter ROS Bag data into XVIZ
Key documents are:
- RFC ./dev-docs/005-ros-module-rfc.md
- User Docs ./docs/api-reference/ros
- Module Readme ./modules/ros/README.md
- Examples ./examples/converters/ros ./examples/converters/ros-custom
Follow the convention that constant enumerated values should be in ALLCAPS. This is a spec change for XVIZ, but retains compatibility with lowercase by forcing a case conversion at the appropriate places within the modules.
Spec change locations:
declarative ui properties
- component type
- layout
- interactions
xviz message
- type
- xviz/start
- session_type
- message_format
- log
- xviz/metadata
- stream metadata
- category
- scalar type, for time_series & variables
- primitive type, for time_series & variables
- annotation_type, for annotations
- stream style
- text_anchor
- text_baseline
- xviz/state_update
- update_type
- xviz/reconfigure
- update_type
A 'Frame' is often overloaded, and in nearly all case
in XVIZ we mean an XVIZ Message. We have created a distinction
where if we use 'Frame' it is not an individual message but the
set of data that constitutes a visual 'Frame' which could come from
multiple messages. Therefore, 'Frame' is still used in @xviz/parse
XVIZ specified data format.
Prior to this functions and classes that operate on XVIZ data
where split across @xviz/builder and @xviz/parser. They will
be moved into @xviz/io in subsequent changes.
Motivation for this is due to @xviz/parser restructuring data that
no longer can be validated against our specification and validation
tooling. This made it difficult to modify XVIZ and validate it is
still conforming. Given that, this module should operate only
at the XVIZ specification level.
Highlights of @xviz/io module:
- XVIZ data classes allow for dealing with XVIZ data regardles
of the format specifics (binary or json)
- Abstraction layers keep concerns isolated and provide and improve
structure for evolving the XVIZ eco-system
Key documents are:
- RFC ./dev-docs/003-io-module-rfc.md
- User Docs ./docs/api-reference/io
- Module Readme ./modules/io/README.md
When processing data in real time if you fall behind the queue can
grow unbounded, so you need the ability to cap it. You also want to
know if you have dropped data so that is now reported as well.
- create XVIZFutureInstanceBuilder to isolate effects of timestamp from XVIZPrimitiveBuilder
- make sure if timestamp < EPSILON of an existing timestamp we do not insert a new one
- ensure primitives are merged into the existing timestamp primitives array
- add test cases for the above
- change getPoseOffset => getGeospatialVector as the arguments are not Poses
- add test cases and comments for getGeospatialVector
- update docs
The declarative UI plot component has a single "independentVariable" and
multiple "dependentVariables". In many places we forgot the "s".
That is not fixed with both the spec and the builder updated and tested.
- update doc examples to match new 'base' primitive properties
- add util func to access primitives thur their top-level 'type'
property
- parsed XVIZ needs context on object 'type', so while it is removed
from objects parsing it will add it to the objects
This provides a simple API that validates provided JSON objects are
the types you would expect. It has a generic API that lets you check
any subobject of the spec and a set of high level methods to validate
the types that the builder objects are most concerned about.
- `DEFAULT_METADATA`: removed (not used)
- `filterStream`: replaced with `STREAM_BLACKLIST`
- `postProcessMetadata`: removed (can be applied to parsed result)
- `postProcessTimeslice`: removed (can be applied to parsed result)
- `postProcessVehiclePose`: removed (can be applied to parsed result)
- `postProcessFrame`: moved to options of `BaseSynchronizer`
- `getTrackedObjectPosition`: removed (can be done in postProcessFrame)
- `observeObjects`: removed (not used)
- Finalize the style specification and update json schema's to match
- Move styles props to snake_case
- Separate stream_styles from style_classes, details in the docs
- Updated documentation to describe style levels, order of precedence, and added tables to condense information.
- Replaces the previous styles as follows:
- color -> fill_color and stroke_color
- thickness_m -> stroke_width
- font_scale -> size
remove debugging code
rebase
fix and add more tests
Only initialize different types of builders in xviz-builder constructor
Update document
resolve comments
