Project Planning - Part 2

The one thing I think corporations have right is this idea of project requirements. To prevent feature creep, as mentioned in my last post, we create a list of what we feel the project should be. It's a list of goals the project should fulfill. No extra features should be added at all, and the sheer amount of paperwork required to change a project's requirements is more than enough of a deterrent.

I decided to write out the requirements I'm putting into my little robot that I'm building. As I started to do this yesterday, I went off on a wild tangent of ideas and equations. My robot should be one of two things: a radio-controlled tank, or an autonomous droid platform to help maintain my apartment while no one is home. The latter sounds cooler, so I started with that. After all, a hobbyist builds robots because it's awesome, right? Practicality sometimes has to take a seat.

The autonomous requirements:

  1. The robot should be able to guide itself to its destination. A degree of inaccuracy is OK.
  2. The robot should return to an out-of-the-way location between each task.
  3. The robot should either charge itself or provide a notification that it needs charging.
  4. New destinations and routines should be easily programmable.

Since this will be a platform to be fitted with a task later, I left the requirements at that. I started to design ways each requirement could be fulfilled.

Autonomous Requirement 1

Requirement 1 could be done easily in three ways, each a little more complex and expensive than the last. I could use time-based directions:

The second method would be to use an accelerometer. Basic kinematics states that the integral of acceleration is velocity, and the integral of velocity is distance. Therefore, I would be able to use distances rather than time.

I would need to use time for turns since most accelerometers do not have a rotational axis. Since a cheap, one-axis (treads can only go forwards or backwards) accelerometer is about $15, I decided that this is better than the first method. I would poll an analog-to-digital converter to get the acceleration. Since I would then have discrete points, integrating becomes a summation, read: trivial. It's also more accurate. The batteries die, top speed will be slower. This method can account for that.

I though of the third method while thinking of the second one. I want to eliminate time from the instructions completely. I'll add a cheap electronic compass. The directions now read:

This also has the added bonus of taking less memory because the instruction list is shorter. I would travel as in the second method. I would turn just as in the second method, but I would poll the compass in place of the accelerometer. I chose this method.

Autonomous Requirement 2

This is where I became stupid. I tried to think of a place in my apartment that was out of the way. I picked the top shelf of my closet. I never use that space. That will be the robot's home, complete with self-charging station. How would the robot get up and down?

I was trying to minimize the number of moving parts. I don't have much room to build things, so I toyed with the idea of an electromagnet. I don't know why my brain does this to me, but that's just the way my mind works, I guess. I would use an electromagnetic crane. Here's where I started making assumptions a creating derived requirements, new requirements needed to fulfill original requirements.

First, to make a crane, I need a power supply. I have two options: wall power or battery power. For wall power, I would need to run an extension cord from a nearby plug into the closet. That's grounds for arguments with the girlfriend. So, I decided on battery power. I guess I won't have a recharge station up there. That's OK, but batteries have a current limit. Speaking of which, how much power does a crane need anyway? That's where the assumptions took over.

I'm sorry to all American readers, but the world of science and engineering uses the metric system. Ignoring the motor to lift the crane for now, I needed to determine the amount of power the magnet itself required. Using the almighty power of Wikipedia, I found this equation:

Magnetic Force Equation

"Mu" is the permeability of the core material. I can get that from a materials table. "I" is the current. Assuming limitless current for now, I can get that from the input voltage and wire resistance. The wire resistance I can get from the wire gauge and wire length. There is a helpful table of resistances here. "A" is the area of the magnet. I can get that from the wire diameter (wire gauge) and core diameter. "L" is the length of the core. I can measure that once I find a suitable core laying around somewhere. "Mu-0" is the permeability of free space, a constant. "F" is the pull force of the magnet. I can get that from the mass of the robot.

So, I have a few variables.

I decided that there was no way my robot was going to weight over 10 kg. When designing, I always plan for the worst-case scenario. So, I fixed the mass at 10 kg, which is about 100 N of force. I have a 100ft bulk of 12 gauge wire sitting around, so that determined the next two variables. That means I need the Voltage, which is derived from my amperage. That means I need to solve for "I," which is now limited to 41 A given my wire gauge. "I" and the wire resistance will give me power draw, so that works out nicely.

The equation above is easily rearranged to give me "I." Since I know the wire length, I can derive "N" from the wire length, wire gauge diameter, magnetic core diameter, and the number of turns of wire per layer. "A" is now a function of "N." Because everything is a function of something else or a constant, I can solve my derivations and make a spreadsheet of my constants to find the best solution. I found this method to be the key to solving for a lot of arbitrary variables simultaneously. Pretend they are constants, and generate a table.

I need to solve for "N" first. I approximate that coils of wire are concentric circles.

Number of Turn Equation

Reality Slaps Me

It was around this time that a friend walked over and saw my testament to over-engineering. He asked me what I would ever need this to do for me. I had no idea. I said that it could get me a drink or something if I gave it a gripper to hold a glass, but I would need to build another device to lift the robot to the sink. That's when I realized how dumb I was being. I was already pre-thinking of heat limits (magnets get very hot) and motor shielding before I realized that I could just make the robot grab a clip on a string. If there were two electrical clips, the robot could charge through them, too. It wouldn't even need to be set down. I could let the robot just dangle by the clips when not in use, saving even more room. It wouldn't even require the shelf!

I've decide to make the robot into an RC tank that fires small pellets. I already have most of the necessary components. Once it's done, I can add an autonomous mode to it... maybe. Either way, I'm not going to let myself get ahead of myself. I'll start writing out my RC Tank requirements soon.