ICubHealthCheckupWeek 03 2011

This page contains the results of all tests run on the iCub between March 2nd 2011 and March 8th 2011.

Unsolved problems are highlighted in red, solved problems in green.

March 2nd 2011, 15:00

Demo 1: old ball reaching

• pc104 started normally.
• cameras (camerasSetForTracking.sh) started normally and operated at ~30fps.
• iCubInterface (iCuyebInterface --from iCubInterfaceSimple.ini) started normally and reported zero errors.
• demoReach_LeftHand_RightEye.sh started normally, but images were shown at ~26fps instead of 30. The tracker module is shown as using 107% of the computing power of a core, this should be under 100%.tracking works, but is not perfect: even when the ball is still, the likelihood is not over the threshold (yellow ring instead of green ring). There is evident overshooting in the movement of the eyes and of the head. All these problems might be caused by the fact that in this demo we are using a hacked version of a module, because it is not in the main branch of the repository. The speed of the arm is normal in this configuration.
• turning off the iCubInterface worked well, the robot was parked normally.

Demo 2 yoga with non-cartesian iCubInterface

• iCubInterface (iCuyebInterface --from iCubInterfaceSimple.ini) started normally and reported zero errors.
• running " iCubDemoY3 --config /app/demoy3/fullBody.txt" reports error: "Problem connecting to /icub/right_leg/rpc:i, is the remote device available?" (plus some others). The legs were not enabled by the configuration files on pc104:

 /usr/local/src/robot/iCub/app/iCubLisboa01/conf/iCubInterfaceSimple.ini
 /usr/local/src/robot/iCub/app/iCubLisboa01/conf/icubSafe.ini (specifically in this one here)
 /usr/local/src/robot/iCub/app/iCubLisboa01/conf/icub_legs_safe.ini

enabling the legs produced this error (repeatedly for some time, then it disappeared) in the iCubInterface:

 Id:5 T:1 R:2 Id:7 T:1 R:2 
 pcan [3] have not heard from board 6 (channel 0) since 72.10 seconds
 pcan [3] have not heard from board 6 (channel 1) since 72.10 seconds
 pcan [3] have not heard from board 8 (channel 0) since 72.10 seconds
 pcan [3] have not heard from board 8 (channel 1) since 72.10 seconds
 pcan [3] have not heard from board 9 (channel 0) since 72.10 seconds
 pcan [3] have not heard from board 9 (channel 1) since 72.10 seconds
 pcan [3] have not heard from board 10 (channel 0) since 72.10 seconds
 pcan [3] have not heard from board 10 (channel 1) since 72.10 seconds
 pcan [3] joint 2, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 3, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 6, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 7, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 8, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 9, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 10, warning not enough encoder messages (received 0 msgs)
 pcan [3] joint 11, warning not enough encoder messages (received 0 msgs)
 LEGSCALIB::Timeout on joint 6 while going to zero!

The yoga at this point starts and works well with head, torso and arms, while the legs are still. The fingers (pinky and fourth finger) move at an acceptable velocity. robotMotorGui starts, but the legs don't report any information and cannot be moved.

• Stopping the iCubInterface takes a long time because the legs don't park, but eventually succeeds.
• Starting the iCubInterface again leads to some timeout errors on the legs, that I couldn't write down. The yoga started, using the legs, but not bending the left knee.

• Stopping the iCubInterface still takes a long time.
• Starting the iCubInterface for the third time gives same timeout errors as in trial #2: "LEGSCALIB::Timeout on joint 2 while going to zero!

" "LEGSCALIB::Timeout on joint 3 while going to zero!" "LEGSCALIB::Timeout on joint 4 while going to zero!" and "LEGSCALIB::Timeout on joint 5 while going to zero!". yoga behaves the same as in trial #2.

• something was disconnected on the board controlling the left knee of the iCub, now Ricardo fixed it and yoga works like a charm.

still, the iCubInterface complains:

 pcan [0] have not heard from board 5 (channel 0) since 93.35 seconds
 pcan [0] have not heard from board 5 (channel 1) since 93.35 seconds
 pcan [0] have not heard from board 6 (channel 0) since 93.37 seconds
 pcan [0] have not heard from board 6 (channel 1) since 93.37 seconds
 pcan [0] joint 6, warning not enough encoder messages (received 0 msgs)
 pcan [0] joint 7, warning not enough encoder messages (received 0 msgs)
 pcan [0] joint 8, warning not enough encoder messages (received 0 msgs)
 pcan [0] joint 9, warning not enough encoder messages (received 0 msgs)

in the robotMotorGui you can change the position of the torso joints, but the robot does not move. Everything else is moving OK, but the left hand last two fingers: they move with a lag and very slowly. After a while the errors disappeared (without restarting the iCubInterface) and the robotMotorGui was able to control the robot. The problems with the last two fingers of the left hand persisted. Interestingly, opening the fingers with the gui slider is much slower than using the "home all" button. Is this an issue related to open-loop control vs closed-loop control? After waiting a bit more, the torso problem came back. This problem was fixed by Ricardo, see day 04.

March 3nd 2011, 15:00

1 - PC104 sometimes when turning on is not in the network (not pingable)

DemoGrasp

• Arm movement very slow
• Still has overshoot with the eyes and head when moving the ball.

March 4th 2011, 16:00

The processes for the grasping demo had to be run on iCubBrain2, as iCubBrain1 was not responding. This problem was later solved by restarting iCubBrain1, which had got stuck in a kernel panic situation.

There was no trace of the grasp demo in the wiki, this was solved by describing how to start that demo in ICub_instructions#Ball_tracking_and_grasping_demo. for this demo the ball tracker works at the expected 30 fps. There is still some overshoot in the movement of the eyes, but it might as small as possible given the delays in the loop. The arm moves very slowly. The head of the robot rolls strangely to the sides when the ball is higher than it and close to it. I don't know if this behaviour is normal. Ugo Pattacini said the movement of the head is intended to be like that.

See the video at [1].

Ricardo fixed some connections on the back of the robot, probably solving the torso-related errors. Such errors have not appeared since in the iCubInterface output.

March 7th 2011, 15:00

• 2011-03-07: iCubInterface is shutting down gracefully. Was due to zombie processes (iKinCartesianSolvers on the icubbrain2). [The problem was trivial but I am not deleting these posts as it might help in troubleshooting in the future]. By the way, there are still some Can Errors on Boards 1 and 6.
• 2011-03-07: iCubInterface has not been shutting down gracefully. This behavior was seen earlier as well when we were having troubles with the iCub head (Last time it was probably due to a cable being pulled around the neck).

From the iCubInterface:-
pcan [0] thread ran 596 times, req.dT:10[ms], av.dT:10.05[ms] av.loopT :0.03[ms]
 Can Errors --  Device Tx:1 Rx:0 TxOvf: 1 RxOvf BusOff: 0 -- Driver Fifo Tx:0 Rx:0
pcan [0] printing boards errors:
None
pcan [2] thread ran 596 times, req.dT:10[ms], av.dT:10.05[ms] av.loopT :0.04[ms]
 Can Errors --  Device Tx:2 Rx:0 TxOvf: 2 RxOvf BusOff: 81 -- Driver Fifo Tx:0 Rx:81
pcan [2] printing boards errors:
None

• 2011-03-07: Joint 15 of the right arm is making noises (Nuno suspects that there is something wrong with the gearbox. Only 1 gearbox left in stock. Should order more),
• 2011-03-07: iCubInterface no more board errors (appears to be random: probably some cable is loose)
• 2011-03-07: iCubInterface could not contact boards 6, 8, 9, 10
• 2011-03-07: iCubInterface behaving wierdly: Board 1, 2, 3, 5, 7 could not be contacted
• 2011-03-07: right arm fixed
• 2011-03-07: right arm broken (cable broken near the elbow)

March 9th 2011, 15:00

Trying to understand what causes the arm to move slowly in the grasping demo. I run the reaching demo, the arm was moving normally. I kept the iCubInterface on, started the Cartesian solvers for the arms and started the grasping demo. The arm moves slowly. When the ball is recognized, the Cartesian solver uses 101% of a CPU core. When the ball disappears, the solver uses only a fraction of that, but the arm still moves slowly.

Next demos

• try out the attention demo
• the modules written by Martim should be committed to the repository and integrated in the grasp demo