barretttechnology / libbarrett Goto Github PK

It would be nice to include a DOF check so the program fails gracefully for a Proficio.

We're trying to run the bt-wam-zerocal script on HERB. We ran into two issues:

1. the default home configuration is infeasible (set in zerocal.conf)
2. several of the configurations in the zerocal sequence are infeasible (set in calibration.conf)

We attempted to fix (1) by changing zerocal.conf to be:

home = ( 3.14, -1.96, 0.0, -0.86, 1.30, 0.00, 2.99 );

We attempted to fix (2) by changing the sequence of configurations in calibration.conf to:

wam7w:
(
    (1, ( 3.14, -1.57,   0.0,  1.57,   0.0,   0.0,   0.0 ), "the J1 scribe marks are aligned"),
    (3, ( 4.71, -1.57,   0.0,  1.57,   0.0,   0.0,   0.0 ), "the plastic elbow covers are vertical"),
    (2, ( 3.14,   0.0,   0.0,   0.0,   0.0,   0.0,   0.0 ), "the inner link is vertical"),
    (4, ( 3.14,   0.0,   0.0,   0.0,   0.0,   0.0,   0.0 ), "the J4 scribe marks are aligned"),
    (6, ( 3.14, -1.57,   0.0,  1.57,   0.0,   0.0,   0.0 ), "the tool-plate is horizontal"),
    (5, ( 3.14, -1.57,   0.0,   0.0,   0.0,   0.0,   0.0 ), "the J5 scribe marks are aligned"),
    (7, ( 3.14, -1.57,   0.0,  1.57,   0.0,   0.0,   0.0 ), "the J7 scribe marks are aligned")
);

With these changes, the bt-wam-zerocal script worked fine. However, the output zerocal.conf has the wrong home configuration:

home = ( 0.434197385, -1.96, 0.0, -0.86, 1.30, 0.00, 2.99 );
zeroangle = ( 3.572641255, 2.788777072, 1.412796306, 3.247437328, 0.1487961364, 6.09450567, 5.677262896 );

If we re-run the zero calibration, the arm (and especially J1) no longer go through the correct sequence of joint angles. We assume this is because the home configuration here does not reflect our changes. If I manually update this home configuration by adding our offsets, we are able to successfully run the calibration again.

However, if we start ex02_hold_position in this state, the WAM violently accelerates and we have to immediately e-stop it. Our hypothesis is that this is caused by the bad zero calibration. In hindsight, we think it may also be caused by an incorrect gravity vector (see below).

There are two other aspects of our setup that might be causing problems:

1. our j1 has modified joint limits (from 0.52 to 5.76 rad)
2. our WAM is mounted vertically, so the default gravity vector may be wrong

@bzenowich: Could you give us advice on how to proceed? Thanks!

Tagging @aaronjoh @cdellin @siddhss5.

Eigen error is thrown since the program manipulates the joint values of the variable jt_type which is > 3 and hence it fails for Proficio.

The current commit does not build, due to a merge state in the version numbers in CMakeLists.txt introduced from d4e417.

<<<<<<< .working
set(libbarrett_VERSION_MAJOR 1)
set(libbarrett_VERSION_MINOR 3)
=======

does not work when config files are in ~/.barrett

I am trying to build a .deb package of libbarrett using CPack. I followed the instructions in the README and tried running make package with the CONFIG_PACKAGE and CONFIG_DEBIAN flags.

This is the entire sequence of commands I ran:

mkdir build && cd build
cmake -DNON_REALTIME:bool=1 -DCONFIG_PACKAGE:bool=1 -DCONFIG_DEBIAN:bool=1 \
      -DINSTALL_EXAMPLES:bool=0 -DINSTALL_SANDBOX:bool=0 ..
make && make package

The make command succeeds. The make package command does produce a .deb package, also prints a bunch of warnings:

[100%] Built target barrett
Run CPack packaging tool...
CPack: Create package using DEB
CPack: Install projects
CPack: - Run preinstall target for: libbarrett
CPack: - Install project: libbarrett
Traceback (most recent call last):
>>> Source: /home/prdemo/libbarrett_source/config
>>> Destination: /etc/barrett
  File "/home/prdemo/libbarrett_source/programs/install_config_files", line 180, in <module>
    main()
  File "/home/prdemo/libbarrett_source/programs/install_config_files", line 59, in main
    os.mkdir(backupDir)
OSError: [Errno 13] Permission denied: '/etc/barrett/BACKUP-20150327-0'
chown: invalid group: `prdemo:prdemo'
/sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
CPack: Create package
CPack: - package: /home/prdemo/libbarrett_source/build/libbarrett-1.2.3_x86_64.deb generated.

Installing the resulting .deb package with dpkg -i libbarrett-1.2.3_x86_64.deb fails with a similar error message:

Selecting previously unselected package libbarrett-dev.
(Reading database ... 303290 files and directories currently installed.)
Unpacking libbarrett-dev (from libbarrett-1.2.3_x86_64.deb) ...
Setting up libbarrett-dev (1.2.3) ...
Current user is = prdemo
Changing owner of examples directory located: /home/prdemo/libbarrett_examples to prdemo
chown: invalid group: `prdemo:prdemo'
dpkg: error processing libbarrett-dev (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 libbarrett-dev

It seems incorrect to chown files in the Debian package based on who is running the build. Also, the current logic in CMakeLists.txt assumes that there exists a group with the same name as the the current user. This is not true in our case and causes the chown: invalid group: prdemo:prdemo error.

More importantly, am I following the right process to build a package?

kHi,

Today I compiled libbarrett and I ran into the following compile error:

libbarrett/programs/autotension.cpp:553:63: error: redeclaration of ‘bool AutoTension<DOF>::engage(int, double)’ may not have default arguments [-fpermissive]
 bool AutoTension<DOF>::engage(int motor, double timeout = 20.0) {

This error occurs because the default value for the argument timeout is in the function definition instead of the function declaration. From cppreference.com:

For member functions of class templates, all defaults must be provided in the initial declaration of the member function.

When changing the function declaration to (line 215)

    bool engage(int motor, double timeout=20.0);

And removing the default value from the function definition (line 553):

template<size_t DOF>
bool AutoTension<DOF>::engage(int motor, double timeout) {

The problem was resolved.

Note that I'm used GCC 5.4.0 to compile

Is there any documentation or example programs available for the python bindings? Are they equivalent to all the CPP libraries?