Clementine Design Document - Drexel CCIyfcai/CS451/samples/... · followed in the design and...

O~~ Design Document

1

Clementine Design DocumentProject Clementine Group

Table of Contents1. Introduction ............................................................................................................................................ 4

1.1. Concept and Overview ................................................................................................................ 41.2. Design Goals ............................................................................................................................... 51.3. Technical Designations ............................................................................................................... 6

2. Design ..................................................................................................................................................... 72.1. Core ............................................................................................................................................. 7

2.1.1. Input Layer Classes .......................................................................................................... 72.1.1.1. InputDeviceFactory ............................................................................................... 82.1.1.2. InputDevice ............................................................................................................ 92.1.1.3. WebcamDevice .................................................................................................... 102.1.1.4. WiimoteDevice .................................................................................................... 11

2.1.2. Data Processing Layer Classes ....................................................................................... 112.1.2.1. Subscriber ............................................................................................................ 11

2.1.2.1.1. Initialize() ................................................................................................. 122.1.2.1.2. RetryInputDeviceRegistration() ................................................................ 122.1.2.1.3. ProcessUpdate(scene) ............................................................................... 132.1.2.1.4. InputDevice() and InputDeviceType() ...................................................... 132.1.2.1.5. GetMostRecentScene() ............................................................................. 13

2.1.2.2. SubscriberMarshal ............................................................................................... 132.1.2.2.1. RegisterSubscriber(subscriber) ................................................................. 142.1.2.2.2. RegisterInputDevice(type) ........................................................................ 142.1.2.2.3. UpdateSubscriber(id) ................................................................................ 14

2.1.2.3. Regressor ............................................................................................................. 152.1.2.3.1. PredictPoint(time) ..................................................................................... 152.1.2.3.2. GetSmoothedValueOfMostRecent(weight) .............................................. 152.1.2.3.3. UpdateModel() .......................................................................................... 15

2.1.2.4. LinearRegressor ................................................................................................... 162.1.2.4.1. Line ........................................................................................................... 162.1.2.4.2. UpdateModel() .......................................................................................... 162.1.2.4.3. PredictPoint(time) ..................................................................................... 172.1.2.4.4. GetSmoothedValueOfMostRecent(weight) .............................................. 17

2.1.2.5. DataPoint ............................................................................................................. 172.1.2.5.1. PushInputPoint(point) ............................................................................... 182.1.2.5.2. GetPredictedPoint(time) ............................................................................ 182.1.2.5.3. SmoothedValue() ...................................................................................... 182.1.2.5.4. ChangeRegressor(type) ............................................................................. 18

2.1.2.6. Scene .................................................................................................................... 192.1.2.7. DataPointMarshal ................................................................................................ 20

2.1.2.7.1. Scene(inputDevice) ................................................................................... 20

O~~ Design Document

2

2.1.2.7.2. onInputEvent(frame) ................................................................................. 202.1.2.8. Timer ................................................................................................................... 21

2.1.2.8.1. SchedueledCallback .................................................................................. 222.1.2.8.2. ScheduelCall() .......................................................................................... 222.1.2.8.3. Update() .................................................................................................... 222.1.2.8.4. Stop ........................................................................................................... 22

2.1.2.9. Point ..................................................................................................................... 232.1.2.10. Color .................................................................................................................. 242.1.2.11. ConfigurationReader .......................................................................................... 242.1.2.12. Putting it all together ......................................................................................... 25

2.1.3. Data Flow ....................................................................................................................... 252.1.3.1. Input Flow ........................................................................................................... 262.1.3.2. Data Point Flow ................................................................................................... 27

2.2. Interfaces ................................................................................................................................... 282.2.1. 3D Interface .................................................................................................................... 28

2.2.1.1. 3DInterface Class ................................................................................................ 292.2.1.1.1. Compute3DPosition .................................................................................. 302.2.1.1.2. Update3DPosition ..................................................................................... 31

2.2.2. Spatial Interface .............................................................................................................. 312.2.2.1. Vector .................................................................................................................. 312.2.2.2. Gesture ................................................................................................................. 32

2.2.2.2.1. endLocation .............................................................................................. 322.2.2.3. GestureResult ....................................................................................................... 322.2.2.4. GestureFactory ..................................................................................................... 332.2.2.5. GestureInterface ................................................................................................... 34

2.2.2.5.1. GestureRepository ..................................................................................... 352.2.2.5.2. ProcessUpdate ........................................................................................... 352.2.2.5.3. FindGestures ............................................................................................. 352.2.2.5.4. ImportGesture ........................................................................................... 352.2.2.5.5. SendGestureResults .................................................................................. 36

2.3. Demos ........................................................................................................................................ 362.3.1. 3D Demo (Tennis) ......................................................................................................... 36

2.3.1.1. Game .................................................................................................................... 372.3.1.2. SceneGraph .......................................................................................................... 372.3.1.3. SceneObject ......................................................................................................... 382.3.1.4. BoundingBox ....................................................................................................... 382.3.1.5. RenderableObject ................................................................................................. 392.3.1.6. StaticObject .......................................................................................................... 392.3.1.7. DynamicObject .................................................................................................... 392.3.1.8. BallLauncher ........................................................................................................ 402.3.1.9. Ball ....................................................................................................................... 402.3.1.10. Player ................................................................................................................. 41

2.3.2. Spatial Demo (Blender) .................................................................................................. 412.3.2.1. Gesture Interpreter ............................................................................................... 422.3.2.2. ClemX11 .............................................................................................................. 42

2.4. Diagnostic Utility ...................................................................................................................... 43

O~~ Design Document

3

2.4.1. Classes ............................................................................................................................ 442.4.1.1. Chart and Support Classes .................................................................................. 44

2.4.1.1.1. Axis ........................................................................................................... 452.4.1.1.2. DataSet and DataPoint .............................................................................. 452.4.1.1.3. Chart ......................................................................................................... 452.4.1.1.4. ScrollingTimeChart ................................................................................... 462.4.1.1.5. GestureChart ............................................................................................. 462.4.1.1.6. LocationChart ........................................................................................... 47

2.4.1.2. Perspective classes ............................................................................................... 472.4.1.2.1. Perspective ................................................................................................ 482.4.1.2.2. 3DInterfacePerspective ............................................................................. 492.4.1.2.3. SpatialInterfacePerspective ....................................................................... 50

2.4.1.3. Input Controllers .................................................................................................. 502.4.1.3.1. 3DInterfaceInputController ....................................................................... 512.4.1.3.2. SpatialInterfaceInputController ................................................................. 51

2.4.1.4. Main class ............................................................................................................ 522.4.1.4.1. MainLayout ............................................................................................... 52

2.4.1.5. Input and Display Flow ....................................................................................... 532.4.2. Mockups ......................................................................................................................... 54

2.4.2.1. 3D Interface Perspective ..................................................................................... 552.4.2.2. Spatial Interface Perspective ............................................................................... 57

3. Future Development ............................................................................................................................. 593.1. Interfaces ................................................................................................................................... 593.2. Demos ........................................................................................................................................ 59

3.2.1. Video Game Shooter ...................................................................................................... 593.2.2. 3-D Architectural Presentations ..................................................................................... 59

4. Design Patterns ..................................................................................................................................... 614.1. Singleton Pattern ....................................................................................................................... 614.2. Abstract Factory Pattern ............................................................................................................ 61

Glossary .................................................................................................................................................... 635. Writing Center Changes ....................................................................................................................... 69

O~~ Design Document

4

1. IntroductionThe purpose of this document is to describe the software architecture and class structure that will befollowed in the design and implementation of Project Clementine.

1.1. Concept and Overview

Project Clementine is a programmer's API. It is designed to make it easy for developers to learn howto use it and implement their applications with it. External devices are used to capture input and sendthe data to the Core layer of the library. There it is processed and, depending on what the developerchooses, sent to the interface level, where either the Spatial interface or the 3D interface interceptsit. From the interface level, the input is scanned for any data meaningful to the interface. If found.this data will be given context. This context, different for each interface, will be relayed to the user'sapplication at regular intervals.

The different contexts given to data in Clementine all attempt to provide the application some idea ofwhat the user is trying to do. The 3D Interface relays information about the 3D position of the user inthe room relative to the camera. The Spatial Interface attempts to map the user's hand movements togestures, then sends those gestures to the application.

The developer's application is meant to extend a class in an interface in order to alert Clementine thatthat is the data and context which they wish to receive. This inheritance will also provide a portalthrough which context data can be passed to the application.

The algorithms that are shared between all context giving interfaces are aggregated into the coresection of the library. Here raw data is smoothed and corrected before it ever reaches the interfacelevel.

Because Clementine is designed for developers to use, and is not a complete piece of software inthe usual sense of the word. The design decisions made in terms of its implementation have morein common with the finished product than other software engineering projects, which must define acontext in which they are to be used.

Our project is designed not only to work, but for the class structure and design to be intuitive anduseful to the target developer using our API. To demonstrate the intuitiveness of our library, we willprovide a demonstration application for each interface. They are discussed in detail in the demossection.

Along with these demos, we are providing a diagnostic utility. This utility will help developersvisualize data coming out of Clementine during runtime so they can better tailor their applications toour library.

O~~ Design Document

5

1.2. Design Goals

• Speed. Project Clementine is best described as real-time. While the responses from the libraryare not instantaneous, they must be as close to instantaneous as possible in order to provide therequesting application with rapid and responsive feedback. If Clementine is too slow to receive datafrom its input devices, the user will quickly become frustrated with the perceived slowness of thesystem. This speed is established in two ways: firstly, with the use of a universal timer throughoutthe library, ensuring a constant interval for which data is to move from one part of the library to thenext. The second is the intelligent handling of delays or slowdowns along the library, in order tosimulate over gaps, and thus minimize the effect these slowdowns have on the overall experience.

• Ease of use and implementation. The library being designed is one piece of an overall psuedo-virtual reality solution for game and application developers. Because small development shops andthe average household's processing and computing power are our goals, Project Clementine must besimple to pick up, provide useful and meaningful feedback to developers who use it, and integratesimply and effectively into existing applications and application frameworks. This same efficiencyapplies to the hardware used with Clementine. Foregoing enormous displays and custom hardware

O~~ Design Document

6

for the average household computer and webcameras / Wii remotes widens the potential developerand user base.

1.3. Technical Designations

All diagrams of class structure, architecture, sequencing, et cetera, are using diagrammatic notation asdescribed in the UML 1.4 specification unless designated otherwise.

O~~ Design Document

7

2. Design

2.1. Core

The core is the most important part of this project. Every other aspect depends upon core, thereforedevelopment on core is to be a main focus.

Core is responsible for the following tasks:

• Polling an input device for input data

• Assigning a time for that input data

• Discovering which DataPoint that input data most likely belongs to

• Smoothing the input data

• Extrapolating missing data

• Queuing waiting data

• Tracking subscribers

• Scheduling updates for waiting subscribers

• Providing updates to subscribers at requested intervals with current data

We will now examine the design for core, and show how our design enables us to perform all of thesetasks.

2.1.1. Input Layer Classes

Requirement Matrix: _data_importing,_data_exporting

O~~ Design Document

8

This section details out the sub-section of Core dealing with Input Devices. The Input Devices areresponsible for grabbing the raw data going along with their hardware, and converting it into 2dimensional point data.

This means that the web cam will be responsible for pulling a snapshot of it's current view,determining the different colored blobs of a given size, and reporting the x and y coordinates ofthose blobs.

Similarly, the wiimote will be responsible for pulling the x and y data for the different Infra Reddots that it is tracking. In the same way, it will report those x and y positions.

2.1.1.1. InputDeviceFactory

Requirement Matrix: _multiple_unique_devices

The InputDeviceFactory object, for which there is only one of in Core, will determinethe appropriate sub-class of InputDevice to instantiate for a given Subscriber. Since there

O~~ Design Document

9

are potentially many different InputDevice sub-classes, a Factory pattern is required todecipher which InputDevice is desired.

In general, a particular Subscriber will know which InputDevice to instantiate based onthe corresponding Interface which is registering the Subscriber. These are only defaultbehaviors, of course, and any Interface will be allowed to create a Subscriber with anydesired InputDevice sub-class.

While the Subscriber may use default arguments or developer specified ones, theInputDeviceFactory::getInputDevice method must be supplied the correct enumeratedvalue.

2.1.1.2. InputDevice

Requirement Matrix:_single_point_exporting,_multi_point_objects_exporting,_raw_data_storage,_data_streamline

The InputDevice class is an abstract class instantiated by the InputDeviceFactory. It'sjob is to trigger the InputDevice::onInputEvent method once it has raw data to supply toCore.

To begin the trigger of the InputDevice::onInputEvent method, the inheriting classeswill also utilize a reference to the Timer class supplied by Core. Based off of the

O~~ Design Document

10

configurations loaded at run time, Core will be scheduling polling events to start theInputDevice::onInputEvent method.

The interface for the Timer object calling InputDevice::onInputEvent will be uniformamongst the inherited classes, but what actually goes on in the method will vary based onhow the device retrieves its raw data.

2.1.1.3. WebcamDevice

Requirement Matrix: _web_cam_data

During the execution of WebcamDevice::WebcamDevice, the _webCam attribute oftype CvCapture* will be created, and subsequently destroyed on the deconstructor,WebcamDevice::~WebcamDevice. This attribute allows for the object to utilze the OpenCvlibrary to grab images off of the web cam.

As we already know from the parent InputDevice class, theWebcamDevice::onInputEvent method is already hooked into the Timer instance of thedevice class. As such, this is the only public method used for this class.

Within the execution of WebcamDevice::onInputEvent, the first private method to becalled is WebcamDevice::getImage. This method will grab the image off of the web camand strip it of it's color. The image needs to be in gray scale to utilize the blob trackingfunctionality of OpenCv.

Following this, the WebcamDevice::getBlobs method will be called, utlizing the imagejust grabbed. From this grayscale image, it will determine the x and y coordinates of everyblob of the non-filtered color, which meets a certain threshold in size. We do not want to beincluding trivially small blobs as actual data points.

Finally, after the correct blobs have been recognized, they will be converted into ourInputPoint data type where they will be gathered in an array and passed throughWebcamDevice::onInputEvent.

External Library. The WebCamDevice will make use of Intel's OpenCV library. It willbe able to scan in the images from the hardware web came and detect colored blobs from theimage.

O~~ Design Document

11

2.1.1.4. WiimoteDevice

Requirement Matrix: _wii_remote_data

Given the simplicity and procedural nature of libwiimote, all actions needed to retrievethe x and y data from the device will be entirely contained within the public methodWiimoteDevice::onInputEvent. As we already know, this method is scheduled using thereferenced Timer object.

External Library. The WiimoteDevice will make use of the libwiimote library, a linuxlibrary used to get position and button actions from a WiiMote device.

2.1.2. Data Processing Layer Classes

2.1.2.1. Subscriber

O~~ Design Document

12

Requirement Matrix: _programmer_interface

The Subscriber class is the base class for all of the interfaces in Clementine. Any interfacemust extend Subscriber.

Each Subscriber instance has an identification number, Subscriber::_id. ThisID number is used by the SubscriberMarshal to differentiate between Subscriberinstances. It is obtained during the call to SubscriberMarshal::PushSubscriber in theSubscriber::Initialize function.

Along with the _id member, each Subscriber has an _updateFrequency. This protectedmember is used when requesting an update from Timer.

The Subscriber::_inputDeviceType member is initially set to InputDeviceType::NONE.This is done so that the Interface level of the hirearchy has the ability to set its InputDeviceto be whatever it may need. This value is used when requesting an InputDevice inside ofSubscriber::Initialize.

The Subscriber::_inputDevice member is used to track the InputDevice currently beingused by this interface. It is how the SubscriberMarshal knows which Scene to obtain forthe Subscriber.

The constructor remains private because this class is an abstract class and not meant to beinstanciated, even though it has non-abstract final methods. Its implementors should beinstanciated and then call these methods.

2.1.2.1.1. Initialize()

A requirement for writing an extension of an interface, is calling this::Initializewhen you want your application to start recieving updates from Clementine. TheInitialize function is a protected method in Subscriber. Though it may beextended, a call up hirearchy is required. For example, if one were to override theSubscriber::Initialize function in either an interface or a users application, onemust first send a call up to Subscriber::Initialize.

Inside of Subscriber::Initialize our Subscriber does two things. It registers itselfwith the SubscriberMarshal via SubscriberMarshal::RegisterSubscriber. In thesame line, it also sets its own Subscriber::_id variable. Next, it attempts to registeran InputDevice using SubscriberMarshal::RegisterInputDevice. In this sameline, it also sets its own _inputDevice variable. If the InputDevice registration fails,SubscriberMarshal::RegisterInputDevice will return InputDeviceType::NONE.In this case, the Subscriber instance will throw an error to be caught by the usersapplication.

2.1.2.1.2. RetryInputDeviceRegistration()

If the users application wishes to retry device registration after afailure in the Subscriber::Initialize method, it can do so via the

O~~ Design Document

13

Subscriber::RetryInputDeviceRegistration method. This method simply repeatswhat was done in SubscriberMarshal::Initialize. It will return true if it was asuccess, and false otherwise.

2.1.2.1.3. ProcessUpdate(scene)

The last method in Subscriber is Subscriber::ProcessUpdate. This method is avirtual method, and as such, it must be implemented by extending classes. It is intendedto be implemented inside the interface level of the hierarchy. This method will becalled at each iteration of _updateFrequency after the Subscriber has been registeredwith the current Scene.

When called, this method sets Subscriber::_mostRecentScene to be the parameterpassed in.

This method, like Subscriber::Initialize requires a call up the hierarchy whenoverridden by child classes.

2.1.2.1.4. InputDevice() and InputDeviceType()

Subscriber::InputDeviceType and Subscriber::InputDevice are justgetters for _inputDeviceType and _inputDevice. These members are notsettable by external classes. _inputDevice is not even settable by child classes,it is only meant to be set in the Subscriber::Initialize method or theSubscriber::RetryInputDeviceRegistration method.

2.1.2.1.5. GetMostRecentScene()

This method returns Subscriber::_mostRecentScene. It exists so that interfaces anduser applications can access the scene at any time if they need more data than what ispresented to them. This is particularly useful in the Diagnostic Utility.

2.1.2.2. SubscriberMarshal

The SubscriberMarshal class is a singleton responsible for tracking and providingdata to all Subscriber instances currently being used by the library. It is also

O~~ Design Document

14

responsible for assigning IDs to Subscriber instances when they request it during theirSubscriber::Initialize method.

The SubscriberMarshal has a private static member called _instance. This static memberholds the only existing instance of SubscriberMarshal providing singleton functionality.This value is used when accessing SubscriberMarshal::GetInstance later on.

Once a SubscriberMarshal is instantiated, it will have two private members. It contains aset of Subscriber instances, held in _subscribers, and _currentID, which contains thecurrent ID number to be assigned to the next requesting Subscriber instance.

To satisfy the singleton pattern, the SubscriberMarshal has the GetInstance method.This public static method provides requesting classes with the one and only instance of theSubscriberMarshal class. Inside of this method, it tests to see if _instance is null, if soit creates the one instance of the SubscriberMarshal, and returns it, otherwise it simplyreturns _instance.

2.1.2.2.1. RegisterSubscriber(subscriber)

Once an instance of SubscriberMarshal is obtained, you can call its three publicfunctions. The first of these functions is RegisterSubscriber. This method takes aSubscriber instance as a parameter and returns an integer. Inside of this function,it adds the Subscriber instance to SubscriberMarshal::_subscribers, thenincrements SubscriberMarshal::_currentID and returns _curentID-1. This way,the Subscriber instance passed in now has _currentID as its Subscriber::_idand is now tracked by SubscriberMarshal. This method also requests a callto SubscriberMarshal::UpdateSubscriber from the Timer class via theTimer::ScheduelCall method. It requests the call to come in the number ofmilliseconds held in Subscriber::_updateFrequency and requests the parameter tobe Subscriber::_id.

2.1.2.2.2. RegisterInputDevice(type)

The second method is SubscriberMarshal::RegisterInputDevice. This methodrequests an InputDevice instance from InputController::GetInputDevice usingthe InputDeviceType passed in. If InputController is unable to create that device,then it returns null.

2.1.2.2.3. UpdateSubscriber(id)

The last method to be called in the SubscriberMarshal instance isUpdateSubscriber. This method takes an integer as a parameter. This methodfinds the Subscriber whose Subscriber::_id equals the parameter passed in.It then retrieves the current scene from DataPointMarshal::Scene using theSubscriber::_inputDevice property as a parameter. It then passes the scene to theSubscriber instance via the Subscriber::ProcessUpdate function.

O~~ Design Document

15

2.1.2.3. Regressor

Requirement Matrix: _data_transformation,_a_href_g_data_point_data_point_a_analysis,_dimensional_smoothing,_data_extrapolation,_future_computation_using_extrapolated_data

The Regressor class is an abstract class. It defines any class that is capable of deciphering atrend in a set of InputPoints. These Regressors are capable of predicting the next point ofdata in their InputPoint set at some time in the future. Due to the nature of dead reckoning,it is more likely that the prediction will be correct when it is a small time in the future.

Each Regressor implementation will have access to both members of the Regressor class.These members are the set of InputPoints that are its data set, the Regressor::_pointsmember, and the Regressor::_regressorType member, which simply denotes the type ofregressor that it is.

2.1.2.3.1. PredictPoint(time)

The Regressor class has three abstract methods that need to be implemented by childclasses. The first of these methods is the Regressor::PredictPoint method. Thismethod takes a time in the future, in milliseconds, as a parameter, and returns thepredicted point at that time.

2.1.2.3.2. GetSmoothedValueOfMostRecent(weight)

The second abstract method required by Regressor is theRegressor::GetSmoothedValueOfMostRecent. This method takes a weightedaverage of the actual most recent InputPoint in Regressor::_points and the valueat that time on the regression function. The value passed in as a parameter must bebetween 0 and 1. This value will be the weight of the actual most recent InputPointwhen performing the weighted average. It will default to 0. If no parameter is passed in,the perfectly smoothed value will be returned.

2.1.2.3.3. UpdateModel()

The final abstract method required by Regressor is the Regressor::UpdateModelfunction. This function is called after the set of InputPoints is changed via the

O~~ Design Document

16

Regressor::InputPoints setter. It triggers the implementing class to reevaluate itsmodel in light of the new data.

2.1.2.4. LinearRegressor

Requirement Matrix: _linear_regression

The LinearRegressor implements the Regressor abstract class. As such, it mustimplement the two abstract methods defined in Regressor. The LinearRegressor classuses the least squares method of finding the line of best fit for the data set. The advantagesof doing this is that the computation will be fast and easy to implement. The drawback isthat not all data follows a linear pattern. Luckily, with out implementation, our data will betaken with such rapidity, that a linear approximation is perfectly acceptable, and preferableover no regression at all.

The least squares method produces a slope and y-intercept for a line that is approximatelythe best fit for the data set. Since the X and Y dimensions of an InputPoint are independentrandom_variables, they must each have their own line of best fit, where the x-axis denotestime, and the y-axis their dimension.

2.1.2.4.1. Line

To satisfy this need, LinearRegressor has its own aggregate class,LinearRegressor::Line. It has an instance of LinearRegressor::Line foreach dimension of the data set, LinearRegressor::_xLineOfBestFit andLinearRegressor::_yLineOfBestFit. LinearRegressor::Line has values that definea line as public members, as well as a function to find the dependent variable at anyvalue of the independent variable (Line::GetYAtX).

2.1.2.4.2. UpdateModel()

This function is an implementation of the abstract Regressor::UpdateModel method.It recomputes the values that make up the LinearRegressor::_xLineOfBestFit andLinearRegressor::_yLineOfBestFit using the method of least squares whenever theunderlying data set is changed.

O~~ Design Document

17

2.1.2.4.3. PredictPoint(time)

When LinearRegressor::PredictPoint is called, it requests thevalue at its parameter from each LinearRegressor::Line, via theLinearRegressor::Line::GetYAtX method.

2.1.2.4.4. GetSmoothedValueOfMostRecent(weight)

When LinearRegressor::GetSmoothedValueOfMostRecent is called, thevalue for the present is obtained from each of the Lines like it was for the futurein LinearRegressor::PredictPoint. However, this value is then averagedwith the actual value at that time, using the weighted average scheme depicted inRegressor::GetSmoothedValueOfMostRecent.

2.1.2.5. DataPoint

Requirement Matrix:_data_history,_data_history_configuration,_data_history_access_time,_data_streamline,_raw_data_storage

The DataPoint class is the central data container for our library. It is the container forall data passed in, out and throughout Clementine. The purpose of the DataPoint classis to hold data about a single entity existing in real-life. This entity may be an IR dot onsomeone's glasses, or a color on the fingertip of someone's glove. The DataPoint containsinformation about that point beyond its current position. It has reference to it's history up to20 InputEvents back. Using this data, it can dead reckon its next point in case of failure orto aid in obtaining the next value.

To perform these actions, a DataPoint needs two things. One is the set of InputPointsheld in the DataPoint::_points array. These InputPoints represent the history of thatpoint, up to 20 InputPoints back. These values are used by the instance of Regressorinside of DataPoint held in the DataPoint::_regressor variable. The _regressormember is used to compute the Regression model for the DataPoint, which in turn can beused in smoothing and dead reckoning.

O~~ Design Document

18

2.1.2.5.1. PushInputPoint(point)

A DataPoint must have the ability to accept new data in the form of InputPoints.This ability is satisfied by the DataPoint::PushInputPoint method. Thismethod will append the passed in parameter to the set of InputPoints stored inDataPoint::_points, if the length of DataPoint::_points is greater than 20, then itwill pop out the least recent observation. This will ensure that there will never be morethan 20 InputPoints used to define a DataPoint. When a new InputPoint is added,the Regressor will be updated with the new values via the Regressor::InputPointssetter.

2.1.2.5.2. GetPredictedPoint(time)

A DataPoint must also be able to predict its position in the future. This ability willbe used in many circumstances. One such circumstance is when the InputDevicecannot provide enough InputPoints to satisfy the existing set of DataPoints. In thisinstance, the DataPoints who cannot be satisfied must dead reckon their next positionusing this method.

To perform this action, DataPoint has a method calledDataPoint::GetPredictedPoint. This method uses DataPoint::_regressor tocompute the point in the future using Regressor::PredictPoint.

2.1.2.5.3. SmoothedValue()

Along with prediction, the DataPoint is capable of returning thecurrent value smoothed. This smoothed value is obtained from theDataPoint::SmoothedValue method, which obtains it's result from theRegressor::GetSmoothedValueOfMostRecent.

For now, Regressor::GetSmoothedValueOfMostRecent will be called with aparameter of 0, thus requesting the smoothed value only, with no weighting to the mostrecent reading. Later the ability to specify the amount of smoothing may be given to theuser's application or to the interface. However, this functionality is not present in thescope of this document.

2.1.2.5.4. ChangeRegressor(type)

It is also possible to change the Regressor of a DataPoint. One may not simply assigna new Regressor instance, but via the public method DataPoint::ChangeRegressor,one can specify the type of Regressor they would like DataPoint to start using.

The scope of this document only covers one type of Regressor, the LinearRegressor.However the future may see multiple Regressors. Thus this functionality is addednow.

O~~ Design Document

19

2.1.2.6. Scene

Requirement Matrix: _input_frames

The Scene object represents everything that is and has recently been seen by anInputDevice, referenced by Scene::_inputDevice. It also has references to thecurrently active DataPoints and the DataPoints within the waiting queue inside ofScene::_activeDataPoints and Scene::_waitingDataPoints. These properties are readthrough the getters of the same name.

The waiting queue is a first-in last-out queue. Meaning that it is like a stack of papers, themost recent one you put on is the first one you pull off. This is because when a point isfound, it is most likely that the most recent point lost is the same as that new point.

The two non-getter methods in scene are there to shuffle DataPoints to and from thewaiting queue. DataPoints in the waiting queue have not been seen for at least 5 reads, andare therefor assumed to not be currently invisible by the InputDevice.

O~~ Design Document

20

2.1.2.7. DataPointMarshal

Requirement Matrix:_resolving_a_href_g_data_point_data_point_a_collision,_finding_next_value,_value_update_distance_tolerance,_loss_of_a_href_g_data_point_data_point_a,_lost_point_prediction,_lost_a_href_g_data_point_data_point_a_removal, _waiting_queue,_a_href_g_data_point_data_point_a_priorities

The DataPointMarshal is another singleton, similar to the SubscriberMarshal. Thereforeit has static _instance and GetInstance properties to satisfy this design pattern.

2.1.2.7.1. Scene(inputDevice)

The one instance of DataPointMarshal will have a list of all current Scene objectsheld in DataPointMarshal::_scenes. To obtain a specific Scene, one has to access itthough the DataPointMarshal::Scene function. This function takes an InputDeviceas a parameter and returns the Scene which belongs to that InputDevice.

2.1.2.7.2. onInputEvent(frame)

The most important method on DataPointMarshal however, is theDataPointMarshal::onInputEvent method. This method is arguably themost important method in the entire library. It takes an InputEvent from anInputDevice, and then decides which Scene that InputEvent cooresponds toousing the InputEvent::_inputDevice. It then procedes to assign the next valueto the DataPoints within that Scene. It does so by comparing the position of theDataPoint's next predicted value obtained via the DataPoint::GetPredictedPoint,to the actual values it has in the InputEvent::InputFrame.

It also decides which DataPoints get moved to the waiting queue (DataPoints whowere not assigned InputPoints after 5 reads), and which waiting queue DataPointsto revive. (see DataPoint flow)

O~~ Design Document

21

2.1.2.8. Timer

Requirement Matrix: _threading,_data_export_rate,_guaranteed_updates,_fastest_update

The Timer class is the only class in core that relies upon the QT library. The QT library'sQTimer class is used in the Timer. QTimer provides an update every X seconds where Xis configurable at each request. Timer will configure QTimer to call the Timer::Updatefunction every 10 milliseconds. This 10 milliseconds, or 1/100th of a second, is whereour upper bound on updates per second (100) comes from. When update is called,Timer::_time is incremented to reflect it.

Timer is a singleton, which means that only one instance will ever exist. This is satisfied bythe private constructor, the Timer::GetInstance and the Timer::_instance properties.

O~~ Design Document

22

2.1.2.8.1. SchedueledCallback

Timer serves another important task other than simply keeping time. It is responsiblefor tracking and service requested callbacks. A callback is when an instance of a classrequests a method of it's to be called at some time in the future. It does this throughthe use of its own private aggregate class, Timer::SchedueledCallback. This classhouses all information pertinent to a specific callback request. That includes theinstance of the object to be called (Timer::SchedueledCallback::Instance), thefunction to call on that instance (Timer::SchedueledCallback::Function), whento call that function (Timer::SchedueledCallback::Time), and what parameterto pass to the function when called (Timer::SchedueledCallback::Parameter).It also contains a method that can be used to call the function with the parameter,Timer::SchedueledCallback::Call.

2.1.2.8.2. ScheduelCall()

To track all of the current callbacks requested, Timer has a private member calledTimer::_callbacks. To request a callback for a specific function, you need onlycall Timer::ScheduelCall with your instance, function, delay, and parameter. It isimportant to note that your function MUST take a void* as its only parameter. This isdue to the fact that C++ does not have dynamic function pointer allocation. Therefore,you must write a wrapper function to satisfy your callback.

2.1.2.8.3. Update()

The Timer::Update method is a slot which is activated whenever Timer::_qtimerreaches an update event. This method increments Timer::_time and then checks tosee if any of the SchedueledCallbacks in Timer::_callbacks have lapsed. If so, itproceeds to call them using the SchedueledCallback::Call method.

2.1.2.8.4. Stop

The Timer::Stop function stops the timer as well as all of QT. It is meant to be calledat the end of a user's application, to clean up loose ends.

O~~ Design Document

23

2.1.2.9. Point

Requirement Matrix: _raw_data_storage

The Point class is just a representation of a 3D point. It is capable of representing a2D or 3D point. The w property is for 3 dimensional homogenization. 2 dimensionalhomogenization uses the z property.

Point::Homogenize simply returns the homogenized representation of the point.

O~~ Design Document

24

2.1.2.10. Color

Requirement Matrix: _web_cam_data

The Color class is a simple way of maintaining red, green, and blue values, specifically todesignate a color. It will be capable of accepting these values individually, together, or as ahexadecimal string as is commonly used in HTML. Subsequently, it will allow for output inthe same forms.

2.1.2.11. ConfigurationReader

Requirement Matrix: _data_export_rate

O~~ Design Document

25

Requirement Matrix: _data_reading_rate,_wii_remote_data,_web_cam_data

The ConfigurationReader is a single instantiated class in Core. It's job is to read andinterpret a run-time configuration file, which will be of a bash-like format. For now, it mustsupport reading the Blob color which the WebCameraDevice must utilize to see blobs. Itwill also need to support the polling rate for any type of device. This is the rate at which thehardware device is read at, not the rate at which the Interfaces will output data.

2.1.2.12. Putting it all together

Above you can see all of core, with the exception of the input classes outlined in the inputlayer section.

The only two classes that we did not explain above are the InputDeviceType andRegressorType classes. These are actually not classes, they are public enumerations to beused at type descriptors.

2.1.3. Data Flow

In this section, we will examine the flow of data into and around core. We will follow data andsee exactly how DataPoints are created, updated and passed on to the Interface level.

O~~ Design Document

26

2.1.3.1. Input Flow

The first important part about receiving data is establishing your Input Devices. Developerswill first create an Interface. Interfaces will come with a default device associated with it,and will also allow the developer to override this feature and specify a non-standard device.

Regardless of how the device in question is determined, it will establish a Subscriberwhich is in charge of delivering the data to the Interface. At this point, the subscriber is

O~~ Design Document

27

aware of the device type, and so passes this information along to the InputDeviceFactory,which allows any sub-class of InputDevice to be created based on this type.

With the correct device instantiated, it is passed along to the controller which will maintainthe devices' existance throughout the duration of the Subscriber.

2.1.3.2. Data Point Flow

Now that the input data has been aggregated into a set of InputPoint objects, and placedwithin an InputFrame, it is time to create an InputEvent. The InputDevice now creates anew instance of an InputEvent. The InputEvent is created with the data gotten from theInputDevice's implementor. This InputEvent is then fired over to the DataPointMarshal viaDataPointMarshal::onInputEvent. This starts the process outlined in the below flowchart.

Once the InputEvent is inside of DataPointMarshal, it is processed. The first step inthis process is to find the Scene object that is linked to the InputDevice reflected byInputEvent::InputDevice. If no such scene exists, one is created. Once we have this Scene,whether just created or already existing, we move on to the next step.

O~~ Design Document

28

We can now begin the process of assigning values to the DataPoints in the Scene. Weiterate over each InputPoint in InputEvent attempting to find a suitable DataPoint.The only DataPoints that are considered at this stage are the DataPoints inside ofScene::_activeDataPoints. To decide which DataPoint goes with which InputPoint, all of theInputPoints are compared to all of the DataPoints. This is an O(nk) time operation, howeverthe size will rarely exceed 5 for either n or k, so this is acceptable.

When being compared, the value of InputPoint::_point is compared toDataPoint::GetPredictedPoint. This way we are leveraging our dead reckoning capability formore accurate iterations.

Once we have the distance between each DataPoint and each InputPoint, we startassigning them together. The closest DataPoint and InputPoint are assigned viaDataPoint::PushInputPoint.

The DataPointMarshal will continue with this process until it reaches one of the threepossible outcomes. Hopefully, there are exactly as many InputPoints as there are DataPoints,and everything works out. If that is not the case, there is either too many InputPoints, or toomany DataPoints.

If there are too many InputPoints, we can bring a waiting DataPoint out of the waiting queueto be take on that InputPoint. If there are no DataPoints in the waiting queue, the extraInputPoint is discarded and the process has ended.

If there are too many DataPoints, we must evaluate the state of our existing DataPoints. Welook at the DataPoints we have left that have not been paired. If any of them have not beenpaired for the last 5 updates, they have probably been lost. If this is the case, they are movedto the waiting queue.

Once there are no more InputPoints remaining to be assigned, and all straggeling DataPointshave been put in the waiting queue, we are finished.

2.2. Interfaces

2.2.1. 3D Interface

The 3D interface takes the positions of two dots in 2D space and extrapolates information aboutdepth from them based upon the distance between them. Assuming that the dots are mounted infixed positions on the user, you can accurately determine the user's distance from the wii remote.When the two dots get further apart, the user is closer to the wii remote.

O~~ Design Document

29

The 3d Interface consists of one class that handles everything from extrapolating 3D positions, tosending the data to

2.2.1.1. 3DInterface Class

Requirement Matrix:_3d_interface,_initialize_function,_process_update,_set_error_bounds,_hardware_device

O~~ Design Document

30

The 3D interface class is the only class needed for this interface. It handles the computationof the 3D locational data and the data output functionality that sends information to the hostprogram.

2.2.1.1.1. Compute3DPosition

Requirement Matrix: _compute_3d_position

This function takes in two dots and a distance variable. The dots are DataPointsand contain information about the 2D location and size of the dot. The double usedfor distance is the key that will allow this function to extrapolate the depth datafrom the dots. When the space between the dots changes, distance can be properlyestimated. This is called the parallax effect. Parallax calculations are a specific type oftriangulation

Once you have the distance information of the two points, it is possible to calculate thedistance since the points and the reader form an isosceles triangle.

O~~ Design Document

31

2.2.1.1.2. Update3DPosition

Requirement Matrix: _update_3d_position

This function sends out the current 3D position calculated by the Compute3DPositionfunction. It outputs a standard Vector3 with x,y, and z positions.

2.2.2. Spatial Interface

Requirement Matrix: _spatial_tracking_interface

The Spatial Interface contains logic for the determination and processing of data points retrievedfrom the Core of Clementine into recognized gestures.

The Spatial Interface is divided up into several classes.

2.2.2.1. Vector

O~~ Design Document

32

The Vector class is a parallel to the vector used in mathematics. It consists of a magnitudeand a direction. Its main purpose is to be a simple subclass for the Gesture class.

2.2.2.2. Gesture

Requirement Matrix: _gesture_library

The Gesture class is how gestures are defined to the Clementine library. A gesture consistsof a series of vectors. In this case, the direction of the vector is a relative angle to theprevious vector, and the magnitude is the speed with which that part of the gesture must beperformed, as a percentage of the total length of time of the gesture.

2.2.2.2.1. endLocation


The endLocation() method of the Gesture class returns the relative position of thegesture from its start position, through every stage of the invocation.

2.2.2.3. GestureResult


O~~ Design Document

33

GestureResult is a class that is designed for containing information about a gesturethat the interface believes has been performed. gesture is a pointer to the specificgesture. certainty is a floating-point value from 0 to 1 regarding the confidence of theinterface in discerning the gesture. position is a Vector3 class corresponding to the 3-dimensional location of the center of the gesture in space. rotation is a Quaternion classcorresponding to the rotation of the gesture in reference to the original gesture definition.percentComplete contains a floating-point value from 0 to 1 regarding how much of thegesture the interface thinks has been completed. potentialOtherGestures is an array ofGesture objects that the interface thinks might have been performed, other than the one withthe most certainty (the gesture that gesture points to).

2.2.2.4. GestureFactory


O~~ Design Document

34

GestureFactory is a class that can be used to import predefined gestures into theinstantiated interface. The spatial interface will come with several common predefinedgestures that developers may import and work with immediately, rather than writing theirown. Some examples of baked-in gestures would include:

• One Finger Drag Left (GestureFactory::CreateOneFingerDragLeftGesture())

• One Finger Drag Right (GestureFactory::CreateOneFingerDragRightGesture())

• One Finger Drag Up (GestureFactory::CreateOneFingerDragUpGesture())

• One Finger Drag Down (GestureFactory::CreateOneFingerDragDownGesture())

• Index finger-and-thumb rotation clockwise(GestureFactory::CreateIndexThumbRotateClockwiseGesture())

• Index finger-and-thumb rotation counter-clockwise(GestureFactory::CreateIndexThumbRotateCClockwiseGesture())

2.2.2.5. GestureInterface

Requirement Matrix: _spatial_tracking_interface

The GestureInterface class is the core class of the spatial interface. It contains themethods used to retrieve sets of data points from core, process them against the definedgestures, import gestures at run-time from the developer's application, and send its results toany part of the application that requests them.

O~~ Design Document

35

2.2.2.5.1. GestureRepository

Requirement Matrix:_spatial_tracking_interface,_gesture_library,_processing_of_data

gestureRepository is the name of the runtime database where gestures thatprogrammers have defined are stored. When the spatial interface begins interpretingdata and discerning whether or not a gesture is being performed, it will search thegestureRepository for the matching gesture.

2.2.2.5.2. ProcessUpdate


When the core begins sending data points to the interfaces, ProcessUpdate retrievesthem and identifies data points that it considers to be prior data points showing upagain. These identifications are them so that they may be processed in chronologicalorder, as quickly as possible.

2.2.2.5.3. FindGestures


FindGestures is the method called after ProcessUpdates has established a contextualhistory for the data points the interface is examining. FindGestures runs an algorithmdesigned to look for similar matches between the historical data passed to the interfaceand the gestures that have been defined in GestureRepository. FindGesturesuses its internal history of the past sets of DataPoint objects to gauge distance,identification, and velocity of each of the points in its current Scene. If a perceivedgesture gets more and more promising (identified with increasing certainty each time)and passes a threshold of certainty, it is added to the internal GestureResult class.The first considered gesture to pass a higher threshold is identified as the most certaingesture and is sent, along with the rest of the internal GestureResult, the next time adeveloper's application asks for information from the spatial interface.

2.2.2.5.4. ImportGesture

Requirement Matrix:_spatial_tracking_interface,_gesture_library,_processing_of_data,_data_format

ImportGesture is called from the developer's application at any convenient point inthe initialization of their program in order to provide the spatial interface with the datathe gestures it needs to test against the input environment.

O~~ Design Document

36

2.2.2.5.5. SendGestureResults

Requirement Matrix:_spatial_tracking_interface,_gesture_library,_processing_of_data,_data_format

SendGestureResults is the final part of the sequence of data processing forthe spatial interface. It is an abstract class that the developer implements in theirSpatialInterface class, and defines the behavior that occurs when the spatialinterface is sending its GestureResult during an iteration.

2.3. Demos

Since the library itself is not capable of displaying its advantages in a tangible way, demonstrationswill be implemented for that purpose. Their purpose is to provide multiple examples showing the easeof use and the wide range of applications in which the library can be used.

The first demo will utilize our 3DInterface class and will be a tennis game in a simulated 3Denvironment. The demo will utilize third party graphics engines, with custom code developed tohandle in-game objects. The user will be able to play the game using the Emitter Glasses and two Wiiremotes.

The second demo will utilize a third party gesture library that will interface with a webcam and apair of gesture gloves. The actual demo will contain custom code for manipulating the developmentenvironment of an open source 3-D modeling application called Blender. The user will be able toperform actions and mouse movements within the environment using only the gesture gloves.

2.3.1. 3D Demo (Tennis)

Requirement Matrix:_3d_demo,_application,_tennis,_other_external_libraries,_a_href_g_avatar_avatar_a_control

The 3-D Demo will be played using two Wii remotes, one set up above the TV for IR tracking,with the user wearing the IR Emitter Glasses as well as holding a second Wii Remote. The IREmitter Glasses will be used with the first Wii remote in order to capture the user's 3-D position.This will be implemented via our 3DInterface class built-in to our API. The second Wii remotewill be held by the player and will be used to detect a swing of the racket using accelerometerdata gathered from it using the wiiuse library.

The demo will use a third party graphics engine, called Ogre, to display the objects graphically onthe screen. Objects will be represented in the following manner.

O~~ Design Document

37

2.3.1.1. Game

This will be the main program and will contain a SceneGraph object, which represents thegame stage, as well as an instance of the Ogre graphics engine.

2.3.1.2. SceneGraph

This is a graph of the scene which holds all the objects that are displayed during thecurrently running game, with the exception of the player and the camera. The push andremoveObject functions handle adding and removing objects from the scene. processTick isresponsible for calling the tick functions in each of the scene's objects.

O~~ Design Document

38

2.3.1.3. SceneObject

This is the most abstract class for an object on the stage. It has a 3-D position, rotation,and scale. It will also have a processTick() function will be called every 32 millisecondsby the game program if the instance's "tickable" attribute is set to true. It will also have aBoundingBox instance which will be used for collision detection.

2.3.1.4. BoundingBox

This class is used for collision detection and each SceneObject has an instance of it. Itcontains the 3-D center point for the bounding box of the object, as well as the box's length,width, and height. It can check if it's colliding with other BoundingBoxes through theisCollidingWith function.

O~~ Design Document

39

2.3.1.5. RenderableObject

This is an extension of a SceneObject, which represents any object that can be rendered in 3-D using the Ogre graphics engine.

2.3.1.6. StaticObject

This is an extension of a RenderableObject which will be used to represent objects that dono change and have no animation during game play.

2.3.1.7. DynamicObject

This is an extension of a RenderableObject which will be used to represent objects thatchange, have animations, or can be destroyed during game play.

O~~ Design Document

40

2.3.1.8. BallLauncher

This is an extension of a DynamicObject and represents the ball launcher used in the game.It can be customized through it's launchSpeed and launchDifficulty.

2.3.1.9. Ball

This is an extension of a DynamicObject and represents a ball that has be launched by theBallLauncher. It contains a velocity as well as a bounceCount to ensure the ball is hit in atimely manner.

O~~ Design Document

41

2.3.1.10. Player

This is an extension of a DynamicObject as well as our 3DInterface class in the API. It willcontain an instance of a Wiimote, which will be used for the swing (acceleration) aspect ofthe player to call the swing() function. It will also implement the Update3DPosition functionas defined in the 3DInterface class.

2.3.2. Spatial Demo (Blender)

Requirement Matrix: _spatial_tracking_interface,_spatial_demo,_blender

The spatial demonstration will incorporate the use of a webcam and gesture gloves within theBlender 3-D modeling environment. The goal of this demonstration is to remove the need forthe user to utilize a keyboard or mouse. All basic functionality will be implemented using handgestures that translate into keyboard and mouse events.

Since there is no hook into Blender that easily provides control to the mouse and keyboard eventswithin the environment, the mouse and keyboard will simulated at a higher level. The X11 server,which is responsible for all input events to the window system, will be used to simulate suchevents. Therefore, the user will not be controlling the blender environment but rather the entireX11 Linux environment but with code that is streamlined for use within Blender.

The Spatial Demo will consist of two components that will be responsible for receiving inputfrom the Spatial Interface and relaying the necessary events to Blender.

O~~ Design Document

42

2.3.2.1. Gesture Interpreter

Requirement Matrix: _gesture_library,_data_format

The GestureInterpreter class is responsible for processing data from the spatial interface. Itreceives an event from the spatial interface at regular intervals. These events are sent to theprocessEvent function and may or may not include a gesture. It is set up to receive messagesat a specific poll rate to ensure the mouse position can be accurately represented at all times.

If the message does not contain a Gesture object, then the mouse position is simply updatedto reflect changes in the x and y parameters compared to the internal record of the current xand y position. If a gesture object exists, then the mouse location will not be updated unlessthe gesture requires it.

2.3.2.2. ClemX11

Requirement Matrix:_blender,_gestures,_vertex_selection,_vertex_merging,_face_creation,_3d_transformations,_3d_manipulation,_menu_navigation

O~~ Design Document

43

The ClemX11 component is an inline C++ header file that includes support for the X11library in the Linux Environment. It is abstracted out of the GestureInterpreter componentbecause it is platform dependent and the goal is to keep the GestureInterpreter as platformindependent as possible.

It contains a list of functions that facilitate easy creation of events. These include mouseevents that control the position of the mouse via the moveMouse function which can movethe mouse pointer to an absolute position or a relative position based on the boolean valuepassed. The other mouse event function (mouseClick) creates click events for the appropriatemouse butotn based on the integer argument.

There are three functions that control the keyboard events. They include the standard keydown (holdKey), key up (releaseKey) and seperate function to handle the combination ofboth these events referred to as a key press (pressKey). Each function takes an integer as anargument. A list of key mappings can be found in the keysymdef.h header file.

2.4. Diagnostic UtilityThe diagnostic utility is an external application like the demos that will operate using the Clementinelibraries. The main purpose of this application will be to show the developer what data is coming out ofClementine.

When working with precompiled libraries, developers are forced to figure out what data will come outof the library. Documentation helps, but all to often, the developer must create an application of theirown to output the data in some way in order to visualize it. This process is time consuming, and provesto be a daunting turnoff when writing applications.

The diagnostic utility alleviates this issue as well as providing a useful debugging tool. The utility willprovide custom perspectives for each interface. This will allow the developer to see custom chartsrepresenting the data Clementine is providing.

This application will be written using the QT framework. QT is very robust and expansive on Linuxsystems. It will allow this application to be compatable with any Linux window manager, as well as

O~~ Design Document

44

allow the leverageing of many of QT's more ubiquitous features, such as the Timer, and the SIGNAL/SLOT macro.

This tool will greatly ease the burden on developers when first learning Clementine, as well as providean invaluable tool when debugging input related issues in their applications.

2.4.1. Classes

In this section we will examine the design of the class structure intended to create the abovementioned functionality

2.4.1.1. Chart and Support Classes

Requirement Matrix: _real_time_graphs, _raw_data, _smoothed_data, _data_accuracy,_real_time_representations

O~~ Design Document

45

The Diagnostic Utility requires a robust and extendible graph rendering tool. Unfortunately,no such QT library exists. Because of this, the Diagnostic Utility will contain its own customgraphing tool using the QT drawing and painting algorithms to render images to a QTwindow.

2.4.1.1.1. Axis

Axis defines a dimension on a Chart. Axis::_minimum and Axis::_maximum denotethe bounds of the Axis. Axis::_step denotes the amount between rendered values onscreen. Axis::_label is the name for this Axis.

It is important to note that Axis is not responsible for rendering itself, it is merelymeant to hold data pertinent to itself as an object.

2.4.1.1.2. DataSet and DataPoint

DataSet is a container for any plotted set of data to be represented on a Chart. EachDataSet must have a unique name stored in DataSet::_name. The color it is to beplotted in will be held in the DataSet::_color variable.

DataSet aggregates the class DataPoint. The DataPoint class is responsible forholding the value of one point of data in a set.

2.4.1.1.3. Chart

Chart is the base class for all graphs and data plots to be used in the Diagnostic Utility.It is responsible for rendering itself, and therefore extends QWidget from the QTlibrary. A Chart has a color, which is its background color, stored in Chart::_color.A Chart also has a reference to each of its axes, stored in Chart::_xAxis andChart::_yAxis.

A Chart is allowed to have multiple sets of data. This will allow for a graph containmultiple lines, each a different color. This setup allows for like data to be plottedtogether for maximum ease of comparison.

2.4.1.1.3.1. PushPoint(x,y,dataSet)

The Chart::PushPoint method is used to add data to the chart once it has alreadybeen created. This can be useful when a chart receives data in real time, or ifyou don't know all of the data that will be on the chart when the chart is created.The mandatory DataSet parameter is a reference to the DataSet that the pointwill be added to. You can obtain a DataSet reference from the Chart via theChart::GetDataSetByName method.

This method is allowed to be overloaded by child classes in order to enforce certainrules regarding their data.

O~~ Design Document

46

2.4.1.1.3.2. paintEvent(event)

The Chart::paintEvent method along with the helper Chart::PaintAxis andChart::PaintPoints methods are responsible for drawing the chart to the pane thatit exists on. It is an overloaded member function inherited from QWidget.

2.4.1.1.3.3. Clear()

The Chart::Clear() function simply clears all of the current data from the Chart'sDataSets.

2.4.1.1.4. ScrollingTimeChart

The ScrollingTimeChart inherits from Chart. This class represents a Chart whoseX axis is time currently, going from ScrollingTimeChart::+maxTimeBack to thepresent time. This chart will scroll in real time and is meant to display real time data.

QTimer is a class from the QT Library that will call a slot every X seconds.ScrollingTimeChart will use ScrollingTimeChart::_updateRate to determine therate at which it will be called.

2.4.1.1.4.1. UpdateChart()

The ScrollingTimeChart::UpdateChart method is the slot that will be called bythe QTimer instance, ScrollingTimeChart::_timer.

This method will be responsible for subtracting _updateRate milliseconds from eachDataPoint's X value on that graph. It is then responsible for requesting this instanceto be redrawn by QT, so the update can be displayed.


This method is overridden in this level of the hierarchy. This is donebecause specifying an x position for a DataPoint does not make sense for aScrollingTimeChart. Any data coming into the chart must be the current value ofthat DataSet. Therefor, the value passed in as the parameter x is ignored in favour ofthe value 0. The parent method is then called with the parameters (0,y,dataSet).

2.4.1.1.5. GestureChart

A GestureChart is a chart that displays a constant line of different colored data on itstop, along with the DataSets that a chart normally displays. (see the spatial interfacemockup)

To accomplish this, the GestureChart needs to know the history of gestures thathave been considered. This value is stored in GestureChart::_gestures. Each entrycorresponds to a gesture reading. The highest index entry is the most recent.

O~~ Design Document

47

2.4.1.1.5.1. PushGestureResult(gesture)

To support this added functionality, the GestureChart needs to know more than asimple (x,y) position to add to one of its DataSets. This is accomplished through thePushGestureResult method. This method takes in the currently considered gestureand appends it to GestureChart::_gestures.

2.4.1.1.5.2. paintEvent(event)

Since GestureChart is adding functionality to the Chart class, it will need tooverride the Chart::paintEvent method in order to paint its specific addedfunctionality. Once the GestureChart has painted its extra data, it will call its parentand allow it to paint itself.

2.4.1.1.6. LocationChart

Another specifice type of chart needed is the LocationChart. This chart will plotonly two points, a sensor position and a relative location. Certain LocationChartsmay want to have a trail behind the relative location to show its movement. This isconfigurable though LocationChart::_trailLength. The alpha value of a point willbe determined by its index in DataSet::_points. The earlier the index, the higher thealpha value. As new points are added using the LocationChart::PushPoint method,points in DataSet::_points will be pushed to lower indices.


This method is again overloaded here because it does not make sense in the contextof LocationChart to specify a DataSet, since all data coming in will be the nextlocation of the one location tracked. Also, this method will be responsible for theindex shifting discussed in the previous section.

2.4.1.2. Perspective classes

Requirement Matrix: _analysis_data

O~~ Design Document

48

The Chart class is basically useless unless it has data to display. Even a Chart displayingdata is pretty useless unless multiple instances are organized in such a way that similar datais placed close together, making comparison easy for the user.

Since our two interfaces are fundamentally different in many respects, the Diagnostic Utilitywill provide multiple perspectives. Each perspective will be taylored specifically to theinterface whose data it displays.

2.4.1.2.1. Perspective

The Perspective class inherits from QGridLayout. QGridLayout is simplya collection of QWidget in some orientation. This inheritance allows for thePerspective to hold the QWidget that it has within itself, as well as be in control oforienting them.

Each Perspective instance has a name that is stored in Perspective::_name. Thisvalue will be displayed at the top of the window.

2.4.1.2.1.1. Initialize()

The only method held within the Perspective base class is thePerspective::Initialize function. This function is polymorphic, and meant to be

O~~ Design Document

49

overridden. However, like all initializers, it is required that the implementer send acall up the hierarchy before initializing itself, so that each level in the hierarchy cando something specific.

The Perspective::Initialize method will be charged with creating sub-layoutsfor its extending classes to populate.

2.4.1.2.2. 3DInterfacePerspective

This class will extend the Perspective class and add to it functionality to displayQWidgets specificly designed to aid in the viewing of data coming from the 3DInterface.

As you can see in the mockups section, the 3D interface will have fourScrollingTimeCharts, one for each dimension of each dot, and twoLocationCharts, one for a top down view and one for a back forward view.

2.4.1.2.2.1. Initialize(inputController)

The 3DInterfacePerspective::Initialize method will create and place all ofthe charts necessary to create the perspective after calling its parent's instance of thismethod (Perspective::Initialize).

This method will then cast the parameter passed in to a3DInterfaceInputController and proceed to connect the signals to theirrespective slots

2.4.1.2.2.2. UpdateLeftEyeCharts(dataPoint)

This method is a slot designed to be connected to the3DInterfaceInputController::UpdateLeftEye signal.

It will update the leftXChart and leftYChart with the x and y positions of theparameter passed in.

2.4.1.2.2.3. UpdateRightEyeCharts(dataPoint)

This method is a slot designed to be connected to the3DInterfaceInputController::UpdateRightEye signal.

It will update the rightXChart and rightYChart with the x and y positions of theparameter passed in.

2.4.1.2.2.4. UpdatePositionalCharts(dataPoint)

This method is a slot designed to be connected to the3DInterfaceInputController::UpdatePosition signal.

O~~ Design Document

50

It will update the topDownChart and backForwardChart with the xz and xypositions of the parameter passed in.

2.4.1.2.3. SpatialInterfacePerspective

This class will extend the Perspective class and add to it functionality to displayQWidgets specificly designed to aid in the viewing of data coming from the SpatialInterface.

As you can see in the mockups section, the spatial interface will have oneGestureChart representing current and past gestures, a series of labels giving dataabout the current gesture, and two LocationCharts, one for a top down view and onefor a back forward view.

2.4.1.2.3.1. Initialize(inputController)

The SpatialInterfacePerspective::Initialize method will create and placeall of the charts and labels necessary to create the perspective after calling its parent'sinstance of this method (Perspective::Initialize).

This method will then cast the parameter passed in to aSpatialInterfaceInputController and procede to connect the signals to theirrespective slots

2.4.1.2.3.2. UpdateGestureData(gestureResult)

This method is a slot designed to be connected to theSpatialInterfaceInputController::UpdateGesture signal.

It will update the gestureChart with the parameter passed in as well as thetopDownChart and backForwardChart with the xz and xy positions of the parameterpassed in.

2.4.1.3. Input Controllers

O~~ Design Document

51

The input controllers are responsible for receiving data from Clementine and routing it to theappropriate signals in the Diagnostic Utility so the different components of the perspectivescan be updated in real time.

There is one input controller for each interface supported by this Diagnostic Utility. Theinput controller is tailored to provide specific data about that interface's state to the variouscomponents in a perspective whenever it is updated.

Each input controller has multiple inheritance. It does this because each input controllermust support the signal/slot macro, but they must each also be extensions of the Clementineinterface they are reading the data of.

It is important to note that these classes are capable of throwing an error if they are createdand no appropriate input device is found by clementine. This error is intended to be capturedand handled by MainLayout::PerspectiveChangeError.

2.4.1.3.1. 3DInterfaceInputController

The 3DInterfaceInputController extends the 3DInterface class from Clementine.This class is responsible for receiving and aggregating the data passed in from the3DInterface, and then sending that data out using its signals

2.4.1.3.1.1. Update3DPosition(position)

The Update3DPosition method is an implementation of the3DInterface::Update3DPosition virtual method. This method is called when the3DInterface is ready to provide a new set of data.

When called, this method will get both the left and right eyeDataPoints from Subscriber::_mostRecentScene and use them toemit the 3DInterfaceInputController::UpdateLeftEye and3DInterfaceInputController::UpdateRightEye signals. It will then emit the3DInterfaceInputController::UpdatePosition signal using the parameterpassed in.

2.4.1.3.2. SpatialInterfaceInputController

The SpatialInterfaceInputController extends the SpatialInterface class fromClementine. This class is responsible for receiving and aggregating the data passed infrom the SpatialInterface, and then sending that data out using its signals

2.4.1.3.2.1. UpdateGestureResults

The UpdateGestureResults method is an implementation of theSpatialInterface::UpdateGestureResults abstract method. This method iscalled when the SpatialInterface is ready to provide a new set of data.

O~~ Design Document

52

When called, this method will emit theSpatialInterfaceInputController::UpdateGesture signal using the parameterpassed in.

2.4.1.4. Main class

The main class is responsible for starting the application and initializing QT. It also containsan aggregate class called MainLayout.

2.4.1.4.1. MainLayout

The MainLayout class is responsible for first setting up the set of menus to be used bythe application, and linking all of those menu options to the appropriate actions. This isall done within the MainLayout::MainLayout constructor.

2.4.1.4.1.1. SwitchToSpatialPerspective() and SwitchTo3DPerspective

These methods are responsible for switching the perspective between the3DInterfacePerspective and the SpatialInterfacePerspective. They are each slots thatwill be hooked into menu options.

2.4.1.4.1.2. PerspectiveChangeError(error)

This method is called if either of the SwitchPerspective methods fail due to someerror in Clementine. It will cancel the perspective change and raise an alert boxrepeating the parameter passed in.

O~~ Design Document

53

2.4.1.5. Input and Display Flow

Understandably, the flow of data through the DiagnosticUtility may be a bit confusing,especially if you are new to the concept of signals and slots and the use of the QT Library.

The above swim lane diagram shows the path data will take when being entered into theDiagnostic Utility from Clementine.

Both Clementine and the Diagnostic Utility rely on QT's QTimer class to trigger timedevents. Though two instances will be used in this application (one inside of Clementine forthe Timer class and one in the Diagnostic Utility in the ScrollingTimeChart classes) thisdiagram only shows one instance of QT.

First the QT library timer comes to an event telling the Clementine Timer to check tosee if any functions need to be called. This time, Timer sees that it does indeed need

O~~ Design Document

54

to call SubscriberMarshal::UpdateSubscriber(1). 1 is the ID of a 3DInterfacesubscriber. So SubscriberMarshal calls 3DInterface::UpdateSubscribe`r withthe current scene. The `3DInterface then performs its calculation and calls3DInterfaceInputController::Update3DPosition with the new computed position.This action hands control off to the Diagnostic Utility.

Once in the Diagnostic Utility, the 3DInterfaceInputController emits its updatefunctions, which are tied to the 3DInterfacePerspective's update functions. The3DInterfacePerspective then updates its charts with the new data. Once this is done,control is released back to Clementine and QT.

Sometime later, QT's QTimer fires an update event to one of the ScrollingTimeChartsin the 3DInterfacePerspective instance updated above via theScrollingTimeChart::UpdateChart method. From here, it requests a newQWidget::paintEvent to be called on itself. Control then returns to QT until QT callsChart::paintEvent and the chart repaints itself.

2.4.2. Mockups

In this section we will examine the general expected layout of what each perspective of theDiagnostic Utility will look like, as well as explain why that is the best setup.

O~~ Design Document

55

2.4.2.1. 3D Interface Perspective

This perspective is intended to show the user exactly what is going on behind the 3DInterface. It has two columns, one for each dot on the person's glasses.

Each column then contains two ScrollingTimeCharts, one for the x dimension and onefor the y dimension. This is done because the x and y dimensions are independent random

O~~ Design Document

56

variables, and therefore should both be plotted separately against time. The independentvariable on these graphs will be time back, with 0 (now) at the right up to 2 seconds back atthe origin.

These graphs will then scroll to the left, as new data comes in and old data becomes older astime progresses.

Not shown in the mockup, but planned for implementation, is multiple data sets for eachgraph. Each graph will show not only the smoothed data coming out of Clementine for thatdot's that dimension, but also the unsmoothed data. This way, the user will be able to seewhat Clementine is doing for them, as well as be alerted to missed data reads.

Below the two columns of graphs representing dot position, there will be twoLocationCharts intended to show the approximate position of the user relative to theposition of the sensor. The left chart displays a top down view of the virtual room, using Xand Z coordinates. The right chart displays a back forward view of the virtual room, using Xand Y coordinates.

O~~ Design Document

57

2.4.2.2. Spatial Interface Perspective

This perspective is intended to show the user everything about the current gesture beingconsidered, as well as some data about previous gestures.

The first component of this perspective is a GestureChart. This chart has a timeline at thetop showing all of the gestures that are and have been considered up to six seconds back.

O~~ Design Document

58

Below that, a the scrolling line portion of the chart shows the relative confidence in thatgesture at that time.

The component below the GestureChart is a set of test outputs designed to show theuser everything about the current gesture. This output shows the gesture name, thepercent confidence in that gesture, the rotation of the gesture from the horizontal, and itsapproximate 3D position in the room. This output area also shows an animated gif file ofwhat the gesture may look like in real life.

Below that, is the final component. Similar to the 3D Interface Perspective, it will show theapproximate 3D position of the gesture in the room relative to the sensor denoted by the reddot. This view will have a fade tail behind the dot to show movement.

O~~ Design Document

59

3. Future DevelopmentThe library has a wide range of uses in many different areas but we are not able to fully explore allpotential implementations due to time restrictions. However, this library is designed to be expanded upon.The following sections describe a few of the potential future uses of the library.

3.1. Interfaces

An interface provide context for input coming from a device and communicates that data to the usersapplication. The creation of interfaces is only limited by the number of devices that can be integrated.Any device that can provide positional data is a potential input device for the library. These caninclude the following:

• GPS - Accurate world positional data can be passed to the library for interpolation.

• Muli-touch Boards - Allow user to have multiple position locations.

• Novint Falcon Game Controller - Provides 3-Dimensional control. (http://home.novint.com/)

• Dual Mice - A user can use one mouse to control X-Y position and the other to control Z-axis.

• Generic PC Joysticks

3.2. Demos

This section describes some of the potential uses of the library. There is no plan to implement any ofthe projects listed below. They are just described here as an initial thought of what kind of applicationscould benefit from the library and how they could impact users. Some of the demonstrations listedbelow may or may not require the development of a new interface in order to interact with certaindevices.

3.2.1. Video Game Shooter

One genre of video games that could instantly benefit from this technology is the first / thirdperson shooter games. The library is capable of imersing the user in the environment throughmultiple interfaces. The players location within the room could be incorperated into the videogame to provide a "duck and cover" style of fighting or even change the viewing perspective ofthe player based on his body posistion and language. The players location can be tracked throughthe use of infared sensors located at desired points on body such as the head and gun.

3.2.2. 3-D Architectural Presentations

The library can offer an inexpensive gateway into a virtual environment to any user. Insteadof presenting a 2-D drawing of a building that can't be visualized or a 3-D model that can't be

http://home.novint.com/

O~~ Design Document

60

toured and manipulated, the library could provide a interactive tour of a 3-D building that canbe explored, experienced and even changed on the fly by the presenter. By using a set of gesturegloves and camera paired up with the right 3-D modeling application and a simple projector,this can give the audience a better experience than looking over the shoulder of someone at acomputer screen.

O~~ Design Document

61

4. Design Patterns

4.1. Singleton Pattern

A design pattern in which only one instance of a class is ever allowed to exist. Static members of theclass provide the one instance, and create it if necessary. The constructor is private.

class Foo{public: static GetInstance() { if(_instance==0) _instance = new Foo(); return _instance; }private: Foo() static Foo* _instance;};

4.2. Abstract Factory Pattern

A design pattern in which a class is responsible for creating and configuring other classes. The factoryis meant to supply implementers of an abstract class upon request.

//the abstract classclass Foo{ virtual void Func();};

//one implementationclass Bar : Foo{ void Func() { ... }};

//one implementationclass Baz : Foo{ void Func() { ... }};

//the abstract factory

O~~ Design Document

62

class FooFactory{ //create configure and return a Bar instance static Bar* GetBar() { ... }

//create configure and return a Baz instance static Baz* GetBaZ() { ... }};

O~~ Design Document

63

Glossary

2D ProjectionThe representation of a 3D environment projected onto a 2D plane.

Alpha valueA value used to determine the transparency of a color. Typically the 4th value added on to an RGBtripplet, denoted by RGBA. For example, 0xFF000088 is a semi transparent red.

Angle AxisAn alternate structure for storing rotational data. It is defined by a vector and a rotation about thatvector.

APIApplication programming interface, a class library meant to house similar functions and algorithmsfor use in 3rd party applications.

AvatarThe object in an application created by the developer that the user directly interacts with/controls.

BlenderBlender is an open source 3D modeling environment available under the GNU license.

BlobA group of similiarly colored pixels found in a frame of web camera input, defined by an area inpixels.

O~~ Design Document

64

BluetoothBluetooth is a short-distance wireless protocol for portable devices. It is used within the scope of ourproject, as in the Wii Remote, to provide wireless connectivity between devices and a computer.

Circular regressionFinding a circle that most closely represents the trends of a set of independent points of data.

Context-sensitiveAn action that is diffenrent depending on the current area of interaction. For example: a context menu,when requested on a file, shows "Delete", "Rename", "Edit", et cetera.

Data PointA data point is a point being tracked by the engine. Its values are what are reported to the subscriber.

Dead ReckoningA method for guessing the next value of a predictable pattern. Take the pattern or function thatrepresents your data, and plug in the next independent variable value to it.

DerivativeThe slope of a line. The rate of change in a function over time.

DeveloperThe target audience for our library. This is the person that will develop custom applications for usersto use.

Error BoundsThe amount of error tolerated for a certain type of input. When the input

ExtrapolationEstimating the next value of an input event based on previous data.

ExtrusionExtrusion is an operation performed on an object in three-dimensional modeling. A plane of an object,when extruded, expands out or in from its original location, while its edges are still attached to theconnecting edges of the object.

O~~ Design Document

65

First-in Last-out QueueA queue who can only provide the most recently entered piece of data. An example would be a stackof paper. You can only retrieve the piece of paper on top, and you can only place a piece of paper ontop.

Gimble lockAn event that occurs when using primitive forms of rotational representation. When rotating 2 ofthe 3 dimensions at the same time, the 3rd will become locked and any rotation on that axis will benullified.

Global Positioning System/ServiceA service that provides the position on the earth of a receiver. It uses a minimum of 3 satelites totriangulate surface position. The civilian service is accurate to within 3-5 meters.

Graphics LibraryA library containing algorithms and classes for displaying 3D environments on a screen.

HomogenizationHomogenization in the context of this project is simply dividing each dimension by the highestavaliable dimension. For example, to homogenize the following point (4,8,2), place 1/2 in thedimension higher, resulting in (4,8,2,0.5), then multiply through by the 4th dimension. Resulting in(2,4,1). This method is used frequently in computer graphics for translating 3D points to 2D points.

InfraredInfrared is a form of light invisible to human vision. It is commonly used to provide basicconnectivity, wirelessly, between devices, such as television remotes.

Input FrameAn input frame is a set of input points that represent all of the read points coming from the inputdevice at that time.

Input PointAn input point is an XY value for a point obtained from an input device.

InterfaceAn interface is a piece of software that allows a device to interact with the core library through aseries of function calls.

O~~ Design Document

66

LathingLathing is an operation performed on a two-dimensional plane. The final result of lathing is a three-dimensional shape whose edge entirely around is the same shape as the external edge of the two-dimensional plane.

Least SquaresA method of linear regression. The line is defined as follows

LibraryA library is a collection of classes that can be used by a programmer when writing an application. Alibrary usually performs a common or complex function that many applications can use.

Line of best fitThe line that best represents a grouping of coorelated or semi-random data. It is computed using linearregression.

Linear regressionFinding a line that most closely represents the trends of a set of independent points of data.

Multipoint objectMultipoint Object - an object that contains multiple data points, all statically positioned.

Parallax EffectThe parallax effect is a phenomenon that occurs when an object is viewed from two viewpointscausing the object to appear at its proper depth. In the scope of our project, when an object moves androtates appropriately opposite on screen to the viewers position in the room, an illusion of depth iscreated.

PerspectiveSome applications need a different internal windowing/dialog scheme depending on the operationthey are trying to perform. These different schemes are called perspectives. An example would be theEclipse debug and development perspectives. Each has dialogs open that best suit the current mode ofoperation of the application.

Precompilation DirectiveA preprocessor directive is code that is interpreted as a compiler compiles code. These segments tellthe compiler what sections of code to compile and how to compile them. Examples are #ifndef …#endif.

O~~ Design Document

67

Preprocessor VariableA variable that can be set in a compilation call, and can be used by percompilation directives.

QTQT is a robust cross platform application framework originally written for Linux in C++, developedby Trolltech. http://www.qtsoftware.com/title-en

QT LibraryAn application framework for linux containing many useful functions and classes. One such functiontaken advantage of by this library is the QTimer, which will repeatedly call a function every Xseconds.

QuaternionsQuaternions are the standard structure for storing rotational data. They are immune to gimble lock.

QWidgetThe base class for any object in an application using the QT Libraries that wishes to be rendered to alocation in a window.

Random VariableA statistics term that denotes an entity that can take on any value within a data set.

Reference frameA reference frame is a set of axes within which a position in space can be measured.

RegressionA statistical method for finding the mean of a data set.

Signal/Slot MacroA C++ macro used in QT applications in which you can link functions together without the use offunction pointers. A member must be defined as a SIGNAL or a SLOT before it can utilize the macro.You must compile your application using the qmake-qt4 builder utility.

SmoothingSmoothing in the scope of this project refers to the removal of outliers from a data set in order to yielda more consistent function, as well as bounding accurate data to within an error range to consider itacceptable data.

http://www.qtsoftware.com/title-en

O~~ Design Document

68

STIThe STI, or Spatial Tracking Interface, is a set of functionality that allows programmers to providemanipulation of their application through observable gestures that the user makes. See SpatialTracking Interface for more information.

SubscriberA subscriber is an agent that requests data point values from the library.

ThreadA thread is a process in a computer. A single processor can only process one thread at a time, thoughprocessed threads are switched rapidly in most modern computers. Having multiple threads allows fora long running process to run independent of a quicker one. Multi-core machines take advantage ofthreads by executing multiple threads at the same time.

UserThe target audience of our developer. This is the person that will use the custom application that thedeveloper creates.

VarianceThe variance of a random variable is the average of the squared distance of its values from thestatistical mean.

Wii RemoteA Wii Remote is an input device created by Nintendo for their Wii video game console. It hasseveral buttons for digital manipulation, as well as an accelerometer, for measuring relative velocity,Bluetooth for connectivity, and infrared sensors for measuring contextual position.

Yaw-Pitch-RollAn alternate structure for storing rotational data. It is definded by a rotation ammount in each of the 3axes, X, Y and Z, or Pitch, Yaw, and Roll, respectively. This form of representation is vulnurable togimble lock.

O~~ Design Document

69

5. Writing Center ChangesWe took the previous version of the design document to the writing center in an attempt to get some helpwith the grammar and wording of the document. We made many small changes to the document after thevisit. These changes included spelling changes and grammar fixes.

Some other issues the writing center helped us with was information seperation. We had multiple sectionswhere we had information that did not relate to its section header. The people at the writing center helpedus find such sections and formulate new sections with more related information.

Clementine Design Document - Drexel CCIyfcai/CS451/samples/... · followed in the design and...

Documents

Transcript of Clementine Design Document - Drexel CCIyfcai/CS451/samples/... · followed in the design and...