Since I started this, I should probably also reply :) I would like to avoid any discussion on the general merit of dynamic ports. I think it was understood by most what I intended with the proposed change. Just going a bit further with what Sylvain already hinted he would like orogen to generate: the helper function for generating the dynamic ports, and a general contract on the lifecycle (e.g. when can the ports be generated.) That orogen itself is not capturing the entire model is fine with me. But the more self-descriptive it is, the better.
Just a few things: - I don't see that generating new ports in the RUNNING state is necessary anywhere. Restricting it for the transition to CONFIGURED is not harmful but only helpful. - How it works now with e.g. the joint_dispatcher is that you create a configuration, if this configuration is not consistent or invalid, you don't transition to CONFIGURED. - The change I proposed would do the same thing: The configuration for the joint_dispatcher (and imho any other module) would just be expressed in a slightly different manner. - Yes, only at run-time would you know if it worked, unless you have another model and validation tool sitting on top. What you gain though, is a) a more streamlined way of how to handle dynamic ports in the code b) a better generic knowledge on the structure of your task c) a cleaner interface for your model validation to hop onto d) a generic and natural way for task introspection One task that was mentioned that would be more complex is the one mentioned by Martin, the robot_frames. Instead of parsing a URDF in task, you would put this into the configuration procedure for your task. I think both syskit and orogen.cpp know how to do this, at least with the transformers, and could probably do the same with robot_frames. Cheers, Jakob _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
