Robot Construction Log

[FIFO]

    For the past year I have been working on constructing the robot described in the 1979 book
How To Build Your Own Working Robot Pet by Frank DaCosta, and I thought that you all
might like to see some pictures of it. The purpose of the robot as described in the book is to
imitate a dog, and so when completed it will be able to navigate a room with sonar, respond to
voice commands, and issue electronic barks. The reason that I decided to build this robot is because
it uses older technology.

    Right now I only have the body constructed, but soon I will be able to start work on the
electronics which will consist of several linear IC's, 74xx series IC's, an Intel 8085 CPU, and
three Intel 8155 CPU peripheral chips. As you can probably see from the pictures, the electronics
will mostly be constructed by wire wrapping with the exception of a few PCBs.

    Hopefully you all will find this interesting. I will post updates as I make more progress, but it might
be some time till I can work on it because of school.

I have attached two pictures below which hopefully you will be able to see.

[mklrobo]

  Cool!   
If you are going to make it resemble something, may
I suggest, K - 9 , modeled from the science fiction show, Dr. Who.
(Everybody knows Tom Baker was the original Dr. Who)
There seems to be empy parts in your robot for expansion, or
to carry things, like, books, food, remote, DVDs, etc.
I would like to ask a question, where permissible; Where did
you acquire your voice command software/IC chips?
I appreciate your help. 

[FIFO]

There seems to be empy parts in your robot for expansion, or
to carry things, like, books, food, remote, DVDs, etc.

    About half of the large empty space in the main body of the robot will be
taken up by two 6v lead acid batteries. The reason I am using lead acid
batteries is that the main drive motor will require over an amp of current,
and the robot is designed to run for several hours at a time.

I would like to ask a question, where permissible; Where did
you acquire your voice command software/IC chips?

    Since the technology I am using is relatively old, the voice command system
is very crude. The operator starts by singing a reference pitch, and then sings
four data pitches. If a data pitch is higher than the reference pitch, than it is considered
a one, however if it is lower, it is a zero. For example if the operator were to sing a
reference pitch, and then to sing two low pitches followed by two high pitches,
the data would be interpreted as binary 0011, or three in decimal. The different numbers
would be mapped to different functions for the processor to call. The circuit is composed
eight TTL logic chips, a 555 timer, and a transistor amplifier and is hard to describe with
out the schematic, however if you are interested I will post the schematic with an explanation.


   

[mklrobo]

  cool!
Your info;
The circuit is composed eight TTL logic chips, a 555 timer, and a transistor amplifier and is hard to describe without the schematic.
Works for me! I understand your intent. The high or low frequency is detected,
then initiates a logic low or high, stacking on the bits until the complete command
data byte/word is formed. Awesome!
I did something like this with transmitting data, in an analog way. confusing?
I made a data transmission method, I call Morse Tone, which tones are used on a frequency of 150 Mhz to pass data. four tones give a binary byte to transmit data, decoded by a common DTMF decoder. The decoded tone is "weighted" to a MCU to provide a data bus. It works well at slow speeds, but can be used very long distances, or locally. I have not tried a faster
decoder, but I assume it could be used at faster rates.
Thanks for your info. 

[Ibaeni]

I'd agree with the comments about K-9. It'd be a cool addition to the project to create an outer case similar to K-9, if you're a fan of the show.

[FIFO]

 

I'd agree with the comments about K-9. It'd be a cool addition to the project to create an outer case similar to K-9, if you're a fan of the show.

   
    That is a good idea and I will definitely consider doing that, however I would like to get the robot working before I work on the aesthetics.

    I have made some progress on the robot and have been able to etch and solder two of the PCBs for the robot. The first one pictured is a voltage regulator circuit, and the second is a relay board that will allow the processor to interface to the motors.

    The voltage regulator is a LP3852 low dropout linear voltage regulator. With a price of four dollars it is not cheap, however its characteristics made it extremely desirable for use in the robot. One of the features that makes is valuable is the fact that the dropout voltage is only about 250mV when driving a 1.5A load, allowing me to use the 6V batteries I was planing on using in the robot.

    I also learned something new about relays, and unfortunately I learned it the hard way. When selecting relays, I tried to find some that was both cheap and would not require a lot of current to drive. After I found some that seemed adequate, I constructed the PCB and soldered the relays only to find that the relays would not activate. After checking the data sheet for the relays I found that they was described as a high efficiency relays. I did some reading online and found that some high efficiency relays use permanent magnets to make it easier for them to switch and are therefore polarized. I was then able to modify the PCB to fix the polarity issue with the relays.

[bdeuell]

very interesting about the high efficiency relays, I was not aware of the use of permanent magnets in relays.
thank you for sharing.

On the topic of using older electronics technology and voice recognition I saw this video a few weeks ago on a voice recognition chip (apparently designed with robots in mind) http://www.eevblog.com/2015/02/11/eevblog-713-vcp200-voice-recognition-1980s-style/. Im not sure if you can still find the chip shown or a substitute but you may find it relevant.

[FIFO]

    It has been some time since I have posted, but since then I have been able to finish the electronics portion for the robot's steering system.

    The robot uses a very crude but hopefully effective servo system to steer. From the attachment you should be able to see that the system consists of five main parts: the feedback potentiometer, the ADC, the magnitude comparator and finally the processor.

    You might be able to see in the first post, a picture of the potentiometer, coupled with the use of gears, to the steering column. The potentiometer is used to get position feedback from the steering column. The analog signal is the sent to the ADC and converted to a 4-bit binary number. When the steering column is in the left most position, the ADC reads 0000, and when the column is full right, 1111.

    The ADC’s output, which represents the steering column’s current position, is sent as one input to the 4-bit magnitude comparator. The processor sends a 4-bit number, which represents where the processor wants the column to turn to, to the other input of the comparator. The comparator compares the two numbers, and outputs its results to the relay board which controls the steering motor. If the input from the processor is greater than the input from the ADC, then the steering motor turns right. However, if the input from the processor is not greater than the input from the ADC, and they are not both equal, then it must be that the input from the processor is less than the input from the ADC and so the steering motor is commanded to turn left. Finally, if the input from the processor is equal to the input from the ADC, than the steering motor is commanded to stop.

    Since this explanation is a little messy, I will give an example of how the servo system should operate. Lets say that the steering column is in its left most position, and the processor wants to steer the robot straight ahead. The ADC would convert the voltage from the potentiometer, and would output to the comparator binary 0000. The processor would output to the comparator binary 0111, which represents a steering angle that is pretty much straight ahead. Since the number from the processor is greater than the one from the ADC, the comparator commands the motor to turn right. As the steering column turns right, the potentiometer turns and so the output from the ADC increases from 0000. When the column is directed straight ahead, the ADC reads 0111, and since that number equals the number from the processor, the comparator commands the motor to stop.

    It should be noted that the diagram attached below is simplified. For instance, the ADC and magnitude comparator are constructed out of 74xx series logic ICs, an op-amp, a resistor ladder, and a voltage comparator. The circuit was a little complicated for me and I did not know if I could explain it clearly. The circuit is interesting however, and if you would like me to post it, I will give it a shot.

[FIFO]

    I have just completed a major portion of the robot's sonar system. I have attached two files to this post, the first one is a photo of the main sonar PCB, and the other file is its schematic. The PCB contains three identical sonar reception circuits, each of which consist of a two stage amplifier, to boost the weak echo of the returning ultrasonic pulses, and a tone detector circuit, to distinguish the 40khz ultrasonic pulse from other signals that may have been amplified.

[FIFO]

    I have made quite some progress on the robot. I have constructed the head and have mounted the sonar PCBs and ultrasonic transducers into it. I have also constructed most of the circuitry for the voice command system. I have also run into several new problems. I have found that the steering gearhead motor keeps stripping its teeth. I believe this is happening because the servo system causes the motor to start and stop rapidly and the momentum of the steering column causes the motor to turn when the motor is being electrically braked, and the force causes the gears in the motor to strip. I could solve this by getting a gearmotor with stronger gears, or get one that has a higher gear reduction and therefore turns more slowly, but that would mean that I would have to machine new mounting brackets and a new coupler to fit the motor. Instead I am probably going to design a PWM circuit so that I can run the motor at slower speeds.

    I also ran into some difficulty with the voice command system. As explained in a previous post, the "voice command" system works by comparing the frequency of notes sung by the operator. The problem I have run into is that the circuit "thinks" that lower notes sung by the operator are much higher than they actually are. This is because the circuit is counting the frequency of the strong harmonics present in the lower notes of the human voice. I need to figure out a way to filter out the higher harmonics of a lower note, but then not filter out higher notes sung by the operator.

[mklrobo]

  Hello!
In reference to the audio filters;
You can use roll off filters, such as high pass, and/or low pass. These can be simple
resistor capacitor combinations. If you want a specific frequency to pass, with a high Q,
you can use a twin - t operational amplifier circuit. To make sure your circuit is performing
like you want it too, you would need an oscilloscope. I would recommend a Velleman
PC oscilloscope, PCSGU250. 12 Mhz bandwidth, with oscope, function generator, spectrum analyzer,
transient recorder, and bode plotter. At $150, quite a deal, compared to the competition and their
functionality. Good luck! 

[FIFO]

     It has been a while since I have posted, but since then I have made a lot of progress on the robot. I have finished 3 PCBs, and have added a power switch, a reset switch, and programming port to the robot. I also reinforced the steering column and drive motor with aluminum angle stock.

    The first PCB is an amplifier board. This board amplifies and filters the signal from the microphone, and also amplifies the audio produced by the robot's bark generator.

     The second PCB is an automatic programmer for the robot. The robot's memory consists solely of RAM, which means that whenever the robot's power is cycled, the contents of the memory are lost, and so the robot must be reprogrammed. The book's solution to reprogramming the robot quickly,is a tape interface. This allows the robot to store its program on a cassette tape, and then when needed, load it back into its memory. However, the circuitry for the tape interface is larger, and more complicated than the main board on the robot, and so I decided to design a simpler more compact solution. I ended making a simple board with a flash based AVR microcontroller that is able to load a program into the robots memory. I find it a little ironic that I used a relatively modern microcontroller, because in the rest of the robot, I have been mostly sticking to using parts that would be available in the 70s, as used in the original project.

    The last PCB is a manual programmer for the robot. It allows me to manually load a program into the robot's memory. It consists of two 4-bit counters, two 7-segment display drivers, a 555 timer, and a few buttons and switches. It is very painful to use this device to program the robot, because to load a single instruction, I have to setup the address, then latch the address, then setup the data, and then finally write the data to memory.

    Now that I have nearly completed the robot, I will attempt to program the robot, and debug some problems on the robot's main board.

    -FIFO

[Aaroneus]

I think what you are doing is awesome! I read How to Build Your Own Robot Pet in high school and it set the standard for me in terms of what to expect from a personal robot.

It would be great if someone would rewrite the book, using current components and technologies. Tech has advanced since then, however many of the capabilities such as tonal commands are still feasible and excellent ways of interacting with a robot. There are components that the hobbyist can use that would ease the pain of implementation.

Keep up the good work! Keep us posted!

[FIFO]

    When the robot powers up, the robot will by default drive in reverse. I have been trying to load a small program that would write to an I/O port that would cause the robot to stop, however, so far I have been unsuccessful.

    The first things I thought of when I could not get the robot to work was that the programmer might not be functioning correctly. I then removed the I/O chip and attached LEDs to the address/data buss, address latch pin, and the write pin and confirmed that the programmer was functioning properly.

    The 8085 CPU has a 16 bit address and a 8 bit data bus that is internally multiplexed with the lower 8 bits of the address bus. The two most significant bits of the address bus are decoded to select one of three 8155 I/O and RAM chips. The next problem I suspected was that the decoder was not wired properly, and that the 8155 chip that I was trying to write to, was not being enabled. After examining the decoder, I noticed that I had wired it incorrectly (it turns out that the mistake was due to a typo in the book). I then corrected the mistake and tried to reprogram the robot. I also confirmed that the motor drivers, that the 8155 interfaces with, were functional.

    The robot was still running in reverse, so I then suspected that the code I was loading into the robot was incorrect. After reading the data sheet for the 8155 and reading the book more closely, I realized that the code was indeed wrong, so I fixed the code and reprogrammed the robot.

    The robot was still running backwards, so I wondered if the code was not being executed because the non-maskable external interrupt, TRAP, was being triggered, and causing the CPU to jump to the ISR. I then measured the voltage on the TRAP pin, and confirmed that it was not causing an interrupt.

    I then suspected that voltage rail was below the minimum level for the 8085 and the 8155s. I checked the data sheets and found that while the voltage was a bit low, it was well within the 10% tolerance required by the chips.

    The next thing that I thought might be the problem was that I did not have any decoupling caps on the 8085 and the 8155s. I then added 0.1uF decoupling caps to those chips, but still the robot drove in reverse.

    I am running out of theories as to what the problem might be caused by, however I still have one idea. I purchased the 8085 CPU new, however the 8155's were used. Their leads are clipped short, and there are traces of solder left on them. I am now wondering if the 8155s are in fact functional, or that maybe I damaged 8085 when I was constructing the robot. The next thing I will be looking into is a way to test the chips.

    I have included top and bottom pictures of the main board below.

    -FIFO

[FIFO]

I think what you are doing is awesome!

Thanks!

    So I have been testing the 8085 CPU and the 8155 peripheral chips. As of now I have not been able to get the 8155s to work, however I have tested the 8085 and it seems to be working (I checked the A/D lines and the Read, Write, IO/M, and Address latch lines with an oscilloscope, and they seem to be operating correctly).

    I also read the data sheet for the 8085 again and found that a RC network was needed on the reset pin, and that a capacitor was needed on the 3 MHz crystal, so I added them, but it did not fix the problem.

    When I was examining the chips, I found that the 8085 marked 8085A, and that two of the 8155s were marked 8155H-2 and the other was marked 8155HC. It turns out the H in 8155H-2s signifies that they are HMOS versions of the 8155, and the 2 means that they are faster versions of the 8155. I am now wondering if I have a compatibility problem with the 8085A interfacing to the 8155H-2s.

    I still have more testing to do on the 8155s, but if I can't find the problem, I will probably post on some EE forums to see if anyone has any ideas as to what is happening.

    -FIFO

[mklrobo]

  Hello!
Awesome work! I have tried also to use the wire wrap direction, and found that the wires acted like
antennas, with the bus speeds. This put out a lot of noise, and loaded down my CPU with a fanout rate.
I did not do a good of job like you have, but only present this as a possibility. Good Luck!! 

[FIFO]

   

I have tried also to use the wire wrap direction, and found that the wires acted like
antennas, with the bus speeds. This put out a lot of noise, and loaded down my CPU with a fanout rate.

    Yeah, I thought that might be a possibility, but I am not experienced enough to know if it is an issue in my case or not. Just to be sure, I set up a test jig for the 8155 on a breadboard, and tried to write to it slowly using an Arduino board. That proved to be unsuccessful, and after several other attempts, I came to the conclusion that the chips were dead.

    I ordered some new ones off of Ebay, and tried to write to those using the same test setup, however I was unsuccessful. At that point I began to doubt whether my test setup was correct, so I installed one of the new 8155s on robot.

    Previously, when I still was using the refurbished chips, I had attempted to program the robot using the manual programmer. It turns out that I had wired it incorrectly, and the address/data bus lines were mixed up. Instead of attempting to fix the programmer, I tried to use the automatic programmer which I thought was working. However as is evident from my previous posts, those attempts proved to be futile.

    Now that I had installed the new chip on the robot, I attempted to program the robot with the automatic programer, but that was ineffective. At this point I thought that the automatic programer might have a problem, so rather than try to debug its the hardware and code, I fixed the manual programmer and housed it in a tea tin. (Previously I had it in a cardboard box, but it looked really suspicious with wires hanging out, a red 7-segment display, and a bunch of red buttons, so I decided that I should make it a little less threatening.) I then used the manual programmer to program the robot to simply stand still, (if you remember, in its naturally unprogrammed state, the robot rolls backward,) and when I was finished, the robot did not move, indicating the the programming had been successful.

    So it appeared that the new chips and the manual programmer worked, but that the automatic programmer did not. The next day I attempted to program the robot again with the manual programmer, but the programmer acted erratically. Since then I have tried to repair it, but have had little success.

    Attached to this post are two pictures of the manual programmer. To operate the programmer, the programmer is first plugged into the back of the robot. Then the two toggle switches directly under the display are used to select which chip to write to. Next, the address to which the data is to be written is set up using the two red buttons on the right side of the programmer. Once the correct address is selected, the button on the top left of the programmer is pushed to latch the address. Then the two buttons on the right side are used again, except this time, to set up the data to write to the address that was previously latched. Once the data is set up, the bottom left button is pushed to write that data.

[FIFO]

    I have been doing some debugging of the programer, and have discovered something very interesting.

    At first I thought that the manual programmer might not have been functioning properly because the supply voltage was too low. I thought this might have been a problem because the programmer is powered by the robot through some relatively long wires, and I thought that the voltage drop might have been enough to drop the supply rail below the tolerance of the ICs in the programmer. I then measured the supply rail at the programer, and while it was low, it was not below the minimum required by the components.

    Even though the supply voltage was in tolerance, because the supply was a little low, I wondered if I increasing the voltage might solve the problem. To test to see if this would work, I removed the main board, (which draws a lot of current and causes the voltage rail to dip a little), and attached the manual programmer. After some testing, it was clear that the programmer was functioning without error. I then measured the supply rail in the programmer, expecting to see a higher voltage, but to my surprise, the rail was only about 30mV higher.

    I now strongly suspect that the main board is somehow interfering with the programmer which is why it is acting erratically.

[FIFO]

    I have finally identified and fixed the problem. Both the manual and automatic programmers put the 8085 into reset when they are being used to write to the 8155s. When 8085 processor is in reset, it tri-states the data/address bus, and the control lines, including the read (active low) line. I assumed (incorrectly) that the 8155 peripheral chips would see the tri-stated read line as a high, and so I did not bother to have the programmer tie the the line high when it was being used to write to the 8155s. Since the tri-stated read line was actually seen by the 8155 as a low, the 8155 pushed its stored data onto the bus, while at the same time, the programmer was pushing the data it wanted to write to the 8155 onto the bus. This bus contention made it impossible to write to the 8155s, and thus program the robot.

    After I figured this out, I tied the read line high when using the manual programmer, and loaded a short program into the robots memory, to make it stand still. It was successful so I tried to load the same program with the automatic programer, and that also worked. Next I attempted to program the robot using the refurbished 8155s that I though were broken, and they worked. At that point I was feeling pretty stupid, but I was glad that it was finally working.

    I have been experimenting with more complicated programs to test the various circuits on the main board, and so far things have been relatively successful. I was having some issues with the 8085 resetting every so often, especially when main drive motor started, but after adding some decoupling and bulk capacitors, the problems disappeared.

[FIFO]

    A while ago I posted a more polished project description of this robot along with some better pictures on the EEV Blog Forum, as a way to bring the project to a close. I linked back to this thread as the build log, but I guess I forgot to post a link here to the write up on the EEV Forum, so here it is: http://www.eevblog.com/forum/projects/1970's-robot/

[FIFO]

The link above is now broken, here is a new link: https://www.eevblog.com/forum/projects/1970_s-robot/

[FIFO]

Thank you! I have a short video clip of it running here (at the end of the article): https://ezrasrobots.wordpress.com/2016/12/03/the-robot-pet/

I also have a new version here, called Pet on a Chip, where I condense all of the control logic and a custom CPU onto an FPGA: https://ezrasrobots.wordpress.com/2021/07/07/pet-on-a-chip/

[mklrobo]

  Totally Awesome!!   

     I love the "pet on the chip" vernacular!!! how about chippett? or petrick?
Just some work play on your project statement.

    your documentation is awesome, and very precise. I love reading the manuals,
and seeing where it all fits in.

    Awesome job!!!   

[FIFO]

Thank you! I took a lot of time to make things really clear. Now I'm trying to figure out what to make next. I was considering trying to develop a high level language and compiler so that it would be easier to program the robot. I don't know very much about that, but it seems like it would be fun.

[mklrobo]

   Excelsior!!   

     Hello again!

     In reference to your high level language, may I humbly suggest Python?
Reason being, Python is "bound" to about every language there is, and
a language that you use on you robot would set the stage for other
people to access and build a robot like yours in a friendly, familiar
platform.
    This would allow you to access other resources as your robot project grows!   

   Good luck!