THE PEDESTRIANS
HomeOverviewSponsorTeamDocumentsProject Detail

Problem Statement

The ultimate goal of the project is to design an electronic pedometer. A pedometer is a device that tracks how far a person has walked, how many steps they have taken, their speed, and how long they have been walking. The device is usually small enough to be clipped to a belt, attached to a shoe, or worn as a watch. In order for the pedometer to perform as expected, we must design and integrate both hardware and firmware.

Hardware and firmware must be designed to perform a variety of tasks. We must design an interactive display system that enables the user to tailor the pedometer to his or her needs. Hardware and firmware will be used to perform calculations for conditions including speed, acceleration, and horizontal or vertical movement. All of these systems must be integrated together in a small, lightweight case and powered by a battery.

The firmware will be produced using the Hi-Tech C compiler in combination with MPASM and MPLAB. Its design and documentation will include algorithms, calculations, and a variable dictionary specifying the type of data and expected range of values in all variables. The hardware design and documentation will include calculations of force and acceleration schematics, simulations, bills of materials, and layouts. The board layout will be performed using Express PCB, and the board schematic will be generated using Design Works Lite.

The design and implementation of the pedometer will be accomplished by breaking the overall task in to smaller parts. Design, implementation, and troubleshooting will all be necessary to achieve the final goal. The degree of success that the project achieves will be determined by the completeness of our design, our ability to produce what we have imagined, and our determination to make it work.

Summary of the Design Process

Our design process was somewhat modified from the traditional design cycle, because we did not have a brainstorming phase. Our client was very specific in what he wanted us to design for him. We met with him early in our design phase and had very specific details about what the project would entail. He also provided the simulator, emulator, and the software packages necessary for our design. Then, as we got to different subsections of our design, he sent us the hardware required to complete that phase. The following is a modification of our initial design approach, which we still continue to use.

Our team approached this problem using a divide-and-conquer method. The problem appeared to be very large and complex, but by breaking it into several subsystems we were able to get a much better understanding of what the project entailed. Once we understood what each of the subsections needed to accomplish and how it needs to interface with any neighboring subsystems, we tackled the problem one step at a time. The link at the top of the page entitled "Project Details" shows the block diagram we used to break up the larger project, and has additional links to more of the project details

Design
Our team was very fortunate during the design phase of our project, because our sponsor, Keith Curtis, knew exactly what he wanted. He was definitely not a 'typical' client. He was very knowledgeable about the technical aspects of the project, because he helped to design the PIC16C782. He also wrote the majority of the manual detailing how to use it. For these reasons he was able to tell us exactly what he wanted.

The biggest design consideration was which microcontroller to use for this project. During our meeting with Mr. Curtis, he made it clear that our project was to be used as a possible application of the PIC16C782 microcontroller. With that major decision taken care of, the hardware was fairly simple to design. It merely had to connect the electrical components required to allow the microcontroller to function.

The firmware took up the majority of the time on the project, mostly due to the learning curve. We were not very experienced with programming microcontrollers. There was one major decision to make- the accelerometer could output either a voltage level, or a waveform with a variable duty cycle. We decided to use the voltage level because the microcontroller can measure that directly, no additional hardware was necessary between them.

Simulation
The majority of the testing was simulation, because we were unable to walk around and see how well the pedometer measured different movements. The hardware was not secure until late in the project, and the cord to the microcontroller emulator was very short. Because of these complications, the majority of the testing was done by tapping the microcontroller to simulate a step. The pedometer functioned well whether it was being moved up and down and tapped on the table, or if it was staying relatively still and someone was tapping the device itself.

Fabrication
Creating the hardware was a little complicated, again due to the learning curve. Not having much experience creating PCB layouts, the board creation took a little longer than expected. Fortunately there was plenty of time allowed in the schedule and this did not become a major concern.

Milestones

The link above reading "Project Details" has an option to view the project schedule. The major milestones described below coincide to the schedule shown under the project details. The following are what we considered to be the most important topics to keep ourselves on schedule:

" Definition of necessary signal conditioning
" Completion of accelerometer algorithms
" Control program completion
" PCB board design
" Completion of display code
" Completion of accelerometer interface code
" Integration of PCB board and microcontroller
" Completion of documentation
" Presentation and poster session
" Final report

Tools Used in the Design

PIC16C782 - Emulator & Simulator
Hi-Tech C compiler
MPASM
MPLAB
Express PCB
Design Works Lite