DDS configuration and QoS

[vmayoral]

DDS are usually configured through xml files. One of the characteristics configured through these files are the QoS policies.

Parsing XML files in embedded devices is not an option. Maybe we could create a tool that creates aheader file with all these configuration options (rosnanodds?)?.

[dirk-thomas]

Since it is configuration it should be changeable without recompilation.

[vmayoral]

That'll require to use some files and parsing. Besides from using xml, any other suggestion?

DDS embedded implementations speak about a footprint of < 200 KB. A library to perform pure C xml parsing can't a considerable part of those 200 MB. I did a bit of digging and found:

Library	License	Object	Static
strlen			25 816
expat	MIT	162 139	194 432
libxml2	MIT	464 328	518 816
mxml	LGPL2+static	32 733	75 832
yxml	MIT	5 971	31 416

Yxml would take about 3% of those 200 KB. Would this size be acceptable? Can we keep up with a part of the code being under the MIT license?

[vmayoral]

I thought a bit deeper on this matter and reached the following conclusion: Since embedded platforms usually don't allow easy access to the code/binaries I'm not sure whether it makes sense to provide a thing such as an xml for changing configuration easily.

Recompiling the code and re-uploading it shouldn't be that much of a pain compared to modifying an xml and re-uploading it. @codebot9000, what do you think?

[codebot]

Yes I think this is one of those cases where "embedded" is an overloaded keyword. For ARM Cortex-A class machines with tons of RAM and storage, it probably makes sense to be able to configure this stuff at runtime. But to fit in a few tens of kilobytes of RAM on a "deeply-embedded" Cortex-M machine, I think it's going to be tough to have a whole lot of runtime configuration options, so I think it a static QoS configuration makes sense. As we know from attempting to do ROS 1 on small machines (which uses XML in its negotiation processes), it's just not a viable format to deal with on microcontrollers, so I agree, let's go with a header file and compile-time configuration. The goal at this point is to get something running end-to-end as quickly as possible, with the expectation that we will be rewriting large portions of it later (probably several times), as we learn more about how to build these systems.