Cloud Robot Team 46 Kecheng Liu Yubo Liu
Cloud Robot Team 46 Kecheng Liu, Yubo Liu, Yigao Shao TA: Mustafa Mukadam Prof. Scott Carney Spring 2013
Outline • • • Introduction Features Design Overview Successes and Challenges Future Improvements and Applications 2
Introduction • Cloud Robot is a true real-time virtual tour platform. • Based on implementation of three-level hierarchy that serves as the prototype for future Cloud controlled platforms 3
High Level Block Diagram 4
Three-Level Hierarchy Web Server Internet General processor (Raspberry Pi) Peripheral Data Real Time Controller (Arduino) Robot (Moving Platform) command 5
Cloud Robot • 1 st layer – Batteries, webcam, GPS antenna • 2 nd layer – Microcontrollers, logic level shifter, sensors, compass • 3 rd layer – H-bridge, GPS • Inside – Batteries, motors, decoupling capacitors 6
Features • • • Live video stream Internet-based information repository User-friendly interface Real-time collision avoidance assistance Four navigation modes – – User control Programmable Path-memorization GPS guided 7
Design Overview • Hardware • Software • Interface 8
Hardware Overview • • Power Module Motor System Sensor System Navigation System Webcam Microcontroller Unit (MCU) Real-Time Controller (RTC) Cross Processor Communication 9
Power Module • Three Separate Power Sources – 2200 m. Ah battery pack – Five 1. 2 V AA batteries for motors – 9 V alkaline battery 10
Motor System • Four 4. 5 to 6 V DC motors • DFRobot, 4 WD moving platform • H-bridge 11
H-Bridge • Design – Gate voltage, max current • Functionality – Direction – Speed 12
Sensor System • MB 1000 Family – Functionality – Accuracy – Algorithm 13
Navigation Module • GPS unit – EM 408 GPS module – Very high sensitivity • Tracking sensitivity: -159 d. Bm – Wide Range Augmentation System (WAAS) support • Improves accuracy to 5 m 14
Navigation Module • Compass unit – HMC 5883 L – I 2 C interface • Compatible with Arduino – Software algorithm support available – Unreliable data 15
Webcam • Tencent QQ XTD • Only has YUV data • 320 X 240 to guarantee fluent vision • USB connection and compatible with Raspberry Pi 16
Microcontroller Unit (CMU) • Raspberry Pi – Flexibility: rich library support, full functional operating system – High processing ability: 700 MHz— 1 GHz – Compatible firmware: USB, Screen, video hardware acceleration, GPIO 17
Real-Time Controller • Arduino Mega 2560 – User friendly interface – Real time control: rich low level processing libraries – Strong community support 18
Cross Processor Communication • Why? – RPI GPIO: 3. 3 V – Arduino digital pin: 5 V • How? – NMOS level shifter – Open-drain device 19
Logic Level Shifter Schematic 20
Interface Overview • WIFI adapter-RPi communication: USB 2. 0 • Video-RPi communication: USB 2. 0 • Compass-ARD communication: I 2 C • GPS-ARD communication: UART-RS 232 • RPi-ARD communication: SPI 21
WIFI Adapter-RPi Communication • Built-in integrated 3 -port USB hub from the direct one of BCM 2835 System on Chip (So. C). • Default driver in the Wheezy distribution Linux kernel 3. 6. • 54 Mbits/s 500 m. A current drawing with 5 V rating • Interface: WLAN 0 22
Video-RPi communication • Built-in integrated 3 -port USB hub from the direct one of BCM 2835 So. C. • Default driver in the wheezy distribution Linux kernel 3. 6. • 10 320*240 frames/s 240 m. A current drawing with FFMPEG RTMP streaming. • Interface: /dev/video 0 23
Compass-ARD Communication • I 2 C protocol – 1 byte = address (7 bits)+read(1) or write(0) • Reliable transmission – Low percentage data loss 24
GPS-ARD Communication • UART-RS 232 (Universal Asynchronous Receiver/Transmitter) • Most popular and reliable 25
RPi-ARD Communication • Communication between RTC (Real-time purpose processor) and GPP (Genera Purpose Processor). • A NEMA-like message protocol GPP and RPP information exchange is defined. – Rpi-message format: info 1, info 2, info 3, …. , $ – Ard-Message format: info 1, info 2, info 3, …, $ 26
Consensus and Synchronization: • SPI in three steps – Done and Interrupt – What • Asynchronous “Ping-Ack” 27
Why SPI? • Best approach: Shared memory • Other choices: SPI, I 2 C, SMBus, Parallel GPIO, Tx/Rx 28
Software Overview • Network Communication – – Instant Massaging Application Engine Symmetric NAT Real-time video streaming • Navigation Algorithm – Obstacle avoidance – GPS Automatic navigation 29
Introduction to Network Communication • Client: Python, C, Bash Script, Java. Script • Server: SQL, PHP • Msg: XMPP, XML, HTML, AIML User Observer Executer (MV) 30
Instant Messaging 31
Application Engine • 2 Servers – Pandorabots • Artificial Intelligence knowledge base – Afallon. yzi. me and monobe. yzi. me • Backward navigation • Patterned navigation • Data logging • Session management 32
Symmetric NAT 33
Real-time Video Streaming http: //mononobe. yzi. me/video. html 34
Avoidance Algorithm Obstacle Distance d MV 35
GPS Auto Navigation Algorithm MV MV MV 36
Successes and Challenges • Verified: – Live video stream – Internet-based information repository – User-friendly interface – Collision avoidance assistance – Three navigation modes • User control • Programmable • Path-memorization • Failed – GPS automatic navigation 37
Why GPS Failed? • Noise affecting SPI communication • Received packets from Arduino are not always correct! • Reasonable Guess: – Interrupt to RPi’s non-real time scheduler • How do we manage to solve it? 38
Setup Failure Model • Taking 500 transmissions and observe the byte aliasing probability is 1/10 in each transmission. • Repetition Coding Algorithm • Basic Idea: 39
Setup Failure Model • n = maximum probability of half of the data sequence being correct. 40
Other challenges: Motor Noise • Hardware solution C = 0. 1 u. F 41
Motor Noise • Software solution – Three-way handshake • Basic idea: – Simple time stamped messages to ensure the critical causal chain of the PING-ACK communication! – Note that Byzantine Failure can never be solved if we are in ideal unreliable asynchronous channel. Luckily, our failure model is not ideal Byzantine type. Data transmission is synchronous. 42
Motor Noise • Result – Only initiate interrupts after motor stops to ensure SPI’s data integrity. – Status is placed in the first byte of Arduino’s transmission. ‘Finish’ and ‘Executing’ message have the maximum hamming distance (Bitwise NOT). Time out is set to 100 times of transmission. Unreliability level is ~ 10^-100. • Problem – Reduces Arduino’s performance 43
Future Work • Improve isolation of motor noise • Replace SPI with shared memory (double buffer) • Increase video streaming capability • Improve navigation schemes 44
Future Applications • Extend prototype to other Cloud applications • 4 G and better communication standards 45
Credits • Special Thanks To: – Professor Carney – TA: Mustafa – The ECE Parts Shop and Mechanical Shop – The entire 445 class 46
Questions? 47
- Slides: 47