yarprobotinterface segfault when using Vizzy's cartesian interface

[plinioMoreno]

Hi all,

I had this error before (around six months ago or so), but I did not have time to track it properly. The modules running are as follows: yarprobotinterface, cartesian controller server, cartesian controller solver and the simple cartesian controller client.

After commanding for a valid position in the left arm's workspace, using the cartesian controller client as follows:

>>set pos (0.3 0.2 0.6)
Solving for: ( 0.300000  0.200000    0.600000)
Going to: (-0.043060    -0.465931    0.564483)
Solved Configuration: [ 5.299081     0.107838   -0.705834    40.000142   0.000000    50.002637  -0.014062   -0.038671    0.000000]

I get a segfault in yarprobotinterface(after compiling it in debug):

[Switching to Thread 0x7fffee7fc700 (LWP 22428)]
0x00007ffff76edffd in yarp::dev::ControlBoardWrapper::setPositions (
    this=0xa52300, n_joints=8, joints=0x7fffd4002990, dpos=0x7fff2402f210)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4997
4997            rpcData.values[subIndex][rpcData.subdev_jointsVectorLen[subIndex]] = dpos[j];


#0  0x00007ffff76edffd in yarp::dev::ControlBoardWrapper::setPositions (
    this=0xa52300, n_joints=8, joints=0x7fffd4002990, dpos=0x7fff2402f210)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4997
#1  0x00007ffff771990d in yarp::dev::impl::StreamingMessagesParser::onRead
    (this=0xa528d0, v=...)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/StreamingMessagesParser.cpp:225
#2  0x00007ffff76b62e6 in yarp::os::TypedReaderCallback<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::onRead (this=0xa528d0, 
    datum=..., reader=...)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:72
#3  0x00007ffff76b6224 in yarp::os::TypedReaderThread<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::run (this=0xadee90)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:311
#4  0x00007ffff7b53cd3 in ThreadCallbackAdapter::run (this=0xadd5c0)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/Thread.cpp:33
#5  0x00007ffff7b53fd6 in theExecutiveBranch (args=0xadd5c0)
---Type <return> to continue, or q <return> to quit---
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/ThreadImpl.cpp:94
#6  0x00007ffff6601b16 in ACE_OS_Thread_Adapter::invoke() ()
   from /usr/lib/libACE-6.0.3.so
#7  0x00007ffff60fe182 in start_thread (arg=0x7fffee7fc700)
    at pthread_create.c:312
#8  0x00007ffff698a00d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The direct joint control (such as IPositionControl) work properly (Gaze tracker is working properly and commanding the arm joints in position control is working as well). In addition, I checked with @pattacini if the cartesian controller server is configured properly in https://github.com/robotology/QA/issues/142.

Let me know if you need further debug information.

The main difference between Vizzy's config files and icub's config files is the wrapper of each arm. The left_shoulder_arm wraps some joints from the shoulders hardware board and the left_arm hardware board. The same is for the right arm.

I do not remember changing the hardware files in the last year apart from the hardware limits of a joint.

@barbalberto , @drdanz is there anything I should look at?

[pattacini]

Hi @plinioMoreno,

If you add up to the [GENERAL] group of the Cartesian servers' configuration file the following option:

DebugInfo on

then a port ending with the suffix .../dbg:o will get opened that serves to stream out debug messages.
Could you try to log those messages as well?

Possibly, you might consider replacing these lines:

if (joints.size()>0)
    lPos[j]->setPositions(joints.size(),joints.getFirst(),refs.data());

with:

if (joints.size()>0) {
    yDebug("size=%d; refs=(%s)",joints.size(),refs.toString().c_str());
    lPos[j]->setPositions(joints.size(),joints.getFirst(),refs.data());
}

[plinioMoreno]

Hi @pattacini,

I added the lines in the code and the debug option, and I got this file: outputDebugCartesianServer.txt.

So it looks like the Cartesian server is sending 9 joints (waist + shoulder + arm), and the left_shoulder_arm wrapper controls 8 joints (shoulder + arm). Vizzy does not have a global wrapper that joints the waist+shoulder+arm joints. Would this explain the behavior? (Just guessing....)

[pattacini]

@plinioMoreno this sounds correct.

You have two device drivers (torso and left_shoulder_arm) and what you see is the cumulative command.

What about instead the yDebug output I asked you to insert? That one should account for different calls: one for torso and one for left_should_arm.

[plinioMoreno]

I put the lines in the code but I forgot to copy the output from the Cartesian Controller Server. You can find it in cartesianServerDebug.txt. Let me know if you need some more info. I think the point to look now is in the ControlBoardWrappper, that makes the yarprobotinterface to crash right after I send the command.

[pattacini]

Thanks @plinioMoreno for the tests.

Yep, I didn't find anything suspicious up to now. You're still in a condition where the Cartesian server and the yarprobotinterface are two separate binaries, right?

What you could do, if you're willing to, is to write and launch a very simple snippet code controlling a bunch of joints in position-direct, with the exact same instructions whose behavior we've been monitoring: i.e. setPositions(). If we're lucky, the problem will still show up and thus we'll be able to narrow it down.

[plinioMoreno]

@pattacini,

Yes, we are still in the condition where the Cartesian controller server and the yarprobotinterface are two separate binaries. I wrote the code snippet to narrow down the problem, and since it is crashing when controlling multiple joints when using IPositionDirect, I decided to perform the similar test, but using IPositionControl2 for controlling multiple joints.

It crashes when sending multiple joints, but when sending control commands to each joint independently, the yarprobotinterface does not crash. The debug info and the code snippets as follows:

Controlling joints in IPositionControl2 mode:

Code snippet

#include <yarp/os/Network.h>
#include <yarp/os/Port.h>
#include <yarp/os/Bottle.h>
#include <yarp/os/Time.h>
#include <yarp/os/all.h>
#include <yarp/dev/ControlBoardInterfaces.h>
#include <yarp/dev/IControlLimits2.h>
#include <yarp/dev/PolyDriver.h>

#include <yarp/os/LogStream.h>
#include <yarp/os/Log.h>

#include <string>
#include <math.h>
using namespace yarp::dev;
using namespace yarp::os;

int jnts = 0;  // joint number

int main(int argc, char *argv[]) 
{
    Network yarp;

    Property options;
    options.put("robot", "vizzy");//Needs to be read from a config file
    options.put("device", "remote_controlboard");
    options.put("local", "/vizzy/left_arm_pos_interface");
    options.put("remote", "/vizzy/left_shoulder_arm");
    //Available parts: head torso left_shoulder_arm right_shoulder_arm
    options.put("part", "left_shoulder_arm");
    IPositionControl *ipos=0;
    IPositionControl2 *ipos2=0;
    IPositionDirect  *iposDir=0;
    IEncoders *enc=0;
    PolyDriver dd(options);
    bool ok;
    ok = dd.view(ipos);
    ok &= dd.view(ipos2);
    ok &= dd.view(enc);
    ok &= dd.view(iposDir);

    if (!ok) {
        yError("Problems acquiring mandatory interfaces, quitting\n");
        return 1;
    }
    double left_arm_speeds[8] = {10.0,10.0,10.0,10.0,10.0,10.0,10.0,10.0};
    double position_one[8] = {10.0,10.0,10.0,10.0,10.0,10.0,10.0,10.0};
    double position_two[8] = {20.0,20.0,20.0,20.0,20.0,20.0,20.0,20.0};
    double position_three[8] = {30.0,30.0,30.0,30.0,30.0,30.0,30.0,30.0};
    int joint_indexes[8] = {0,1,2,3,4,5,6,7};
    ipos2->setRefSpeeds(left_arm_speeds);
    ipos2->getAxes(&jnts);
    for (size_t j=0; j<8; j++){
    ipos2->positionMove(joint_indexes[j],position_one[j]); //This one works properly
    }
    ipos2->positionMove(jnts,(const int*)&joint_indexes,position_two); //This one causes the crash
  return 0;
}

Debugger ouput of yarprobotinterface

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff4b7fe700 (LWP 12682)]
0x00007ffff76ddfe1 in yarp::dev::ControlBoardWrapper::positionMove (this=0xa52370, n_joints=11, 
    joints=0x7fff3c003e80, refs=0x7fff3c003ec0)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:1569
1569            subIndex = device.lut[joints[j]].deviceEntry;

Backtrace:

#0  0x00007ffff76ddfe1 in yarp::dev::ControlBoardWrapper::positionMove (this=0xa52370, n_joints=11, 
    joints=0x7fff3c003e80, refs=0x7fff3c003ec0)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:1569
#1  0x00007ffff771151d in yarp::dev::impl::RPCMessagesParser::respond (this=0xa52748, cmd=..., response=...)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/RPCMessagesParser.cpp:1768
#2  0x00007ffff766677b in yarp::dev::DeviceResponder::read (this=0xa52748, connection=...)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/DeviceDriver.cpp:64
#3  0x00007ffff7b0affc in yarp::os::impl::PortReaderBufferBase::read (this=0xa526f0, connection=...)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/PortReaderBuffer.cpp:440
#4  0x00007ffff7b099cd in PortCoreAdapter::read (
    this=0xaddbb0, reader=...)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/Port.cpp:162
#5  0x00007ffff7af2f15 in yarp::os::impl::PortCore::readBlock (this=0xaddbb0, reader=..., id=0x7fffe40030a0, 
    os=0x0)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/PortCore.cpp:1225
#6  0x00007ffff7b0056b in yarp::os::impl::PortCoreInputUnit::run (this=0x7fffe40030a0)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/PortCoreInputUnit.cpp:296
#7  0x00007ffff7b53fd6 in theExecutiveBranch (
    args=0x7fffe40030a0)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/ThreadImpl.cpp:94
#8  0x00007ffff6601b16 in ACE_OS_Thread_Adapter::invoke() () from /usr/lib/libACE-6.0.3.so
#9  0x00007ffff60fe182 in start_thread (
    arg=0x7fff4b7fe700) at pthread_create.c:312
#10 0x00007ffff698a00d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Controlling joints in IPositionDirect mode:

Code snippet

#include <yarp/os/Network.h>
#include <yarp/os/Port.h>
#include <yarp/os/Bottle.h>
#include <yarp/os/Time.h>
#include <yarp/os/all.h>
#include <yarp/dev/ControlBoardInterfaces.h>
#include <yarp/dev/IControlLimits2.h>
#include <yarp/dev/PolyDriver.h>

#include <yarp/os/LogStream.h>
#include <yarp/os/Log.h>

#include <string>
#include <math.h>
using namespace yarp::dev;
using namespace yarp::os;

int jnts = 0;  // joint number

int main(int argc, char *argv[]) 
{
    Network yarp;

    Property options;
    options.put("robot", "vizzy");//Needs to be read from a config file
    options.put("device", "remote_controlboard");
    options.put("local", "/vizzy/left_arm_pos_interface");
    options.put("remote", "/vizzy/left_shoulder_arm");
    //Available parts: head torso left_shoulder_arm right_shoulder_arm
    options.put("part", "left_shoulder_arm");
    IPositionControl *ipos=0;
    IPositionControl2 *ipos2=0;
    IPositionDirect  *iposDir=0;
    IControlMode2    *imode=0;
    IEncoders *enc=0;
    PolyDriver dd(options);
    bool ok;
    ok = dd.view(ipos);
    ok &= dd.view(ipos2);
    ok &= dd.view(enc);
    ok &= dd.view(iposDir);
    ok &= dd.view(imode);

    if (!ok) {
        yError("Problems acquiring mandatory interfaces, quitting\n");
        return 1;
    }
    //double left_arm_speeds[8] = {10.0,10.0,10.0,10.0,10.0,10.0,10.0,10.0};
    double position_one[8] = {10.0,10.0,10.0,10.0,10.0,10.0,10.0,10.0};
    double position_two[8] = {20.0,20.0,20.0,20.0,20.0,20.0,20.0,20.0};
    double position_three[8] = {30.0,30.0,30.0,30.0,30.0,30.0,30.0,30.0};
    int joint_indexes[8] = {0,1,2,3,4,5,6,7};
    iposDir->getAxes(&jnts);
    for (size_t j=0; j<8; j++){
        imode->setControlMode(joint_indexes[j],VOCAB_CM_POSITION_DIRECT);
    }
    iposDir->setPositions(jnts,(const int*)&joint_indexes,position_one);//yarprobotinterface crashes
  return 0;
}

And its corresponding debugging output from yarprobotinterface:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffee7fc700 (LWP 13260)]
0x00007ffff76edf06 in yarp::dev::ControlBoardWrapper::setPositions (this=0xa52370, n_joints=11, 
    joints=0x7fffd4002950, dpos=0x7fff40003100)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4993
4993            subIndex = device.lut[joints[j]].deviceEntry;

backtrace:

#0  0x00007ffff76edf06 in yarp::dev::ControlBoardWrapper::setPositions (this=0xa52370, n_joints=11, 
    joints=0x7fffd4002950, dpos=0x7fff40003100)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4993
#1  0x00007ffff771990d in yarp::dev::impl::StreamingMessagesParser::onRead (this=0xa52940, v=...)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/StreamingMessagesParser.cpp:225
#2  0x00007ffff76b62e6 in yarp::os::TypedReaderCallback<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::onRead (this=0xa52940, datum=..., reader=...)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:72
#3  0x00007ffff76b6224 in yarp::os::TypedReaderThread<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::run (this=0xadef00)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:311
#4  0x00007ffff7b53cd3 in ThreadCallbackAdapter::run (
    this=0xadd630)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/Thread.cpp:33
#5  0x00007ffff7b53fd6 in theExecutiveBranch (
    args=0xadd630)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/ThreadImpl.cpp:94
#6  0x00007ffff6601b16 in ACE_OS_Thread_Adapter::invoke() () from /usr/lib/libACE-6.0.3.so
#7  0x00007ffff60fe182 in start_thread (
    arg=0x7fffee7fc700) at pthread_create.c:312
#8  0x00007ffff698a00d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[randaz81]

hi @plinioMoreno, can you give us some info about your current version of yarp and icub-main?
git status
git log -1

[plinioMoreno]

@randaz81, here are the repositories' info
yarp:

git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

git log -1

commit 4c5136725968c12cf1df318ba04dce410b101071
Author: Daniele E. Domenichelli <[email protected]>
Date:   Thu Sep 22 11:52:52 2016 +0200

icub-main:

git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   src/libraries/icubmod/cartesianController/ServerCartesianController.cpp
    modified:   src/libraries/icubmod/cfw2Can/Cfw2Can.cpp
    modified:   src/libraries/icubmod/cfw2Can/Cfw2Can.h

git log -1
commit fb8f5a0b1f28a0fa07818411bff7382721a07c2e
Author: Ugo Pattacini <[email protected]>
Date:   Thu Sep 22 11:52:52 2016 +0200

[pattacini]

Thanks @plinioMoreno for your precious tests.

For the meantime, while we'll be investigating this, you could disable multiple joints control by inserting the following option within the [GENERAL] group:

MultipleJointsControl off

[barbalberto]

From the code you posted, in the multiple joint you use the joint number got from getAxis, which is returning 11 joints because the wrapper is configured for 11 joints. This can be easily seen in the segfault report:

in yarp::dev::ControlBoardWrapper::setPositions (this=0xa52370, **n_joints=11**, joints=0x7fffd4002950, dpos=0x7fff40003100)

but then you are using vectors with 8 values, hence the segfault.

If you want to control 8 joints, simply use 8 as first parameter of the setPositions call.

[plinioMoreno]

Hi @barbalberto,

after reading your comment, I remembered that the control board wrapper defined for the left_shoulder_arm reads all the joints connected to the control board left_arm_joints, which includes the arm joints and the finger joints.

So this means that I have to change that wrapper, removing the finger joints from left_arm_joints elem and creating a new wrapper for the finger joints. Following this approach, the code should work as expected and I will not need to change the setPositions call in any of the other modules (cartesian, etc). I'll do the changes and let you know, thanks!

[barbalberto]

I'm not sure what you are trying to achieve, in any case my advise is that the config file of the robot should be touched only in extremely rare cases!! This in practise means change the files only to reflect a real world hardware change.

For the user code perspective, if the user want to control all the joints it can be done with

iposDir->getAxes(NumberOfJointsOfThisPart);
double * myWanderfulRefs = new double(NumberOfJointsOfThisPart);
iposDir->setPositions(myWanderfulRefs);

otherwise, if the user wants to control a subset of joints, this can be happily done with:

int howManyJointsIWantToControl = 8;
double myWanderfulRefs[howManyJointsIWantToControl] = {10.0,10.0,10.0,10.0,10.0,10.0,10.0,10.0};
int joint_indexes[howManyJointsIWantToControl] = {0, 3, 7, 10, 2, 5, 9, 4};
iposDir->setPositions(howManyJointsIWantToControl,
                      &joint_indexes,
                      myWanderfulRefs);

There is no need to change the config file in order to do it. That said, feel free to do what you think is the best to be more confortable with the use.

[pattacini]

I would indeed differentiate the two cases. One thing is the two snippets above (where there's the error @barbalberto's just spotted), a different thing is the Cartesian controller.

There's no need to hive off the control of the fingers from the wrapper. In iCub we have actually only one device handling arm and fingers joints. In this case, the Cartesian controller device will use the last joints of the kinematic chain (the first three are for the torso device) to cover the first joints of the arms, ruling out the fingers.

[plinioMoreno]

Let's clarify a bit more. I wrote the code snippets like that (sending only 8 joint values) in order to replicate the behavior of the Cartesian Controller server. On the initial segfault test, the Cartesian Controller server was sending eight joints (see file Cartesian server debug). However, the left_shoulder_arm wrapper is concatenating the [shoulders(3) left_arm(8)], but the last three of the left_arm do not need to be controlled by the Cartesian controller server because are the finger joints. This is why I'm thinking on changing the left_shoulder_arm wrapper definition.

[pattacini]

Hi @plinioMoreno

The error in the following instruction you used in the snippet

iposDir->setPositions(jnts,(const int*)&joint_indexes,position_one);

is that jnts is equal to 11 but should rather be 8 (thus, do not use getAxes() for it), which amounts to the length of joints_indexes so as position_one arrays.

The Cartesian controller device should be using the correct value, even though there's a crash caused by some other reason. That should have been already checked in the logs you acquired (did we overlook anything, maybe?).

Therefore, I'd suggest you to carry out the tests again with the "fixed" snippets and see what will be the results.

That being said, you could certainly keep on splitting the arm and the fingers with new devices, but bear in mind that the Cartesian controller device should work also in the current configuration (the same we have with the iCub).

[barbalberto]

I agree with @pattacini. To say it with different words, it is fine that the wrapper has 11 joints and the cartesian (or whatever controller) uses only 8 joints. They do not need to match. The setPositions with three arguments has indeed been created to accommodate for those cases.

[plinioMoreno]

Thanks for the clarifications @barbalberto and @pattacini. I'll re-do the snippets with the correct number of joints and let you know.

[plinioMoreno]

@barbalberto and @pattacini ,

I changed the code snippets, reducing the number of joints to 8 and both snippets worked properly.

In addition, I added the field

MultipleJointsControl off

in the configuration of the Cartesian Controller server and now it works properly.

However, the initial behaviour reported in this issue (segfault in yarprobotinterface) is still happening. Since the snippets are not providing clues, what do you think I can test to try to find out, @barbalberto, do you want to look at the first message of this issue and let me know if I should do any additional test for debugging?

[barbalberto]

A few question to understand what is going on.

I changed the code snippets, reducing the number of joints to 8 and both snippets worked properly.

Does this means that the robot moves and yarprobotinterface does not crash using the snippet and cartesian control?

In addition, I added the field

MultipleJointsControl off

in the configuration of the Cartesian Controller server and now it works properly.

Is there a problem if MultipleJointsControl is not off?
Everything is fine as long as MultipleJointsControl is off, the robot works and so on, and it crashes only when this field is on?

Can you please run a test where it does not work and send me the log of robotInterface, server, solver and the output of the following yarp read?
yarp read ... tcp+log.in:/vizzy/left_arm/command:i

[plinioMoreno]

@barbalberto,

Exactly, all your points are correct. When using the snippets, yarprobotinterfacedoes not crash. yarprobotinterface crashes when I use the cartesian controller, right after sending a goal position. But if I set the MultipleJointsControl off, yarprobotinterface does not crash.

I'm running the same test reported initially in this issue (now with all the logs), which is running the following modules: cartesian controller client, cartesian controller server, cartesian solver, yarprobotinterface, /vizzy/left_shoulder_arm/command:i output, and the debugger output of yarprobotinterfacewhen crashing:

[Switching to Thread 0x7fffee7fc700 (LWP 22428)]
0x00007ffff76edffd in yarp::dev::ControlBoardWrapper::setPositions (
    this=0xa52300, n_joints=8, joints=0x7fffd4002990, dpos=0x7fff2402f210)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4997
4997            rpcData.values[subIndex][rpcData.subdev_jointsVectorLen[subIndex]] = dpos[j];


#0  0x00007ffff76edffd in yarp::dev::ControlBoardWrapper::setPositions (
    this=0xa52300, n_joints=8, joints=0x7fffd4002990, dpos=0x7fff2402f210)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/ControlBoardWrapper.cpp:4997
#1  0x00007ffff771990d in yarp::dev::impl::StreamingMessagesParser::onRead
    (this=0xa528d0, v=...)
    at /home/vizzy/repositories/yarp/src/libYARP_dev/src/modules/ControlBoardWrapper/StreamingMessagesParser.cpp:225
#2  0x00007ffff76b62e6 in yarp::os::TypedReaderCallback<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::onRead (this=0xa528d0, 
    datum=..., reader=...)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:72
#3  0x00007ffff76b6224 in yarp::os::TypedReaderThread<yarp::os::PortablePair<yarp::os::Bottle, yarp::sig::Vector> >::run (this=0xadee90)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/include/yarp/os/PortReaderBuffer.h:311
#4  0x00007ffff7b53cd3 in ThreadCallbackAdapter::run (this=0xadd5c0)
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/Thread.cpp:33
#5  0x00007ffff7b53fd6 in theExecutiveBranch (args=0xadd5c0)
---Type <return> to continue, or q <return> to quit---
    at /home/vizzy/repositories/yarp/src/libYARP_OS/src/ThreadImpl.cpp:94
#6  0x00007ffff6601b16 in ACE_OS_Thread_Adapter::invoke() ()
   from /usr/lib/libACE-6.0.3.so
#7  0x00007ffff60fe182 in start_thread (arg=0x7fffee7fc700)
    at pthread_create.c:312
#8  0x00007ffff698a00d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Let me know if you need further tests.

[barbalberto]

The command received by the the robotInterface looks well formed to me. Also the config files I see here https://github.com/robotology/robots-configuration/tree/master/vizzy are ok. Is the robot using that files or there are some changes?

Can you please redo the same test:
yarp read ... tcp+log.in:/vizzy/left_arm/command:i
with the snippets and with the cartesian with MultipleJointsControl to off for comparison?

Can you also summarize which pc is running which executable and double check that all pc involved are updated at the same version of yarp and on the same branch? Maybe if you can update all yarp, using the master branch and then recompile the application.

[plinioMoreno]

@barbalberto,

The robot configuration files have not changed, we are using the files from the robots-configuration repository.

We have only one pc running the yarpserver, cartesian server and solver, which is the same pc connected to the control boards. The yarp and icub-* repositories are from September 22, 2016, and all of them are master branches. About the update and recompilation, I will be able to do it only on the coming week.

The log from the command:i port when MultipleJointsControl is off:
yarp read ... tcp+log.in:/vizzy/left_shoulder_arm/command:i. Let me know if you need more info.

[barbalberto]

From your description everything seems ok. I don't see a difference between snippets and real case such to create this behaviour.
The only thing that cames to my mind is a wrong connection between two modules. Can you post also the connection you see from the webpage ip_address:10000 from your browser?
In the previous post I made a mistake, I meant to do the test with the flag MultipleJointsControl set to on, can you try again please?
yarp read ... tcp+log.in:/vizzy/left_arm/command:i

On your comment of nearly 1 month ago you said:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   src/libraries/icubmod/cartesianController/ServerCartesianController.cpp
    ...

What are the differences on file ServerCartesianController? Can you post the git diff output?

[barbalberto]

Hi, I found a bug in ControlBoardWrapper which may be related to your issue. Can you update yarp master and try again?

Thanks

[plinioMoreno]

@barbalberto, It worked! Now I can control multiple joints when using the Cartesian Interface.

[pattacini]

Great news! That's been a nasty one.
Thanks @barbalberto for fixing.