Talk:Low-cost Robotics

Goals

• September 2010

Written state-of-the art in the area, including a reasoned and commented collection of relevant sites

• September 2010

Selection of an appropriate tool to support plug-and-play interaction among HW/SW modules, on widely used standards (e.g., CAN bus). A candidate is CAN Festival. Test of the tool on ST-based boards (and Microchip as well)

Notes

Communication Middleware

Notes on communication needs among modules in a robotics architecture

Goal: to put in evidence dimensions along which to classify needs and build a framework to identifying requirements for communication among modules in a robotic architecture. We will consider autonomous robots oriented to service and game applications. Modules include control modules at all the needed levels, and smart sensors/actuators, such as smart cameras, sonar belts, multi-link arms (this rises the question of hierarchical communication (among the smart links, and between the "arm" and the rest of the robot.

Communication Band

In principle, all the modules are powerful enough to perform locally the elaboration that does not need interaction with other modules. Exchanged information should concern few bytes about commands and high-level data (such as self-localization, localization of objects, desired position of end-effector, ...).

The speed at which these data should be exchanged depends on the production/consumptions of data, so on the elaboration at both sides of the communication channel. Extreme values might be 1 KHz for a control with force feedback, rising to a banwidth of few kilobytes/sec

Scenarios

• 1 - ROBOGAME - A small, 3-wheeled robot plays a dynamic game with a human player.

The robot bears 3 mice for odometry, a range sensor belt (8 sonars), a camera, a speed controller for the three motors, a higher level controller (MIND) to manage the game interaction (including LEDs, speech, movement).

Motors are mounted with KAMRO wheels and are controlled at 100Hz (Tc=1/100 sec).

The control goal is set by the MIND in term of speed for each motor, once every Tc. These are 3 bytes. Soft real-time is required.

Odometry is implemented by a HW module that receives displacement data from the three mice, and computes locally the differential position and pose w.r.t. the last time instant in which it was able to provide it. This should be in principle at least synchronized with the control cycle, so it should happen every Tc. Data provided are: relative displacement along orthogonal axes (2 or 4 bytes), relative rotation (2 bytes), the corresponding estimated errors (6 bytes), and the absolute time stamp of the beginning and end of the considered period (4 bytes). With the mentioned choice, there is little need to guarantee that data provided reach who neeeds them (who will eventually manage the fact that some info is missing), but there is some need of time synchronization.

The range sensor belt is managed by a module that collects distances to objects in 8 directions every Tsb sec. It provides the last 2*8=16 bytes upon request, eventually together with a time stamp. Requests might be issued every Tc sec.

The camera might detect up to 8 different objects of up to 8 categories each, and provide their position and dimensions of the envelope rectangle in the image coordinates: this means 8*(3*(2*((2*8)+(2*8)))bits or 192 bytes. If this is made available on request, a time stamp (2 bytes) is needed. Requests can come every Tc sec.

SUMMARY of 1

• • Band less than 300 bytes/sec
  • Time sync among modules
  • Soft real-time

Requirements

- Low hardware requirements to run on 8-bit microcontrollers
- Some way to sync all processes (distributed clock)
- Lowest possible latency for real time control
- Possibility to run on different hardware links (low cost as CAN, high bandwidth as Ethernet, wireless like Zigbee)

Candidates

• Hardware link

- CAN
- Ethernet
- 802.15.4 - >Zigbee

• Communication protocol

- CANopen - TTP/A - UDP - (Ethercat)

• Communication framework

- http://www.canfestiva.org -

• Middleware

• Distributed objects

- http://arco.esi.uclm.es/en/node/18

Proposal

• CAN+Ethernet+ZigBee
• LCM for marshaling and communication (publish/subscribe)

- Some system to pass messages to local processes
- Some kind of distributed clock on LCM

• (Minimalist VM for scripting purposes)