EDGE™ Wireless Open-Source/Open-Architecture Command and Control System (WOCCS) Group Members: –Eric Hettler –Manuel Paris –Ryan Miller –Christian Moreno –James Reepmeyer

EDGE™ Problem Wireless Open-Source/Open-Architecture Command and Control System (WOCCS) Used to control and communicate with remotely controlled vehicles and devices Communicate data over multiple channels in both directions  Send data to device for control  Receive data from device for feedback and data collection Fully modular Common interface

EDGE™ Module Breakdown

EDGE™ Stakeholders - Harris Corporation Providing funding and guidance Not the end user Work with the government on many projects that require security clearance Cannot allow senior design teams to work on these projects Designed this project to get students interested and involved with Harris and RF communication Create a pool of newly graduated engineers to recruit from

EDGE™ Stakeholders – MSD Teams End user Many senior design projects in the past required wireless communication This was a failure point in some cases Rarely had time to develop the wireless communication and just bought off the shelf systems This new system will be modular enough to meet the needs of any senior design team that needs to use it

EDGE™ Historical Project – P08027 Bio Track, Wireless Assistive Control System (WACS) Goal: Human movement interface to control RC car Used COTS components –BioRadio available data channels 4 total channels used –Labview Input filtering Signal processing Wireless data output –Custom RF hardware and microprocessor for RC car Communicated at 434MHz and 325MHz bands Total project costs: ~$411 –RF component costs: ~$100 –No software costs- Labview student version?

EDGE™ WACS Results Successes –Wireless vehicle control with muscle movement input User simulates vehicle driving motions Output from Labview is sent wirelessly to RC car Received data converted to directional signals Problems –Syncing error between Labview and BioRadio –Latency-induced device shutdown (work-around used) –BioRadio channel crosstalk (work-around used) –No feedback method for user Time-constraint based? Extra data channels existed to convey feedback –User tethered to PC area

EDGE™ P06501: About Zigbee Technology Engineers : 2 CE, 3 EE Sponsors : Sensorcon, PCB Express Advisor : Dr Hu, Dr Reddy Problem : Crossbow Technology provides wireless sensor motes but cost deters the creation of large networks Requirements : Sending commands to the network, receiving messages from the connected mote and display the real time network topology Solution : Create low cost ZigBee Data Forwarding Unit (DFU) hardware and software prototype

EDGE™ P06501: About Zigbee Technology Why : Low-power Low-cost Use of standard (Protocols and Hardware) Results : 3 concepts have been studied, only one until the end Life-time calculations : more than 4 years The final project works Open-Source, Open-Architecture Conclusion : This project relates with our project, the low-power is very useful. The only problem is the range, which is 30ft outdoor. Is it possible to go further with this technology? Lessons Learned : Find different solutions for the same problem Low-power implies sleeping devices : how to transmit data to sleeping devices Most important : separate each part of the project in sub-projects, hence the need of good modularity (interface device/device)

EDGE™ Historical Project – P08201 Vehicle Systems Technology Track, 10 Kg Payload Modular Robot Goal: Construct a land-based robotic platform. In this project, the platform was wirelessly controlled. Used COTS components –Crossbow TelosB Mote IEEE compliant, 250 kbps data transfer rate, 30 m range USB port for programming and/or communication –Crossbow MICAz module 2.4 Ghz Transceiver IEEE compliant, 250 kbps data transfer rate, 30 m range USB port for programming and/or communication –Freescale CSM12D Microcontroller Six PWM channels, Two for drive motors, Four for steering motors Twelve digital inputs Eight encoders –Java and nesC Total project costs: ~$2500 –Wireless components rather inexpensive

EDGE™ Results Successes –Wireless vehicle control Successful wireless control Each motor module could be controlled individually Long battery life Ways to Improve –Display when robot is out of range –Add functionality to obtain feedback from robot –Add PID control to maintain speed during manual operation –Add PID control to maintain position used under autonomous navigation

EDGE™ Common Problems Limitations Feedback Use of unproven and untested systems Distance and Range do not scale very well When using COTS, capability never exactly matches needs

EDGE™ To Conclude What we are confused about : Our knowledge set does not align with the project Possible direction for the future : Determine our scope Conduct several interviews