search

ros-controls / ros_controllers

Generic robotic controllers to accompany ros_control
http://wiki.ros.org/ros_control
BSD 3-Clause "New" or "Revised" License
571 stars 525 forks source link

High level api for diff_drive_controller #154

Closed 130s closed 9 years ago

130s commented 10 years ago

From experience on interacting novice ROS users (but well acquainted on robotics) I'm tempted to add high level, more user-friendly api in general. For 2D navigation operation (regardless elevation), some functions I'd like to see might be:

(Names and args can be optimized.)

I thought either move_base or diff_drive_controller might be the right place to add things like above, or at least the right place to discuss. I just started applying ros_control to my software but hope I'm not missing basic concepts of it.

bmagyar commented 10 years ago

Hello Isaac, Could you please elaborate on in which context would you use such an API? This controller works by subscribing to a topic typed with geometry_msgs/Twist, which let's you define the desired speed and orientation delta while the controller is accumulating these changes and spits out an odometry estimation.

In it's current state the diff_drive_controller is a ros_control plugin which takes control of the configured velocity-controlled joints and implements the behaviour is described above. If you take all that off it's nothing but the differential drive math of textbooks.

As the other controllers in ros_control you usually don't have direct access to the controller itself, because you load them in the controller_manager, it let's the controller access to the hardware abstraction layer through and sends it's commands to the joints through that.

A higher level API that makes a robot move from point A to B in a given duration belongs to the move_base or other higher level components of the navigation stack I believe.

adolfo-rt commented 10 years ago

If the interface you want to expose can be implemented in a non-realtime node that talks to the controller through its existing ROS API, I'd say that's the best way to go. I tend to prefer having realtime controllers as simple as possible, and to push these convenience constructs to a higher level whenever possible.

The thing with multiple command entry points is that the controller must maintain a consistent internal state, and enforcing a policy for canceling/queuing/merging goals from all available entry points. By having a simpler controller API, we defer these choices to the client, who more often than not knows better which policies make more sense for its application.

Let me know your thoughts on this.

130s commented 9 years ago

Thanks for the insight you two. Sounds like my preliminary guess was right; the role of high-level api I think of and diff_driver_controller is clearly separated. Maybe I'll discuss in move_base repo (I'm not yet sure that the most suitable place though) when a 2d navigation project begins in a month.

geometry_msgs/Twist is generic, yes, in the ROS community. If we could provide even more generic api somewhere with ROS-agnostic syntax (as in my OP), that would even lower the barrier for novice programmers (this becomes nontrivial for us at TORK where we've dealt with dozens of people new to ROS).