The SCORPIO Robotics Project: An Example of Hardware- Software Codesign John K. Estell Computer Science and Engineering Department The University of Toledo Toledo, Ohio 43606-3390 phone: (419) 537-3532 E-mail: estell@cse.utoledo.edu Abstract The purpose of the SCORPIO robotics project was to develop a microcontroller system for an inexpensive, small-scale, walking robot. This was performed as a class project by the students in the Microcomputer Systems II course during the Spring 1993 Quarter at The University of Toledo. The students were required to handle all aspects of the design process, from the initial planning stages to the delivery of a finished product. In order to accomplish this task, the collaborative efforts of both hardware and software designers using an embedded systems approach was required. By focusing on the use of the codesign methodology, one promotes more thoroughly thought out designs, encourages communications between design groups, and requires understanding of the problem prior to solving it. In addition, the codesign methodology encourages the use of computer tools to facilitate the design process. This instructional format allows students enrolled in the course to gain actual codesign experience while solving a "real-world" problem within a limited amount of time. 1. The Codesign Process The word "codesign" reflects an approach to the development of a system through the simultaneous, integrated development of modules from more than one design area. In the field of embedded controllers, this specifically refers to the concurrent use of both hardware and software design. In an embedded controller system, one typically has processors dedicated to the performance of specific functions. These functions are implemented using a combination of hardware and software modules. Using the traditional approach, development of the hardware and software modules would be performed almost independently of each other. The lack of communication between the groups working on the design would often lead to incompatibilities between hardware and software modules, requiring modifications to be performed before a final design could be approved. By adopting the codesign methodology, one stresses communication and interaction between the hardware and software development groups, which helps in avoiding pitfalls such as schedule and cost overruns caused by such communication problems. Paradigms for codesign are currently being investigated [1-4], and the methodology is still in its infancy. However, there are some general principles involved with the process. First, one needs to adopt a flexible design strategy, where the system is initially modeled as a composition of functional units. Members of both the hardware and software development teams work on the stepwise refinement of the system model. The design teams perform appropriate design evaluations for each of the functional units, such as cost, reliability, and performance. Team meetings are frequently held to promote communication and interaction between the development groups. Once the design evaluations have been analyzed and the functional units have been broken down into hardware and software units, further meetings are held between the groups in order to maintain communication and to assist in the fine tuning of the system design. By using paradigms that promote concurrency and group cooperation among those involved in the process, the codesign methodology promotes more thoroughly thought out designs, encourages better communication between project members, and forces the participants involved to fully understand the problem being evaluated prior to solving it. As applied to the SCOPRIO robotics project, the codesign process starts with extensive planning of the problem statements and specifications, as these serve as an overall guide to the project. Failure to spend sufficient time here can be catastrophic later on, as misunderstandings on the part of one group can adversely affect the operations of other groups. This can be partly handled by requiring students to analyze the possible failures in their design and to make their designs flexible enough to accept changes without major revisions. Misunderstandings are kept to a minimum through the remainder of the codesign process by requiring all groups to maintain good communications. This can be best handled by the instructor, whose role in the course is not that of a lecturer but instead that of a project manager. The group members must regularly meet with the instructor; this is done during the time at which the class is scheduled. Prior to the meeting, each group is required to submit a memorandum indicating the current status of their work. The memorandum is then distributed to all students in the class and is put on the agenda for discussion. This fosters good documentation practices as well as allowing the students to improve their written and oral communication skills. All this planning is of little use unless students have access to tools appropriate to the task. Ideally, one would have available for use computer simulation tools that would allow both hardware and software components to be handled as abstract, functional entities that can be easily manipulated and tested. Unfortunately, the current state of codesign technology has not yet reached that level. It should be noted here that current developments with application-specific integrated circuits makes it likely that CAD systems supporting embedded systems design will be available in the near future [5]. These systems, as they appear, will be very beneficial for students learning the codesign process. The students enrolled in this class had access to such laboratory equipment as in-circuit emulators and logic analyzers. These tools are highly valued for the time that they save in the design process. 2. The SCORPIO Robotics Project The SCOPRIO robot designed in this course is based on the Stiquito robot developed by Jonathan Mills of Indiana University [6]. The Stiquito robot is an inexpensive six-legged "creature" that uses nitinol actuator wire, formed from a nickel-titanium alloy, for its propulsion mechanism. Wire made from this alloy can be stretched as much as 8% when cool, and will return to its shorter length when sufficiently heated. The contraction of the wire can thus be used as a mechanism for providing force to an object in order to perform work. This "deform/reform" cycle can be repeated many times [7]. The legs of the Stiquito robot are made from piano wire, with the nitinol actuator wire being connected to the "knee" of the leg. When current is passed through the nitinol wire, power is dissipated in the form of heat. The heat contracts the nitinol wire, causing the leg to move. When the nitinol wire cools to a temperature below the transition point, it is stretched out by the tension present in the piano wire. This system results in a working, movable leg possessing one degree of freedom. The goal of the SCORPIO robotics project was to design a microcontroller board could be placed on the Stiquito robot, thereby freeing it from the restriction of being attached to another device for intelligent applications. An additional goal for the design was to have the capability of transferring the controller to other platforms with a minimum of design modifications. The first step in the codesign process undertaken by the students was to develop the general requirements for the system, in order to better define the problem and to limit its scope. It was decided that the robot must be a self-contained entity possessing the ability to make simple decisions based on a sensory input. For future reference, a name was given to this project: SCORPIO, which is an acronym for "Stiquito Controller using On-board Resources to Provide for Independent Operation." A formal proposal was then presented to the instructor, covering the problem and the general system requirements necessary for the solution. At this point the instructor must closely scrutinize the proposal in order to make sure that it is possible for the students to accomplish the task within the time allotted for the course. Once the instructor's approval was received, the students continued with the design. 3. Hardware System Specification and Implementation The design decision having the greatest impact was the selection of the microprocessor. This is one of the most critical steps in the codesign process, as the selection of the microprocessor strongly influences both the hardware and software design. Unfortunately, it is also that portion of the design that is most subject to constraints, primarily financial. In the academic environment, the selection of a microprocessor is usually determined by the emulation systems already available within the department. In our case, approval was received for the purchase of a new PC-based emulation system, with restrictions to the total cost. It was eventually decided that a 8051-family microcontroller would be chosen for the project. The arguments for this selection were that 8051-family emulator systems are relatively inexpensive, and several of the 8051-family microcontrollers are both cheap and easy to obtain. In addition, this family is used extensively in the embedded systems field. For example, in 1992 the number of 8051-family microcontrollers shipped to American customers by Intel and Philips was 74 million [8]. Having exposure to such a popular device would be beneficial to a student when looking for a job in the embedded systems area. After further study, it was decided that the 80C32 microcontroller [9] would be selected for the project. The 80C32 is an 8-bit CMOS single-chip microcontroller which is backwardly compatible with the 8051. It contains an on-chip 256 byte RAM, four 8-bit ports, three 16- bit timer/counters, a six-level interrupt structure, a full-duplex serial channel, and a Harvard architecture capable of supporting up to 128 KB of external memory. Once the processor was selected, the memory specifications were straightforward. Due to cost and weight constraints, it was decided that one 32 KB static RAM IC and one 32 KB EPROM IC would be used. While the software design group indicated that for their code they would only need a couple kilobytes of memory, it was deemed sensible to make the full addressing space of the 80C32 available for any future growth in either executable programs or the operating system. The decoding circuitry was designed such that the system can be used as a von Neumann machine if so desired, thereby allowing for greater programming flexibility. Once the microcontroller was selected, the specifications for the system were addressed. In the hardware specifications there are two major design constraints that must be confronted: power limitations, and weight limitations. The power limitations stem from the need for SCORPIO to carry its own power supply. While solar cells can provide some assistance, the need for a battery was readily apparent once the requirements for nitinol activation were considered [7]. In order to use the nitinol wires they must be heated, and this heat comes in the form of power dissipation through the wire. It is recommended that, for the diameter of nitinol wire being used, 180 mA of current be used for activation. Therefore, when each leg is moved, 180 mA is demanded from the power supply for a short amount of time. The weight constraints also have an effect on the power supply. SCORPIO must be able to carry its own weight, and the weight that it can carry is a function of the number of legs present in the design. This was a problem because of the piano wire used for the legs. As the Stiquito robot has a stated loading capacity of 50 g [6], a design based on this structure must assume that each leg can support roughly 8 g. The component causing the greatest loading effect on the body of the robot is the battery. In addition, the weight must be reasonably distributed over the body of the robot. Considering the weight and stability issues, it was decided that a new body had to be designed that would support a heavier payload. The stability was increased by widening the distance between each pair of legs. The width of the separation was made large enough to make room for holding either a 9 V transistor battery or two 1.5 V AA batteries located side-by-side. The length of the body was such that there is sufficient room for two batteries or sets of batteries. The loading capacity was increased by incorporating styrene rods into the leg design. The result was an eight-legged body that operated under the same principles as the original Stiquito robot design, but with the ability to support a load of over 400 g. Figure 1 is a photo of the SCORPIO robot taken apart to show the body, the power supply (consisting of one 9 V transistor battery and two 1.5 V AA batteries), and connections to the controller board. The leg controller circuitry presented the students with additional questions. The simple solution was to design the controller to handle eight legs, each possessing one degree of freedom. However, it might be desirable to incorporate into a future version of SCORPIO either more legs, or more degrees of freedom per leg, or both. For this portion of the design, flexibility was a key issue. After some discussion and analysis, it was decided that the leg controller circuitry would be given the ability to control up to 40 nitinol actuator wires, using multiplexed memory-mapped I/O organized in five banks of eight outputs each. The controller outputs not used for controlling a leg can be used to operate other related devices, such as a set of pinchers for grabbing objects. 4. Software System Specification and Implementation The software group determined that, in the long run, it would be best if a control language were developed for the SCORPIO system. Programs written in the SCORPIO Control Language (SCL) would be compiled on a PC, then downloaded to SCORPIO. The robot would have a monitor program written in 8051 assembly language that would include an interpreter used for executing the control language programs. The primary benefit of this approach is that the control language is independent of the actual implementation of SCORPIO. If a new version of SCORPIO were designed using a different microcontroller, all that would be needed is a new monitor program. The programs written in the control language would not have to change. The use of a high-level language (in particular, C) was considered, but was rejected. While there would be a reduction in the coding time, the efficiency of a high- level language is less than that found in an assembly language program. This is even more significant when using a microcontroller from the 8051 family. The architecture used here results in convoluted approaches to data handling by a C compiler [10]. Many things were considered when developing SCL. First was the need for simplicity in the construct of the language. With this in mind, a language was developed with few commands and only two addressing modes. Another goal was to have complete control over SCORPIO's movement with the language. Finally, it was desired that the language possess sufficient robustness such that elaborate programs could be written. It was decided that the language would be implemented using an interpreter residing on-board SCORPIO that would operate on code generated by an assembler. This approach allows SCL to be independent of the hardware used to control the robot. Consequently, if a hardware change is made, only the interpreter and subsequent assembly language routines will need modification. The current version of SCL is similar to assembly language. The elements of the language are mnemonic and are usually followed by a single operand. The reason behind this is that it is much easier to write an assembler for an assembly-like language than it is to write a compiler for a structured language. For this particular design, only a minimal set of language elements were implemented. SCORPIO's movements are controlled by commands for going forward and turning either left or right. Decision making ability is available from the jump, test, and compare instructions. Furthermore, the language allows the user to call subroutines written in machine language from a user program. The user-supplied routine can be assembled using any 8051 assembler and then loaded into memory using the SCORPIO communications package. This feature was added for testing and debugging new SCORPIO functions and for implementing custom-designed hardware drivers. At the present time, plans are being made to expand SCL to include "intelligent" or "self-awareness" commands such as the need for battery recharging and performing proximity detection using IR sensors. Programs written in SCL are parsed by the SCORPIO Language Assembler (SLA). Written in C for portability, the assembler breaks down the mnemonics and operands into eight- bit codes. The difference is that, in other assemblers, the values represent the machine code for a particular processor while the codes produced by the SLA represent routines and data to be handled by the interpreter. Figure 2 shows the listing file generated by the assembler from an example of SLA code. The first column in the listing file contains the address of the current instruction. To the right of the address is the hexadecimal opcode(s) of the instruction; these opcodes are also stored in an object file. Finally, an address table is printed listing the address of each label present in the program. Note that, with the exception of the target address for a machine language subroutine call, all addresses are relative addresses. The SCORPIO kernel is composed of three items: the interpreter, the monitor, and the communications package. All of these items reside in EPROM on the controller's microprocessor board. The SCORPIO interpreter is a program that reads SCL opcodes from external RAM and executes the corresponding machine language procedures stored in ROM. The interpreter parses each instruction before executing the appropriate routine; therefore, a program written in SCL will not be as fast as one written entirely in the machine language of the microprocessor. The interpreter should be as efficient as possible so the performance of SCORPIO is not adversely affected. Due to this, the interpreter was written entirely in 8051 assembly language instead of a high-level language. This optimizes the operation of the interpreter, resulting in increased speed and efficiency. The development of the interpreter evolved into a virtual processor for SCL. The interpreter has three registers: an accumulator, an instruction pointer, and a step-size register. It also has three flags: carry, negative, and zero. All instructions referencing the accumulator use the SCORPIO accumulator, while all instructions referencing or setting flags use the SCORPIO flags. This is another portable aspect of SCORPIO. The interpreter's registers are independent of the architecture used; therefore, the interpreter can be implemented on any system. This also reserves the actual registers of the microprocessor for use exclusively by the interpreter, which makes writing the interpreter much easier. Error checking is also performed by the virtual processor to ensure that the SCORPIO hardware is not damaged accidentally by an SCL program. A prime example where error checking is essential is the movement commands. If a leg is activated for too long, or not given enough time to return to its original position, the nitinol wire actuators can be severely damaged. In this case, only the interpreter controls how long the leg is "turned on" and also waits for the leg to return to its original state before executing the next instruction. Therefore, the hardware is protected from any accidental damage that could be directly caused by an SCL instruction. The monitor program controls the main processes of the SCORPIO robot. It is the routine executed upon powering up the device, and it has the task of initializing all of the registers, timers, and interrupts required for its operation. At this point the monitor waits to receive a command via the modem connection. Data transfers for the modem are handled by using the XMODEM-CRC protocol. The protocol was chosen primarily for convenience; as there are many PC-based communications packages available that use this protocol, only the 8051 portion of this code had to be implemented. The procedure for writing and executing a SCORPIO program is straightforward. First, a PC platform is used to develop the SCL program code in a text editor. The SLA assembler takes the code and converts it into an object file containing interpreter instructions. The XMODEM-CRC protocol is used to transfer the object file to the SCORPIO robot. This is done by instructing the monitor to load the data it receives into a specified location in memory. Finally, the monitor invokes the interpreter, thereby executing the program controlling the robot. 5. Conclusion The effects of the codesign process used in this course are evident in the results: Figure 3 shows the assembled SCORPIO robot, which is now operational. The students successfully implemented their design decisions. As part of the experience, the students were required to write technical papers describing their project along with the traditional documentation reports. Their papers have been accepted for publication in a book to be published by IEEE Press on nitinol-powered robots. This exposes them to another aspect of design: communicating the results of research with one's professional colleagues. The students worked effectively as a group, with progress being made concurrently in both the hardware and software areas during the tenure of the course. The anonymous reviews submitted at the end of the course attest to the student's enthusiasm for classes of this type. They found the openness of the class to be beneficial to their efforts. They were able to test their design and knowledge capabilities according to productivity and accomplishment instead of scores derived from homeworks and exams. The experience of having an integrated hardware and software project was found to be a positive one. On one of the course evaluation sheets, a student wrote that "[t]his class was very useful in learning what real engineering is all about." The course has incorporated many features considered as vital portions of the computer science and engineering design curriculum [11]. The problem selected was open-ended. Students were required to formulate the design problem statements and specifications. Various solutions were considered with regard to such factors as cost, feasibility, and reliability. Detailed system specifications were produced, and good communication channels in the form of oral presentations and written documentation were established in order to adhere to the specifications. One of the benefits of having a class undertake such a project is that it exposes them to real-world issues. Students have to look at such things as the efficiency and the cost of the design. The open-endedness of the problem gives students the opportunity to apply creative solutions to each portion of the problem. It also allow students to obtain a greater view of how the hardware and software components interact. The codesign process is ideally suited to students in a computer science and engineering curriculum. Their knowledge of both computer science and computer engineering allows them to possess a deeper understanding of the overall situation, thereby allowing for more informed decisions to be made. This exposure to the codesign process will be a valuable tool in their future careers. References [1] G. Borriello, K. Buchenrieder, R. Camposano, E. Lee, and W. Wolf, "A D&T Roundtable: Hardware/Software Codesign," IEEE Design & Test of Computers, Vol. 10, No. 1, pp. 83-91, March 1993. [2] D. E. Thomas, J. K. Adams, and H. Schmit, "A model and Methodology for Hardware-Software Codesign," IEEE Design & Test of Computers, Vol. 10, No. 3, pp. 6-15, September 1993. [3] S. Kuman, J. H. Aylor, B. W. Johnson, and W. A. Wulf, "A Framework for Hardware/Software Codesign," IEEE Computer, Vol. 26, No. 12, pp. 39-45, December 1993. [4] P. Subrahmanyam, "Hardware-Software Codesign: Cautious Optimism for the Future," IEEE Computer, Vol. 26, No. 1, p. 84, January 1993. [5] G. De Micheli, "Extending CAD Tools and Techniques," IEEE Computer, Vol. 26, No. 1, pp. 85-87, January 1993. [6] J. Mills, "Stiquito: A Small, Simple, Inexpensive Hexapod Robot," Computer Science Department, Indiana University, Technical Report No. 363a, September 1992. [7] R. Gilbertson, Motorless Motion! Working With Shape Memory Wires, 2nd ed. San Anselmo, CA: Mondo-tronics, Inc., 1992. [8] T. Sperry, "Tools for 8051 Development," Embedded Systems Programming, Vol. 6, No. 3, pp. 49-60, March 1993. [9] Intel, Embedded Microcontrollers and Processors, Volume 1. Mt. Prospect, IL: Intel Corporation, 1992. [10] J. Ganssle, The Art of Programming Embedded Systems. San Diego: Academic Press, 1992. [11] T. Booth, T. Brubaker, T. Cain, R. Danielson, R. Hoelzeman, G. Langdon, D. Soldan, and M. Varanasi, "Design Education in Computer Science and Engineering," IEEE Computer, Vol. 19, No. 6, pp. 20-27, June 1986. ===================================================== .start 0000 31 0A START: STS #0A ;set step- size to 10 0002 01 28 FWD #28 ;forward 40 steps 0004 11 0F RGT #0F ;turn right 15 steps 0006 97 00 LOOP: LDA #00 ;clear the accumulator 0008 48 CA B0 JSR &CAB0 ;jump to 8051 subroutine at CAB0h 000B A1 32 CMP #32 ;compare the accumulator to 50 000D 71 04 JEQ STOP ;stop if they're equal 000F 00 FWD A ;forward # of steps in accumulator 0010 42 F5 BCH LOOP ;loop again 0012 40 STOP: RET ;return to monitor .end -- Labels -- START - 0000 LOOP - 0006 STOP - 0012 Figure 2. Example of an SLA listing file containing SCL code.