Introduction

As our final project, we decided to design and build a robot capable of vacuuming the floor of a room or area without any human interaction other than just starting the unit. We realized the need for a cheap and convenient product that can be easily used to vacuum a room on its own, saving a person valuable time.

The robotic vacuum is mainly built from a circular piece of foam board, as shown in Figure 1. The robotic vacuum uses a rotating brush underneath the unit to vacuum a carpet as it passes over it, as shown in Figure 2. Two stepper motors, aligned across the center axis of the robot, are used to accurately drive the robotic vacuum around a room. Because the body of the robot is circular and the steppers are placed along the center axis, the robot can spin in place in any direction. One free-spinning chair wheel is located at the rear of the robot to keep it balanced.

Figure 1. Top view of robotic vacuum.


Figure 2. Bottom view of robotic vacuum.

The robot is programmed to sense the direction of a collision with an obstacle using an onboard accelerometer. If the robotic vacuum hits an object head-on, it backs up and changes direction. If an obstacle is hit at an off-angle, the robotic vacuum turns away from the direction of the impact. The robotic vacuum’s movement is based upon a random walk around a room, which theoretically will cover the entire area of a room given enough time. The robot is programmed to drive straight until an obstacle is hit. At that point, it will turn and continue driving straight until another obstacle is hit, and so on.

Back to Top

High Level Design

• Rationale and sources of the project idea

Our project was inspired by an existing robotic vacuum cleaner, the Roomba®. Current robotic vacuum cleaners on the market, produced by iRobot and Electrolux, can cost up to $1700. The idea of a designing and building a device that can perform the same functions as the existing market brands on a budget of $50 was a challenge that we wanted to take on.

We had an idea of the supplies and equipment available to us and realized that our robot could be built using an accelerometer, several motors and a microcontroller, among various other pieces of equipment. We considered obstacle avoidance, but realized that IR sensors would be too expensive to implement and would not be necessary. A slight collision with an obstacle could be detected by our accelerometer, and the appropriate response could be programmed with our microcontroller.

Because we are using stepper motors for our bot, it is theoretically possible to determine the distance traveled by each wheel and perform room size calculations, which could have been inputted to an algorithm to better cover the room. However, we discovered a torque problem when we realized that the wheels sometimes slip on the carpet surface, and other times do not move at all. Because of the torque inconsistencies, proper distance determination would not have been possible, so our only option for covering an entire room was to use a random walk in which the robotic vacuum collides with an obstacle and heads off in a different direction until the room is vacuumed.

Initially, this bot was designed with only a carpet-sweeping function in mind. A carpet sweeper, which picks up trash as it is swept across the floor, is not a motorized device. If the carpet sweeper did not satisfactorily pick up trash off the floor, we would motorize it to spin using a DC motor. After some testing, we decided to motorize the sweeper for other reasons.

• Logical structure

A block diagram for the entire system is shown in figure 3, followed by the descriptions of the components.

Figure 3. Logical block diagram of the robotic vacuum.

The 9V battery clip can hold one 9V battery. The clip contains a 3V output, which is connected to the accelerometer's Vcc connection. The Mega32 MCU is directly connected to the battery on the battery clip.

The signal from the accelerometer is inputted into the MCU's analog to digital converter. The x-axis output is sent into port A0, and the y-axis output is sent into port A1 on the Mega32. After several calculations are made, the MCU sends the appropriate commands to the stepper motors and DC motor.

The stepper motors and DC motor are connected to a 9.7V 3200mAh battery pack due to the current demands of the motors. The stepper motors are used to drive the robotic vacuum, so wheels are attached to the axels. The DC motor controls the spinning carpet sweeper brush.

• Hardware tradeoffs

The initial design of the robotic vacuum included two DC motors as the driving motors. However, their implementation would have been more difficult than using the stepper motors because of the requirement of additional hardware like an H-bridge for each motor to allow forward and reverse motion. DC motors are also imprecise, and it would have been very hard to determine how fast or far each wheel had turned without the use of Hall-effect sensors. Because stepper motors can be very precisely controlled, and spun backwards and forwards without the need for any circuitry other than a ULN2003 Darlington array chip, it was decided that stepper motors were ideal for this project.

We were caught off guard by the lack of torque produced by the stepper motors. As soon as we switched from a 7V power supply to a 9V battery, the drop in torque was noticed immediately. The two stepper motors no longer had the capacity to move the weight of the robotic vacuum, so another hardware tradeoff that was made was the procurement of higher-capacity batteries. Two 9.7V 1600mAh radio-controlled car battery packs were used in parallel to provide the 3200mAh of current to the robotic vacuum’s motors.

Because the carpet sweeper brush is attached directly to a DC motor, a system was necessary to control the speed of the brush so that it does not overheat the motor and surrounding systems, and so that the shaft of the sweeper brush does not violently separate from the shaft of the motor. A pulse-width modulation system was developed to limit the speed of the DC motor, and is explained in the Software Design section.

• Relationship of the design to available IEEE, ISO, ANSI, DIN, and other standards

Every device used in the development of our robot will have already passed IEEE compliance standards, so we do not need to worry about any such technical issues. No other standards apply to this project.

• Existing patents, copyrights, and trademarks which are relevant.

Our product, if placed on the market, would be in direct competition with similar vacuum cleaners produced by iRobot, Karcher, and Electrolux among a variety of other brands. All the products are similar in size, shape and function. However, the algorithm used by our vacuum cleaner to vacuum a room is unique to our bot. The Roomba®, iRobot’s vacuum, for example, follows a snail-shell pattern outwards from its current position and uses a type of sonar until it finds a wall to follow, after which it bounces off of obstacles in a similar manner as our robot. The Electrolux brand uses a type of radar to map a room and avoids colliding with obstacles altogether.

Our robotic vacuum is initially placed in part of a room, and just moves straight until an obstacle is detected, at which point it either turns left or right and continues on its way. No patent, copyright, or trademark issues should be relevant to our bot because our algorithm and equipment are unique, to the best of our knowledge.
 

Back to Top

Hardware Design

The body of the robotic vacuum is composed of a circular piece of foam board, onto which all the components are attached. Along the diameter of the circle are the two stepper motors and wheels. The motors are mounted to the underside of the unit with aluminum brackets and the wheels are glued onto the shaft of the stepper motors. At the rear of the robotic vacuum lies the third supporting wheel, which spins freely in all directions. All the wheels were taken from an old, broken office chair. The supporting wheel’s shaft, which points vertically, is secured with hot glue so the rear wheel does not wobble as it turns. Figure 4 shows the labeled physical components placed on top of the robotic vacuum.

Figure 4. Labeled physical components of robotic vacuum.

Because the body of the robotic vacuum lies several inches above the ground, foam board bumpers were created to nearly touch the floor so that a low-lying obstacle could be detected, as shown in Figure 5. Inch tall bumpers were also added to the top of the unit to prevent a collision with an obstacle above the body of the robot. We did not want the robotic vacuum to get stuck under an obstacle or have the wires torn off as the unit tried freeing itself, so we gave the wires and circuitry an overhead clearance.

We decided to use separate battery supplies to power the circuitry and the motors. The batteries capable of sourcing the most current were separated from the circuitry only for precautionary purposes. We did not want some sort of drop in voltage or other discrepancy with the motor batteries to have an adverse effect on the circuitry. The 9.7V motor batteries, which comprise most of the weight of the robotic vacuum, are mounted in the rear of the unit, above the supporting wheel, to keep it balanced.

In addition to the stepper motors, which are used to move the robotic vacuum, we decided to motorize the carpet sweeper for several reasons. The stepper motors did not have enough torque to push the robotic vacuum and the carpet sweeper at the same time. Also, a spinning brush could possibly collect more garbage from the floor than a free-spinning brush. With these two considerations, a hole was drilled in the side of the sweeper through which the shaft of the DC motor was placed and connected to the shaft of the circular carpet sweeper brush. The motor was mounted to the side of the carpet sweeper body using foam board. Heat considerations were taken into account, and from prior experience with the stepper motors, we knew that too much heat from the motors would melt any hot glue used to hold the motors, so foam board was glued together to physically hold the motor in place and dissipate heat. Figure 6 shows the sweeper and motor setup. Software was used to control the speed of the spinning brush so that it would not overheat the motor or break apart because of too much force. This control system is explained in the Software Design details.

Figure 6. Internal view of carpet sweeper and DC motor.

The carpet sweeper is attached to the bottom of the base of the unit using foam board supports hot-glued together. The height of these supports was adjusted to allow the sweeper brush to just barely touch the floor and pick up any garbage that it passes over. The spinning brush would definitely assist the robotic vacuum’s forward movement, as it would basically provide for a third forward-spinning wheel. As explained in the Software Design section, the sweeping brush only spins when the robotic vacuum is moving forward, so as to not interfere in the robotic vacuum’s turning capabilities.

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.

Figure 7. Pinout for the ULN2003 Darlington array chip.

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.

Figure 8. Basic connections for the MMA6261 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.

Figure 9. Oscilloscope output from the accelerometer with motors running.

• 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.

Back to Top

Software Design

Our code uses a 4 millisecond time base to precisely determine system timing and ensure that a new analog conversion will be ready in each new interrupt. When the power is initially turned on to the system, a 5 second pause takes place before any of the motors start. Because of the sudden jerk caused by the motors, we placed an additional 2 second delay on the start of the collision detection system.

The collision detection system uses Port A on the Mega32 chip, and cycles between Port A0 and Port A1, which are connected to the x axis and y axis of the accelerometer, respectively. The port switching takes place every interrupt cycle, and samples the output of the accelerometer. Threshold conditions are put in place such that if a spike output occurs from the accelerometer, the system captures the spike and ignores any consequential spikes afterward for a set amount of time. If only the y axis produces a spike, it is clear that a head-on collision has occurred. An off-center collision occurs if the y axis and x axis spike is initially above or below a certain threshold voltage. As soon as a threshold value is reached, a collision is considered to have occurred, and the ADC is ignored until the appropriate turning action is performed by the robotic vacuum.

To control the DC motor that controls the brush, a pwm pulse is generated, using a 50ms period. For 5ms out of 50 ms, Port D is turned on, turning the motor on. For 45 ms out of 50 ms, Port D is turned off. Surprisingly, only this 5 ms pulse is necessary to power our motor and give it enough torque to spin nicely. The reason the motor had to be pulsed is that the motor is ridiculously powerful for its purpose, so aside from connecting it to a lower voltage power supply, which was not feasible, we had to pulse the motor. The pulsing also helped with heat issues that are explained the Hardware Design section.

Two functions exist, forward() and backward(), which consist of a series of output states for the stepper motors. It is possible to spin each motor independently of the other using these two functions. Stepper Motor Data Sheet, provided in the References section, was used to determine the exact sequence of outputs to the stepper motor.

In order to turn the unit after a collision, one of the wheels is set to reverse while the other wheels remains moving forwards. We actually noted that the IntelliBot group used similar stepper motor code to what we needed. Our stepper motors have a slightly different sequence than the motors used by the IntelliBot team, but they used a clever approach, which we imitated, to their forward() and backward() outputs. During a spin, the sweeper brush is turned off so as not to interfere with the spin. We calculated that there are about 48 steps per revolution, taking into account the angle per step of the motor and the circumference of the wheel attached to the motor. With that in mind, we decided not to have the robot turn exactly 90 degrees no matter what kind of collision occurs. If an off-center collision occurs, the unit will spin 80 steps, or about 75 degreees. In a head on collision, the unit will spin 110 steps, or about 103 degrees. These numbers were somewhat arbitrary, but we wanted the angles to be large enough to avoide a second collision with the same obstacle.

Initial testing of the stepper control functions was performed using the STK500 board. Because the board had pushbuttons , we used the pushbuttons to test out the turning functions, as well as the optimal speeds we would want our unit to run at. Initial calibration took place before the individual components were placed onto the body of the robot.

Back to Top

Results

Even with our simple algorithm, our robot is able to cover large floor areas as well as find its way into and out of small corners.  As the robot randomly traverses the room, the sweeper installed underneath manages to pick up a significant amount of dirt.  Emptying the catch bin after a few minutes of testing is proof that although the sweeper might not be picking up everything in sight it clearly pulls in enough grime to be considered a success. 

There are, of course, occasions in which the robot behaves somewhat unpredictably.  Early on in testing, scope outputs of the accelerometer after a collision indicated that there would be a certain amount of uncertainty.  This is because the waveform resulting from a collision is not a constant, but instead the output is a damped oscillation with significant voltage swings above and below the mean.  The frequency of this oscillation, however, was relatively slow and a high sampling rate generally sufficed to catch the first spike, at which time we set a timer to ignore the rest of the oscillation, usually about 100 milliseconds.  With some tuning we were able to maximize the chance of detecting the correct direction from the accelerometer.  Since our algorithm is essentially a random walk through the room we decided that the occasional errors were acceptable.

Perhaps the most significant obstacle we faced was that of producing the necessary torque to reliably move the robot with the sweeper, which inherently produced a large amount of friction.  That friction, combined with our less than ideal wheels, foam board chassis, and the limitations of battery power, was a huge headache at every stage of the design and remains the largest hindrance to the robot’s reliability.  The help with this problem we scavenged more powerful batteries from old radio controlled cars, spent hours fussing with the height of the sweeper off of the ground, experimented with different traction methods on the wheels, and shifted weight around the body of the robot.  However, the most significant design change was to add a DC motor to help drive the sweeper brush while the robot moved forwards. 

Since our robot was completely self contained and running off of its own power, safety was not as much an issue as if our project utilized a house current power supply.  There is, however, a relatively large amount of current sourced to the three motors which required that we use proper circuitry capable of providing that current with no danger of burning themselves, the microcontroller, or the user, of course.  The robot operates with no human interaction and so the user interface consists of a simple switch.  We programmed a ten second wait time after being turned on prior to starting to give the user time to put down the robot before the wheels and sweeper begin to turn.

Back to Top

Conclusions

Since our robot essentially mimicked the random walk algorithm incorporated in the most common commercial automatic sweeper, the Roomba, we can say from experience that the electronics required to implement such a design were certainly within our ability to reproduce for this project.  However, the mechanical aspects were very difficult to perfect in our rough prototype.  Since commercial robots are manufactured from robust materials it is no surprise that they would probably be more reliable than our home made sweeper robot.  That being said, since the mechanical side of the project became more of a challenge as time went on if we were to do this again we would start with more robust parts, specifically wheels, and be slower to rush to the glue gun to stick things together.

• Intellectual Property Considerations

We used the some of the movement and collision aspects of the Roomba, a robot sweeper that currently sells for around $300, but because we built our robot without ever having actually used or taken apart a Roomba, and also because our robot uses accelerometers to detect collisions (the Roomba uses a front bumper) our design is sufficiently different to avoid any patent or intellectual property issues.  We would, however, like to thank the designers of the IntelliBot (Spring, 2003) for the help that their final report provided with stepper motor operation.  The driver code that we used for our own steppers was very similar because we couldn’t see any cleaner or more efficient way to drive them.

• IEEE Code of Ethics

We strove to comply in any way possible to the following ten IEEE ethical guidelines:

1. to accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.

Although our design is very safe because of the nature of its self contained power we were very cautious during the testing when using any significant power supply to source current to our motors.  When constructing our circuit, we were careful to avoid possible short circuits across the motors which we know to be pulling the most significant current.

2. to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;

Our interest was to create a carpet sweeping robot.  Since we worked independently from other groups this was not in conflict with others.

3. to be honest and realistic in stating claims or estimates based on available data;

We documented in full the abilities and shortcoming of our project in this report.

4. to reject bribery in all its forms;

At no point did we consider bribery as a viable alternative to the completion of this project.

5. to improve the understanding of technology, its appropriate application, and potential consequences;

What we learned in designing this robot will be applicable to many other projects in the future and we will be more ready at that time to contribute and improve.

6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations.

Again, this project served as a learning experience but at no time did we overstep the boundaries of safety given our current knowledge because we were working on a relatively low power consumer device.

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;

We attempted to help other groups whenever we could offer it and certainly acknowledged any criticism from others that would help us towards our final goal.

8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;

No persons were treated unfairly during the course of this project.