Dave,<div><br></div><div>The original API review for the trajectory planner focused solely on the public C++ functions and ROS interface. As such, since the private API of the classes could change, we decided not to make things virtual/protected. Also, there was no real use case at the time to drive designing things differently. If some virtual methods and protected members are all you need to make the changes you want, feel free to submit a patch here: <meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="https://code.ros.org/trac/ros-pkg/newticket">https://code.ros.org/trac/ros-pkg/newticket</a> and I'll look into putting it into navigation. However, you should realize that there's no real commitment to stability for that private API... it hasn't changed in awhile now, but it still might.</div>
<div><br></div><div>Hope all is well,</div><div><br></div><div>Eitan<br><br><div class="gmail_quote">On Sat, Oct 23, 2010 at 1:37 AM, David Feil-Seifer <span dir="ltr"><<a href="mailto:david.feilseifer@gmail.com" target="_blank">david.feilseifer@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have found the trajectory_planner and trajectory_planner_ros classes<br>
from the base_local_planner package rather useful. However, I am<br>
trying to extend those classes to make trajectory planner aware of<br>
more than just goal, obstacles, and global path.<br>
<br>
Rather than just copy the classes outright, I am trying to make a<br>
class people_planner and people_planner_ros that inherits from<br>
trajectory_planner and trajectory_planner_ros, respectively. I then<br>
re-implement the generate_trajectory function from trajectory_planner<br>
(along with other smaller changes, but that is the main one) to fit my<br>
needs. However, this is impossible with the current version of<br>
trajectory_planner, since functions are not virtual, and data are<br>
declared private instead of protected.<br>
<br>
Currently, I am able to just copy the headers to my local package, and<br>
make the changes that I want and include those rather than the headers<br>
from base_local_planner. Then I simply include the base_local_planner<br>
library, and the header changes and variable protection is as I want<br>
it, but that seems less than optimal. Is there a design decision<br>
behind not having data declared protected and functions being virtual?<br>
<br>
Thanks in advance,<br>
Dave<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br></div>