The Design of Freddy

Overview

        FREDDY is a programmable robot with collision avoidance capability. FREDDY can receive a set of instructions via a serial port interface and follow them. If FREDDY encounters an obstacle during the execution of this program, FREDDY will use the remainder of its program to find its ultimate destination. FREDDY will then use its AI to navigate to that point, avoiding whatever obstacles it encounters along the way.

        This document will begin by giving a general high level design of FREDDY. It will then discuss the functional decomposition of the project and will then move on to a list of the physical components used to build FREDDY. None of the alogirthms are discussed in too much detail due to the fact that the page contains the all the code that we used to build the system. Most of this code is fairly straight forward and can be understood by anyone with a basic knowledge of C for the 8051 and Visual Basic.


General Design

        FREDDY has at its heart an 8051 microcontroller. This microcontroller performs a number of tasks, from downloading the program to running the AI, and is mounted on one of three breadboards that contain the electronics in the center of the robot. All of the other electronics on these breadboards are used to either support the hardware (the stepper motors and the sonar) or the 8051 itself.

        FREDDY is programmed with a very simple programming language summarized in the table below. Each command is one byte long with the first three bits being reserved for the instruction id. The first two bits are used to tell FREDDY to pause, move forward, left or right. The third is used to tell FREDDY to ignore the sonar and thus turn off the collision avoidance system. The other 5 bits are used to convey the number of times that the instruction should be repeated. This allows us to get more mileage out of our code space. For example, if the user wanted the robot to move forward in a straight line for 5 forward commands, instead of giving the system five seperate commands the user can send it one command to be repeated five times. In the systems memory, the directive will now take up one byte rather than five, leaving more space for other instructions.


Code Meaning
00100000 Start and Stop command. This is the only special reserved byte.
00XXXXXX Pause command, the last five bits has to represent a number greater than 1
01XXXXXX Left command
10XXXXXX Right command
11XXXXXX Move forward command
XX1XXXXX Ignore the sonar (either the first two bits or the last two bits must be a number greater than 1)

   FREDDY's basic instructions set

Functional Decomposition

The project was divided functionally into a number of smaller pieces, these are listed below.

User Program: Before we could do any real testing, we needed an easy way to download programs to the machine. We accomplished this by writing a program in VB that gave us an easy to use UI for creating and downloading, byte by byte, our programs.
Control Logic: Within the 8051, the first task that starts is the control logic. This is the task that sets everything up and does the central processing. The control logic also decides when to fire the sonar and decomposes and runs each instruction.
Serial Interface: This task has two functions, it downloads the program from the serial link as it comes from the PC and it serves to the control logic the next command in the queue as the program executes. The Serial Interface is divided into an interrupt driven upper half, and a normally scheduled bottom half. The upper half handles the first task, while the bottom half handles the second.
Motor Controller: This task runs the motors. It creates the pulses used by the motor driver chips to actually drive the stepper motors. The direction of each of the motors is determined by output bits set in the control logic.
Sonar Controller: This task controls the sonar and records the value of the counter upon detecting an echo from the sonar. It is also responsible for resetting the sonar for the next time that it is read.
AI: This is the biggest and most involved of all the tasks. When FREDDY first encounters an obstacle, this task is called. It pulls the remainder of the program, byte by byte, from the memory and uses it to determine where its ultimate destination. It then records the location of the obstacle in a grid map stored in memory. Each square on the grid, has four bits used for path finding. The grid map is 101x101 squares and each square is the width of one forward movement. Although the algorithm is fully functional in the compiler, we were unable to get it to work on the machine itself.


Physical Components

Number Item Description Comments
- Cardboard base This provided the main structure to the machine
3 Small Breadboards Mounted in the center, these provide us a place to put our electronics
1 8051 Microprocessor This is the real heart of the machine
1 32K external memory Due to the complexity of the AI, the 256 byte memory of the 8051 proved insufficient. Thus we installed a 32K RAM. This RAM does not appear to be as functional as we had hoped.
1 RS-232 Tranciever Used for downloading instructions from the user program
2 Stepper Motors Provide the basic motive force for our vehicles
2 Motor Drivers Provide power to the motors
1 TTL eight bit latch (SN74LS373) Used in interfacing the external RAM with the 8051 chip
1 Sonar Tranciever Used to provide forward rangefinding
1 32 MHZ clock Used by the 8051
Assorted Capacitors, Resistors and Diodes Used for various purposes
Assorted Legos Used to build supporting structures and the castor wheel in the back



Problems

        FREDDY was an interesting project in that there appeared to be more problems at the end than at the beginning. When we first began working on the device, we divided the programming into three small pieces, one for each of us. These pieces included the serial port, control logic and motor controllers. Each of us wrote our parts and then integrated the whole in a Tuesday lab session. After some debugging in the compiler, we burned the chip. FREDDY worked the first time. Then the problems started.

Sonar

        Here we experienced a number of problems due to the electrical characteristics of the sonar and the ATMEL. The biggest problem was the failure of the ATMEL to recognize the ECHO line on one of its interrupts. At first we thought that this was due to the interrupt pin only recognizing a falling edge on the line, so we added an inverter. This did not solve the problem. Then we switched the internal code to a busy wait (it didn't hurt us in terms of cycles since the sonar code was the only thing running on the ATMEL) yet the problem persisted. So our third course of action was to look at the electrical signals themselves.
        The problem now appeared to be the fact that the electrical signal was on the edge between being a logical high and low. Thus, the atmel wasn't seeing the rising edge at all. We solved this problem by adding an external pull-up resistor to strengthen the signal. Thus, the problem was solved. We left the code using the busy wait loop so we didn't have to worry about the inverter, and went on to other things. You might hope that this was all, but wait, there is more!

The AI

        Timmy (the name has been changed to protect me from retribution) was a man who had a dream, he felt he could build an AI that would amaze even the greatest researcher in the field. So he began work on this marvel after the initial bot was complete. He worked tirelessly for hours not only building incrementally upon the algorithm, but learning the intricacies of the compiler as he tested and debugged the code on the way to perfection. And then it happened, he exceeded the standard code limit. Luckily he found dongles that allowed him to compile and was able to continue his activities on the full version of Kiel, but not without many trials along the way and many hours spent cursing Ectingdule. So he continued, and finally installed his program into the beast to be tested.
        The new FREDDY, enlightened by Timmy's efforts, surged forward down the hallway towards an obstacle just like before. And just like before, FREDDY was able to use his sonar to detect the object and stop. Unlike before, FREDDY was able to maneuver around the object and continue on its way. Success!! FREDDY worked!! The AI worked!! or at least that is what Timmy thought.
        Timmy was not one to trust the first run of anything. Being an experienced software engineer he knew that the first result only tell part of the story. Thus he tested FREDDY again, this time with more than one object. FREDDY, just as before, was able to maneuver around the first object with relative ease, yet with the second, FREDDY froze and began firing its sonar repeatedly. Timmy's heart sank. Yet he knew the code had been throughly tested in the compiler and being an experienced software engineer, he knew it must be a hardware problem, so he would leave it to the harware guys to figure out.
        The hardware guys worked tirelessly at the task until, none of FREDDY was functional! This was disconcerting. FREDDY's development appeared to be going backwards. Bugs were appearing where they hadn't been before. The worst of it was that with the removal of parts, power consumption appeared to be going up and not down! Finally, the bugs were found. Some of the parts were no longer wired correctly and part of the stepper motor control lines had actually parted. The motor was quickly repaired and tested to make sure it was back to functioning, likewise the miswiring was corrected, but there was still no activity. Then one of the hardware guys realized that somehow, an old copy of the user program was being used to try and communicate with FREDDY. When this was replaced, FREDDY was back to its old self once again. Yet all was not well, the AI still did not function.
        Timmy was back on the case with the hardware guys behind him. They stepped through the code and worked tirelessly to perfect the algorithm. As the night dragged on, they moved closer and closer to a working product. They were able to see in code the same problems that they had seen in actual operation and were hopeful that once these problems were isolated, FREDDY would be like the scarecrow from the Wizard of Oz after he met the Wizard. But it was not to be. After the AI was successfully debugged and, according to the Keil compiler, was 100% functional, FREDDY would still not work. It appears that there was some problem with the external memory being used for the device. Even with the basic program that did not include the AI, which they had wisely kept as a backup, FREDDY still had problems with longer programs. This was one thing they didn't have the time or equipment available to fix, so they decided right then and there to demo what they did have and leave things at that. Thus, FREDDY isn't as smart as he could be, but he isn't totally stupid either, and we are back in the realm of a hardware problem.




Conclusion

        FREDDY was a bit ambitious for the time that we had, but we successfully accomplished most of our design goals. We were able to build on the things that we had learned in class and through labs to add functionality rather quickly to the device. As this is a prototype device, we decided to remove some of the constraints that would be challenging not in their academic application, but in regards to available materials and time. This included the idea to use a wireless kit and to have an onboard power supply. We also added some functionality that was helpful mainly in testing the device, including ambilical cords for sending instructions and providing power to the device. If we were to continue development, the cords at least would be replaced by their wireless equivalents and we would probably spend more time on the design of FREDDY's body. We would also try to repair the electronics so that the external memory was fully usable as had been the hope in the original design. Despite these changes and the problems encountered along the way, FREDDY was a successful project. The platform we developed could concievably be used as the basis of future projects where the developers may wish to concetrate on some feature of robotics beyond the basics.


All materials on this page are copyright Daniel Dunham, David Deterra and Jeremy Hance. The University of Washington Department of Computer Science and Engineering has full rights to the use of this project. All other rights reserved.