[Rock-dev] assumptions in joint_dispatcher -- NamedVector

[Jakob Schwendner]

Hi,

> If an (named) element does not exist, it should be created when using the
> operator[](std::string name).
I am against this, as it will then result in a silent failure when the joint is read.

> This way motion controllers do not have to initialize the size of the vector in
> configuration state, which again eliminates the need to put the joint names
> or the number of total joints into an configuration file
> (.yml) for the controller at all (one place less where they are defined).
This imo breaks the modeling aspect, that we are so proud to have in rock. You should let the model define what the component generates, or should generate. This way you can do verification if e.g. a joint is not available, even though it should be.

> 
> As syskit may provide a different network plan at later times, additional joints
> may become available in a later stage, in the current case you need to start
> another controller to handle them.
Not sure I understand this...

> 
> Nevertheless, the check whether the joint is available should be done on
> Joint driver level, not on controller level.
It should definitely be also done on controller level, and also be known outside for verification.
Modules are responsible for themselves, and should not rely on other module to do the checking for them.

> 
> This behavior would also remove an error source, as the [] operator throws
> an exception in case the joint is not available, if a dev forgot to catch it
> around the access, a joint controller whould exit and potentially the robot
> whould do something stupid then.
Like putting the controller into an error state, because something he is expecting is not there?
Does not sound stupid to me.

> 
> I personally have never seen something like this:
> 
> try{
> 	joints["wheel"].speed = 0.5;
> }catch (InvalidName invalidName){
> 	LOG_ERROR("Joint %s does not exists\n",invalidName.name) }
> 
> I think the joint controller should know best which joints exist.
Because from a controller point of view the default behaviour of going into error state because the exception is thrown on access is fine for me. 

I know that there is a case, where you have joint drivers, that don't reliably put out all joints at the same time, especially at startup. Just masking this by allowing joints to be missing does not sound like a good idea to me. The best way would be to put some collect and wait until all joints are there behavior into the driver, or into the dispatcher. OR, in case missing joints is something nominal for the controller, put the collection mechanism inside and do the logic there. Removing the checks: maybe not so good.

Cheers,

Jakob