Project Plan

Yesterday we submitted our project plan. Included is a modified proposal, which now consists of the general abstraction of the human computer interaction barrier with the input of an accelerometer. Where the reasoning is that if a paradigm is developed to create interactive and intuitive applications we do not need to reinvent the capture methods for any of these types of applications. Examples including,

• motion driven applications, that is to accomplish a task we perform a common movement associated with the task



• ergonomics in developed applications, this is to allow the user to be more comfortable in accomplishing some task
  

Figure: System Block Diagram (tank reciever left, user transmitter right)

Click picture for higher resolution

The system block diagram was developed along with two finite state machines describing each of the actions, that is of the user transmitter and the tank reciever.


This version of the project plan can be downloaded here.

Communication protocol

In order for our transmission of instructions to be as effective, and so that our project may be subdivided into the user control side and the tank respond side a unified communication protocol must be established.

Earlier today we discussed various methods, but have settled on the following scheme:

• Instructions may be of various lengths, to terminate an instruction a semicolon must be present. After a semicolon in a sequential string is reached the next character is the start of the next instruction.
• All requests come from the user. This includes sending motor direction and speed to the tank, and requesting distance data. (The distance data is considered to be of a lower priority than updating the motors).

syntax

• Location: ``R'' for `right'. ``L'' for `left'. ``F'' for front. ``B'' for `back'.
• Component: ``M'' for `motor'. ``S'' for `sensor'.
• Request: ``?'' for `request'.
• Adjective: ``f'' for `forward'. ``r'' for `reverse'.
• Decimal value: integers are allowed to represent decimal values.

semantics

• Location must come first during instruction; unless it is a request, then both sensors are sent back.
• Component always follows the location.
• This may be followed by an adjective.
• And can be followed by a decimal value.
• Must end with semicolon;
  

Example

RMf255;

This reads as ``R''ight ``M''otor ``f''orward with pulse width at decimal 255.

Accelerometer calibration

In the case of this iPod Touch application, the screen is held at a comfortable viewing angle. It is seen however, that the ball runs backward and must be opposed with a force to keep the ball in a static position. Notice, that when the appropriate angle is applied to offset the ball to a static position the screen becomes unviewable with a glare from our current perspective. The iPod is placed on a desk to show the opposite affect.


Conclusion: Calibrate the accelerometer for the user during application start up. This allows the user to be in any type of position (laying down, sitting at a desk, standing, hanging from monkey bars, or anywhere else).

Draft Proposal

We received feedback on our draft proposal. The modifications necessary are to not focus on
autonomous control, allowing our focus to be directed on the human interface device; this feature may still be added later.

The need statement must be modified to demonstrate the benefit of operating with accelerometer based control.

• Show psychological evidence that accelerometer input devices are more intuitive
• Compare with current accelerometer based input devices (iPod Touch/ iPhone) type devices. This may include to have calibration on start up, so the user does not have to fight the input and rather feels where the tank would like to move to.
• Compare accelerometer based input to standard game pad/joystick input

Marketing requirements should describe what our final prototype will include, such as

• Size of tank and input controller
• Sensors
• Feedback to the user (Display distance to an obstacle, sound alerts, etc.)
• How user will provide input

Level-0 description needs to be modified to include the device layers of

• The tank
• User input transmitter/receiver
• Tank transmitter/receiver

And, to modify our behavior to read more as pseudo C code.

Read the original email from Dr. Coulston Here.

Welcome

This blog is to outline the development of our CMPEN 352w (embedded systems) final project. A Google Code site exists and can be accessed at http://code.google.com/p/cmpen352w/. Updates of the development code will be housed there, and updates on ideas and development will be housed here.