ros_control/RosTrajectoryExecutor #149

gilwoolee · 2017-04-03T23:50:06Z

Need to review and write unit-tests.

I have some issue compiling this. (I can only compile it if I comment out test-relevant lines in root CMakeLists.txt.)

coveralls · 2017-04-04T00:07:37Z

Coverage remained the same at 85.391% when pulling b013bfd on RosTrajectoryExecutor into 4cd2795 on master.

mkoval

This is missing docstrings and unit tests. I suggest splitting the bulk of the functionality into a function that converts a aikido::Trajectory into a trajectory_msgs/JointTrajectory to simplify writing the unit tests.

For a first pass, it's probably good enough to test that function. Ideally, if you're feeling adventurous, you could also try to test the ROS integration. 😁

mkoval · 2017-04-04T00:49:56Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+// actionlib and DART both #define this macro.
+#undef DEPRECATED
+#include <actionlib/client/action_client.h>
+#undef DEPRECATED


@jslee02 Is this still necessary? I believe DART switched to the DART_DEPRECATED macro to avoid a conflict just like this.

Not necessary. DART switched to the DART_DEPRECATED since version 6.0.1.

@gilwoolee Can you switch from DEPRECATED to DART_GENERATED and remove this #undef.

mkoval · 2017-04-04T00:51:29Z

src/control/ros/CMakeLists.txt

+add_component_targets(${PROJECT_NAME} control_ros "${PROJECT_NAME}_control_ros")
+add_component_dependencies(${PROJECT_NAME} control_ros control statespace trajectory)
+
+# coveralls_add_sources(${sources})


Unless there is a strong reason not to, we should uncomment this.

mkoval · 2017-04-04T00:52:33Z

src/control/ros/RosTrajectoryExecutor.cpp

+      return "goal tolerance violated";
+
+    default:
+      return "unknown";


Nit: Include errorCode here, e.g.:

std::stringstream errorString; errorString << "unknown (" << errorCode << ")"; return errorString.str()

mkoval · 2017-04-04T00:53:12Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+    std::chrono::milliseconds connectionTimeout
+      = std::chrono::milliseconds{1000},
+    std::chrono::milliseconds connectionPollingRate
+      = std::chrono::milliseconds{20}


Nit: Rename this to connectionPollingPeriod.

mkoval · 2017-04-04T00:53:32Z

src/control/ros/RosTrajectoryExecutor.cpp

+RosTrajectoryExecutor::~RosTrajectoryExecutor()
+{
+  // Do nothing.
+  // TODO: Should we wait for the current trajectory to finish executing?


@psigen @ClintLiddick Any thoughts here?

mkoval · 2017-04-04T00:56:05Z

src/control/ros/RosTrajectoryExecutor.cpp

+  util::StepSequence timeSequence{mTimestep, true, 0., _traj->getDuration()};
+  const auto numDofs = mSkeleton->getNumDofs();
+  const auto numWaypoints = timeSequence.getMaxSteps();
+  const auto numDerivatives = std::min<int>(_traj->getNumDerivatives(), 2);


I am not sure if this is correct - it seems like it should be valid for numDerivatives to be 1, so we can execute a piecewise linear trajectory.

Why can't it be 0? Later we seem to assert that it's between 0 and 2.

Good point. 👍

mkoval · 2017-04-04T00:57:36Z

src/control/ros/RosTrajectoryExecutor.cpp

+    Eigen::VectorXd tangentVector;
+    auto state = space->createState();
+    _traj->evaluate(timeAbsolute, state);
+    space->logMap(state, tangentVector);


Using logMap here only makes sense on Rn and SO2 joints. We may want to add an explicit check to that effect. This is the compliment to the single-DOF restriction we have in #147.

Are we supporting anything other than Rn and SO2 joints? I can add a type-check before the whole conversion happens.

I don't think so. At least, I can't think of any other joints that admit a unique parameterization as a single real number. Anything else is difficult to shoehorn into the JointTrajectory message.

mkoval · 2017-04-04T00:58:28Z

src/control/ros/RosTrajectoryExecutor.cpp

+  ROS_INFO("Transition: CommState = %s TerminalState = %s",
+    _handle.getCommState().toString().c_str(),
+    _handle.getTerminalState().toString().c_str());
+#endif


Delete dead code.

mkoval · 2017-04-04T00:59:47Z

src/control/ros/RosTrajectoryExecutor.cpp

+    {
+      mPromise.set_exception(
+        std::make_exception_ptr(
+          std::runtime_error(message.str())));


We should use a custom std::runtime_error subclass here. Otherwise, it will be difficult to distinguish between "expected" (e.g. trajectory was aborted) and "unexpected" failures (e.g. an invalid parameter).

mkoval · 2017-04-04T01:00:11Z

src/control/ros/RosTrajectoryExecutor.cpp

+    mInProgress = false;
+  }
+
+  // TODO: Check mGoalTimeTolerance here as a fail-safe.


I don't know what this means and don't think it is necessary.

mkoval · 2017-04-04T01:08:21Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+    trajectory::TrajectoryPtr _traj, const ::ros::Time& _startTime);
+
+  /// Simulates mTraj. To be executed on a separate thread.
+  void spin();


We should refactor this function into a spinOnce-style callback that we can call from the Executor implemented in #151. That is potentially important because it lets us consolidate all of our various callbacks, e.g. multiple RosTrajectoryExecutors and JointStateSubscribers, into a single thread.

Nevermind! It turns out that spin() is already implemented that way. 😅

Maybe we should rename this to something more obvious? Maybe step() or tick()?

gilwoolee · 2017-04-05T22:44:28Z

src/control/ros/RosTrajectoryExecutor.cpp

+  util::StepSequence timeSequence{mTimestep, true, 0., _traj->getDuration()};
+  const auto numDofs = mSkeleton->getNumDofs();
+  const auto numWaypoints = timeSequence.getMaxSteps();
+  const auto numDerivatives = std::min<int>(_traj->getNumDerivatives(), 2);


Why can't it be 0? Later we seem to assert that it's between 0 and 2.

gilwoolee · 2017-04-05T23:16:21Z

src/control/ros/RosTrajectoryExecutor.cpp

+    }
+    else
+    {
+      message << "Execution failed";


Is this correct? It seems like you'd get here if (_handle.getCommState() == actionlib::CommState::DONE) && (terminalState == TerminalState::SUCCEEDED) .

Believe it or not, this is actually correct! 😈

There are two classes of errors in this function:

The state of the actionlib state machine is reflected by getCommState(). If the goal handle finishes for any reason - even if communication is lost with the action server - the state machine transitions to CommState::DONE.

Once in CommState::DONE, getTerminalState() indicates why the goal terminated. This can be TerminalState::SUCCEEDED or one of several error conditions.

If the goal finished in TerminalState::SUCCEEDED, then getResult() contains the result message. In the case of FollowJointTrajectoryResult, the message contains an additional error_code.

To summarize: (1) and (2) are actionlib errors and (3) is a FollowJointTrajectory error. It's possible for the actionlib call to succeed, but for executing the trajectory to fail (in fact: this is the most common case of failure we observe in practice).

The else clause here populates message with "Execution failed" to differentiate actionlib errors from controller errors. Note that isSuccessful is not set to false, so the message will only be used if the result->error_code != Result::SUCCESSFUL condition fails below.

Does that make sense? Maybe add a comment or two to explain this? 😅

gilwoolee · 2017-04-05T23:38:23Z

src/control/ros/RosTrajectoryExecutor.cpp

+  }
+
+  // Setup the goal properties.
+  // TODO: Also set the goal properties.


What does this mean?

We should eventually add support for populating the goal_tolerance, goal_time_tolerance, and path_tolerance fields in the control_msgs/FollowJointTrajectory message.

gilwoolee · 2017-04-06T00:49:45Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+{
+public:
+  RosTrajectoryExecutor(
+    ::dart::dynamics::MetaSkeletonPtr skeleton, 


Why do we need to tie each RosTrajectoryExecutor instance to a specific skeleton?

Great point! It seems like we could replace mSkeleton with a list of DOFs.

This probably comes from my lack of knowledge in ROS. My question was, can't a RosTrajectoryExecutor be very flexible and take trajectories covering different set of dofs? Will serverName refer to something specific like arm-controller-server, etc.?

gilwoolee · 2017-04-06T00:50:43Z

src/control/ros/RosTrajectoryExecutor.cpp

+  }
+
+  const auto trajectorySkeleton = space->getMetaSkeleton();
+  for (const auto dof : mSkeleton->getDofs())


If this Executor instance is not tied to a specific mSkeleton, this check will not be necessary.

mkoval · 2017-04-07T02:30:13Z

src/control/ros/RosTrajectoryExecutor.cpp

+  util::StepSequence timeSequence{mTimestep, true, 0., _traj->getDuration()};
+  const auto numDofs = mSkeleton->getNumDofs();
+  const auto numWaypoints = timeSequence.getMaxSteps();
+  const auto numDerivatives = std::min<int>(_traj->getNumDerivatives(), 2);


Good point. 👍

mkoval · 2017-04-07T02:31:33Z

src/control/ros/RosTrajectoryExecutor.cpp

+  }
+
+  // Setup the goal properties.
+  // TODO: Also set the goal properties.


We should eventually add support for populating the goal_tolerance, goal_time_tolerance, and path_tolerance fields in the control_msgs/FollowJointTrajectory message.

mkoval · 2017-04-07T02:33:26Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+{
+public:
+  RosTrajectoryExecutor(
+    ::dart::dynamics::MetaSkeletonPtr skeleton, 


Great point! It seems like we could replace mSkeleton with a list of DOFs.

mkoval · 2017-04-07T02:34:11Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+// actionlib and DART both #define this macro.
+#undef DEPRECATED
+#include <actionlib/client/action_client.h>
+#undef DEPRECATED


@gilwoolee Can you switch from DEPRECATED to DART_GENERATED and remove this #undef.

mkoval · 2017-04-07T02:57:30Z

src/control/ros/RosTrajectoryExecutor.cpp

+    }
+    else
+    {
+      message << "Execution failed";


Believe it or not, this is actually correct! 😈

There are two classes of errors in this function:

The state of the actionlib state machine is reflected by getCommState(). If the goal handle finishes for any reason - even if communication is lost with the action server - the state machine transitions to CommState::DONE.

Once in CommState::DONE, getTerminalState() indicates why the goal terminated. This can be TerminalState::SUCCEEDED or one of several error conditions.

If the goal finished in TerminalState::SUCCEEDED, then getResult() contains the result message. In the case of FollowJointTrajectoryResult, the message contains an additional error_code.

To summarize: (1) and (2) are actionlib errors and (3) is a FollowJointTrajectory error. It's possible for the actionlib call to succeed, but for executing the trajectory to fail (in fact: this is the most common case of failure we observe in practice).

The else clause here populates message with "Execution failed" to differentiate actionlib errors from controller errors. Note that isSuccessful is not set to false, so the message will only be used if the result->error_code != Result::SUCCESSFUL condition fails below.

Does that make sense? Maybe add a comment or two to explain this? 😅

gilwoolee · 2017-04-09T07:01:24Z

@mkoval I addressed most of your comments, which resulted in two major changes:

a new conversion function from Trajectory to trajectory_msgs::JointTrajectory in Conversions.hpp
a new Exception class that inherits from std::runtime_error. I am actually a bit not sure what exactly how this class will be used and what methods we need here. Your comment was:

We should use a custom std::runtime_error subclass here. Otherwise, it will be difficult to distinguish between "expected" (e.g. trajectory was aborted) and "unexpected" failures (e.g. an invalid parameter).

Could you add to this? Should I make an enum type to classify the errors into expected and unexpected?

Unit tests are added for the new conversion method. I still need to write unit tests for RosTrajectoryExecutor, but since I've already made some big changes, it'd be great if you could comment on them while I work on the tests.

@jslee02 could you take a look too? Thanks a lot!

coveralls · 2017-04-09T07:07:40Z

Coverage remained the same at 85.208% when pulling f750b32 on RosTrajectoryExecutor into a9b50ae on master.

jslee02

I made some comments mostly on styles. The only blocker is the undeclared variable numDofs. I guess it's space->getDimension().

jslee02 · 2017-04-10T18:59:20Z

src/control/ros/Conversions.cpp

+  auto state = space->createState();
+  trajectory->evaluate(timeAbsolute, state);
+  space->logMap(state, tangentVector);
+  assert(tangentVector.size() == numDofs);


numDofs is not declared.

jslee02 · 2017-04-10T19:01:25Z

src/control/ros/Conversions.cpp

+  const auto numDerivatives = std::min<int>(trajectory->getNumDerivatives(), 1);
+  const auto timeAbsolute = trajectory->getStartTime() + timeFromStart;
+
+  Eigen::VectorXd tangentVector, jointTangentVector;


Nit: Declaring multiple variables on one line is not our convention.

jslee02 · 2017-04-10T19:14:46Z

src/control/ros/Conversions.cpp

+  assert(0 <= numDerivatives && numDerivatives <= 2);
+  const std::array<std::vector<double>*, 2> derivatives{
+    &waypoint.velocities, &waypoint.accelerations};
+  for (int iderivative = 1; iderivative <= numDerivatives; ++iderivative)


Nit: It took a bit to understand what iderivative means. I think it would be nicer if we change the name to be easier to distinguish the index segment and derivative for the readability like iDerivative, derivativeIndex, or derivIndex.

This is the convention I typically use for naming loop variables, so I suspect you're going to have a lot more comments like this on the other ros_control pull requests. 😅

I generally like this convention, but I am fine with @gilwoolee renaming the variables if you insist... 😞

jslee02 · 2017-04-10T19:33:42Z

include/aikido/control/ros/Conversions.hpp

+/// Supports only 1D RnJoints and SO2Joints.
+/// \_param[in] trajectory Aikido trajectory to be converted.
+/// \_param[in] indexMap Mapping between trajectory's joints and ros joints.
+/// \_param[in] timestep Timestep between two consecutive waypoints.


Nit: Please remove the leading underscores.

jslee02 · 2017-04-10T20:04:08Z

include/aikido/control/ros/Conversions.hpp

+/// \_param[in] trajectory Aikido trajectory to be converted.
+/// \_param[in] indexMap Mapping between trajectory's joints and ros joints.
+/// \_param[in] timestep Timestep between two consecutive waypoints.
+const trajectory_msgs::JointTrajectory convertTrajectoryToRosTrajectory(


Nit: Returning const qualifier for non-reference rvalue is meaningless. Related SO posts: 1, 2

jslee02 · 2017-04-10T22:59:26Z

src/control/ros/Conversions.cpp

+  const auto& waypoints = jointTrajectory.points;
+  for (size_t iwaypoint = 1; iwaypoint < waypoints.size(); ++iwaypoint)
+  {
+    Eigen::VectorXd nextPosition, nextVelocity, nextAcceleration;


Nit: One variable declaration per one line. (see above)

jslee02 · 2017-04-10T23:06:04Z

src/control/ros/Conversions.cpp

+    currTimeFromStart = nextTimeFromStart;
+  }
+
+  return std::move(trajectory);


std::move( ) is unnecessary. Related SO answer.

jslee02 · 2017-04-10T23:16:26Z

src/control/ros/Conversions.cpp

+    }
+
+    // For RnJoint, supports only 1D.
+    if (rnJoint && rnJoint->getDimension() > 1)


I think we need to explicitly check whether the dimension is not one because it can be zero.

jslee02 · 2017-04-10T23:24:25Z

src/control/ros/RosTrajectoryExecutor.cpp

+std::future<void> RosTrajectoryExecutor::execute(
+  trajectory::TrajectoryPtr traj)
+{
+  static const ::ros::Time invalidTime;


Passing invalid time is intentional? I think we could simply pass the current time using ros::Time::now().

Passing an invalid time is intentional. Passing ros::Time::now() computes the timestamp in this process, whereas passing ros::Time() causes the controller to compute the timestamp when it receives the message.

This difference can be significant if the client and server are running on different computers.

jslee02 · 2017-04-10T23:42:29Z

include/aikido/control/ros/Conversions.hpp

+/// \_param[in] trajectory Aikido trajectory to be converted.
+/// \_param[in] indexMap Mapping between trajectory's joints and ros joints.
+/// \_param[in] timestep Timestep between two consecutive waypoints.
+const trajectory_msgs::JointTrajectory convertTrajectoryToRosTrajectory(


I would like to suggest patterning the two convert function names. convertJointTrajectory() doesn't convey the original and target type in the function name unlike to the latter function name, and convertTrajectoryToRosTrajectory() uses only Trajectory to refer JointTrajectory unlike to the former function name.

We could put both of original and target type name to the function name like convertJointTrajectoryToRosJointTrajectory() but this might be too long. So my preference is including only the goal type to the function name so that we can call the correct conversion functions depending on the target type. We don't need to worry about the original type since functions can overload for the argument types, which is the original type, but not for the return type.

TL;DR: I suggest renaming the two function names to something like:

convertToSplineJointTrajectory() convertToRosJointTrajectory() // or toSplineJointTrajectory() toRosJointTrajectory()

mkoval · 2017-04-11T01:23:24Z

include/aikido/control/ros/RosTrajectoryExecutionException.hpp

+
+  RosTrajectoryExecutionException(
+    const std::string& what,
+    actionlib::TerminalState terminalState);


TerminalState is an enum, so there is no point in avoiding a copy here.

mkoval · 2017-04-11T01:26:19Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+    std::chrono::milliseconds connectionTimeout
+      = std::chrono::milliseconds{1000},
+    std::chrono::milliseconds connectionPollingPeriod
+      = std::chrono::milliseconds{20}


I am generally supportive of this, but I am not sure how to implement it. We store these durations in member variables, so this would require templateing the entire class on DurationA and DurationB. It's possible we could do some type erasure shenaniganz to avoid this, but I don't think it's worth the effort at this point.

mkoval · 2017-04-11T01:27:35Z

include/aikido/control/ros/RosTrajectoryExecutor.hpp

+
+  bool waitForServer();
+
+  void transitionCallback(GoalHandle handle);


Nope. This function is passed as a callback to ActionClient::sendGoal, which expects this signature.

mkoval · 2017-04-11T01:28:36Z

src/control/ros/Conversions.cpp

+  assert(0 <= numDerivatives && numDerivatives <= 2);
+  const std::array<std::vector<double>*, 2> derivatives{
+    &waypoint.velocities, &waypoint.accelerations};
+  for (int iderivative = 1; iderivative <= numDerivatives; ++iderivative)


This is the convention I typically use for naming loop variables, so I suspect you're going to have a lot more comments like this on the other ros_control pull requests. 😅

I generally like this convention, but I am fine with @gilwoolee renaming the variables if you insist... 😞

mkoval · 2017-04-11T01:29:05Z

src/control/ros/Conversions.cpp

+void reorder(std::map<size_t, size_t> indexMap,
+  const Eigen::VectorXd& inVector, Eigen::VectorXd* outVector)
+{
+  *outVector = Eigen::VectorXd::Zero(inVector.size());


This is a helper function in an anonymous namespace, so I suggest just adding an assert.

mkoval · 2017-04-11T01:31:18Z

src/control/ros/RosTrajectoryExecutor.cpp

+std::future<void> RosTrajectoryExecutor::execute(
+  trajectory::TrajectoryPtr traj)
+{
+  static const ::ros::Time invalidTime;


Passing an invalid time is intentional. Passing ros::Time::now() computes the timestamp in this process, whereas passing ros::Time() causes the controller to compute the timestamp when it receives the message.

This difference can be significant if the client and server are running on different computers.

coveralls · 2017-04-11T02:23:14Z

Coverage remained the same at 85.208% when pulling 9b9ba1e on RosTrajectoryExecutor into a59975f on master.

…obotics/aikido into convertJointTrajectory

…obotics/aikido into RosTrajectoryExecutor

coveralls · 2017-04-12T01:48:31Z

Coverage decreased (-0.01%) to 85.208% when pulling 65292c0 on RosTrajectoryExecutor into 8f1a94b on convertJointTrajectory.

coveralls · 2017-04-13T14:48:55Z

Coverage decreased (-0.01%) to 85.208% when pulling 6ad1d9c on RosTrajectoryExecutor into 8f1a94b on convertJointTrajectory.

jslee02

This recent change looks good.

However, the ROS control code is not being tested by CI since actionlib is not found.

Conflicts: include/aikido/control/ros/Conversions.hpp src/control/ros/CMakeLists.txt src/control/ros/Conversions.cpp tests/control/ros/CMakeLists.txt

and use find modules to find actionlib and control_msgs

coveralls · 2017-04-14T03:14:20Z

Coverage decreased (-2.3%) to 82.204% when pulling 2537bfd on RosTrajectoryExecutor into 2b21ddd on master.

jslee02

Okay! CI now builds and tests all the Aikido components (except for rviz testing) without zero warnings.

gilwoolee added 6 commits April 2, 2017 16:35

ros/Conversions

43ea8bf

Cleaning up CMakeLists.

e3f783b

CMakeLists cleanup

4391bf9

Style change to match AIKIDO style guide.

338f1b7

Checking joint-name matches

aafa1cf

Initial commit for RosTrajectoryExecutor

b013bfd

gilwoolee self-assigned this Apr 3, 2017

mkoval mentioned this pull request Apr 3, 2017

Aikido ROS control #111

Closed

Temporarily removing tests in CMakeLists.

793a23a

gilwoolee requested review from jslee02 and aditya-vk April 3, 2017 23:54

jslee02 added this to the Aikido 0.1.0 milestone Apr 4, 2017

mkoval requested changes Apr 4, 2017

View reviewed changes

mkoval reviewed Apr 4, 2017

View reviewed changes

gilwoolee added 2 commits April 4, 2017 18:04

Merge branch 'master' into convertJointTrajectory

a2e0ed8

Addressing some of Mike's comments

22ba7b4

gilwoolee commented Apr 6, 2017

View reviewed changes

gilwoolee added 3 commits April 6, 2017 20:29

Addressing Miks and JS's comments.

9e09781

Merge branch 'master' into convertJointTrajectory

6714011

Minor bug fix, adding one test for joint mapping.

785871b

mkoval requested changes Apr 7, 2017

View reviewed changes

gilwoolee added 6 commits April 7, 2017 10:05

Merge branch 'master' into convertJointTrajectory

c98e8ea

Adding conversion from trajectory to ros trajectory.

5a655e5

Addressing Mike's comments.

d4bdaa3

Merge master and latest Conversions.cpp

300e050

Line wrapping

d0d29dc

Removing a line.

f750b32

jslee02 suggested changes Apr 10, 2017

View reviewed changes

mkoval requested changes Apr 11, 2017

View reviewed changes

jslee02 added 2 commits April 10, 2017 21:36

Merge branch 'master' into convertJointTrajectory

3a10630

Merge branch 'master' into RosTrajectoryExecutor

9b9ba1e

gilwoolee added 5 commits April 11, 2017 17:14

Addressing Mike's comments

064aa8a

Merge branch 'convertJointTrajectory' of https://github.com/personalr…

8f1a94b

…obotics/aikido into convertJointTrajectory

Changing method names

fc70347

Merge branch 'convertJointTrajectory' of https://github.com/personalr…

4fd63b7

…obotics/aikido into RosTrajectoryExecutor

Addressing Mike and JS's comments.

65292c0

gilwoolee changed the base branch from master to convertJointTrajectory April 12, 2017 01:37

gilwoolee mentioned this pull request Apr 12, 2017

Adding an abstract BarrettHandPositionCommandExecutor class #166

Merged

Changing constructor to templated, removing reorderMap.

6ad1d9c

jslee02 suggested changes Apr 13, 2017

View reviewed changes

jslee02 added 3 commits April 13, 2017 14:15

Suppress warning

5db6d4e

Merge remote-tracking branch 'origin/master' into RosTrajectoryExecutor

6b71cb1

Conflicts: include/aikido/control/ros/Conversions.hpp src/control/ros/CMakeLists.txt src/control/ros/Conversions.cpp tests/control/ros/CMakeLists.txt

Fix Conversions

98e8440

jslee02 changed the base branch from convertJointTrajectory to master April 13, 2017 18:38

jslee02 added 2 commits April 13, 2017 22:37

Add missing dependencies to package.xml

5f0f1ae

and use find modules to find actionlib and control_msgs

Suppress warnings

2537bfd

jslee02 approved these changes Apr 14, 2017

View reviewed changes

brianhou mentioned this pull request Apr 14, 2017

ros_control/RosJointStateClient #150

Merged

brianhou merged commit 1b3fc38 into master Apr 14, 2017

jslee02 deleted the RosTrajectoryExecutor branch April 15, 2017 00:33

jslee02 mentioned this pull request Apr 16, 2017

rviz module is not being tested by CI #169

Closed

jslee02 mentioned this pull request Apr 27, 2017

aikido rviz always fails #128

Closed

brianhou mentioned this pull request Jun 27, 2017

Update with new aikido method name. personalrobotics/rewd_controllers#12

Merged


		bool waitForServer();

		void transitionCallback(GoalHandle handle);

ros_control/RosTrajectoryExecutor #149

ros_control/RosTrajectoryExecutor #149

Conversation

gilwoolee commented Apr 3, 2017 • edited Loading

coveralls commented Apr 4, 2017

mkoval left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gilwoolee commented Apr 9, 2017

coveralls commented Apr 9, 2017

jslee02 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Apr 11, 2017

coveralls commented Apr 12, 2017

coveralls commented Apr 13, 2017

jslee02 left a comment

Choose a reason for hiding this comment

coveralls commented Apr 14, 2017

jslee02 left a comment

Choose a reason for hiding this comment

gilwoolee commented Apr 3, 2017 •

edited

Loading