align=left]The custom PC board was built to the specifications provided on the ECE 476 web page. An AT Mega32 MCU was placed on the board to allow the robot to run completely independent of the STK500 board. The circuits necessary for the implementation of this project included an opto-isolated amplifier circuit for the DC motor, and the use of two ULN2003 Darlington high-current amplifiers for the stepper motors. Because the stepper motors are run with pulses rather than a continuous stream of current, like the DC motor, an opto-isolated circuit was not deemed necessary. Figure 7 shows the pinout diagram for the ULN2003 chip. Pins 9 and 8 were connected to the positive and negative terminals of the 9.7V battery pack, respectively. Appendix B shows the complete system schematic.



The accelerometer was hot-glued to the center of the foam-board body. With this placement, accurate readings of front and side collisions would be detected. The 9V battery clip was placed off to the side to be able to power both the custom PC Board and the accelerometer. The PC Board can take anywhere from 9V to 12V for power, and the accelerometer uses 3V as its input. With these restrictions in mind, we connected the 9V battery directly to the custom PC Board, and used the 3V regulated output from the 9V battery clip to power the accelerometer. Figure 8 shows the pinout for the MMA6261 x-y accelerometer



When mounting the accelerometer, we debated filtering the output signal to reduce the level of noise coming from it. The noise, as seen in Figure 9, is caused by the pulsed stepper motors and the spinning of the sweeping brush. We decided not to filter the output of the accelerometer for fears of filtering out the collision spike, and decided instead to use threshold voltages to detect collisions. The background noise of the motors can be neglected, and only if the accelerometer output passes certain threshold values is a collision detected. Figure 9 shows the x and y-axis outputs from the accelerometer, read with the oscilloscope. The top output displays the x-axis, the left and right directions of the robot, and the bottom output represents the y-axis accelerometer, the forward and backward directions, while all onboard motors are running. Clearly, the movement of the motors cause a larger amplitude signal in the y direction than the x direction. There are currently no collision spikes on the screen output, but when a collision occurs, a clear spike can be seen on the screen. The zero-g output for both axes is approximately 1.48V according to the MMA6261 data sheet, and both signals are centered around that value



Things we tried which did not work.

Initially, we wanted the robotic vacuum to have 4 wheels, two driving wheels and two supporting wheels. Our intention was to use a potentiometer and use the analog-to-digital converter to convert the voltage drop across the potentiometer into a precise direction for our unit. One of the main issues with achieving this goal was detecting the direction of the wheel using the potentiometer. Using a standard chair wheel, we hot-glued the metal free-spinning shaft to the wheel so that the wheel could not spin separately from the shaft. Then we glued the potentiometer to the end of the wheel and supported the potentiometer in a way such that when the wheel turned, the potentiometer dial was turned by the shaft.The main reason this approach failed was because the wheel needed to be perfectly vertical in order to spin freely without the free-spinning shaft. This was unattainable using foam board, so we machined several pieces of metal for our purposes to glue onto the foam board. Because the metal was to be mounted on foam board, and the other wheels were not perfectly aligned, this approach failed again.


Our last attempt at using a fourth wheel was to create a body for the unit machined entirely out of a circular piece of metal. This would ensure that the wheels would be perfectly aligned. However, after visiting the machine shop, the only available piece of scrap metal that was suited for our purposes was a steel “donut,” which had a hollow center. This piece of metal was machined correctly, but the weight of the entire robot proved to be too much for the stepper motors to be able to drive. Had a suitable piece of aluminum been found, the weight of the metal might not have been an issue. After this final attempt, however, the idea of determining direction was scrapped. It was decided that even with the inconsistencies in the stepper motor torques and wheel slippages, because we decided to use a random walk technique, the exact direction of the robotic vacuum was inconsequential.

As explained earlier, the attempt to use a standard 9V battery to power the stepper motors failed because the battery could not source enough current to the motors. We even tried an array of 9V batteries in parallel, but the power provided was still not enough to drive the entire weight of the unit. Each 9V battery supposedly has about 200 ohms of resistance, so using four batteries in parallel results in an equivalent resistance of 50 ohms. This resistance only allows 9/50 = .18 amps of current to flow to the motors, which is definitely not enough to move our robot.

Another attempt at powering the motors was made with D-cell batteries. 6 batteries were added in series to provide a 9V supply with enough current to spin the stepper motors. The torque provided by these batteries was somewhat more than that provided by the 9V batteries, but the sheer weight of all 6 batteries counteracted any benefits. We realized that we needed current from a compact set of powerful batteries. We acquired two 9.7V 1600mAh rechargeable NiMH battery packs, which we connected in parallel to provide a theoretical 3200 mAh of current to our motors. This final attempt at satisfying our power requirement succeeded, and further testing could be performed.

As explained earlier, our attempts at running the carpet sweeper without a powered brush failed because of the lack of torque on the part of the stepper motors. By using a DC motor to turn the brush, the stepper motors were no longer responsible for turning the brush, so that problem was solved after some modifications to the carpet sweeper case to accommodate the motor shaft.

With apporximiately one week remaining before our project due date it looked as though the robot was coming together quickly. We had overcome most of the power issues and had even mounted the sweeper, although it was slightly too high off the ground to be effective. Because things were going well we wanted to add to our project and decided to implement a wireless base station that the robot would be able to locate and return to after a designated amount of time. This would have been a proof of concept exercise to show the feasibilty of an automatic recharge station. To implement the base station we planned to use ultrasonic transducers: there would be one transducer at the base station emitting 40kHz pulses and three more transducers mounted on the robot to detect the pulse. By evaluating the time difference between the arrival of the pulse at the three robot transducers we planned to have the robot turn towards the base station and return there. Unfortunately, the mechanical nature of our project made the robot's basic function unpredicatable in the days before our demo and we were forced to abandon the base station to fix problems inherent to the sweeping ability of the robot. However, had we continued work with the base station the biggest problems would have been creating enough power at the base station to be readable from a distance and that the ultrasonic transducer signals were very directional and needed to be scattered.

Towards the completion of the project, a thin, rectangular sheet of iron was placed around the front of the robotic vacuum to be used as a large bumper, capable of hitting obstacles near to the floor and obstacles an inch above the robotic vacuum’s circuitry. This metal bumper added too much weight for the stepper motors to drive, so it was removed