Mudd Rover ☯Design Document☯ Version 0.2 Ron Coleman Josef Brks Schenker Akshay Kumar Athena Ledakis Justin Titi1. Overview The basic idea behind Mudd Rover is to create an autonomous robot with an onboard camera that is capable of finding a line on the floor, orienting itself properly and then finally following it. The processing done behind the scenes will take place using the XiLinx Spartan FPGA that is mounted on XSB-300E. Part of the FPGA will be programmed to be our custom video processing hardware. The skeletal form of the robot will be a tank-like vehicle built with LegosTM. The method of communication between the XSB-300E and the Mudd Rover will take advantage of the Lego RCX and its companion serial IR Tower. Primitive commands will be sent from the XSB-300E via the serial IR tower to the Lego RCX, which will be mounted on the Mudd Rover. The seamless communication between the XSB-300E and the Mudd Rover will give the appearance of an intelligent robot with a vast amount of processing power onboard even though 100% of the processing will actually be taking place remotely. There are three distinct parts to this project: Video Processing, Serial / IR Communication, and the Brain of the Mudd Rover.2. Video Processing 2.1. Overview The X10 Video camera will be connected to the SAA7114 Video Decoder located on the XSB-300E via a composite video cable. The X10 video camera will be sending a constant NTSC signal to the SAA7114 decoder. The SAA7114 decoder will process this stream of video and send it out in digital form to our custom video processor and its accompanying software. This package of hardware and software will be refered to as SourceFinder from this point on. SourceFinder will then process select frames of the digitized video and gather the information needed by the Brain of the Mudd Rover in order to direct Mudd Rover to achieve its task. 2.2. SAA7114 Video Decoder The first step in our video processing is the Phillips SA7114H video decoder. The video input direct from the camera mounted on the Mudd Rover to the chip via the RCA jacks (either J7 or J8 on the board), which connect to AI23 and AI24 respectively. We will deal with the raw data in the YUV 4:2:2: format. For the purposes of our project, however, we will only be using the Luminance, value, Y—so practically we will only use every other bit inputted into the system. Rather than using the Phillips chip for any processing, we simply use it as an analog-digital converter. The data enters the chip in an 8 bit word, and gets passed straight to SourceFinder. 2.3. SourceFinder-Hardware The hardware component of SourceFinder is a simple component in VHDL that takes the video input one line at a time and outputs the location and size of the largest light source on the line. As inputs, SourceFinder takes the 8 bit data stream from the SAA7114 Video Decoder, the video clock, and the Horizontal and Vertical reference values. Using these inputs, the hardware runs through each line building the largest light source and outputs it for use by the software component of SourceFinder. SourceFinder outputs two pieces of information, the position of the light source (using a 10 bit wire) and the length of the source—also a 10 bit integer. Since the SAA7114 Video Decoder chip reads video at 30 frames a second, by performing this task in hardware, we can read new inputs at 5-6 frames a second with great enough speed to ensure that our programs can react in real time to any input offered.2.4. SourceFinder-Software 2.4.1. Overview Upon leaving the SourceFinder Hardware component, position and length of the light source are sent to the software component of SourceFinder. It reads in the values and thereby determines the location of the total light source on the entire screen. The goal of this program is to find the central point of a distinguished area on the path that the rover will be following. We will also determine the direction that the rover will be moving in, by finding the slope of the path in each given frame. This is done in 4 steps: 1. Find the central point of each line. 2. Divide each frame into equal sections and find the center of each section of the frame, using information from step 1. 3. Using information from step 2, find the central point of each frame. 4. Find the slope of the line, by calculating the line between the top and bottom section of each frame. 2.4.2. Implementation The input for this program is the start point and the length for a distinguished (either dark or light) set of pixels for one line of a given frame. The algorithm we will use is: #define SCREENSECTIONS 2 #define LINES_PER_SEC 5 #define FRAMEHEIGHT SCREENSECTIONS * LINES_PER_SEC int startposition; int length; int i = 0; int s = 0; int j = 0; int main(){ int lineaverage[LINES_PER_SEC]; int sectioncenter[SCREENSECTIONS]; int lineslope; int tempsum = 0; for( , , ) {/*NOT REAL CODE startposition = getstartposition(); length = getlength(); */ lineaverage[i] = startposition + (length/2);//find out how to shift to divide i++; //finds center of each line if(i == LINES_PER_SEC){ i=0; for(j=0; j<LINES_PER_SEC; j++){ sumofaverages = lineaverage[j] + sumofaverages; }//end for sectioncenter[s] = sumofaverages / LINES_PER_SEC; sumofaverages = 0; s++; if(s == SCREENSECTIONS){ s = 0;for(j=0; j < SCREENSECTIONS; j++){ tempsum = sectioncenter[j] + tempsum; }// end for centerpoint = tempsum / SCREENSECTIONS; tempsum = 0; lineslope = (LINES_PER_SECTION * (SCREENSECTIONS - 1) ) / (sectioncenter[0] - sectioncenter[SCREENSECTIONS - 1]); // This rise can be hard coded when we know the exact specs }//end if }//end if }//end for }// end main 2.4.3. Performance and Memory Usage The estimated runtime of this algorithm is O(2(N+k)), where N is the number of lines per frame and k is the number of sections that each frame is split up into. Assuming we will split the screen into about 6-8 sections, k is less than 3% of N, so its addition to the runtime is minimal, but we are including it for good measure. In order to run this program we will be storing 7 variables of type int, which would require 14 bytes of storage. In addition we will be storing N/k + k variables of type int. This would require 2*(N/k + k) bytes for storage. N is the number of lines per frame and k is the number of sections that we
View Full Document
Unlocking...