robotalk: a general robot control framework can we access r2d2 & c3po with the same control...

RoboTalk: a general robot control frameworkCan we access R2D2 & C3PO with the same control commands?

Allen Yang Yang

University of Illinois at Urbana-Champaign

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

H. Gonzales-Banos, V. Ng-Thow-Hing, J. E. Davis

Honda Research Institute, Mountain View, CA

L18306

I think you need a slide after this one showing a picture of R2D2 and C3PO - to highlight the differences between the two droids. You can also tell a funny story that to avoid being sued by Lucasfilm, we will substitute these two droids with ones with similar characteristics - then dissolve out the picture with ones with Pioneer and Asimo instead.

2

Copyright Lucasfilm Ltd.

Motivation

Mobile Robot with Pan-Tilt Camera

Honda Asimo Humanoid Robot

L18306

Here's a sample of what I'm talking about...

L18306

I think you should show a brief video of both the pioneer and asimo doing the same thing - explain that they are both running off the same client. This will get your audience's attention to listen to the rest of the talk.

3

Why do we need a motion specification?

Difficulties for researchers in robotics: Industrial copyright Programs are not re-usable in

different robot families, even different versions of same robot families

Have to choose OS based on the drivers provided

Not easy to share a robot remotely with other collaborators in different locations





Motion Commands

Windows? Linux? Mac OS?

Embedded OS?

4

Project goals

Whatever: (cross-model) Provide a network-enabled interface for Asimo which is

independent of the controller libraries Access to other robots & simulators: Pioneer, Puma

Whoever: (cross-platform) User interface must be cross-platform: support Unix, Linux, Mac

OS X and Windows. Wherever: (cross-network)

Good quality of service across the Internet.

5

Demo Videos

6

Contributions

A robot specification standard One command interface Four command modes between client and server:

Direct Delay Playback Broadcast

Easy-to-change robot driver implementation on the server-end

7

Previous Work

Player [R. Gerkey and A. Howard, 2003]

Open Architecture Humanoid Robotics Platform (HRP)[F. Kanehiro, et al., 2004]

Open Pino Project [F. Yamasaki, et al., 2000]

OROCOS [http://www.orocos.org/]

Dedicated systems ARIA [robots.activmedia.com/ARIA/]

Robonaut [H. Aldridge, et al., 2000]

Athena [J. Biesiadecki, et al., 2001]

L18306

Make sure you have something to say about these bullets - and maybe how Robotalk differs from these.

8

Why not others?

Do not support humanoid robots Hard to change driver implementation Do not have network quality support Do not have protection mechanism for

exotic robots

9

System Architecture

System Overview Client/Server Structure Four Communication Modes

10

Architecture - Specification Standard

Configuration Spec

Command Spec

Communication Spec

Abstraction

11

Architecture - System Overview

Client/Server

...

Client

Client

Server

Asimo Library

Pioneer Library

Simulator





Configuration Spec

Command Spec

Communication Spec

12

Architecture - Robotalk Server

Server Daemon

Robot Daemon

Read and Write TCP/IP sockets

Issue Robot Driver Calls

CClientConnection

CClientConnection

Provide: Buffering, Scheduling, Panic, etc.

Class Interface

.

.

.

CRobotDriver

13

Architecture - CClientConnection

CClientConnection

Command Queue

Return Queue

Playback Queue

Read

Write

Input commands

Feedback

Priority Queues

Server Daemon

Robot Daemon

14

Architecture - CClient

Read Daemon

Return cache

CClient Class

Class Interface

Commands to the server.(Blocking/Nonblocking)

Feedback

(Nonblocking)

Broadcastcache

Function calls

15

Architecture - Communication Modes

Direct mode: blocking & instantaneous, for debug purposes

Delay mode: nonblocking, instantaneous or delay

Playback mode: nonblocking, adaptive caching based on channel quality

Broadcast mode: periodic query feedback

L18306

I think this slide can be removed - put the bullets with the actual detail slides that occur later on. You only have 15 minutes, so don't put slides where you may repeat yourself later

16

Direct Mode

Client Server Sync system clock

Clock

Command Cache

RobotDaemon

Client

Function call

Cache Return Cachereturn

L18306

On ALL these slides with the communication modes, I feel there are two many animation sequences. You don't want to keep hitting the keyboard or mouse to advance the slide elements, as this will interrupt your flow... if you are going to use animation, break this up into fewer chunks - for example, you don't really need to do the arrows as separate animations - just group them with the boxes they point to,

17

Delay Mode

Client Server Sync system clock

RobotDaemon

Client

Cache

Function call

return

Delay

Command Cache

Clock +

Return Cacheerror signal

18

Playback Mode

Client

Cache

Function call

return

Return Cacheerror signal

Clock

Playback Cache

Command Cache

Delay

RobotDaemon

Client Server

Length of the sequence

19

Broadcast Mode

Client

Cache

Broadcast

call

return

Command Cache

RobotDaemon

Return Cachedata

Delay

20

Conclusions

Motivations System Structure Four Network Command Modes Future Extensions

Exclusive control Data channels Controlling multiple humanoid robots Virtual humanoid robots

21

Virtual Humanoid

Server

Pioneer Library

Camera Library

Puma Library



QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Site A

Site B

Virtual Humanoid

22

Thank you!

Allen Yang: [email protected] Hector Gonzales-Banos: [email protected] Ng-Thow-Hing: [email protected]

All videos available online: perception.csl.uiuc.edu/RoboTalk/

robotalk: a general robot control framework can we access r2d2 & c3po with the same control...

Documents

ca slide

crobotdriver slide

serverend slide

different robot families

robot specification

command interface

periodic query feedback

motivation mobile robot