API review

Proposer: Wim Meeussen

Present at review:

• Sachin
• Eitan
• Stu
• Vijay
• Melonee
• Wim
• Tully

Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Stu

• Is the velocity completely ignored?

• It doesn't necessarily call a joint_trajectory_action. It just invokes a JointTrajectory action which happens to execute the trajectory.

• Could we separate this into two pieces: one piece that smooths the trajectory, and another piece that passes the trajectory off to the smoother, and then passes the result off to the trajectory controller? The benefit is that you can change the smoother just by pointing the commanding piece's action client at a different namespace. The action for the smoother might look something like this:

SmoothTrajectory.action:

trajectory_msgs/JointTrajectory trajectory

# Maybe:
float32[] velocity_limit
float32[] acceleration_limit
---
trajectory_msgs/JointTrajectory smoothed
---

Tully

• I feel like the ability to "extend" the trajectory in time should be parameterized in such a way that if the smoothing takes too much elongation the action will abort. Otherwise you have no clue how long the smoothed trajectory will take.

Sachin

• All the functionality here is a duplication of the functionality in the trajectory_filters package. Can we use that package instead of adding yet another duplicated functionality which may confuse users? I can take this code and add it in as another smoother and you can configure it directly from xml (just like filters).

• Why is this directly calling the controller? This should just be a library that smooths/filters trajectories. Have two components in here - a C++ api and a ROS api. This is what the trajectory_filter_server in the trajectory_filters package does.

Meeting agenda

To be filled out by proposer based on comments gathered during API review period

Notes

• A consistent method is valuable.
  • The filters currently do it.
  • The filters however requires c++ a ROS API would be nice, consistent service or action interface
  • nodelets could be another solution

  • Standardize on action API

    • for each different filter/generator

Three elements Controller - trajectory in Generator - trajectory from planner, trajectory to controller Plugin - generator calls out to get the trajectory smoothed or other things. (mode TBD)

How do we deal with failures?

• Say in plugins, can return back error code in action result

• use same feedback as controller

* Plugin is connected as Service

Parking Lot

• nodelets are deprecating filters except for in realtime (sachin want's more publicity)
• deprecating services with actionlib service wrapper

Conclusion

Package status change mark change manifest)

• Action items that need to be taken.

• Major issues that need to be resolved