Parameter manager refactoring

[JMoore5353]

All the parameter manager does currently is manage the interface with the ROS2 parameter system and save the values locally into a dictionary. This was probably originally needed because of the speed at which we need to query parameters and get the return value (several times per execution loop).

However, a simpler implementation of the param_manager would be to not have it and just call the params directly from the ROS2 node. Since ROS2 params are managed by each node (instead of rosmaster as in ROS1), it might be fast enough. If it is fast enough, it would be better to do away with the param_manager and just use the ROS2 system.

We should do a speed test and calculate the difference in speed between calling params from the param_manager and calling them from the ROS2 node.

[JMoore5353]

@iandareid @bsutherland333 Interesting analysis:

This was all done in the update call of the estimator_example.
Procedure:

1. Measure time to query the param_manager::get_double method
2. Measure time to query the same parameter from the ROS2 api (this->get_parameter)
3. Save both measurements to file
4. Repeat while collecting data for several seconds

Here are the results!

More detailed results:

Method	Min	Max	Mean	Num Samples
Param Manager	0.000151	0.020404	0.001126	6246
ROS2 API	0.001956	0.192338	0.007506	6246

This tells me that it is worth it to keep the Param Manager, especially if we want to operate at fast speeds with ROScopter. Thoughts?

[iandareid]

It seems like param manager is much faster!

It seems to me we should use param manager!!!! A fifth of a millisecond could be considerable if a researcher ever wanted to really push for something in the kilohertz range.