* The following video files have been tested on Apple QuickTime 6.5.
|
I. |
Implementation on a Pioneer 2 mobile robot and Honda ASIMO v 1.5 humanoid robot. |
|
|
|
|
|
|
|
II. |
Performance of four command modes with/without network congestion. In each video, the bottom left corner shows part of the client GUI window. The sequence command will start on the client side when the ACTION button is hit by the mouse. The top right corner shows the rendering result from STAGE simulator. |
|
|
1. Delay mode with 0 second delay without congestion. (as the ground truth) It is equivalent to the direct mode running on the nonblocking mode: demo The server receives packages with client clock as timestamps. Since the clocks are synced, and the delay duration is 0 second, the motion starts nearly immediately. |
|
|
2. Direct mode without congestion. Blocking mode communications causes slight delay: demo A slight overshot is observed of the whole sequence comparing to the ground truth above. This result is due to the blocking mechanism which introduces delay for all commands |
|
|
3. Direct mode with congestion. The unpreserved timing information through the network severely distorted the sequence: demo When the network congestion is severe, there is no way that direct mode may preserve the timing between commands. Although the timestamps in command packages are correct, the server can not preserve the sequence as it is sent. Hence the pattern in the simulator is random. The unpredictable replay should be treated as a dangerous factor for humanoid robots. |
|
|
4. Delay mode with 10 second buffer on the server with congestion. The server was able to replay the first 10 seconds intact: demo Thanks to the user specified delay, the server will cache sequence commands for 10 seconds and start replay. The simulator does not receive any commands in 10 seconds after the mouse click on the GUI. Since the whole sequence takes about 25 seconds, the pattern is still distorted after 10 seconds. |
|
|
5. Playback mode without congestion. The server sampled the time interval of the first 5 commands and estimate the replay delay: demo Playback mode automatically calculate appropriate delay based on the total length and the network condition. In the case without congestion, the server starts the sequence nearly immediately. |
|
|
6. Playback mode with congestion. The server sampled the time interval of the first 5 commands and estimate the replay delay: demo In playback mode under severe network congestion, the server is conservatively adjust the delay of the whole sequence based on the first five commands it receives. The key result by demo 5 and 6 shows: regardless of the network condition, playback mode protocol always preserves the command sequence correctly over the network. |