[ros-users] extending trajectory_planner by inheriting from other classes

Eitan Marder-Eppstein eitan at willowgarage.com
Mon Oct 25 18:44:55 UTC 2010


Dave,

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:
https://code.ros.org/trac/ros-pkg/newticket 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.

Hope all is well,

Eitan

On Sat, Oct 23, 2010 at 1:37 AM, David Feil-Seifer <
david.feilseifer at gmail.com> wrote:

> I have found the trajectory_planner and trajectory_planner_ros classes
> from the base_local_planner package rather useful. However, I am
> trying to extend those classes to make trajectory planner aware of
> more than just goal, obstacles, and global path.
>
> Rather than just copy the classes outright, I am trying to make a
> class people_planner and people_planner_ros that inherits from
> trajectory_planner and trajectory_planner_ros, respectively. I then
> re-implement the generate_trajectory function from trajectory_planner
> (along with other smaller changes, but that is the main one) to fit my
> needs. However, this is impossible with the current version of
> trajectory_planner, since functions are not virtual, and data are
> declared private instead of protected.
>
> Currently, I am able to just copy the headers to my local package, and
> make the changes that I want and include those rather than the headers
> from base_local_planner. Then I simply include the base_local_planner
> library, and the header changes and variable protection is as I want
> it, but that seems less than optimal. Is there a design decision
> behind not having data declared protected and functions being virtual?
>
> Thanks in advance,
> Dave
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101025/b494bb82/attachment-0003.html>


More information about the ros-users mailing list