personalrobotics / pr_ros_controllers

ros_control controller plugins developed by the Personal Robotics Lab at CMU

pr_ros_controllers

PRL controllers that are compatible with the ros2-control framework and are ready to use with many robots, MoveIt2 and Navigation2.

Many of these controllers pull heavily from the upstream ros2_controllers.

pr_ros_controllers's Issues

Refactor REWD controllers into base DARTController class

Handle init boilerplate in base class.

Check Joint Names in Request Match Names from URDF

In REWD controllers. Reject messages that specify incorrect joint names.

Add Doxygen Comments to Controllers, Messages, and Interfaces

Split pr_control_msgs into separate repository

Build error - rewd_controllers

When I try to build a project about ada, i got this message. According to here, I tried
sudo apt-get install ros-indigo-ros-control ros-indigo-ros-controllers
But it still not build.

Error message:
Errors << rewd_controllers:cmake /home/shen/research/ada_block_sorting/logs/rewd_controllers/build.cmake.000.log CMake Error at /home/shen/research/ada_block_sorting/src/pr_ros_controllers/rewd_controllers/CMakeLists.txt:13 (message): controller_interface package must be at least version 0.10.0, not packaged in Indigo. Please upgrade to Jade or build the ros_control packages from source.

`cd /home/shen/research/ada_block_sorting/build/rewd_controllers; catkin build --get-env rewd_controllers | catkin env -si /usr/bin/cmake /home/shen/research/ada_block_sorting/src/pr_ros_controllers/rewd_controllers --no-warn-unused-cli -DCATKIN_DEVEL_PREFIX=/home/shen/research/ada_block_sorting/devel/.private/rewd_controllers -DCMAKE_INSTALL_PREFIX=/home/shen/research/ada_block_sorting/install -DCMAKE_BUILD_TYPE=RelWithDebInfo; cd -
...............................................................................

Failed << rewd_controllers:cmake [ Exited with code 1 ]
Failed <<< rewd_controllers [ 2.5 seconds ] `

Poling Thread or New Thread for Each Action Goal

Should we create a new thread for each action goal (current implementation), or have a single thread that pulls goals off a queue or poles until there's a goal available? In REWD controllers.

Support file:// URIs to load URDF

Make helper function that creates a default ResourceRetriever and use it in grav comp and position controllers (later in DARTController/REWDController base class).

The ForceGate Controller (JTC) should inherit from the main JTC

Ideally, the force-gated joint trajectory controller (JTC) should inherit from the main ROS JTC, like the position and velocity controllers do. The reason we don't do this is that the fix to the non-0 terminal velocity bug has not yet been backported to humble. Once it is, we should update the JTC to follow a similar inheritance paradigm as the position/velocity controllers.

Enforce Joint Limits in REWD Controllers

Support cancelling and preemption in PositionCommand

Allow Subset of Joints to be Controlled in JointGroupPosCtrl

position_command_interface should register joint names

Right now, you register a device (group) name instead of the expected individual joint names. This means that a position_command controller and a position controller can both be controlling the same joint at the same time, unless special logic is inserted. This can cause unintended consequences.

Use FollowJointTrajectoryAction instead of custom SetPositionAction

From @mkoval:
I am wondering if we can ditch the custom actionlib command and simply use FollowJointTrajectoryAction. There are two key advantages. First, we don't have to define yet-another custom message type. Second, we can slowly start supporting more of these features in the future.

This is serious overkill for our application, so we would require that the goal:

• all joints are specified
• a single waypoint
• does not contain velocities or accelerations
• time_from_start, goal_tolerance, joint_tolerance, and goal_time_tolerance are all zero

There are a few key advantages:

• reduces the number of message types (like you said)
• the user's code no longer has to depend on pr_ros_controllers
• we can re-use the same client code that we do for FollowJointTrajectory

If we need more custom fields, we will close this issue, but if not, we should standardize.