Sunday, April 26, 2009

Video of tank avoiding walls

Tank driving around in REDC 140!

The tank is currently responsive and driving around on the floor in our lab with wireless commands from the user. Test runs are recorded and will be up on YouTube soon. During these trials the responsiveness is being calibrated for the optimal turn and speed change, that is, remove any jerkiness during transitions.

Problems that occurred during fully operational tank control includes:
  • The H-bridges require at least 12 V to operate; our battery only supplied 9.6 V, so we replaced this power supply with a 21.6 V 1200 mAH cordless drill battery. This new battery was found at Big Lots for $20 with a free drill.
  • Noise from the motors disrupted the control signals. Filter capacitors were placed on all of the power rails to reduce this AC noise.
  • The pulse width modulated waveforms and direction signals from the MCU are passed through a restoring buffer. The waveforms are sent through two inverters, and the direction signals are inverted; this allows for a single hex inverter (74LS04) to accommodate all of these signals.
  • A TX wire from the user's MCU and the XBee was severed, disabling communication.

Friday, April 24, 2009

Updates on the project

We have been working, so much however, that this development blog has not been updated for days!

Milestone II was completed this past Tuesday and can be accessed here.
This includes
  • Wireless communication between the User and Tank
  • Operating motors based on accelerometer input
  • National Semiconductor LMD18200 3A, 55V H-Bridges, to drive the motors (the old stacked H-bridges finally died on us)
Look forward for many posts in the next day including YouTube videos of what has been happening.

Tuesday, April 14, 2009

Milestone I

The goals for milestone I are complete by the deadline.

There is a minor problem with the XBee outstanding that is to be addressed today. Specifically communicating PIC to PIC, this may be due to using the incorrect sending and recieving function (``printf'' may be too fast, perhaps send character by character with a specified delay).

The milestone I report can be downloaded here.

First stage in motor control

This video demonstrats the ultrasonic sensor controling the speed of the motors. If an object is within one foot, the motor stops. If the object is between 1 and 2 feet, the motor is at half power. Finally if the object is greater than 2 feet away the motors move at full power.

Monday, April 13, 2009

Accelerometer experimental values

Table 1: Accelerometer Calibration Experiment Results

The following test was performed on the calibrated output of the accelerometer. Initially the accelerometer was calibrated in the static state sitting on a table; increments based on a degree measurement. The X and Z were measured as shown in Figure 1, and Y was measured as shown in Figure 2.

Calibration of the module is done by taking a snapshot of the x, y, and z values during startup. The values in Table 1 are simply the difference between these initial values and the sampled values at the various angles. That is
K_calibrated = K_initial - K_sample,
where K is either the x, y, or z direction.

This experiment is going to be refined to show the sampled value along with the calibrated value, where the rollover is shown. Updates to come...

Figure 1: Measurement setup for X and Z axis

Figure 2: Measurement setup for the Y axis

It is noted in the test that the X and Y values correspond for their respective angles.

Friday, April 10, 2009

Accelerometer and motors functional

Today we accomplished both the accelerometer and motor control with an H-bridge.

The accelerometer was tested by writing an interrupt service routine (ISR) that samples eight values from each of the X, Y, and Z vector directions. This was to ensure that the sampling frequency was great enough and was not being slowed down by other programming tasks. After the total of 24 values were recorded into the X, Y, and Z arrays, a function is called from the ISR that disables interrupts (so that new values do not alter this test) and prints out the collected results on Hyper Terminal. Once all of the values are printed, interrupts are enabled so that this process continues indefinitely.

Motors operate independently with pulse width modulated waveforms sent to the H-bridges. The regulated 5 V power was removed from the H-bridge so that the motors now revieve the full 9.6 V of power.

Thursday, April 9, 2009

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.

Tuesday, April 7, 2009

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).
  • 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.
  • 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;


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

Thursday, April 2, 2009

Accelerometer calibration

This short video shows a demonstration of an application, ``Super Monkey Ball Lite'', not taking advantage of calibrating the user position.

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.

Wednesday, April 1, 2009


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 Updates of the development code will be housed there, and updates on ideas and development will be housed here.