ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

We depend on 'rapidjson', so maybe adding it?'s complicated..

asked 2018-05-14 18:35:48 -0600

jimwhitfield gravatar image

Greetings ROS-safarians. We've developed a ROS driver to read from and control the OmniPreSense radar sensor, which does much of its communications as a JSON message. We chose rapidjson as our library for encoding and decoding JSON payloads.

One of the benefits of rapidjson is that it appeared to be in ros already. (It is listed in as rapidjson-dev) Alas, it's not that easy :(

So, the rapidjson-dev package in Ubuntu 16.04 is archaic (0.12) and our driver made use of some more contemporary calls. We thought we might just add the rapidjson repo to ros ( ) and get back to using the modern API.

However, we just found that Ubuntu 18.04 and it's predecessor 17.10 updated to the modern rapidjson API (1.1.0). (And I think there might now be a deb package named 'rapidjson' , though 'apt-get install rapidjson' does NOT work in 16.04--perhaps it does in 18.04?)

So, ultimately the question is how do we add (to ROS, as a library we can declare we are dependent on) a modern rapidjson which can be available consistently in Ubuntu 16.04 (xenial) and Ubuntu 18.04 (bionic beaver). (We need 16.04LTS for ROS-for-raspberry-pi) It seems like we certainly cannot just rely on the deb package "rapidjson-dev" even though in Ubuntu 18.04 it would have been just fine.

Should we create a ROS package and let the build farm build it? It seems like it. I expect we should not call our clone "rapidsjon-dev" (because that's available by apt install rapidjson-dev) However, since there is a "rapidjson" deb archive, then that name is also not a good choice. Is it a good idea or bad idea to add it under the name "rapidjson-ros"?

Any advice is welcome. Sorry if this is a newbie question--I'm relatively new to ROS. Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-05-15 03:20:26 -0600

tfoote gravatar image

updated 2018-05-15 03:20:52 -0600

In general you can wrap up a 3rd party package into a ROS package but if there is one available upstream you should renamespace it or suppress all the symbols from escaping the package so as not to collide with the upstream one that may be in use by or more other packages.

The other option would be to conditionally compile the contents inside your package on the older platforms. It's usually easier to not expose the symbols this way.

In general our default position is to use the version packaged upstream. When there are different versions across the Ubuntu distros support you need to use ifdefs and the like to be dual compatible.

If the package is not released at all we can consider a backport of the newer versions as it won't conflict with the existing installation that doesn't exist. But since the older version already exists that won't work unless it can be shown to be compatible.

In this case I'd suggest considering building the library internally to your package on the older platforms and not exposing any of the symbols. And once Melodic has dropped support for Artful you can start relying on the upstream version in bionic if the version in stretch is up to date enough, or the stretch backports will work.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2018-05-14 18:35:48 -0600

Seen: 379 times

Last updated: May 15 '18