RObo Dog

Introduction

The project, “Robodog?is an autonomous car that follows sound. The car can follow almost any audible sound that human can create by using three onboard microphones. This project was possible because of the fact that the speed of the sound is relatively slow compare to the MCU.

We took apart an old remote control car and replaced the internal circuit with our own driving circuit. For the sound detection, we used three ordinary omni-directional electret microphones.

High Level Design

We picked this topic for our project because we wanted to make something that anyone can easily use. While remote control cars are very common, sound controlled cars are not, because of the complicate issues involved with sound processing. However, us people cannot create radio frequency signal! So we thought that it will be very interesting to design a car that can “hear?human voice.

Preparing for the project, we thought about using the difference of the sound intensity (power) through the different microphones depending on the distance from the sound source. However, we found out that it was not a good idea because the intensity of the sound decreases in quadratic fashion with distance, which meant that the car can only detect the direction of the sound from very short distance (2 or 3 feet away). Talking to the professor and the lab instructors, we realized that the speed of the sound is very slow relative to the speed of the MCU. Using this fact, we came up with an algorithm which computes the direction by looking at which microphone received the sound first.

We hoped to design a car that can approximately locate the sound source after hearing the sound once, but we failed to do that because of issues such as the sensitivity of the microphones, the attenuation of the sound, the reflection of the sound, etc. Instead, we designed so that after calling the car, the car moves for certain time in one direction, stop, then waits for the sound again. So it takes a couple of moves until reaching the caller.

[Figure1. Sound Wave Propagation]

We wanted to be able to control the car from fairly long distance. Since the signal from the microphone is very small, we used amplifier with high gain. Also in order to block out low frequency noise, we used a two level low frequency filter to filter out the noise.

[Figure2. Block Diagram]

Program Design

Direction Detection

The most important part in detecting the direction of the sound was the speed of ADC. We needed the MCU to carry out ADC from 3 pins switching back and forth in maximum speed. The microphones were approximately 30cm away from each other, which meant that the maximum time the sound takes from one microphone to another was about 1ms. Since we did not need good quality of the sound, we ran the ADC at the speed of 16MHz/64 = 250kHz. Using ADC interrupt, we switched the pin and ran the ADC for all three microphones. Upon finishing ADC, we looked at the value and checked if any of the converted signal was over a certain value, which we picked by trial and error. If none of the microphone signal was over the value, which meant that none of the microphones received sound, we ran the ADC again. If only one microphone signal was over the value, it meant that that microphone received the sound first, hence it is the closest to the sound source. Then we stopped the ADC and drove the car in the direction corresponding to the microphone, which received the signal.

Driving the Car

Since we took out the original circuit in the RC car and made our own circuit, we had to write the program that can control the car correctly.

Rear Motor

The rear motor was relatively easy, since it was setup to drive in only forward direction. It was controlled by setting a pin (PORTB.7) high to drive and low to stop.

Steering Motor

The steering motor gave us the most trouble. There are two signals associated with the H-bridge, which controlled the motor. The first one was the direction (0: Left, 1: Right) and the second was for the PWM signal, which basically turned on and off the motor. There were two major problems, which arose from the mechanics of the car,

Once the car steered to one direction, the wheels would stick to that position until some kind of external force was applied.
Different force was needed for steering in different direction because of the motor was closed to left wheel of the car than the right.

To solve these issues, we set up a timer to control how long we were going to apply the signal to the motor. In order to get the wheels to the correct position, we found out the time we need to apply the signal by trial and error and to get the wheel back to the original position, we applied opposite direction for a set amount of time, which also was found by trial and error. For the second problem, we applied the signal for different amount of time for different direction of steering.

Hardware Design

Sound Processing Unit

The voltage output from the microphone was very small, in the range of 10mV. In order to detect the sound, we built a high pass amplifier using LM358 op-amp. High pass filter was chosen to filter out the low frequency background noise such as 60Hz noise. Simple RC high pass filter was cascaded to improve the performance. The signal out of the filter was biased to approximately 3V in order to bias the amplifier at the high gain region, since we were using single 9V power supply for the op-amp. The op-amp was set up as non-inverting amplifier with gain of approximately 200. The output of the amplifier was connected to the voltage protection circuit consisting of a resistor and two diodes to prevent voltage going above 5V or below 0V, which can harm the MCU.

Motor Driving Unit

The driving unit consisted of two major parts; rear motor driver and steering motor driver.

Rear Motor

The car was setup to go only forward. For that, the only circuit we needed was the opto-isolator circuit to protect the MCU from the voltage spikes of the motor.

Steering Motor

The steering motor had to be able to change the direction of the rotation in order to steer the wheels, for which we built an H-bridge circuit. We first tried using LMD18200 H-bridge that we sampled, however, LMD18200 needed at least 12V to operate and the packaging of the component needed a special board, which caused some difficulties. Our H-bridge consisted of 4 transistors (TIP31, TIP32) with 4 input resistors. There was a diode connecting the emitter and the collector of the BJT to prevent negative voltage. The H-bridge operated with 6V power supply and has 4 inputs which were, FORWARD, ~FORWARD, REVERSE, ~REVERSE. Theses input signals were created from a digital circuit, which took the opto-isolated DIRECTION and PWM signals from the MCU and created above signals.

The H-bridge took these signals and outputted 2 signals, which were connected to the motor. The opto-isolation was needed since the power supply of the digital circuit and the H-bridge was different from the power supply of the MCU. The 5V power for the digital gates was created by connecting a 1N4001 to the 6V power supply from the 4 AA batteries of the car, which caused a voltage drop of 0.7V, providing 5.3V power.

Results

The speed of execution was very quick as expected. The microphones picked up the audio signals every time and the car would immediately respond. The only mechanism slowing the car down was a delay we put in to ensure that the microphones do not react to the noise from the motors while they are in operation.

The accuracy was also very good. The proper microphone consistently picks up the correct direction of the signal. The car could only go forward, right and left, which limited the movement of the car a little. One of the things that we wanted to fix was the large turning radius of the car, which caused for somewhat wide turns.

Safety was not a major issue for our project. There was no human contact with the car during the operation, so most safety considerations are avoided. The wires are taped down to prevent anything from coming loose during the operation. The range of operation is about 10 meters, so there is always needs to be an operator within that distance for the motors to run. Also, the car, after hearing the call, only moves for 1 second, so even if the car collided with other objects, it was not critical.

Interference from other projects was not a problem due to the filters we used before the amplifiers input. Background lab noise did not cause the car to operate because the audio signal needed to go over the voltage threshold to trigger the car. However, constant clapping and whistling of certain “malicious?individuals such as Eric to trigger our car did become a bit of interference.

The usability of our project is very good. Any person with a voice or who can clap can operate the vehicle. There was no training needed to operate our car.

Conclusions

The results of our project exceeded both of our expectations. Our original goal was to get a range of about 5 meters. The real range is approximately 10 meters and maybe further depending on the intensity of the signal. Although we ran into a lot of small battles in designing this project, if we have to do it over, we will design the project again in the similar fashion.

There are no standards that needed to be followed since we used signals in the auditory range to control the vehicle.

The code we generated were totally original, the hardware aspects we learned about are also available in the public domain. The project was inspired in part by the Blind Bot project of ECE 476 Spring 2004. ECE 476’s labs were referenced for our hardware. (H-bridge, opto-isolator) We do not believe that our project probably has a patent opportunity.

Ethics

...to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment; Our projet was in any way dangerous or harmful to the public. The way of calling the car did create some level or noise, but we are pretty sure that almost everyone enjoyed our whistling. Our only worry is endangering the job of canine species as pets, because our car was so good!
...to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;To our knowledge, there was no other group who were working on the similar project. Within our group, we were both very excited about the project.
...to be honest and realistic in stating claims or estimates based on available data; We did not in any way manipulate the result of the project or over exaggerate our result. Even though we started out with a larger claim, as we experimented with various options, we were able to bring down the claim to more practical level. In fact being honest and realistic were about the only things we had going for us for about the first three weeks; it didn’t work and we didn’t know why.
...to reject bribery in all its forms; To our knowledge, we did not receive any bribery of any kind. I know for sure that I didn’t get paid at all for this project, I have to check with my partner though; he just bought a Dodge Viper now that I think about?/font>

...to improve the understanding of technology, its appropriate application, and potential consequences; Through the project, we learned to approach and conquer a set goal, by following the process of planning, analyzing, experimenting, simulating, debuggin, etc. It was a valueable time for us because we learned how to integrate our previous knowledge on different technology into a solid project.

Appendix

Commented Program Listing

Link to the code (Microsoft Word file)

Schematics