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
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
