Difference between revisions of "Talk:Low-cost Robotics"

Revision as of 17:01, 25 August 2010

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 - ROBOGAME
* Band less than 300 bytes/sec
* Time sync among modules
* Soft real-time

• 2 - MOBILE MANIPULATOR - A 6 DOF arm mounted on a balancing robot should perform Robocup@Home tasks, with force feedback.

The robot is a balancing robot (two independent wheels, encoders on the engines, IMU). Sensors are a laser scan, a smartcam, and a sonar belt. The arm is a 6 DOF arm, with force feedback on the fingers. MIND decides where to go, on the basis of a map (SLAM), and select goals for the basis (pose, but also speed) and for the arm, once positioned the basis.

BASIS - A control loop includes the engines for the wheels, IMU and controller. This is connected to MIND from which receives setpoints of relative pose (6 bytes) and/or speed for each wheel (4 bytes), every Tcm= 1/100 sec.

The control loop is closed every 1/1000 sec. This is a control loop and it is implemented by low-level modules. IMU, engines and motors are not smart. This is not affecting communication.

ROBOTIC ARM - Let's consider that each DOF is implemented by a smart motor, and a 3-axis force sensor is mounted on fingers. Each motor posts on the bus its position (time stamped) and expected position of others... (NON SO COME SI POTREBBE FARE, SE CON CONTRATTAZIONE (ma non a 1000Hz), MASTER_SLAVE, ...) In any case some tens of bytes will move every millisecond. Hard real-time is needed, and time syncro. The loop is closed with information from the force sensor, which adds some ten of bytes each millisecond. (QUESTO E' L'UNICO PUNTO IN CUI SI AVREBBE UNA FORTE LA RICHIESTA SUL TEMPO).

SUMMARY of 2
* band less than 300 bytes/sec among MIND, smartcam, smartLRS, basis controller and ARM.
* soft real time and time syncrhronization among the same modules
* hard real time, time synchronization and >500Kbytes/sec for ARM, mainly due to force feedback (manage separately?)

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)