ECE 477 Digital Systems Senior Design Project Rev 8/09 s1

ECE 477 Digital Systems Senior Design Project Rev 8/09

Homework 9: Software Design Considerations

Team Code Name: RoboSiM Group No. 11

Team Member Completing This Homework: Bryan McDonnel

E-mail Address of Team Member:

Evaluation:

SCORE

DESCRIPTION

Excellent – among the best papers submitted for this assignment. Very few corrections needed for version submitted in Final Report.

Very good – all requirements aptly met. Minor additions/corrections needed for version submitted in Final Report.

Good – all requirements considered and addressed. Several noteworthy additions/corrections needed for version submitted in Final Report.

Average – all requirements basically met, but some revisions in content should be made for the version submitted in the Final Report.

Marginal – all requirements met at a nominal level. Significant revisions in content should be made for the version submitted in the Final Report.

Below the passing threshold – major revisions required to meet report requirements at a nominal level. Revise and resubmit.

* Resubmissions are due within one week of the date of return, and will be awarded a score of “6” provided all report requirements have been met at a nominal level.

Comments:

Comments from the grader will be inserted here.

1.0  Introduction

Robotic Surveillance in Motion (RoboSiM) is an autonomous vehicle capable of surveying a remote location. In short, it is a robot capable of traveling to a designated position, recording audio for a specific amount of time, and returning the data back safely. To accomplish this task, there are several things that must be accomplished.

Before the vehicle can be sent out on its mission, a home location, a target location, and a recording time need to be specified on an SD card. This can be easily done using a PC to write the data to the SD card. After placing the card in the vehicle, it can be powered on. After initialization is complete, the vehicle’s journey begins.

During transit, the robot periodically samples its onboard GPS module, ultrasonic sensors, and digital compass. These peripherals allow the vehicle to find its way to the target and avoid obstacles along the way.

After reaching its destination, the vehicle can begin its surveillance. The robot will hold its position and record audio for the specified length of time. The captured audio is encoded and stored on the SD card, so that it can be retrieved and played back when the robot returns to its home location. After, completing its observation of the target location, the vehicle embarks on its return trip.

In order to complete all of these steps successfully, the robot’s operating system must be robust enough to handle any extraordinary events that it encounters while out in the field. But, it must also be light enough to perform adequately in an embedded environment. The sections below will detail the steps taken ensure RoboSiM’s reliable operation, including hardware-software interface considerations, application organization, and code module functionality. A software narrative will also be provided to solidify the ideas behind RoboSiM’s software design.

2.0  Software Design Considerations

Describe the design considerations that are guiding the development of the software for your project. This description should include: explicit (detailed) mappings of memory (locations for static data, variables, stack, heap, code, etc. in SRAM/EEROM/Flash), mapping of external interfaces (port names/addresses), utilization of integrated peripherals (including operating modes/register initializations required), and overall organization of application code (e.g., interrupt-driven, state machine, polling loop, etc.). Include the rationale for choosing the application code organization indicated. Include a flowchart (or pseudo-code) that depicts the flow/activity of your “main” program (place this illustration in Appendix A). Also, indicate any provisions you have made for debugging and/or “built-in self-test” modes of operation.

RoboSiM is an embedded systems project, and as such, requires careful consideration of all options at each stage of development. Like all designs, each decision has the potential to affect several aspects of the project. But, unlike general purpose systems development, embedded systems must be designed within a tighter set of constraints. In particular, embedded software development is often restricted by limited memory space, little to no abstraction, and weaker hardware. With the right design choices, however, these restrictions can be overcome, and may even contribute positively to the outcome of the project.

2.1  Hardware/Software Interface

The design of RoboSiM’s operating system depends largely on the hardware on which it will run. The vehicle will be equipped with a PIC24H microcontroller containing 128 kB of user-programmable flash program memory and 16 kB of RAM [1]. The chip is based on a modified 16-bit Harvard architecture, and utilizes 24-bit instructions [1]. Figures 6 and 7 in Appendix C below show the layout of program and data memory, respectively, for the particular model chosen for this project.

Program memory is organized into 16-bit words, with each memory address corresponding to a single word. It is divided into two distinct sections: the User Memory Space and the Configuration Memory Space [1]. Application-specific instructions are stored in the User Program Flash Memory section (addresses 0x000200 to 0x0157FE). This section of the program memory has 87,550 indices, but this doesn’t translate into space for 87,550 instructions. Since, each index of program memory refers to a 16-bit word, and each instruction is 24-bits wide, a single instruction must occupy two indices. This means that there is room for about 44,000 instructions. While this does restrict the potential size of the operating system’s control routines, it is not an unreasonable constraint. With careful planning and code optimization, this space limitation should not be a problem.

Data memory, like program memory, is organized into 16-bit words, with each memory address corresponding to a single word. But, unlike program memory, it is byte addressable. Data memory is split into three sections: the Special Function Register (SFR) space, Data RAM, and DMA RAM [1].

The 2kB SFR space contains the microcontroller’s PC registers, working registers (16 in total), and peripheral configuration registers. RoboSiM will make use of the following peripheral control registers: Interrupts (0x0080 – 0x00E0); Timer (0x0100 – 0x013C); Output Compare (0x0180 – 0x01AE); I2C (0x0200 – 0x021C); UART (0x0220 – 0x0238); SPI (0x0240 – 0x0268); and ADC (0x0300 – 0x0372) [1].

The 16 kB Data RAM space is used by the PIC24H’s heap and software stack. This portion of the address space, while 16 kB in total size, actually encompasses the DMA address space. When DMA is in use, the microcontroller’s effective data RAM space is reduced by 2 kB. RoboSiM, however, won’t suffer from this, since DMA is not used. When used in conjunction with embedded C, the data RAM should provide plenty of working room for all of RoboSiM’s necessary computations.

2.2  Application Organization

With low-level hardware considerations made, a higher-level application view can be adopted. Since the operating system’s task is to coordinate the interaction of the system’s peripherals, it is important to consider the different methods of organizing the application. An interrupt driven application is well suited to asynchronous environments, such as capturing keyboard strokes. A state-machine oriented application works well for very structured environments, like a USB communication protocol. An application built around a polling-loop works well for situations in which several things may happen, each needing to be checked regularly.

RoboSiM has a unique operating structure in that there are two exclusive modes of operation: Navigation, and Surveillance. While travelling to the indicated target, the vehicle will not be recording audio. Once the vehicle has reached its destination, it stops and surveys the area by recording audio samples. These two modes require different amounts of “attention” from the microcontroller, and thus subscribe to different organizational paradigms.

During the Navigation phase of a given mission, the vehicle will operate in response to regularly scheduled interrupts. While this may seem to defeat the purpose of an interrupt driven application, it actually makes implementation very easy. The microcontroller’s Timer module can be configured to trigger an interrupt at very precise intervals, allowing the robot to sample its sensors and correct its course periodically.

For example, the Timer module could be configured to interrupt at a rate of 10 Hz. While handling each interrupt, the microcontroller queries the GPS module, storing the position response to memory. Only on the tenth interrupt, however, is a course correction performed. The 10 GPS samples are median-filtered to produce the actual position that the course correction will be based on, reducing the effect of erroneous position samples. This extended sampling scheme shouldn’t be affected by the movement of the robot, since the vehicle will only be moving a small distance (6 inches) each second.

Figures 3 and 4 in Appendix A below illustrate how a course correction decision is performed. For the vehicle to navigate to the intended target location, it only needs to know two positions: its own position (as indicated by the GPS module), and the target location (as read from the SD card). Given the robot’s latitude and longitude, R(λr, φr), and that of the target, T(λr, φr), a signed distance vector and slope can be computed.

In the equations above, Δλ represents the latitudinal difference between the target and the vehicle, and Δφ represents the longitudinal difference. These two values, (Δλ, Δφ), make up the signed distance vector. The slope, m, of this distance vector is simply the quotient of its two components. Figure 3 shows how the signs of this direction vector and its slope can be used to determine the cardinal direction in which to proceed.

Once the target has been reached, the Surveillance phase begins. At this point, the vehicle holds its position and prepares to record, encode, and store audio samples gathered from the target area. This mode of operation lends itself very nicely to a state-machine design since there is a very structured set of operations that need to be performed repeatedly.

Speech recording needs a sample rate of about 44 kHz for effective audio reproduction. For each of those 44,000 samples, the microcontroller needs to capture a voltage sample from the microphone, encode it using an ADPCM algorithm, and store it in an appropriately sized buffer. These steps repeat until the buffer is filled, at which point it is written to the removable SD card. This entire process continues until the specified recording time has been reached. The highly repetitive nature of this recording algorithm makes the choice of a state-machine based design trivial.

Adaptive Differential Pulse Code Modulation (ADPCM) is particularly well suited to encoding speech due to a high correlation between consecutive speech samples [2]. ADPCM encodes audio by storing the difference between a predicted value and the actual value of a given sample. This allows a significant reduction in the number of bits to store a particular sample, yielding a highly efficient encoding. Luckily, Microchip has made available a very detailed application note on implementing ADPCM encoding in a computationally efficient manner on PIC microcontrollers [3].

To store the audio on the SD card in a PC-readable manner, the microcontroller must support FAT16/32 file formats. Microchip, has also made an application note and library freely available for this very task [4, 5]. This will allow the operator of the vehicle to play back the retrieved audio recording easily on any PC.

After completing its surveillance task, the vehicle enters the Navigation phase again. The vehicle returns to the position it marked as “Home” before embarking on its mission. After, arriving at “Home”, the vehicle stops so the recorded audio can be retrieved and played back.

3.0  Software Design Narrative

First, illustrate the hierarchical arrangement of the various code modules you are writing and/or adapting (from commercially available or “shareware” sources). Include this diagram as Appendix B. Then, on a module-by-module basis, describe what each code module does, the purpose it serves, and how it works. Also, for each code module, indicate its completion status (e.g., successfully ported and tested, outlined in pseudo-code, written but not tested, etc.). Be sure to include references for any “shareware” (or otherwise) code modules you are porting to your project. DO NOT INCLUDE ANY CODE LISTINGS IN THIS REPORT – instead, include “hot links” in the body of your report to the source listings on your team’s web site. (A “nice touch” would be also to include “hot links” to the corresponding source code listings in the hierarchical block diagram.)

The source code for RoboSiM’s operating system is divided into several different packages of operation, each encapsulating a specific group of functions to ensure maximum portability. Each package is further subdivided into modules, each defining an API. Each of the packages and their member modules are defined in the following sections.

3.1  Kinetics

The Kinetics package defines motor functionality through a very simple interface. It consists of an API that encapsulates hardware interaction in an easy-to-use set of high-level functions. The PWM Module from the System package (detailed below) is used by the Motor Control API, which provides a simple way for the operating system to issue navigation commands to the motors.

·  Motor Module – Outlined

3.2  Navigation

The Navigation package specifies the navigational decision-making protocols. It is separate from the Kinetics package to distinguish policy from implementation. The Navigation package contains a GPS module which encapsulates all the specifics of communication with the GPS module. This module provides an API for retrieving position updates, and configuration of the GPS chip. A Decision module makes use of the GPS API and the Sensors Package (explained below) to decide how to control the vehicle.

·  GPS Module - Incomplete

o  int gpsConfigureUart(int baudRate, int numStopBits, int numDataBits, int parity, int memOption) – Configures the GPS chip’s UART communication interface with the specified characteristics.

o  float gpsGetAverageLatitude() – Returns the average of all the latitude samples for the previous round of GPS samples.