Chico head: Difference between revisions

From ISRWiki
Jump to navigation Jump to search
No edit summary
 
(25 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Basic info=
[[Image:ChicoHead.jpg|frame|left|caption|Chico head.]]
[[Image:ChicoHead.jpg|frame|left|caption|Chico head.]]
The storage memory of Chico head is a USB stick. The image for that data is on Blackhole:
[[Image:ChicoHeadUsbStick.jpg]] <br>The storage memory of Chico head is a USB stick. There are 2 images (~4GB each) for that data on Blackhole:
   smb://blackhole/database/ICUB/CHICO_BACKUP_image1.7-oc
   smb://blackhole/Database/CHICO_HEAD/CHICO_BACKUP_image1.7-oc.bin
The image can be dumped on a new USB stick with the "dd" command:
  smb://blackhole/Database/CHICO_HEAD/CHICO_HEAD_BACKUP_image1.8_2014_02_10.bin
   sudo dd bs=4096 if=CHICO_BACKUP_image1.7-oc.bin of=/dev/sdXXXXX
The second image is more recent and features some improvements respect to the first one.<br>
An image can be dumped on a new USB stick with the "dd" command:
   sudo dd bs=4096 if=CHICO_HEAD_BACKUP_image1.8_2014_02_10.bin of=/dev/sdXXXXX
Specify the correct sd device istead of sdXXXXX (sdb, sdc or the like). Pay attention not to overwrite the wrong disk!
Specify the correct sd device istead of sdXXXXX (sdb, sdc or the like). Pay attention not to overwrite the wrong disk!
DD doesn't give you progress information while it's running, you can make it write such information on the screen by sending it a special message:
  sudo kill -USR1 $(pgrep ^dd)
Before removing the USB stick, run sync to ensure that all data has been written:
Before removing the USB stick, run sync to ensure that all data has been written:
   rsync
   sync
People who know about the image are Ricardo Ferreira and Alex.
People who know about the image are Matteo, Ricardo Ferreira and Alex.
 
In case you improve the content of the USB stick and want to make a new image of it, you can use a command like this:
  sudo dd if=/dev/sdXXXXX1 of=/home/matteo/sdXXXXX1.bin
 
=readme.txt=
The remaining of this page is the content of the readme.txt file in the home directory of Chico head (That file is not updated, it was generated on Feb. 6 2014):
 
Log in: like the one for the iCub
 
==Demos==
 
To start the X server:
startx (or startxfce4)
 
When you are in the X interface you can open terminals and start the various processes from there.
* Scripts 1 and 2 start the YARP server and the iCubInterface (used for moving the robot).
* Scripts 3_1..3_3 start the right camera, start a viewer and connect the two.
* Scripts 4_1..4_4 start the emotion system and cycle emotions in a fixed sequence.
* Script 6 moves the head and the eyes in a fixed sequence.
 
All of this was running together smoothly on Feb. 6 2014.<br>
On Mar. 21 2014 the facial expression system was not working at all. The YARP driver could not be initialized and the board emitted a weird sound when approached with a finger. Once the associated USB port was disconnected, the delays in accessing the USB stick greatly reduced. It is possible that the broken board was contributing to the known USB problems by jamming the USB system. <br>
The board was substituted on Mar. 24 2014 and is now working smoothly. While we were at it, we also fixed the lower eyelid which was loose.
 
==Known problems==
* The ethernet adapter on the bottom of the robot does not work.
* Turning on the robot with a cable plugged into the ethernet connector in the head of the robot gets the system stuck. You can plug the cable in after boot and initialize the ethernet connection with: sudo dhclient eth0.
* Sometimes the iCubInterface gets stuck because it stops being able to communicate with some of the boards. It happened once on Mar. 21 2014 while the head seemed to be the limit of one of the joints. That joint was not actuated any more, while the others remained actuated. A similar problems seems to be happening on Vizzie.<br>
[[Image:ChicoHeadCommunicationProblem.png|300px]] Click on the image to see the high resolution version.<br>
* Something can block one application (typically the terminal and gedit) or parts of the system for 10..20 seconds. The problem was worse when we had the old faulty facial expression board connected to the system, but persists now with the new board and persists even (possibly to a lesser extent), when such board is not connected to the system.
  The freezing seems to be triggered both by some disk read and write operations.
  The system is still responsive, the affected application freezes, other applications can also freeze at that time if they need to access the disk (I suppose).
  It doesn't give problems to the demos once they have been started.
* It was common to get this USB-related error at boot time, after changing the facial expression board for the new one and using different USB cables/connection on PC104, the error doesn't appear any more:
  >>USB 3-2: device descriptor read/64, error -71
  >>device not accepting address 4, error -71
  >>device not accepting address 5, error -71
After which the system booted normally.
It seems to happen every time that the USB connector for the facial expression is connected to the board.
It might mean that the USB connectors as a whole are requiring too much current.
Even if the system is started and run without the facial expression connector plugged in, the system still freezes.
 
====USB pen drive test====
* I ran hdparm 4 times and got these results (with low variation):
  $ sudo hdparm -tT /dev/sda
    /dev/sda:
    Timing cached reads:  5390 MB in  2.00 seconds = 2697.28 MB/sec
    Timing buffered disk reads:  74 MB in  3.05 seconds =  24.27 MB/sec
* I tried to run "bonnie", but it didn't work.
  sudo bonnie -u1000
* I used iostat, I did an "ls" after the first measurement
$iostat -dkx 5 (displays measures every 5 seconds)
  Device:          rrqm/s  wrqm/s r/s  w/s    rkB/s    wkB/s avgrq-sz avgqu-sz  await  svctm  %util
  sda              0.00    0.00  0.00  0.00    0.00    0.00    0.00    0.00    0.00  0.00  0.00
  sda              0.00    13.39  0.00  0.81    0.00    56.80  140.00    0.01    9.00  4.00  0.32
  sda              0.00    3.69  0.00  0.65    0.00    2.60    8.00    8.27 1216.00 716.00  46.59
  sda              0.00    2.72  0.00  3.09    0.00    24.68    16.00    15.81 2809.18 294.12  90.74
  sda              0.00    0.00  0.00  1.00    0.00    4.80    9.60    32.69 4841.60 1000.00 100.00
  sda              0.00    0.00  0.00  2.20    0.00    11.18    10.18    25.63 10185.82 454.55  99.80
  sda              0.00    0.00  0.00  2.19    0.00    17.53    16.00    12.01 13870.91 454.55  99.60
  sda              0.00    0.00  0.00  1.00    0.00    4.00    8.00    5.96 20111.20 1000.00 100.00
  sda              0.00    0.20  0.00  1.00    0.00    4.78    9.60    0.45 13737.60 152.00  15.14
  sda              0.00    0.40  0.00  0.40    0.00    3.20    16.00    0.00    0.00  0.00  0.00
 
svctm = service time in milliseconds (not including the time spent in queue.
await = service time including waiting in queue. it peaks at 20 seconds!
 
Little data is written, almost no data is read. Lots of time is spent in queue...
Why? Could it be that the USB pen is "asleep" and needs to be woken up?
 
==Wishlist==
*Once the face detector+gaze demo was working on this platform. Maybe it could be restored with little effort.
 
==Improvements since previous bootable image==
*The demos work out of the box.
*The keyboard layout is Portuguese both for the real terminals and the X session.
*The browser doesn't write cache to the disk (freezing at almost every click)
*The sources lists have been updated, so more packages can be installed.
*Added the readme file
 
 
 
 


[[Category:Robots]]
[[Category:Robots]]
[[Category:Vislab]]
[[Category:Vislab]]

Latest revision as of 20:10, 24 March 2014

Basic info

Chico head.


The storage memory of Chico head is a USB stick. There are 2 images (~4GB each) for that data on Blackhole:

 smb://blackhole/Database/CHICO_HEAD/CHICO_BACKUP_image1.7-oc.bin
 smb://blackhole/Database/CHICO_HEAD/CHICO_HEAD_BACKUP_image1.8_2014_02_10.bin

The second image is more recent and features some improvements respect to the first one.
An image can be dumped on a new USB stick with the "dd" command:

 sudo dd bs=4096 if=CHICO_HEAD_BACKUP_image1.8_2014_02_10.bin of=/dev/sdXXXXX

Specify the correct sd device istead of sdXXXXX (sdb, sdc or the like). Pay attention not to overwrite the wrong disk! DD doesn't give you progress information while it's running, you can make it write such information on the screen by sending it a special message:

  sudo kill -USR1 $(pgrep ^dd)

Before removing the USB stick, run sync to ensure that all data has been written:

 sync

People who know about the image are Matteo, Ricardo Ferreira and Alex.

In case you improve the content of the USB stick and want to make a new image of it, you can use a command like this:

 sudo dd if=/dev/sdXXXXX1 of=/home/matteo/sdXXXXX1.bin

readme.txt

The remaining of this page is the content of the readme.txt file in the home directory of Chico head (That file is not updated, it was generated on Feb. 6 2014):

Log in: like the one for the iCub

Demos

To start the X server: startx (or startxfce4)

When you are in the X interface you can open terminals and start the various processes from there.

  • Scripts 1 and 2 start the YARP server and the iCubInterface (used for moving the robot).
  • Scripts 3_1..3_3 start the right camera, start a viewer and connect the two.
  • Scripts 4_1..4_4 start the emotion system and cycle emotions in a fixed sequence.
  • Script 6 moves the head and the eyes in a fixed sequence.

All of this was running together smoothly on Feb. 6 2014.
On Mar. 21 2014 the facial expression system was not working at all. The YARP driver could not be initialized and the board emitted a weird sound when approached with a finger. Once the associated USB port was disconnected, the delays in accessing the USB stick greatly reduced. It is possible that the broken board was contributing to the known USB problems by jamming the USB system.
The board was substituted on Mar. 24 2014 and is now working smoothly. While we were at it, we also fixed the lower eyelid which was loose.

Known problems

  • The ethernet adapter on the bottom of the robot does not work.
  • Turning on the robot with a cable plugged into the ethernet connector in the head of the robot gets the system stuck. You can plug the cable in after boot and initialize the ethernet connection with: sudo dhclient eth0.
  • Sometimes the iCubInterface gets stuck because it stops being able to communicate with some of the boards. It happened once on Mar. 21 2014 while the head seemed to be the limit of one of the joints. That joint was not actuated any more, while the others remained actuated. A similar problems seems to be happening on Vizzie.

Click on the image to see the high resolution version.

  • Something can block one application (typically the terminal and gedit) or parts of the system for 10..20 seconds. The problem was worse when we had the old faulty facial expression board connected to the system, but persists now with the new board and persists even (possibly to a lesser extent), when such board is not connected to the system.
 The freezing seems to be triggered both by some disk read and write operations.
 The system is still responsive, the affected application freezes, other applications can also freeze at that time if they need to access the disk (I suppose).
 It doesn't give problems to the demos once they have been started.
  • It was common to get this USB-related error at boot time, after changing the facial expression board for the new one and using different USB cables/connection on PC104, the error doesn't appear any more:
 >>USB 3-2: device descriptor read/64, error -71
 >>device not accepting address 4, error -71
 >>device not accepting address 5, error -71

After which the system booted normally. It seems to happen every time that the USB connector for the facial expression is connected to the board. It might mean that the USB connectors as a whole are requiring too much current. Even if the system is started and run without the facial expression connector plugged in, the system still freezes.

USB pen drive test

  • I ran hdparm 4 times and got these results (with low variation):
 $ sudo hdparm -tT /dev/sda
   /dev/sda:
   Timing cached reads:   5390 MB in  2.00 seconds = 2697.28 MB/sec
   Timing buffered disk reads:   74 MB in  3.05 seconds =  24.27 MB/sec
  • I tried to run "bonnie", but it didn't work.
 sudo bonnie -u1000
  • I used iostat, I did an "ls" after the first measurement

$iostat -dkx 5 (displays measures every 5 seconds)

 Device:           rrqm/s   wrqm/s r/s   w/s     rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
 sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
 sda               0.00    13.39  0.00  0.81     0.00    56.80   140.00     0.01    9.00   4.00   0.32
 sda               0.00     3.69  0.00  0.65     0.00     2.60     8.00     8.27 1216.00 716.00  46.59
 sda               0.00     2.72  0.00  3.09     0.00    24.68    16.00    15.81 2809.18 294.12  90.74
 sda               0.00     0.00  0.00  1.00     0.00     4.80     9.60    32.69 4841.60 1000.00 100.00
 sda               0.00     0.00  0.00  2.20     0.00    11.18    10.18    25.63 10185.82 454.55  99.80
 sda               0.00     0.00  0.00  2.19     0.00    17.53    16.00    12.01 13870.91 454.55  99.60
 sda               0.00     0.00  0.00  1.00     0.00     4.00     8.00     5.96 20111.20 1000.00 100.00
 sda               0.00     0.20  0.00  1.00     0.00     4.78     9.60     0.45 13737.60 152.00  15.14
 sda               0.00     0.40  0.00  0.40     0.00     3.20    16.00     0.00    0.00   0.00   0.00

svctm = service time in milliseconds (not including the time spent in queue. await = service time including waiting in queue. it peaks at 20 seconds!

Little data is written, almost no data is read. Lots of time is spent in queue... Why? Could it be that the USB pen is "asleep" and needs to be woken up?

Wishlist

  • Once the face detector+gaze demo was working on this platform. Maybe it could be restored with little effort.

Improvements since previous bootable image

  • The demos work out of the box.
  • The keyboard layout is Portuguese both for the real terminals and the X session.
  • The browser doesn't write cache to the disk (freezing at almost every click)
  • The sources lists have been updated, so more packages can be installed.
  • Added the readme file