Jeremy Zoss's profile - activity

For what it's worth: Blue Workforce, the manufacturers of the Ragnar robot and owner of its driver repository declared b

I know I'm jumping the gun a bit, but I was wondering if anyone's had any experience integrating custom inverse-kinematics plugins (e.g. ikfast) with moveit.

I've created an ikfast solver for my robot, and followed the instructions at wiki/Industrial/Tutorials/Create_a_Fast_IK_Solution to generate a plugin. But it feels like this plugin may not be moveit-compatible??

When I run the moveit setup_assistant, I don't see my new plugin in the list of kinematics solvers (only KDL and PR2 solvers). If I manually edit kinematics.yaml to point to my new plugin, I get an error when running the planning environment: According to the loaded plugin descriptions, the class _____ does not exist. Declared types are ...KDL... and ...PR2...

I also checked the moveit documentation for Groovy/Kinematics/Custom_Plugin, but it doesn't exist yet.

Does anyone have any pointers, or is my best bet to wait for the documentation/code to be officially released?

Thanks!

Have you followed the steps listed on the MoveIt Tutorials page: 3D Perception/Configuration? In particular, you need t

I'm working on providing MoveIt support for a parallel (Delta-style) robot. Are there any examples of current parallel-mechanism robots that are being used with ROS?

I have seen discussions from 2011 and 2013, but no links to actual code.

I understand that we'll need to "cheat" a little in representing the robot in URDF, and provide our own FK/IK routines. I think I've got a good handle on the required steps, but it would be helpful to review any other example implementations, if available.

The URDF is created with all floating joints. The tool plate is defined relative to base_link (a hack). The robot publishes 4 driven joint positions. A custom state_publisher node performs kinematics to compute the positions of all 8 links and the tool plate, and publishes the resulting transform

We've actually completed this work, and published the ROS package for the delta-style Ragnar robot back in December 2015.

I am creating a Unit-Test program for my catkin package, using gtest. I have set up my CMakeLists.txt to compile the unit-test program and link against my package library. In one of the tests, I would like to read in an external data file to use in the test routine. This data file is in the same directory as my utest.cpp file: <package>/test/test.dat.

In rosbuild, I run tests using make test, and the working directory is the package root. So, I can reference the test data file using a relative path: test/test.dat.

In catkin, I run make run_tests and the working directory is in the catkin_ws/devel tree. The build process does not copy my data file to this tree, so it is unclear how I should specify the relative path to my data file.

What is the best-practice for dealing with test data files under catkin?
NOTE: I don't want the test executable or data-file to be installed in the final package. These are for unit-test purposes only.

In case it's helpful, here's the relevant section of my CMakeLists.txt:

catkin_add_gtest(test_myPackage test/utest.cpp)
target_link_libraries(test_myPackage myPackage_lib)

EDIT :
NOTE: William has updated his example code, so the following bugs have been fixed. I'm leaving in this discussion for historical reasons, but the updated code should work as-is

I tried running the example code provided by @William below. When I rename test.dat to test1.dat, both tests still pass. I think the issue is with how the test code loops over the data file lines. No tests are run if the file is not found, but neither is an error thrown. Adding the following line helps to catch this case:

in.open("data/test.dat", std::fstream::in);
ASSERT_FALSE(in.fail());    // this is the new line
int op1, op2, expected;
while (in >> op1 >> op2 >> expected) {
  EXPECT_EQ(expected, test_with_data::add(op1, op2));
}

Once that line is added, both tests fail with the mis-named test1.dat file. However, once the file is restored to the correct name, the second method still fails. If I add a print of the current working directory to test_with_data2.cpp, it reports: ws/build/test_with_data/test. It looks like the WORKING_DIRECTORY argument is relative to the build directory. However, if you use an absolute path, the 2nd test method works as expected:

catkin_add_gtest(${PROJECT_NAME}2-test test/test_with_data2.cpp WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}/test)