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.

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.

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.

9. to avoid injuring others, their property, reputation, or employment by false or malicious action;

At no point was the construction of our project driven by malicious motives.

10. to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.
We hope that allowing public web access to this report with help future semesters of students interested in pursuing similar projects.

Acknowledgements

We would like to thank everyone from ECE 476 that spent time in the lab towards the end of the semester because everyone helped us out either

morally or technically. Certainly worth mentioning however, are Professor Bruce Land, our TA Ryan Peterson, and all of the other TAs who combined

to keep the lab open almost whenever I could get myself to Phillips to work and provide a continuous supply of answers to our never ending questions.

Thanks also to anyone out there who puts schematics of their circuits online for the public to use (especially past 476 people, including the makers of the

IntelliBot). I can’t imagine what it would be like to design a complicated system without all of the information that’s out there today.