Laser Controller API review
Proposer: Vijay Pradeep
Present at review:
- List reviewers
- Vijay Pradeep
- Stu Glaser
- Wim Meeussen
- Eric Berger
ROS API defined at pr2_mechanism_controllers/LaserScannerTrajController
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.
Vijay
Some possible things to discuss
Controller Name (LaserController, LaserTiltController, etc)
Do we need a special message (pr2_msgs/LaserScannerSignal) to interface with laser snapshotter? Could it be something more generic?
- Do we need the same functionality exposed as both a message AND service?
set_traj_cmd is a more generic & flexible version of set_periodic_cmd. Do we need both?
Stu
Make max_rate and max_acc consistent. I suggest max_velocity and max_acceleration
It's publishing pr2_msgs/LaserScannerSignal. Does this message need to get moved up into a higher stack (should pr2_controllers depend on pr2_common?)?
When I see set_periodic_cmd and set_traj_cmd, I assume that the traj_cmd isn't periodic.
- The subscriptions and services have the same names.
Meeting agenda
To be filled out by proposer based on comments gathered during API review period
Conclusion
Param & Msg: max_rate -> max_velocity, or remove if not needed
Param: max_acc -> max_acceleration
msg field: max_accel -> max_acceleration
d_error_filter -> velocity_filter
Plugin Name: LaserScannerTrajControllerNode -> LaserScannerTrajController
- msg: time: Use a ros::Duration. Call it time_from_start
msg: pos -> position
Big Changes [to punt on]
- Use the trajectory_msg/JointTrajectory to send commands
- Generate Cubic splines outside of controller, and send it segmented linear blended sections
Package status change mark change manifest)
Action items that need to be taken.
Major issues that need to be resolved