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;"><div class="im">
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>>><br>
On Tue, 16 Nov 2010, Konrad Banachowicz wrote:<br>
<br>
<br></div>
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>><mailto:<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 class="im">
<br>
<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>
</div></blockquote>
<br>
I am not so convinced that is approach is good practice.<div class="im"><br></div></blockquote><div>Inclusion of these trajectory generation code is a way to go for me.<br>But from my point of view there is reason against including it directly in KDL.<br>
Waiting on inclusion of my patches, release of KDL, update of KDL in ROS would stop my development for a while.<br>I think that things can be done in parallel, i can develope my components with embedded trajectory generation and work on inclusion in KDL.<br>
When new KDL would be released i will swich may nodes to new implementation. <br></div><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">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- 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>
<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.<br>
I don't understand how it would be implemented.<br>
Can you point my to some code implementing this approach ?<br>
</blockquote>
<br></div>
Most of the KDL code is being designed in this way: first virtual<br>
interfaces (generic to a full family of kinematic chains), then various<br>
concrete implementations, each with its own configuration parameters, and<br>
only then embedding into a component model (be it RTT TaskContexts, or ROS<br>
nodes) with asynchronous message types.<br><font color="#888888">
<br>
Herman<br>
</font></blockquote></div><br>I would like to discuss more design of orocos robot controller than internal design of individual components.<br>I think we should start from communication between hardware/sorvo component and trajectory generation.<br>
I created oro_servo_msgs for this purpose but i developend it with IRP6 manipulators in mind.<br>I imagine that it could be common way of communication with any modern manipulator like KUKA LWR.<br>