2010/11/16 Herman Bruyninckx <span dir="ltr"><<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be">Herman.Bruyninckx@mech.kuleuven.be</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Tue, 16 Nov 2010, Konrad Banachowicz wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
2010/11/16 Herman Bruyninckx <<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be" target="_blank">Herman.Bruyninckx@mech.kuleuven.be</a><mailto:<a href="mailto:Herman.Bruyninckx@mech.kuleuven.be" target="_blank">Herman.Bruyninckx@mech.kuleuven.be</a>>><div>

<div></div><div class="h5"><br>
On Tue, 16 Nov 2010, Konrad Banachowicz wrote:<br>
<br>
- mixing the creation of a TaskContext with a specific implementation of a<br>
generic interface (trajectory generation in this case) is not a good<br>
practice; these three things should be separated, in order to improve<br>
modular reuse.<br>
- more in particular, new trajectory generation algorithms are preferably<br>
submitted to Orocos/KDL as contributions, instead of "hiding" them inside<br>
a ROSified node, where they are very difficult to reuse in other<br>
frameworks or stand-alone applications.<br>
Trajectory generation reside in ROS stack because it is intended to be as much as possible compatible with trajectory generation used in ROS.<br>
<br>
I have no problem with using ROS nodes to improve interoperability, but<br>
functional algorithms belong in component/node-independent source trees,<br>
for maximal reusability within whatever 'component framework'.<br>
<br>
Yes  you are right but look how image processing code is developed in ROS.<br>
It begin as independent nodes/packages and over time move into OpenCV.<br>
<br>
- I do not see much Configuration options, while this subject of trajectory<br>
generation, servoing etc lends itself extremely well to fine tuning and<br>
customization via setting of configuration properties.<br>
I have not seen any parameters that can by configured in trajectory<br>
generation algorithm which i implemented.<br>
<br>
Strange. Typically, I expect parameters such as maximum speeds, minimal<br>
time steps, required tolerance, etc.<br>
<br>
Yes but these parameters is specified for every trajectory point independently through JointTrajectoryPoint message.<br>
<a href="http://www.ros.org/doc/api/trajectory_msgs/html/msg/JointTrajectoryPoint.html" target="_blank">http://www.ros.org/doc/api/trajectory_msgs/html/msg/JointTrajectoryPoint.html</a><br>
<br>
</div></div></blockquote>
<br>
I find it better practice to separate the Communication from the<br>
Configuration: the most basic, reusable approach is to provide a<br>
configuration API, and only then wrap this into a message-based communication.<font color="#888888"><br></font></blockquote><div>I don't understand how it would be implemented.<br>Can you point my to some code implementing this approach ?<br>

</div></div><br>