Using json in msg
Is it good practice to use the ros2 json message, ie, in a standard message like std_msgs / string, write a string with a json structure?
ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Is it good practice to use the ros2 json message, ie, in a standard message like std_msgs / string, write a string with a json structure?
Is it good practice to use the ros2 json message, ie, in a standard message like std_msgs / string, write a string with a json structure?
I would say "no".
One of the main points of using standardised messages as we do in ROS is that they allow you to encode both syntax) (ie: the exact form of data (layout, sizes of fields, etc)) and the semantics (ie: the meaning (so x
is the first element of a vector
that has its origin at frame_id
)) in a single definition.
This allows both consumers and producers of such messages to be very explicit about the information they are communicating, and allows things like decoupling in time (ie: a consumer that receives messages that were produced 2 years ago should still be able to interpret them).
Your suggestion essentially comes down to using a field of type string
and populating it with data that syntactically fits that field perfectly fine (a JSON string is still a string
), but semantically seems like a bad fit: a JSON string is not just a string
, it's (typically) actually a stringified (ie: serialised) representation of some higher order data structure (such as a list, map or even worse: arbitrary application-specific classes).
Interpretation of that string
field now has two "layers" (in contrast to the 'normal' situation where we use only appropriate msg types):
string
We could say that "special knowledge" (ie: layer 2) is always required to be able to interpret a message, but the main difference here is that by using properly typed messages the special knowledge is (at least partly) embedded in the contract that exists between the producer and consumer: it's the semantics part of the message definition. That is very powerful, as it greatly reduces coupling between the producer and consumer: very little knowledge of the internals of the producer are imported into the consumer, making things like replacing components and mixing-and-matching components to create applications a lot easier, as neither will assume (too much) about the other.
If producer A
starts putting JSON (or anything that is not actually really a plain string
) into a field, the correct interpretation of that field completely depends on consumer B
knowing that field contains JSON (and not just an arbitrary plain string). This couples A
and B
, as they both must assume their communication channel works that way, or they can't function.
To make it more explicit: even though the message definition tells me that consumer B
accepts a string
, if I send it anything but JSON, B
will fail to process the message, even though both syntax and semantics have been adhered to (but note that ... (more)
This question is similar to mine: https://answers.ros.org/question/3026... .
@VictorLamoine: I'm not sure actually. Using polymorphism (as you suggest in your question) would maintain syntax and semantics (to a certain degree), while throwing typing out of the window (which using JSON in a string
field is akin to imo) does not.
Asked: 2019-02-07 00:46:25 -0500
Seen: 2,543 times
Last updated: Feb 07 '19
ros2 msg field name reservations
ROS2 timer callback stops working after a few hours
Linking to lib is using -lmylib instead of ws/install/pkg/lib/mylib.so
[ROS2] Two machines are in same network but can't communicate in ROS2 [closed]
How do I include the Python "packaging" library on build farm?