MARVIN:

A Robot from a TI-92

Chris Lambert

Aaron Wright

Copyright © 1999

Do not duplicate or distribute this report in part or in its entirety.

This report is to be used as informative only. Do not use any information in this report for building your own robot or any other device, or for writing an interface with such a device, without permission from the writers.

The Marvin project started in Fall of 1996. Inspired by the question "Why do you want to be an engineer?" asked by Dr. Gidley of Geneva College, Project Head Chris Lambert decided to get some people together to build a robot out of a 80386-40 programmed in QBasic. The robot’s functions were to be simple, basically move around controlled by a remote computer. This project died hard when shortly after the software was completed, the hard disk failed and it was all lost.

In Spring of 1997, the project was started up again, this time with six members instead of three. The new hope was the TI-92 graphing calculator from Texas Instruments. Using a chip that uses a 68000 core running at 10MHz, the TI-92 would be perfect. There were several reasons to use the TI-92. Chris Lambert had the most knowledge of digital logic at the time; he knew what an AND gate was, and that was about it. Since this was a pre-built system, it would be much easier to get working. In addition, the screen would be wonderful to display error messages for debugging and any other feedback from the program. The keyboard would be a very useful tool for input into the system by the user. The serial port on the TI-92 would make it very easy to transfer data to and from a computer for either a remote control (which is also pre-built into the calculator) or sending program code. Fargo, a hack on the TI-92 which allows the calculator to run assembly (written by David Ellsworth), was available as well as extensive debugging software designed for complicated assembly games. The biggest reason is because it gave us hands-on experience with a real full microprocessor on a beginning level.

Beginning level… well maybe not. Immediately the team began to dream. They began to invision tanks and hovercraft and other such vehicles run by TI-92s. They went to Dr. Kim, Electrical Engineering Department of Geneva College to ask about facilities that were available for personal use. It was at that point that the idea of entering into Region 2 IEEE Hardware Competition Summit Challenge at West Virginia University arose. The team agreed to try. Texas Instruments graciously donated four TI-92s, and Marvin Jr. was built. Functioning at less than what was hoped for, the team struggled during the last few hours before the competition. The robot was placed on the arena and actually moved. Marvin Jr. made it all the way to the final round and came out in second place.

The Marvin Project continued. The following year, a more advanced version of the robot using the same conceptual design and far better parts was underway. Software was rewritten, and the only physical parts salvaged from Marvin Jr. were a gear and a few voltage regulators. A puff of smoke and a fried TI-92 later, a second robot named Marvin Luse Wiar was moving around the board. Luse gave the team (which most of the time was actually only one member, but at times was three members) more headaches over loose and broken wires than can be imagined. If anything went wrong, its guaranteed it was a loose wire. Luse’s most challenging problem was not a loose wire however, but electromagnetic emissions from the ball collector motor. This caused major problems with the weak signals coming from the infrared sensors. Several motors were tried and one from a tape deck (designed to not give off any noise) was eventually used.

So Marvin Luse Wiar worked.

Design: Chris Lambert and Aaron Wright

Built: Chris Lambert and Aaron Wright

The Ball Collector works like the brush on a vacuum cleaner. The balls are "rolled" up off the floor and into a tray three inches above the playing surface. The original design used a large gear and a worm gear to spin the roller, but this caused way too much vibration and was very loud. This motor also emitted a decent amount of electromagnetic fields. These in combination caused Luse to skip lines and count lines that were not there.

The motor system was replaced with a racing motor and a belt system. The vibrations were completely gone, but the high-power racing motor dumped out more electromagnetic fields than the previous motor.

The motor was replaced with a motor from a tape deck, and Luse could finally perform all of his functions perfectly.

Design: Chris Lambert and Aaron Wright

Built: Chris Lambert

Aaron Wright thought up the idea of putting a gate in front of the ball storage area to release the balls. The original design was to tip the storage bin so that they would roll out.

The gate uses Muscle Wire ordered from Jameco. When powered, the Muscle wire heats up and shrinks to it’s original length. When it cools, it allows a rubber band to stretch it back.

Design: Chris Lambert

Built: Aaron Wright

One thing that would give a robot extreme power in a competition is to allow add-on devices. Three reed relays are controlled by the TI-92 to operate three devices, literally anything the team wants to run. One device that is making use of this system is the Muscle Wire Ball Gate. Anything from a wench to a speech chip can be attached to these and be controlled from the TI-92.

Design: Chris Lambert

Built: Chris Lambert

The basic structure of Luse is built primarily out of wood. Wood was chosen because it is easy to work with, it is cheap, and it does not conduct (less chance of an accident). The TI-92 and the mainboard are suspended on top of the robot using a ripped up yardstick. The rest of the yardstick was placed vertically on the front of the robot to hold the muscle wire and any devices that might need to be attached. The batteries and the power supply slide in onto a tray directly under the mainboard. In the rear, sticking out of the bottom of the mainboard is the robot interface card. Right in the heart of Luse is the ball collection and storage device. Below the plywood base of the robot are the infrared sensors. Scattered throughout the robot are small circuits running the sensors, diagnostics and the power. Most importantly, there are wires everywhere.

Design: Chris Lambert

Built: Chris Lambert

Two 12V stepper motors each driven by a dual H-bridge (designed by Chris Lambert) and a pre-programmed PIC from Jameco move Marvin Luse around the board. Two-inch diameter plywood wheels support Luse above the ground. Thick rubber bands keep the wheels from slipping on the ground.

The 12V steppers perform well, but no one has liked the fact that there is 12 volts floating around. Late in the building process the 12 volts claimed the life of one of the donated TI-92s, but luckily nothing in the rest of the robot was hurt. A backup TI-92 replaced it and performs well.

The PICs were a good investment, since no one had worked with steppers before. They interfaced very well with the TI-92, giving the programmer the ability to control speed and direction of each motor.

Built: Sam Foster and Aaron Wright

Sam Foster designed and built a very nice auto switching power supply for Luse that regulated a +5 output voltage with a current up to 3 Amps. It used two batteries, and upon the output voltage dropping below 4.6 volts it would automatically switch over to the reserve battery. Dr. Kim thought that this was two much for Luse, and had us build a smaller power supply with two standard 7805 5-volt regulators. This was not able to sustain a high enough voltage when everything on Luse was operating. A third design was then built that consisted of a more simplified version of the original, without the switching capabilities, and was implemented into the final design.

Design: Chris Lambert

Built: Chris Lambert

Design: Chris Lambert

Built: Chris Lambert

The sensor grid has three sections. A forward section, a middle section, and a rear section. The forward section is used to track a line when the robot is moving forward. The rear section tracks a line when the robot is moving in reverse. The middle section tells the circuitry that the robot has advanced a line either forward, back, left or right depending on the mode it is in. As seen in the picture, the forward grid is much more complex than the rear grid. The robot will primarily be moving forward. If it ever gets bumped, it has a lot higher chance of getting back on track using the forward grid than it does the rear grid. The rear grid does not have the ability of the forward grid due to power restrictions and for simplicity since it is not used often.

See next page for layout.

3) Rear sensor grid:

Design: Chris Lambert

Built: Aaron Wright

Except for two pairs of mislabeled inputs, the line tracker circuit (also known as "Aaron’s circuit") worked perfectly on the first try. This circuit reads the sensors and outputs from the TI-92 and does a few things with the information. First, using the outputs from the TI-92 it determines the current mode of the drive wheels (forward, back, left or right). Using this information, it will enable different parts of the sensor grid. In forward mode, it will shut off the appropriate motor to track the lines using the forward grid. In reverse, it uses the rear grid. When it gets a signal from the middle grid, the information is fed into one of four D flip-flops that the TI-92 can read telling it that the robot has moved forward one space, back one space, left a space or right one space. This gives the TI-92 a lot less to think about and makes reaction time instant without bogging down the processor.

The next pages are notes and schematic drawings of the circuit. Note that the middle sensor array was implemented as only three sensors, not eight as shown. The two front (G,K) were combined into one sensor, the four in the middle (H,I,L,M) were combined, as well as the two in the back (J,N).

(Schematic)

This is intentionally blank.

(Equations)

This is intentionally blank.

Design: Texas Instruments

Built: Texas Instruments

The TI92 is the brain of Marvin. The TI92 runs on a proprietary chip that uses the Motorola 68000 core, running at 10 MHz. We overclocked the TI92s that we use in Marvin to 20 MHz (bus speed overclocked from 2.5 MHz to 5 MHz) and have had no ill effects.

The TI92 has several internal functions that Luse Wiar uses. The main interrupt that is used runs once every 18^th of a second. This is used in a couple ways. Marvin will use this for timing as well as running any software interrupts. Chris wrote an interrupt that actually "multiplexes" this interrupt so that different interrupts can be run on the same actual interrupt, even at different speeds.

Design: Chris Lambert

Built: Chris Lambert, Aaron Wright

The mainboard is the board that interfaces with the TI92, and is designed to interface with any other 16-bit microprocessor system that the team would like to use. The prototype version used in Luse was not a full-function mainboard. Luse’s mainboard’s abilities included minimal addressing, minimal serial interfacing, multi-function card support, diagnostics and I/O port enabling. A full function mainboard will have more functions that include a multiplexed serial interface, full addressing for EPROM/RAM support on device cards, a speaker, a buzzer, a more advanced diagnostic system and a latched 16-bit bus monitor.

The TI92 is addressed basically in two-megabyte sections. There is at least one section available in every TI92, but some don’t have a second available section. So basically you can only count on having two megabytes of space. The design Chris decided upon addressed the last half megabyte to the mainboard which re-addressed the first one and a half megabytes to a different card depending which port was active. That way each card that was plugged into a Marvin unit would have one and a half megabytes of addressing space. The mainboard can handle up to thirty-two cards or I/O ports.

Design: Chris Lambert

Built: Chris Lambert

The card that interfaced the mainboard with the rest of the robot is called the robot interface card. This is a multi-function card. It reserves all thirty-two of the I/O ports but only uses two of them. The first port that it uses doubles as a motor interface as well as a diagnostic. This is a full read/write I/O port, enabling the team to test the robot’s bus by writing to the port and reading back from it. If the same value is found, it is working. The motor function of this device also has a little more to it than just motors. Using all sixteen bits of the port, the TI92 can control speed and direction of each individual motor. Luse uses stepper motors, but these are not controlled straight from the I/O port. Two pre-programmed PICs (ordered from Jameco) are between the I/O and the steppers. This allows the TI92 to have an extreme amount of control over the steppers, and at the same time not use much CPU time.

The second port on the robot interface card is the read I/O port used for communicating with the sensors. The port is not hooked up directly to the sensors, but rather to "Aaron’s Circuit" enabling the robot to have asynchronous reading of the sensor arrays as well as use up minimal CPU time.

Design: Chris Lambert

Built: Chris Lambert

There are three basic diagnostic systems built into Luse. The first diagnostic system is on the mainboard itself. It is simply an array of LEDs hooked up to the "port-enabled" signal to each of the thirty-two ports. The way it works is a program will turn ports on and off in a loop in such a way that every port is turned on at some point and every port is turned off at some point. If every light turns on and off when it is supposed to, then more than likely there is not an error in the data bus, and at lease most of the addressing is working. This helps to narrow down any problems that occur. If there is a visible mistake in the pattern of lights, it is obvious where the problem is. If there is no mistake, it is obvious where the problem is not. This information is very helpful during debugging.

The second diagnostic system works in a similar way. This is on the robot interface card itself, and is more extensive. The TI92 will write to the card and read back from the card in a pattern that makes sure that every data line is turned on at some point and turned off at some point. If the values read back to the TI92 match what the TI92 sent to diagnostic, then everything is working. In addition to the first diagnostic, this tests reading as well as writing, and since it is testing an actual I/O port the team can know for sure that it is fully functioning. Another advantage to this system is that it can be put into a loop at very high speeds and continuously test counting all passes and failures. This allows for testing for interferece from other subsystems. Run the test, turn on the subsystem and if the tests begin to fail, then there is too much interference. No subsystem in Luse gave enough interference to cause this diagnostic to fail.

The third diagnostic system is attached to the sensor grid. It is simply an array of LEDs that are wired to the output of the first Schmitt inverter in the sensor grid (see page 5). This allows the team to set the sensitivity of each of the sensors so that it is on while it is over a white area and off while it is over a black area. The team can also see if a sensor ever fails to work properly.

Design: Chris Lambert

Programmed: Chris Lambert

Dayla is the name of the Marvin Operating System. Dayla is written in Motorola 68000 assembly. It is primarily designed to run a user code commonly referred to as the "Dayla script." Dayla in itself is basically a robotics programming language. With "if-then" statements and variable support, this language gives the user far more power than he needs. Dayla script is modular. It is programmed in "tasks," allowing the robot to decide when it wants to complete certain tasks. If it is ever diverted to another location for some reason, it will continue completing tasks in the most efficient way starting from it’s current location. This also allows each robot to have a different "personality," completing different types of tasks before it gets around to others. Luse did not make use of this. Luse was programmed using only one task so that it would run the exact course that was programmed into it.

This is only the beginning. Dayla, on boot-up, auto-scans for the Marvin unit to tell what addressing scheme to use. It then scans memory for any software drivers to use. These software drivers have extreme power. They can run interrupts and/or be called from the script as user-defined functions. Since they are written in assembly, the drivers have all the power anyone could possibly want. All of Luse’s hardware is accessed using software drivers like these.

After software drivers are loaded, Dayla does a scan of all the ports to determine which ports have something attached to them. If there is something at a specific port, it will automatically load the driver which is stored in an EPROM on the card and know how to use it. This allows a robot user to simply plug in any card and have absolutely no configuration to do. The robot will know exactly how to use it. Luse’s hardware was designed to not show up in a hardware scan so it can be directly accessed using software drivers.

Design: Chris Lambert

Programmed: Chris Lambert

The compiler is written in Visual Basic. The purpose of this program is to write Dayla script very quickly using a point-and-click method. This allows for rapid programming of Luse. This compiler is very specific to Luse and the competition.

Here is a screenshot of the program: