left and right arms inertial MTB sensor issues

nunoguedelha commented 8 years ago

Description of the failure

While testing the inertial sensors in the arms, we observed wrong measurements on boards 1B10, 1B12, 1B7, 1B8 and 1B9 for the left arm/hand, and 2B7, 2B8, 2B9 and 2B10 for the right arm/hand. In the attached plots, the red line stands for the sensor measurements, and the blue line for the predicted measurements computed from the joint positions and the theoretical gravity vector.

1B7, 1B8, 1B10, 1B12, 2B7, 2B8, 2B9

We observe a significant orientation error between the expected and the measured proper acceleration vectors, which should be caused by a mismatch between the CAD, the wiki mounting reference and the actual mounting of the MTB boards on the robot, or (less probable), between the CAD and the URDF model. To be checked with @Mick3Lozzo and the production team.

1B9

the measured value is constant (all digits from the published sensor data) although the orientation of the arm is changing. Most probably the sensor data are not being updated which would mean that the MTB board is not sending new data to the PC104. to be checked with @marcoaccame and @valegagge.

2B10

All data from the sensor is 0xFFFF (timestamp and x, y, z acceleration components) which indicates an error at the MTB or EMS board level. To be checked with @marcoaccame.

Detailed conditions when the failure occurred

While we are moving the iCub arms randomly, we are comparing the predicted measurements (computed from the joint positions and the theoretical gravity vector) against the actual sensor measurements. This provided us the plots attached, from which we derived the analysis.

Left arm plots

jointpositions_leftarm normaccestvsaccmeas_leftarm xyzaccestvsaccmeas_leftarm angleaccestvsaccmeas_leftarm

Right arm plots

jointpositions_rightarm normaccestvsaccmeas_rightarm xyzaccestvsaccmeas_rightarm angleaccestvsaccmeas_rightarm

marcoaccame commented 8 years ago

Hi @nunoguedelha, please send me the xml files you have used for the configuration of the device and I will do some checks to see what's wrong with boards 1B9 and 2B10. For sure board 2B10 is not enabled by the default xml files, thus if you haven't changed the relevant xml file the value will not be printed on the yarp port.

nunoguedelha commented 8 years ago

@marcoaccame , for anyone else following the issue, I summarise our discussion here: I had edited the files localy on PC104, but just adding predefined sensor names into the list of activated sensors. We can't access those files now. Anyway, the mentioned sensors 1B9 and 2B10 were activated otherwise we would have seen all zeros instead of FF or a constant value. Also, as additional info, I confirm that the timestamp for the 1B9 is also constant. The full constant data chunk is:

3.0 1.0 5888868093.0 -2144.0 17296.0 608.0
 |   |          |        |     |      |
1B9  acc.   timestamp    x     y      z

nunoguedelha commented 8 years ago

sensor data dumper files sent to you. Also, I'm attaching here a chunk of the files with enough data illustrating the issue.

dataLeftArm.log.txt dataRightArm.log.txt infoLeftArm.log.txt infoRightArm.log.txt

nunoguedelha commented 8 years ago

@maggia80, @Mick3Lozzo, @DanielePucci, I've checked all the accelerometers in the CAD, the wiki photos and the SIM model (chest, arms) and I found 1 error on the MTB_2B8 position: the CAD / Sim model / URDF match, but there is a mismatch between the CAD and the wiki photo, so probably the robot also. Attaching 2b8repositioning photo...

maggia80 commented 8 years ago

We should change in the CAD, since spoken with the Production Unit and they always mount the 2B8 in this position therefore we should change the CAD/URDF accordingly.

Mick3Lozzo commented 8 years ago

left_right

@maggia80 @DanielePucci @nunoguedelha ok, but this means that in the model the MTB scsys on forearms won't be symmetric anymore.

Attached screenshot is the current situation of the CAD. Plastic covers are the same, for both left forearm and right forearm. Every cover has a twofold series of pre-drilled MTB fixing holes, and in each configuration some holes remain undrilled, in order to maintain symmetry between left and right forearm. Technically in the photo there is a wrong assembly of components.

nunoguedelha commented 8 years ago

Also, while a mismatch in the order of the boards can be solved by simply renaming them in the CAD, changing the board position could be simpler to do on the wiki reference photos/future drawings. Anyway, it might be worth checking how they are actually being mounted on the real robot. Maybe they were "naturally" mounted symmetrically. All the arm boards need to be checked on the robot anyway, the mounting scheme is quite error prone.

maggia80 commented 8 years ago

Indeed the MTB are mounted on the robots like in the pictures in all the V2 robots (I double check with the Production) . They are not simmetrically mounted, that is why I suggest to change the CAD at this time.

Mick3Lozzo commented 8 years ago

Corrected & committed on CAD, assemblies, drawings and shrinkwrapped model.

DanielePucci commented 8 years ago

👍

julijenv commented 8 years ago

Hi @MagnusJohnsson , could you tell me if this previous answer solved your issue or not? , thx in advance.

traversaro commented 8 years ago

The issue is the MTB can be mounted in different ways in different robots. The issue was reported to the mechanical and electronics teams, and if I remember correctly @maggia80 took an action to make sure that all the MTB will be consistently mounted in new robots. I don't know if we agreed what to do with MTB mounted on existing robots, but the issue is not specific to this robot, so we can close it.

nunoguedelha commented 8 years ago

@traversaro , just for your information, regarding the specific issue on the board 2B8, the decision as per @maggia80 's suggestion was to update the CAD, as @Mick3Lozzo did, and leave the current physical configuration on the existing robots.

Now, there were other remaining issues:

[ ] 1B9 : the measured value is constant (all digits from the published sensor data) although the orientation of the arm is changing.
[ ] 2B10 : All data from the sensor is 0xFFFF.

I don't remember the status on these. @marcoaccame , can you confirm these issues have been solved?

traversaro commented 8 years ago

@nunoguedelha sorry, I missed this two points. That I think this issues needs to be fixed.

nunoguedelha commented 8 years ago

👍

marcoaccame commented 8 years ago

Hi @nunoguedelha,

I don't know if the issues are solved. I can tell that:

if from 2B10 all data is 0xFFFF, then there must be some problem on connector on the MTB
if the measure is constant them maybe the actual sensor is broken,

I can give support to P&M to fix the robot (the lumix innit?) which is now in preparation to leave.

(@julijenv & @davidetome).

nunoguedelha commented 8 years ago

Thanks @marcoaccame

davidetome commented 8 years ago

HI guys,

the problem has been fixed. Attached the log files of yarp ports readings for boards 2B10 and 1B13. As predicted by @marcoaccame :

2B10 had a wire cut
1B13 was malfunctioning also when touching the skin patch attached. We replaced the board with a new one and all went ok.

left_hand_inertial.txt right_hand_inertial.txt

@julijenv @Fabrizio69

robotology / icub-tech-support