Rosparam load error when encountering complex YAML types

Answer first

In most cases you do not need to change the parameter server at all. A rosparam load failure on a file with nested maps or lists is almost always caused by the YAML structure not matching what the loader expects — typically a missing top-level namespace key, a list where a map is required, or a value the YAML parser interprets as an unexpected type. The fix is to correct the file layout and verify the result with rosparam get, not to redesign parameter storage.

Separating fact from assumption

One premise in the question needs correcting: the ROS 1 parameter server is not limited to primitive strings. It stores XML-RPC types, which include dictionaries and arrays, so nested structures are legal. What it does not accept are YAML-specific constructs that have no XML-RPC equivalent (custom tags, anchors in some parser versions, or heterogeneous structures that fail conversion). This answer assumes ROS 1 (Noetic or earlier) with rosparam; ROS 2 Humble uses a different parameter model (ros2 param load, per-node parameters with declared types), so the advice does not transfer directly.

How to diagnose your specific file

1. Capture the exact exception: rosparam load params.yaml 2>& | tee load_err.txt. The Python traceback usually names the offending key or the type it could not convert.
2. Check the top level of the file. rosparam load file.yaml loads keys into the global namespace; rosparam load file.yaml /my_ns loads them under a namespace. A common failure is a file written for one form being loaded with the other.
3. Validate the YAML independently of ROS: python3 -c "import yaml,sys; print(yaml.safe_load(open('params.yaml')))". If this fails, the problem is YAML syntax, not ROS.
4. After a successful load, confirm types: rosparam get /my_ns and compare against what your node expects via rosparam get /my_ns/some_key.

On the design question

Given that the server already supports nested maps and arrays, the practical question narrows to validation and error messages, not native complex-type storage. A separate pre-load schema check is the lowest-risk option: validate the YAML against a JSON Schema (or a simple Python type-check script) in CI or a launch wrapper before calling rosparam load. This changes no core APIs and cannot break existing nodes. Stricter validation inside rosparam itself would improve error messages but risks rejecting files that legacy launch setups depend on, so it would need to be opt-in. Extending the server with new native types offers little benefit and real compatibility cost, since clients already receive dictionaries and lists through the existing XML-RPC API.

What would change this recommendation

If your traceback shows the failure occurs on a structure that is valid YAML and valid XML-RPC (for example, a deeply nested but homogeneous map), share the minimal YAML snippet and the full error text — that would indicate a parser-specific limitation rather than a schema problem, and the workaround would differ (flattening keys or splitting the load across namespaces).