Implement the generic "ParameterServer" trait for rosbridge.
Since rosbridge lacks the capability to directly access parameters we'll have to rely on service calls to the ROS API node and trust that users run the ROS API node. All methods should provide a descriptive error message in the event of being unable to contact the ROS API node that clearly states that the rosapi node needs to be running.
We'll need to generate an instance of the rosbridge service messages and store them in the backend. I have not seen this API change significantly, so we should be able to get by with "hard-coded" Request and Response types.
Implement the generic "ParameterServer" trait for rosbridge.
Since rosbridge lacks the capability to directly access parameters we'll have to rely on service calls to the ROS API node and trust that users run the ROS API node. All methods should provide a descriptive error message in the event of being unable to contact the ROS API node that clearly states that the rosapi node needs to be running.
We'll need to generate an instance of the rosbridge service messages and store them in the backend. I have not seen this API change significantly, so we should be able to get by with "hard-coded" Request and Response types.