As mentioned in this thread there are many different aspects of parameters that add significant complexity. Depending on your application there are many different levels of persistence that might be necessary, for some ephemeral is fine, for others there should be backups mechanisms to recover state following hardware failures. Similarly there are parameters that need to be validated within ranges or enums, or otherwise validated sometimes with runtime constraints.
Generic nodes and blackboards are very convenient but they lead to unclear ownership and lack the ability to define semantics in documentation. In particular the lifecycles needs of different parameters may be quite different. For example if you have a parameter that needs high persistence and one that doesn’t want it, then you now need to be able to set policies per parameter on the generic parameter server. And potentially try to tie their lifetimes and data management correctly to external events it starts to get much more complicated.
Whereas if we provide good tools for managing parameters within nodes the data can live with the nodes which own the data. A simple example is setting a parameter on a sensor, the parameter is limited by the capabilities of the sensor. The parameter must be validated by the sensor driver, so there needs to be a mechanism for the driver to get callbacks for the changes and then maybe revert the change to the global parameter, and this can get into fighting updates for the state of the parameter. Also if you do something like plug in a new version of the sensor, and it doesn’t have a parameter that the previous sensor had. That parameter will still exist, and the user might be surprised that when they change the parameter there’s no behavior change. There’s no visibility into the fact that that parameter is now useless. It’s just vestigial but will persist as long as the parameter server stays online.
As more of the system state evolves this vestigial state will accrue. It might be that some of these parameters overlap between nodes that ran before and suddenly you’ll get different behavior based on the order of previous launches.
It’s much cleaner to actually keep the parameters in nodes that have semantic meaning. It may make sense to have specific nodes that are standalone and part of a launch file for a particular application. But these nodes should plan to own the lifecycle of the parameters, document the semantics, provide appropriate persistence models. As we look towards supporting security these nodes can have appropriate access control. (Access control on a blackboard type nodes add a lot of complexity.
Similarly a “global” parameter server has undefined behavior if you have two robots that are operating independently then roam onto the same network. If you do need or want state to be persisted, you can launch a specific node that’s setup to have a specific backup to a database or other storage mechanism and will reload state. But if you’re thinking about doing that what is the benefit of having the parameters stored in an external process? Does requiring a network connection improve anything? If we had good libraries such that any node could easily set validation policies for parameters, and have modules that can enable persistence for parameters, then the node that owns the parameter can provide it with semantic meaning and provide the necessary persistence for each parameter.
So what I’d like to suggest is that instead of focusing on providing a separate node that just holds parameters and add lots of features to that, instead we provide methods and libraries that can build on and extend the node’s parameter API to allow semantically meaningful parameters integrated into the nodes that use them. And this is not to say that you can’t leverage a parameter from another node, but don’t just try to put all the parameters in one place. They are all accessible from any node on the system independent of which node is hosting them so centralizing them just breaks down the modularity of the system. We may also want to develop standard parameter interfaces that multiple interchangeable nodes can implement, but that’s much more introspectable than just putting the “expected” parameter onto the parameter server and hoping that the other node will read the same parameter with the same semantic meaning.
