P10218 Robot Applications Platform

Detailed Design Review
February 12, 2010

1:00 pm

P10218: Robot Applications Platform / 1|Page

Table of Contents

P10218: Robot Applications Platform / 1|Page

Project Summary

Agenda

Robot Behavior

Customer Needs

Engineering Specifications

Action Items

Systems Diagram

Bill of Materials

Server Specification

Use Case Selection

Web User Interface

Prototypes

Class Diagrams

Server Side

Robot Side

Model

BeagleBoard

LCD Panel Assembly

Implementation

Webcam

Driver Support

Hardware

Test Plan

Test Server User Access

Test Web Portal Advanced Features

Test Robot Advanced Features

Test Robot/Server Interface

Feasibility Analysis

MSDII Gant Chart

Project Summary

This Project is part of the ongoing Wandering Campus Ambassador project. The Wandering Ambassador is meant to heighten awareness of environment issues and serve as an ambassador that wordlessly communicates with passerby. It wanders a pre-determined territory in a curious fashion, performing care taking duties for the plant it carries, streaming a web cam feed, and communicating wordlessly via an LCD panel. Team P10216, the navigation team, is responsible for putting the hardware together and writing low level code that interfaces with the hardware. Team P10217 is responsible for integrating the locomotion, navigation and our team’s work. We are in charge of designing and implementing an environment where software applications may be developed and integrated with the low level code for the hardware. The Software Applications team will also be responsible for implementing additional features, including a live web cam and an LCD panel for communication.

Team Members

Jeff McAfee (EE) Project Manager – Fifth year Electrical Engineering student in the Kate Gleason College of Engineering at RIT;he will be graduating in May 2010. Professional Interests include Digital Design and Communications. Upon graduating will begin full-time employment at Syracuse Research Corporation in Syracuse, NY.

David Leeds (CE) Technical Lead – Fifth year Computer Engineering student in the Kate Gleason College of Engineering at RIT;he will be graduating in May 2010. Professional Interests include Digital System Design and Embedded systems. Upon graduating will begin full-time employment at Harris RF Communications.

Alex Ford (SE) – Fifth year Software Engineering student in the Golisano College of Computing and Information Sciences at RIT; he will be graduating in May 2010. Professional Interests include intelligent and embedded software systems.

Katlyn Walsh (SE) – Fifth year Software Engineering student in the Golisano College of Computing and Information Sciences at RIT; she will be graduating in May 2010. Professional Interests include Digital embedded software systems.

Stephen Wright (SE) – Fifth year Software Engineering student in the Golisano College of Computing and Information Sciences at RIT; he will be graduating in May 2010. Professional Interests include computer graphics.

Agenda

  1. Introduction (1:00-1:05)
  2. Project Summary (1:05-1:25)
  3. Goals
  4. Robot Behavior
  5. Action Items
  6. Customer Needs/Specifications
  7. Bill of Materials
  8. Software Design Overview (1:25-2:15)
  9. Use Cases
  10. UML Diagrams
  11. Website
  12. Motion Planning
  13. Hardware Overview (2:15-2:45)
  14. LCD Screen
  15. Video Camera
  16. Scheduling/Test Plan (2:45-3:00)

Robot Behavior

The Wandering Campus Ambassador is an autonomous robot intended to showcase the abilities of RIT's engineering students, and serve as an advocate for environmental awareness. In order to achieve these goals, it must take care of the plant it carries with it, and interact with its surroundings. This document is meant to capture the details of how these goals should be achieved.

Our goals for the appearance and behavior of the robot are to create an autonomous being which has both robot and organic qualities. It is not meant to have any qualities which would be considered human. The robot is meant to walk a fine line between being a robot, yet not appearing to be too inorganic. The plant certainly adds a more organic feeling to its appearance, but we don't want to compromise this balance by adding features which would give the impression of it having overly human or robotic characteristics.

These design constraints also mean that if it plays any sort of audio, it should be subtle and unobtrusive, a human voice or an obnoxious beeping sound. Playing a short melody after moving to a target location, or updating its Twitter status, however, would be an acceptable behavior. It would still draw in passerby while at the same time not being annoying.

By the same token, any images it displays on the LCD screen should not be overly robotic. Spitting out raw data onto the screen would not be very interesting to the average passerby. Instead, the robot could take the data available to it and generate an interesting statement to make about it. For instance, it could pull data from the temperature sensor and output something like, “It is very warm out today. It is 86 degrees out.” Alternatively, the robot could display images on the LCD to wordlessly convey its status.

Another aspect of the robot's behavior is its movement. The robot is currently constrained to an area only one GPS section wide, however once we've developed algorithms for it which are sufficiently advanced, it will range over a wider area. The movement of the robot has two purposes – the first is to take care of the plant. The robot needs to provide adequate sun, rain, and temperature levels. The second purpose is to wander autonomously to capture the attention of pedestrians.

There is no particular pattern which the robot must adhere to when it moves – the only constraints are that the motion must not be too fast or jerky. It will move at a maximum speed of ten inches, and start and stop smoothly. It should not interfere with pedestrians – but it shouldn't ignore them entirely, either. The robot can't follow people, since that may interfere with them or lead it outside of its set wandering area. It can however, attempt to recognize people via the web cam and move slightly or turn towards them, perhaps displaying an image on its LCD screen if it recognizes that they are nearby.

When the ambassador loses its Wifi connection, it will drop down to a more restricted wandering pattern, using the original movement algorithm that constrains it to an area one GPS section wide. This way the robot doesn't simply stop and play dead – it continues to move and interact with others, but will not wander off where it can't receive a Wifi or GPS signal any longer.

P10218: Robot Applications Platform / 1|Page

Customer Needs

P10218: Robot Applications Platform / 1|Page

Engineering Specifications

P10218: Robot Applications Platform / 1|Page

Action Items

Item # / Description / Responsible / Due Date / Close Date / Comments
A001 / Contact Mark Chast / Replacement about Server / Steve / 02/05/10 / 02/08/10 / Mark Chast has left RIT
A002 / Make Decision on Webcam for Purchase / Dave / 02/05/10 / 02/05/10
A003 / Make Decision on LCD for Purchase / Jeff / 02/05/10 / 02/05/10
A004 / Complete Order Form for LCD / Jeff / 02/05/10
A005 / Complete Order Form for Webcam / Jeff / 02/05/10
A006 / Develop CSS Files / Jeff/Dave/Steve / 02/05/10 / 02/05/10
A007 / Complete MSDII Schedule / Team / 02/08/10
A008 / Assist Nav Team with I2C Issues / Katlyn / 02/05/10 / 02/08/10 / I2C Up and Running
A009 / Design of Motion Algorithms / Alex / 02/08/10
A010 / Completion of Detailed Design Pre-Read / Team / 02/10/10
A011 / Server space configuration / Alex / 02/24/10
A012 / Contact SE for server space / Alex / 02/12/10
A013 / Implement web site / Jeff/Dave/Steve / 04/16/10
A014 / Implement robot portal subsystem / Alex, Katlyn, Stephen / 04/02/10
A015 / Implement web server subsystem / Alex, Katlyn, Stephen / 04/09/10 / Most of this implementation will be Java applets.
A016 / Implement Twitbook application / Alex, Katlyn, Stephen / 04/16/10 / Includes setting up Facebook and Twitter accounts.
A017 / Implement motion algorithms / Alex, other SEs if necessary / 04/16/10
A018 / Implement plant care profiles / Alex, Katlyn, Stephen / 04/09/10
A019 / Integrate web cam with BeagleBoard / David / 04/16/10
A020 / Integrate LCD with BeagleBoard / Jeff / 04/16/10
A021 / Implement Robot Side Java Platform / Steve / 04/16/10
P10218: Robot Applications Platform / 1|Page

Systems Diagram

P10218: Robot Applications Platform / 1|Page

Bill of Materials

Item / Part Description / Supplier / Part # / # Needed / Price Per / Unit / Total Price / Part
System 1
1 / Header Board For MSP430F1161 / Sparkfun Electronics / DEV-00047 / 1 / $34.95 / each / $34.95 / MCU
2 / Kit Dev BeagleBoard Rev C / Digikey / 296-23428-ND / 1 / $149.00 / each / $149.00 / Processor
3 / Logitech Webcam C250 / Logitech / 960-000415 / 1 / $34.99 / each / $34.99 / Webcam
4 / Crystalfontz 320x240 LCD / Crystalfontz / CFAG320240CX-TFH-T / 1 / $106.98 / each / $106.98 / LCD
5 / BeagleBoard Headers / $0.00
6 / Jumpers 12” 10ea / Sparkfun Electronics / PRT-09387 / 4 / $4.50 / each / $18.00
Total Cost / $343.92

Server Specification

The server for the Wandering Campus Ambassador will be used to host the web portal (website) to the Ambassador, a database to store information collected by the Ambassador and server-side software to communicate and manage the Ambassador. To accomplish this, the following tools will be used in a Windows server environment:

Apache Tomcat 6.0.24(Current version)

Tomcat is used to help link the functionality of a web server to a website.

XAMPP 1.7.3 for Windows(Current version)

XAMPP includes the following utilities:

  • Apache 2.2.14 (IPv6 enabled) + OpenSSL 0.9.8l
  • MySQL 5.1.41 + PBXT engine
  • PHP 5.3.1
  • phpMyAdmin 3.2.4
  • Perl 5.10.1
  • FileZilla FTP Server 0.9.33
  • Mercury Mail Transport System 4.72

The server will be used to host a webcam feed from the Ambassador, display data related to the Ambassador, and offer direct control of the Ambassador to those with the required credentials. To safely accommodate the space requirements for these tools, database storage and any software developed by the Applications team, a minimum of 10GB of server space is preferred.

Use Case Selection

Name: / Robot pushes status data updates to the server
Actors: / Robot
Description: / The robot sends a message to the server containing its updated status and sensor data.
Preconditions: / Robot must have an internet connection via Wifi
Postconditions: / The latest sensor data will be stored on the server.
If a new status message has been generated, a new message will have been posted to Twitter/Facebook.
Normal Flow: /
  1. The robot reads the latest results from the sensors.
  2. The robot checks the time since it has last posted data, if 30 minutes have passed, it decides to push status updates to the server.
  3. The robot pushes status data updates to the server.
  4. Server receives status data update.
  5. Server sends a response indicating that the data was successfully received
  6. Server stores the status data and status message (if a new one has been generated)
  7. If a new status message has been generated, the server spawns a thread to post the message.

Alternative Flows: / 3a. The robot pushes status data updates to the server.
3b. Robot does not receive a success reply.
3c. Robot waits and then attempts x re-tries.
Exceptions: / n/a
Priority: / High
Frequency of Use: / High
Assumptions: / n/a
Notes and Issues: / The robot will push status updates every thirty minutes or so.
Name: / User views sensor data via web page
Actors: / User
Description: / The user navigates to the status web page of the robot, and views the available sensor data.
Preconditions: / Robot must have an internet connection via Wifi
Postconditions: / Robot status is displayed to the user.
Normal Flow: / 1. User navigates to status web page of the robot.
2. Web page sends request to stand alone server for robot status.
3. Server pulls most recent sensor data from the database.
4. Server responds with robot status
5. Web page displays robot status
Alternative Flows: / n/a
Exceptions: / n/a
Priority: / High
Frequency of Use: / High
Assumptions: / n/a
Notes and Issues: / We intend to use Ajax to pull updates for the page every few minutes or so. This way the page will update dynamically with having to refresh the page.
Name: / User views robot web cam
Actors: / User
Description: / The user navigates to the web cam page of the robot portal, and views the streaming video.
Preconditions: / Robot must have an internet connection via Wifi
Postconditions: / Robot web cam is displayed to the user.
Normal Flow: /
  1. User navigates to web cam page
  1. Web page sends request to stand alone server for web cam data
  2. Server responds with video frames.

Alternative Flows: / 3a. Server responds with “no video available” message.
3b. Send video not available error to video player
Priority: / Low
Frequency of Use: / High
Special Requirements: / n/a
Notes and Issues: / n/a
Name: / User logs in with administrator credentials
Actors: / A user with administrator privileges
Description: / The user navigates to the web page of the robot, and logs in as an admin.
Preconditions: / Robot must have an internet connection via Wifi
Postconditions: / Manual control and (partial) configuration of the robot is now available via the web page.
Normal Flow: /
  1. User navigates to robot's web page.
  1. User selects “log in”
  2. Login page is displayed to the user.
  3. User enters valid user name and password
  4. Web page sends log in request to server.
  5. If the user is on the list of admins, and no one else is currently logged on, server sends authorization request to RIT LDAP.
  6. LDAP responds with yes
  7. User can now view manual Controls Page.

Alternative Flows: / 5a. Web page sends log in request to server.
5b. LDAP responds with no.
5c. Server responds with failure for login
5d. Login page is redisplayed to user with error message.
5a. The web page sends log in request to server.
5b. The user is not on the list of admins.
5c. Server responds with failure for login
5d. Login page is redisplayed to user with error message
5a. The web page sends log in request to server.
5b. An admin is already logged in.
5c. Server responds with failure for login
5d. Login page is redisplayed to user with error message
Exceptions: / n/a
Priority: / Medium
Frequency of Use: / Low
Notes and Issues: / We are planning to hook the authentication into RIT’s LDAP.
We are not permitting more than one admin to be logged in at a time. This reduces the complexity considerably, since we won’t have to worry about conflicting commands from two or more users.
P10218: Robot Applications Platform / 1|Page
Name: / User controls robot via web page controls
Actors: / Admin
Description: / The user navigates to the manual control page for the robot, and remotely controls it via the controls provided on the web page.
Preconditions: / Robot must have an internet connection via Wifi.
User must be logged in as admin.
Postconditions: / Robot moves in the direction selected by the user.
Updated web cam and GPS info is displayed to the user.
Normal Flow: /
  1. User navigates to robot's 'controls' web page.
  1. User commands the robot to turn left.
  2. Web page sends 'turn left' request to server.
  3. Server forwards the 'turn left' request to the robot client
  4. Robot client stops autonomous movement thread.
  5. Robot client calls 'turn left' function.
  6. Robot turns left.
  7. Robot client responds to request with updated web cam image and GPS info.
  8. Server responds to request with updated web cam and GPS
  9. Web page with updated web cam and GPS is displayed to user

Alternative Flows: / 5a. Server forwards the 'turn left' request to the robot client
5b. Server does not receive a response from the robot.
5c. Controls page is redisplayed to user with error message.
Exceptions: / n/a
Priority: / Low
Frequency of Use: / Low
Notes and Issues: / If the robot does not receive a movement request for x minutes, it re-spawns the autonomous movement thread. This way we avoid users forgetting to explicitly hand control back to the robot.
Name: / User chooses alternate profile for autonomous movement
Actors: / Admin
Description: / The user navigates to the manual control page for the robot, and selects an alternate profile for autonomous movement.
Preconditions: / Robot must have an internet connection via Wifi.
User must be logged in as admin.
Postconditions: / Robot begins to move according to the new movement profile that has been selected.
Normal Flow: /
  1. User navigates to robot's 'controls' web page.
  1. User selects a control algorithm from drop down box
  2. Control algorithm info is displayed to the user.
  3. User hits “apply movement algorithm”
  4. Web page sends request to server to change movement algorithm
  5. Server sends request to robot to change movement algorithm
  6. Robot client stops autonomous movement thread.
  7. Robot client starts selected autonomous movement thread
  8. Robot begins moving according to newly selected algorithm
  9. Robot client responds to request indicated success.
  10. Server responds to request with indicated success
  11. Web page displays notification to user that the algorithm has been successfully changed.

Alternative Flows: / 6a. Server sends request to robot to change movement algorithm
6b. Server does not receive a response from the robot.
6c. Controls page is redisplayed to user with error message.
Exceptions: / n/a
Priority: / Low
Frequency of Use: / Medium
Notes and Issues: / None.
Name: / User chooses alternate profile for plant care
Actors: / Admin
Description: / The user navigates to the manual control page for the robot, and selects an alternate profile for plant care.
Preconditions: / Robot must have an internet connection via Wifi.
User must be logged in as admin.
Postconditions: / Robot begins to take care of plant according to parameters specified in the profile selected.
Normal Flow: /
  1. User navigates to robot's 'controls' web page.
  1. User selects a plant care profile from drop down box
  2. Plant care profile info is displayed to the user.
  3. User hits “apply plant care profile”
  4. Web page sends request to server to change plant care profile
  5. Server sends request to robot to change plant care profile
  6. Robot begins caring for plant according to selected plant profile
  7. Robot client responds to request indicated success.
  8. Server responds to request with indicated success
  9. Web page displays notification to user that the plant care profile has been successfully changed.

Alternative Flows: / 6a. Server sends request to robot to change plant care profile
6b. Server does not receive a response from the robot.
6c. Controls page is redisplayed to user with error message.
Exceptions: / n/a
Priority: / Low
Frequency of Use: / Low
Notes and Issues: / How are we dynamically switching between plant care profiles?
The plant care profile will be threshold values for watering, sun/shade seeking, etc.
Name: / Robot posts Twitter/Facebook update.
Actors: / Robot
Description: / The robot posts an update to its linked Twitter/Facebook accounts using either current sensor data or pre-generated statements.
Preconditions: / Robot must have an internet connection via Wifi.
Postconditions: / Update is posted to the website and Twitter/Facebook.
Normal Flow: /
  1. X Hours have passed since last Twitter update.
  1. Robot generates a statement to post. It may do this using sensor data or choose a phrase at random.
  2. Robot sends new status update to server as a string that has been generated using sensor data. i.e. “It is currently 78F out.”
  3. Server spawns a separate thread with the necessary parameters to post the update.
  4. Update is posted to the website and Twitter/Facebook.

Alternative Flows: / n/a
Exceptions: / n/a
Priority: / High
Frequency of Use: / High
Notes and Issues: / It's still not decided what kind of material should be posted. Sensor updates are a little boring, yet dynamically generating things for it to say is also outside of the scope of the project right now.
P10218: Robot Applications Platform / 1|Page

Web User Interface