It seems to me that having both motors on for X milliseconds would equal the robot traveling Y distance.

Even if you had an "infinite" battery - this would never be true, because wheels/treads/legs/whatever slip on surfaces, motors vary in speed (even when supplied constant current and voltage), etc. In the real world, this will not work.

This however is not the case because as I'm sure you know. Voltage and Amperage tapers off the battery as it's used (See, I learned that!)

so what do I use or what term do I google to find out how to prevent this from happening.

Well - the term you're looking for is "regulation" or "regulator" - ie: "voltage regulator" or "current regulator" - a voltage regulator ensures that a constant voltage is present at the output, whether the input voltage is too high or too low; there are certain limitations to this - many regulators (especially linear regulators like on the Arduino, which gives it a constant 5 volts to run on) have what is called a "drop out" voltage - that is, if the voltage goes below this amount, the regulator will stop working (in the case of the Arduino's voltage regulator, it's 7 volts).

A current regulator ensures a constant amount of current is available to a circuit or component, and won't let it go above or below a set point, regardless of whatever the circuit it is powering is doing, or the input. If you combine both of these circuits, you essentially get a regulated power supply - one which will supply a set voltage and current.

That said - you rarely see such lengths gone to for a small motor supply system. Generally, you just figure out your total current draw and max current draw, ballpark some averages, then figure out how long you want to run and how many amp-hours (Ah) of battery capacity you will need, and try to get a battery that will provide that capacity.

What I want is that if the battery is supplying 9v at the beginning of its life, the motors get 7v.
If the battery is supplying 6.999999v the whole thing stops.
(Note: I may be talking about Amperage too, I don't know)

Not sure what you mean by this; voltage typically doesn't drop drastically in a battery until it's close to the end of the amount of current it can supply for the load in question. You'll see some drop, but not instantly on a fully charged battery (hopefully, you're not using any of those expensive PP3 square 9 volts, are you? If you are - STOP).

If you must use a "9 volt" source - grab a 9.6 volt radio-control battery pack and a proper smart charger (so you don't overcharge it - which is bad); go with an NiMH pack at first. Don't start with a lithium-based pack; even with a proper charger, they can and have caught people's houses on fire; you need to be very careful with them, and charge them properly (best way I've heard is to take a hollow concrete block, place it on a concrete surface, put the packs inside and charging, then top the holes off with another concrete block - even then, keep a fire extinguisher handy).

When you charge the pack, don't leave the house and check the packs regularly as they charge. If you notice anything abnormal, disconnect them from the charger.

These packs will give you a long run time, and they are fairly easy to work with (you may need to get some bare-lead plugs or whatnot from the hobby store to make connections to your robot, though). They will require an initial investment, but should last a good while.

Essentially, I want to get as close to accurately predicting Xtime = Ydistance

You can't - for the reasons I cited before. They way you make your robot go for a given distance (as well as make sure both tracks or wheels move at the same rate) is via a wheel encoder system. This can be a simple slot encoder (if you don't care about the direction the motors/wheels spin) or a quadrature encoder (if you do).

The only thing you can predict (to a certain level of confidence) is - once you know your total current draw and how long you need to run for - is the size of the battery needed to make it run for that length of time (in reality, your calculations and what you see in real life will not match exactly - because batteries have specs, too - and the cells that make up the battery generally have a set "de-rating" graph that will tell you how long the battery will match it's rated amp-hours for a certain voltage level and temperature over time - also, the battery will heat up as it is used, which will de-rate it further - just keep that in mind).

I also should mention that if its possible I'd like to keep a single power supply (Arduino & Motor Controller)

Yes, you can do this, but you might want to add some noise isolation components to the motors involved (generally just a simple small-value non-polarized ceramic capacitor across the leads of the motor will work well - but you can get more complicated if you need to; look up "DC motor noise suppression" for details). Ultimately, you'll want to power the motors directly off the battery, and -not- from the Arduino's voltage regulator. If your motors are 6 volt motors, though, you may want to look into whether they are -really- rated at 6 volts only, or if they have a larger range. Motors generally are rated in a range (3-6 volts, or 3-12 volts, etc) that they will operate at. Look on the motor itself for information on who the manufacturer is, and see if you can find a model number to look up the spec sheet online from the manufacturer. You can run a lower rated motor on a higher voltage supply, but it's life will be shortened (in some cases very rapidly - mainly in the brushes and bearings). If you are really worried, and the motor is rated lower than what the battery can supply, then you may want to see if you can find the same sized motor just in a higher rating bracket.

I don't have a multimeter, can anyone recommend one to get? I'm in the US.

Where in the US? Do you have a Harbor Freight close by? If so - get their ad, and look at the coupons. Invariably they have a cheapo Cen-Tech on "sale" for $5.00 or so with a coupon. Sometimes if you are really lucky, you can get one free using the "freebie" coupons on the front of the flyer.

http://www.harborfreight.com/7-function-digital-multimeter-69096.html

Are they the greatest multimeter on the planet? Not by a long shot, but when you are learning electronics, having essentially disposable meters can be very useful. Even when your not destroying them, they are handy to just have a bunch around for when you need to stick multiple meters on something for testing, and you don't have a ton of money to invest on the equipment.

That said - I haven't found a Cen-Tech meter to be "crap" either; when testing resistors with them, they read as well as my slightly more expensive Extech meter, which I picked up at Fry's Electronics. Now, I haven't compared a Cen-Tech to a calibrated Fluke or anything like that (can't afford such a meter), but I doubt the difference would be so great for beginner level electronics to justify the extra expense.

So - pick up a Cen-Tech to learn with; go through various tutorials and such, and learn how to use it's features to measure voltage, resistance, and current. Once you understand all of its functions, and how to use them in the proper manner to avoid damaging the meter, then go out an pick up something more expensive. But keep picking up those cheapo meters; they are well worth it (I carry one in my truck, and have one in my garage - just for auto repair issues and roadside problems; I also keep one in my office desk, and a few in my workshop).

Why not have a go at making a new part; from what I've seen, it doesn't look too difficult (just time consuming). You'd have your part, and others would thank you, I'm sure, when you contributed it back to the community!

For the Android software part, I'd start here:

http://opencv.org/android

You don't mention, though, what you plan on using for the robot arm; ultimately, though, you are going to want to write software to come up with what is called an "arm solution". This is not easy - not by a long shot.

That said - this site should offer some good insight (and code examples in QBASIC, IIRC) on how to do it:

https://sites.google.com/site/proyectosroboticos/

It's in spanish, so you may have to use google translate on the site; I found that when using google translate, the site translated very well to english - it may actually translate better to french or other "romance" languages.

I am stuck now with the Navigation systems. what I need to be done is he following:

- inserting a detailed room map to be able to determine exact locations; for example when I say " Bathroom " the arduino will automatically change the word to its saved location on the map as {X,Y} coordinates.
- receive the current robot's location from the encoders and convert it onto  {X,Y} coordinates.
- the arduino should draw the path to be followed to reach that point. The collision avoidance mechanism is already done.

Please help me with the code that I can implement, I am really lost guys.

Please note that I will not use any GPS devices.

Help me guys it is really urgent

What you are proposing, in the real world, will not likely work. The main reason is that no sensor is perfect, and no drive system is perfect. For instance, if you placed the robot you built in some position, and called that position (in cartesian coordinates) [0,0] - and then you directed the robot to move (let's say in meters) forward to [0,10] then right to [10,10], then move diagonally back to your start point of [0,0] - even if there were no obstacles in the way, you would not arrive exactly back where you started, even if you carefully controlled everything. If you told the robot to repeat this motion, the error drift of the system would be such that after only a few iterations, your robot would be no where near it's original starting point.

This is reality. What you are attempting to do is called "localization" - basically getting your robot to navigate in a fairly unfamiliar environment and "know" with a certain degree of certainty (btw - it can never be 100 percent sure - because it's sensors aren't perfect, either) where it is, compared to what it has previously learned about it's environment as it moved around and used it's sensors to build up a map of it's surroundings (and perhaps compared it to the map it had in memory).

Localization is only part of the issue - the other part is mapping, as I indicated above. This process actually has a name (well, an acronym): SLAM

http://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping

It is not an easy problem to solve - in fact, there are many "solutions" to this problem, none of them are perfect.

Fortunately, you have a platform on which you can explore this fascinating field and try out some of those solutions; you will definitely need and want that "map" (each room could be considered a "way-point" of sorts - you might want to set up other way-points as well to help the system - perhaps ones in the middle of doorways, ones along the middle of hallways, at T-junctions, etc).

This is only part of the solution, though. You need to also be able to use your sensors (hopefully, you can measure distances with these sensors?) to determine where you are, and implement a method for the robot to "take a guess" at where it likely is, based on it's last measurement(s) - as well as it's prior measurements, and also an idea of how to get closer to it's goal (one of the way-points) on it's next move.

There is also the need to do path planning (wavefront, A*, etc) - so you know what is an optimum solution to get from point A to point B.

I know all of that is fairly vague. It's a big subject, one with no optimum solution, yet. People have been researching this issue for a half century or more. All I can say is that any potential system you might make without taking something like SLAM into account is likely not to work very well at all. The only way to have any hope of it working well in some fashion (without delving deep into a SLAM solution), would be to somehow have markers or way-points (perhaps QR codes on the ceiling or floor, with a camera pointed up/down) that encode where that way-point is, how far away and in what direction other way-points lie, and to utilize the orientation of the way-point QR code (that is, how much it is rotated when the camera images it) in a way to indicate in what direction the robot is facing when it scanned the QR code way-point.

Another potential solution would be to use some kind of "digital paper" pattern for the floor:

http://en.wikipedia.org/wiki/Digital_paper

With this, and the right software, your robot could know exactly where it is in a building, and what direction it is facing. It's kinda like a pre-computed SLAM system, in a manner of speaking.

None of these solutions have an easy implementation, and I doubt you are going to get anyone writing you a set of code to implement a naive system (which will likely ultimately fail - then again, if this isn't an issue - that you just need something that appears like it could work, at least in a controlled setting, then maybe naive code will be ok).

If you are really interested in learning about SLAM (and other techniques for autonomous driving/navigation) - I encourage you to take this free online course:

https://www.udacity.com/course/cs373

...now as far as a naive system - here's what you could potentially try:

1. Build a map of way-point vector coordinates on your map, using whatever you wish to denote units; you will need one per room (center of room, or whatever is convenient or best) - but you will also want coordinates along hallways, at T-junctions, in doorways, etc.

2. For each path from one way-point to the next, you will need to build a list (a linked list would work well) of way-point vectors to designate the paths. Remember that paths are 2-way; you may want to have "common paths" along hallways and such, and "exclusive paths" - say from hallway to door to room way-point. You could then link up these meta-path lists into larger paths, which should take up less memory. Each node in the list for the path should have some way of indicating in what direction the robot is travelling it (so it knows whether to move forward or backward in the list).

3. You may need to measure and adjust things using the ordinary cartesian distance equation; there's likely to be a bit more than usual of geometry needed to know based on what way-point you are at, and what direction you are facing, how to turn and get to the next way-point.

4. You are obviously going to need to integrate the encoder values (distance travelled) and direction facing, amount turned, etc into the system so that as you back up, turn, etc - to avoid obstacles - these take into account the needed changes in position.

Ultimately, though - even doing all of this - you are still doing "dead reckoning" - and without some kind of on-board or external means of ascertaining direction and position within the environment to a certain degree of precision, the actual position of the robot vs where the robot believes it is at (it's "belief value") will be wildly divergent in short order.

This may be a silly question, but can I use both Digital and Analog servos with the Software Servo library?

What do you mean by "digital servo"?

Do you mean a servo that takes standard PPM RC control signals, and using an internal microcontroller, updates the position at a quicker rate? Example:

http://www.hobbypartz.com/servos1.html

...or do you mean a servo that uses a digital bus (and is programmable, has various feedback via bus, etc)? Example:

http://www.robotis.com/xe/dynamixel_en

If the former, it shouldn't be an issue; if the latter - then no; not without some kind of method of conversion (which would almost defeat the purpose of these specialized servos).

https://github.com/BleuLlama/TinyBasicPlus

Hello my names Jon i took a kids old barbie jeep put the ground directly to the ground of the motors
then put the positives to 2 different relays put a Bluetooth shield on my Arduino UNO and the wires of
the relays to the arduino the motors positives went to relays then to the barbie jeeps 12v battery ,
my problem is it worked for a while then the ground was on fire its pretty thick wire so i dont think
its gauge please help.

Are you talking about a Power Wheels jeep? If so, you might want to visit this forum for some further help:

http://www.modifiedpowerwheels.com/forum/

You also -definitely- want to put a fuse inline between the battery and positive rail, as close to the battery as possible (in fact, if you are using the standard Power Wheels battery, it should have an inline fuse). Those batteries can dump a ton of amps when shorted and cause a fire, as you have witnessed. Don't be stupid around them.

You obviously have a short somewhere. Perhaps if you posted your schematic of how you had things hooked up, that might help us. Also - what kind of relays are you using? Those motors are typically rated around 20 amps or so, so if you relay isn't designed for that kind of current, you're going to run into trouble (perhaps the relay fried and shorted things?).

The kind of relay you should be using are automotive relays rated at 20 Amps or greater (BOSCH); they are pretty cheap from an auto parts store. Get a 40 Amp one if you can find it. Also get the wiring harness and plugs and such. Make all your connections very tight (a loose connection is a high-resistance connection!). Crimp the connectors on; you might also flow some solder into the connection if you have an iron with enough watts - but a good quality crimp will do the job.

Check all of your connections, then double check them. You might want to experiment running a much smaller motor off a smaller battery through the harness until you know you haven't got any shorts or other problems. Also - when you first hook up the actual Power Wheels for testing - mount it wheels off the ground, and test it without it being on the ground. That way, if something goes wrong, you aren't chasing after a runaway vehicle (yeah, I know they don't go fast, but why chase after something like that?)...

Ok thanks for the quick reply. I'm going to try what I came up with and if its no good I will post more detail.  Thanks

Use a 2-input AND gate (78HC08 or similar).

Tie one input pin of the and gate HIGH with a pull-up resistor. Hook up to that same pin your switch, which when it closes, grounds the pin of the AND gate. Hook the other input pin of the AND gate to the output pin of your Arduino. Finally, hook the output pin of the AND gate to your h-bridge or whatever you are using to control the steering motor (make sure the 7808 chip you are using has enough current sourcing ability to drive the input of your controller). Do the same thing with your other limit switch and the other input to your controller.

Code your program to keep both digital outputs on the Arduino LOW; in this position, the ouput of each AND gate will be LOW - and the motor won't run. Bring one line HIGH, and provided the other pin of the AND gate isn't being forced LOW by it being at the limit of the switch, you'll activate the motor - until the limit is reached, in which case the other input of the AND gate is brought LOW - putting it's output LOW - regardless of the input from the Arduino. In that case, the other AND gate should have one pin HIGH (pulled up), and the other still LOW (from the Arduino) - so set the first pin LOW and the other pin HIGH, and run it in the opposite direction.

Hopefully, this makes sense. You can do the same logic in software if you want, of course (at the cost of a couple of extra pins)...

The tubes are clear, so optical sensing might not be my best choice. 

Still - you might want to give it a try - maybe using something like these:

http://www.goldmine-elec-products.com/prodinfo.asp?number=G18740

Note that the above device is -really- tiny (maybe 3-4 mm in diameter); both the IR led and transistor face upward, so perhaps without a tube, there would be little reflectance, but when you put one it, there would be more.

As far as using switches, you could use something like:

http://www.goldmine-elec-products.com/prodinfo.asp?number=G18631B

...or similar...

Of course, the real problem (whatever you use) will be hooking all of those sensors up and reading them; that won't be an easy task (especially for the IR device mentioned). You would basically need to do something like an LED matrix - but rather than lighting the LED, you would want to read the sensor (well, in the case of the IR sensor thing - you would need to do both). Regardless, you are looking at a ton of wires!

Maybe what might be better would be to not use an Arduino, but go for something like a Raspberry Pi (or one of those other ARM/linux embeddable PC boards) - and use a web cam (facing down?) and some machine vision software (ie, OpenCV and Python?) to verify whether the hole is filled or not...

i have 2 motors from a old rc car i took apart but i am confused to whether i can use them one comes with x2 green Resistors solder on the circuit that's the back motor and the over is from the front steering which dose not.i was also wondering if i could desolder the boards from off the motors and just have wire there any help on how to use the motors with out frying my arduino will be grate

Notice the board on the "steering" motor - notice how both boards look the same, with the exception of the missing parts? See how where those missing parts are labeled on the board as "L1" and "L2"? Notice the schematic symbol of a rounded bumpy line for each of those on the board?

What I am getting at is these parts are -not- resistors; they are actually "axial lead" inductors - small coils which are designed to pass DC voltages/current, but not AC:

http://en.wikipedia.org/wiki/Inductor

Such inductors come in many shapes and sizes (as you can see in the wikipedia article); the color bands - like a resistor - indicate the value of the inductor. Inductors are typically used in filtering circuits. Axial lead thru-hole inductors typically have a body colored green or blue to differentiate them from similar sized thru-hole resistors.

Also note on both of these boards the capacitors. Capacitor work in the opposite manner of an inductor - they can pass AC, but block DC.

In the case of these motors - the purpose of all of these parts is to filter motor noise; when small (or large) brushed-DC motors run, the commutator inside the motor sparks (some more than others depending on design), which results in a ton of electrical noise, which can travel back up the motor wires to the controlling circuit (h-bridge, etc). This can lead to the circuit failing or otherwise malfunctioning.

In the case of the drive motor - the motor likely is under a heavier load than the steering motor (and because it is running more or less constantly compared to the other motor) - and thus generates more noise. So - those inductors allow the DC current to run the motor, but block the AC signal coming back out of the motor. In addition, on both motor PCBs, the capacitors  (the small SMT parts) are likely soldered between the terminals of the motor - shorting the AC signal across - but allowing the DC to pass into the motor (you will also sometimes see capacitors soldered from each terminal to the metal "can" or case of the motor - but that doesn't appear to be the case here).

The reason there are no inductors on the steering motor is likely because since it isn't used as much (nor has as large a load on it), it didn't produce enough noise in testing to be a concern to the designers/engineers of the toy.

That explains the why and what; as to your question of removing them - I would advise that you leave them on; if you can (and depending on your application of the motors), you might want to purchase and incorporate the same sized inductors for the other motor as well. It couldn't hurt - depending on what your project is, of course.

Generally, though, you can get away with a simple small value non-polarized ceramic capacitor across the terminals of a small brushed DC motor to reduce the noise output; if you wanted to know what size you should use (or whether you need to add inductors or whatnot), that would depend on the amount of noise generated by the motor - and to know that, you would need to use an oscilloscope to see the noise being generated by the motor under load. Once you knew the approximate frequency range and voltage levels of this noise, you could then calculate (or perform trial and error fitting) what is needed for the capacitors and/or inductors to act as a filter to remove or reduce the noise in the system.

You want to keep this noise out - especially in a microcontroller system - because such noise can cause everything from blown parts (rare, but it can happen depending on the voltage level of the noise) to erratic operation of the microcontroller (generally, in this case the noise will travel on the ground side of the circuit). In extreme cases where the noise in the operation of the motor is great (beyond what can be controlled by simple filters) - you might need to use isolation of some sort to keep the motor side of the the controller separate from the digital input signal side (opto-isolators or other devices are typically used for this).

[JimboZA]

The two left wheels are linked together with gears, and the two right wheels are linked together with gears.

You don't mention it, and I think this is what JimboZA is getting at - but this "gear train" you are talking about needs to be such that wheels on one side of the vehicle turn in the same direction; so make sure that your gear train has an odd number of idler gears (or uses some other configuration) between the drive gears attached to the wheels.

I fact, the best way to achieve such a drive system is to not use gears, but rather chains or toothed belts; it's also a more forgiving design, since you can simply provide tensioning mechanisms on one end of the vehicle to tension the drive properly (whereas with a geared system, you would need to design to a certain tolerance so that your gear train runs smoothly and doesn't bind or otherwise have problems - which isn't a simple task).

Is it possible to rotate the car by turning one motor counterclockwise and one motor clockwise?

Yes - this is called "skid steering" - for instance:

http://en.wikipedia.org/wiki/Skid-steer_loader

It has this name for a very good reason - when you drive your wheels in this manner to make a turn (and this occurs whether it is a gradual turn, or the "turn-on-a-dime" method you mention), some of the wheels will "skid" on the surface you are driving on. This ultimately leads to a bunch of issues - the least of which is that the surface being driven on may get torn up (which of course depends on the size of the vehicle, it's mass, tire contact patch, etc).

Depending on the grip of the wheels, you may have issues like "bouncing" where the tire will skid and "jump" or "vibrate" on the surface (this would more likely occur with rubber tires on a hard surface like concrete or asphalt); you also need to be aware that while skidding (regardless of surface) you will be applying lateral loads to the wheels, tires, bearing, hubs, etc - of the vehicle; these need to be engineered and designed properly to take this strain - otherwise you end up with broken parts (or at least parts that wear out quicker than they should).

Rarely do you see differential or "skid-steer" machines driven in such a manner (that is, "turn-on-a-dime") because of such issues; especially when it comes to tracked vehicles, such skid-steering may actually cause a "thrown-track", in which the track comes off (or breaks off!) the driver wheels and idlers - necessitating an expensive repair (at best - you obviously don't want this to happen in a war zone in a tank, because that could lead to much worse consequences!).

Instead, such machines in general use gradual turning, which are done by driving one side slower than the other at speed. In the case of skid-steer machines like loaders and such (which have four wheels), they'll likely only be driven on a compliant surface (sand, dirt, grass, etc), or their drive tires will have little or no tread on them (in the cases where they are driven on hard surfaces, gradual turning will generally be used).

What would the spacing of the wheels have to be?

Well - if you want the best performance in "turn-on-a-dime" mode (regardless of the strain on the system or other issues) - then the best positioning would be at the vertices of a square - which would roughly have a turning capability that corresponds to that of a circle whose diameter is the line between opposite corners of that square.

Now - in the case of "turn-on-a-dime" - if you wanted this capability, but less strain on the system (at the expense of a much more complicated mechanical arrangement) - you could allow each wheel to pivot on a vertical axis. Provided that the center of this axis through the wheel positions it right on the vertex of the square/circle, you could tilt the wheels to follow the line of the circle (basically "toe-ing in" each wheel at the corners), and any skidding would be very minor, if any.

This was actually the system used on the various recent Mars Rover vehicles - as well as talked about in this paper:

http://www.ri.cmu.edu/publication_view.html?pub_id=524

I bet you never thought that such a seemingly-simple system could have such complexities!

Finally - I also want to mention that, back in the 1960s and 1970s (and actually into the 1980s) there were a variety of manufacturers (and kits) of 6-wheel skid-steer ATV machines; they were basically the quad-cycles and "Polaris" machines of their day - here's an article on such a machine from Popular Science magazine, December 1961:

http://books.google.com/books?id=TiEDAAAAMBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

A good patent on a similar vehicle (with interesting suspension systems described) is USPTO #3506079:

http://www.google.com/patents/US3506079

Good luck with your project, and I hope this helps.

Is this a possible future?

No - you know why? Because at the very bottom, way down at the nanometer trace level on the IC die - is still good 'ole analog (and discrete) electronics.

Do you know how digital electronics work? Have you ever studied the history of electronics? Do you know what RTL and DTL are?

If you don't, then you owe it to yourself to learn - as well as learn about how vacuum tubes work, and why - along with their original discovery (oh, Edison - had you and Tesla not been such prideful fools!) - oh, and crystal radio, of course (which indirectly led to the invention of the transistor - in fact, long before the first crude transistor was invented, people were experimenting with multiple-contact crystal detectors, which were really close to what a transistor is).

Also - did you know you can make a transistor using water...? It's not very efficient, but it does work...

Grob's "Basic Electronics" - starts with "what is an electron" - and moves from there (mind you, this is considered an EE101 textbook, with a price to match - so shop used for older editions).

Horowitz's "Art of Electronics"

For basic electronics (though with a bent toward RF for obvious reasons) - the ARRL's "Understanding Basic Electronics" can be a good resource...

Have you looked at this site?

http://electronicsclub.info/ (it's a european/UK site - so it doesn't use the same nomenclature and symbols for schematics as an American site - so keep that in mind).

Here's a couple others:

http://www.learnabout-electronics.org/
http://openbookproject.net/electricCircuits/

Also - you might want to check out the Forrest M. Mims III's books - specifically the ones known as the "Engineer's Mini-Notebooks":

http://www.forrestmims.org/

These were originally published via Radio Shack in the 1970s thru the early 1990s, mainly - but they are still available in larger formats as well (though the pocket versions will always be my favorites). There were several that were geared toward beginners - from basic schematics and circuits, to semiconductors and transistors, to the 555 timer, and all kinds of others. However, due to the era - there wasn't any on microcontrollers (and surprisingly, I never saw one on microprocessors of the era, either - I guess because they were still rather expensive, and they weren't something Radio Shack carried in bare form, plus they were much more complex to understand and build a simple system, unlike today's microcontroller systems).

Have you thought about building your own chassis? It may or may not be cheaper, depending on the materials you use (and where you're located in the world), but it might be more satisfying.

You can make a real nice chassis using a bit of 1/4" plywood (cut out circles using a jig saw), some thin threaded rod and nuts (maybe some washers, too); add on a couple of motors with wheels, like these:

http://www.allelectronics.com/make-a-store/item/DCM-351/24-VDC-GEAR-MOTOR-W/TURNTABLE/1.html

(attach them with some right-angle brackets) - or use some plastic lawnmower wheels coupled to a pair of these:

http://www.allelectronics.com/make-a-store/item/DCM-441/12/24-VDC-GEAR-MOTOR/1.html

...more fabrication needed, though - but it comes with a bracket!

Add a few cheap swivel casters...

Basically - you could end up with something more like a house robot; something that stands about 2 - 2.5 feet tall - with three or four plywood circles, the bottom one could hold your batteries and motors (and maybe motor controller); the center one could hold your processing unit (Arduino, small PC, etc), plus maybe a ring of ultrasonic sensors; the top one could hold your camera, pan/tilt unit, etc (plus other sensors). It would actually be the perfect expandable platform (leave enough room on the center or top level - or add a fourth level - and you could later add an arm, for instance).

If you shopped for the parts right, you could easily build such a robot chassis for $50.00 USD or even less (shop for some of the parts at thrift stores and such, for instance - how about this: use aluminium pizza trays for the chassis? I also am always finding 4-packs of small casters at thrift stores - people buy cheap furniture that comes with them, and don't use them).

Or - do the same thing, but go smaller. Use smaller 6-8 inch threaded rod; use hobby plywood from a hobby shop for the body (or purchase from the dollar store cheap pressboard or plastic clipboards, and cut them into circles - also, from Costco and similar membership warehouse stores that cater to businesses, they sell cardboard circles for pizza makers! Plus cheap metal pizza pans!); continuous rotation servos for the motors. For wheels, most hobby shops sell wheels that will attach to servo horns - or you can make some out of plastic screw-lids from peanut butter jars (add a rubber band for a tire). Cut a ping-pong ball in half and attach it for a cheap "caster" wheel (works on most smooth table-top surfaces).

Fabricating it yourself will open up a world of possibilities and let you make your robot how -you- need it to be. Something you need to start doing when you go out shopping or scavenging (come on - some of the best robot making junk is thrown away!) is looking at something in a way that makes you go "hmm - how can I use this on a robot?"

You'll go grocery shopping, and find items all over the place (of course, the best is at a hardware or auto-parts store) that you can use to fabricate robots with. If you have a significant other who's with you, they may think you're nuts - and maybe you are (or will be) - but that's half the joy! Also - as I noted above - be sure to check out thrift stores (my favorite is Goodwill Stores), as well as garage/yard/tag/boot sales (whatever they call 'em in your neck of the woods).

Oh - also - be sure to check out Ham Fests - sometimes you can find interesting bargains (I've bought working 24VDC matched wheelchair motor pairs with wheels/tires for $50.00 - you -will not- ever find a bargain like that most elsewhere - except at Goodwill - where I recently found - but didn't purchase - a Pride mobility chair with differential steering for $20.00 - but it needed batteries - it was too heavy for me to lift/move, too).