You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parsing complex objects from JSON uses a __type field inside the JSON to determine the C++ type. Conveniently, when registering the type with the JSON exporter, the template automatically infers a string to represent the type. (See tutorial page for how serialization is done and registered with BehaviorTree.CPP.)
C++ templates are infamous for their verbosity. Even something relatively svelte
std::vector<std::double>
hides default value complexity, and so gets converted to something verbose in its full name:
"std::vector<double, std::allocator<double> >"
This is what happens to some common ROS2 types (at least in humble):
It's verbose and ugly. These full template names aren't commonly used in C++ for a reason, and even the short ones are commonly abbreviated with aliases.
It requires an exact string match, instead of merely valid C++. E.g. this does not get parsed
and fails silently in certain parts of the BehaviorTree.CPP stack, e.g. ImportBlackBoardFromJSON()
It is specific to C++. Currently, the __type field must match what BehaviorTree.CPP expects -- which could cause a name collision for other languages and libraries deserializing the same JSON. It is common in large systems to define types using some common schema language, e.g. ROS2 IDL, JSON schema, or protobuf, then generate the types in C++ and other languages. These serialization/schema languages have their own programming-language-independent notation for representing types, e.g. geometry_msgs/Transform in ROS2 IDL, e.g. type hints (.NET docs)"Circle:http://schemas.datacontract.org/2004/07/MyApp.Shapes" or "Circle:#MyApp.Shapes".
Requested solution
When registering JSON function, support a custom type name string.
Interface Change
Add an optional type_name parameter to the BT::JsonExporter::addConverter() functions and BT::RegisterJsonDefinition(). E.g.
Problem Statement
Parsing complex objects from JSON uses a
__type
field inside the JSON to determine the C++ type. Conveniently, when registering the type with the JSON exporter, the template automatically infers a string to represent the type. (See tutorial page for how serialization is done and registered with BehaviorTree.CPP.)C++ templates are infamous for their verbosity. Even something relatively svelte
hides default value complexity, and so gets converted to something verbose in its full name:
This is what happens to some common ROS2 types (at least in
humble
):"geometry_msgs::msg::Pose_<std::allocator<void> >"
"geometry_msgs::msg::Quaternion_<std::allocator<void> >"
"geometry_msgs::msg::Transform_<std::allocator<void> >"
"geometry_msgs::msg::Vector3_<std::allocator<void> >"
"geometry_msgs::msg::Point_<std::allocator<void> >"
Issues caused
ImportBlackBoardFromJSON()
__type
field must match what BehaviorTree.CPP expects -- which could cause a name collision for other languages and libraries deserializing the same JSON. It is common in large systems to define types using some common schema language, e.g. ROS2 IDL, JSON schema, or protobuf, then generate the types in C++ and other languages. These serialization/schema languages have their own programming-language-independent notation for representing types, e.g.geometry_msgs/Transform
in ROS2 IDL, e.g. type hints (.NET docs)"Circle:http://schemas.datacontract.org/2004/07/MyApp.Shapes"
or"Circle:#MyApp.Shapes"
.Requested solution
When registering JSON function, support a custom type name string.
Interface Change
Add an optional
type_name
parameter to theBT::JsonExporter::addConverter()
functions andBT::RegisterJsonDefinition()
. E.g.becomes
Behavior
If the type name is left blank, it behaves as it does currently, with
BT::demangle()
's best effort to create a readable type name.If the type name is provided, then it is used instead in the
JSONExporter::type_names_
map.Ideally, if called multiple times, it would register multiple names for the same type.
Discussion
This added freedom addresses all three issues. Application developers can:
__type
The text was updated successfully, but these errors were encountered: