Allow parameter array and map containers

[sevenbitbyte]

Issues

Improves parameter behavior to more closely match rosmaster

• [Bug] Loading params from yaml via roslaunch and <rosparam> not consistent with roscore #25

Repro Steps

Create map_tests.yaml as shown below:

joints: 
  - (JointA, 0)
  - (JointB, 1)
  - (JointC, 16)
map1: {"key": "value", "bar": "foo"}
arr1: [3, 2, 1, {"foo": "bar"}]
map2: {"[0]": 1}

Load the map into roscore:

rosparam load ./map_tests.yaml

Dump parameters:

rosparam get /

arr1:
- 3
- 2
- 1
- {foo: bar}
joints: ['(JointA, 0)', '(JointB, 1)', '(JointC, 16)']
map1: {bar: foo, key: value}
map2: {'[0]': 1}

There should be no difference in behavior between vapor_master and roscore

[sevenbitbyte]

needs minor dead code cleanup

[HWiese1980]

I've tested the PR on my system. It works so far, aside from one thing:

I'm still seeing a differing behavior when using it like this:

ros::init(argc, argv, "test");
ros::NodeHandle nh("~");

// following expression always returns empty vector, even if parameter exists and fully-qualified path for the parameter is valid
nh.param<std::vector<std::string>>("joints", joints, std::vector<std::string>>()); 

Using nh.getParam instead in place of nh.param<...> works in this case because getting a vector does not seem to require an empty default value. It just returns an empty vector if the parameter does not exist. However, I'm not sure if every node out there is aware of that fact or if it's commonly known "best practice" to use nh.getParam instead of nh.param<...>in this particular case.

Though, using nh.param<...> and nh.getParam with roscore both work like a charm.

[sevenbitbyte]

Oh interesting, in your test case was joints parameter an empty array initially?

If so we have a clear path to correct:

The ros 1.1 xmlrpc protocol does not explicitly indicate types so we're forced to infer via set values. When set to a null/empty value we have little to no type information. We can relax our type inference some to enable determining type at a later time when a non-null value is set.

[HWiese1980]

You mean the joints variable in the node before calling nh.param? Yes, it's defined simply as follows:

std::vector<std::string>> joints;

The corresponding parameter on the parameter server is initialized - as mentioned somewhere else - by using <rosparam command="load" file="$(find...)" /> in a launch file.

[HWiese1980]

... which also launches the node that does nh.param resp. nh.getParam

[HWiese1980]

I'm wondering how roscore infers the type in this case...

[sevenbitbyte]

@HWiese1980

Have a look at #27 turned out to be a simpler explanation, rather than type inferencing was simply a parameter existence check not updated for the array life-cycle added in PR #26.

[HWiese1980]

@sevenbitbyte at a first glance #26 and #27 seem to solve #25 for now. Awesome! 👍

I'll continue testing and see if my whole stack now works like with roscore.