Dan

Sensor Network-BasedMobile Pendulum Robot : 

Sensor Network-Based Mobile Pendulum Robot Karl-Erik Årzén, Dan Henriksson, Anton Cervin (+ 13 students)

Objectives: 

Objectives Test case for control over a sensor network Investigate the performance that can be achieved using state of the art sensor network technology (Telos B / Zigbee) Nothing new from a control point of view

Telos B Platform: 

Telos B Platform A new platform for low power research Monitoring applications: Environmental Building Tracking Long lifetime, low power, low cost Built from application experiences and low duty cycle design principles Robustness Integrated antenna Integrated sensors Soldered connections Standards Based IEEE 802.15.4 USB IEEE 802.15.4 CC2420 radio 250kbps 2.4GHz ISM band TI MSP430 Ultra low power 1.6mA sleep 460mA active 1.8V operation State of the art sensor network mote technology

Controlled Mobile Robots: 

Controlled Mobile Robots Mobile robots in a sensor networks Robots needs to be controlled  inverted pendulum Simulated in TrueTime Implemented in lab (project course) Vision for localization

Robot: 

Robot Two DC motors Angle sensor 1 Telos mote 2 ATMEL AVR Mega8 (motors) 1 ATMEL AVR Mega16 (pendulum sensor) I2C bus

Hardware Structure: 

Hardware Structure Telos Mega16 Mega8 Mega8 I2C Radio Pendulum Motor1 Motor2 Telos Telos Telos Telos

Control Structure: 

Control Structure Local Telos or Remote Telos

Communication Structure: 

Communication Structure Single hop Multiple (two) hop Telos Telos Controller Vision data 20 ms roundtrip delay 40 ms roundtrip delay

Input-Output Latencies: 

Input-Output Latencies Open loop unstable process  local safety controller required Activated if a control signal has not arrived from a remote controller before the next sampling instant Tuned for 50 ms latency Sampling packets and control packets are tagged with time stamps (sample #)

Routing Scenarios: 

Routing Scenarios Static routing Scenario 1: During certain times (in certain regions) the robot sends directly to controller node 1 (single hop) Otherwise the robot sends to controller node 2 via the forward node (two hops) Time-division Scenario 2: The robot always sends to both controller 1 (directly) and controller 2 (via forwarding) The control signal that is received first is used Later arriving control signals are discarded Simultaneous sends causing collisions

DEMO: 

DEMO No camera Stabilization only Switch between local control – red lamp remote control (1 hop) – green lamp remote control (2 hops) – both lamps Disturbance node PC/Telos radio listener node

Experiences: 

Experiences Slow communication, approx 10 ms / hop for 20 byte packets (payload) 50 ms nominal sampling interval  1-2 hops between controller and mobile robot feasible Unless the internal communication within the network is scheduled to avoid collisions, a very large amount of collisions leading to resends or lost packets occur Also if the internal communication is scheduled, packet losses do occur Consequences for closed loop control the application must tolerate long time periods in open loop local backup controller collocated with sensors and actuators required for safety-critical applications or open-loop unstable processes time stamping essential Telos and TinyOS have worked surprisingly well however, documentation insufficient no problem implementing fairly advanced controllers using floating point

Some suggestions for future work: 

Some suggestions for future work Identify network resources that are possible to manipulate (control) for state of the art sensor network technology send power, …. Define control schemes for these Identify network sensors and network actuators Joint demonstrator scenarios if possible associated with official RUNES tunnel scenario