(New addition at the end.)
When I started this, I was trying to decide what sort of robot to build, and in the process I was talking to some new people about how to make a simple robot. One commented that he would like to make a Start Here robot, but the ultrasonic sensors were much cheaper than the (Sharp) infrared sensors, but he was not sure if you could use an ultrasonic sensor to make a Start Here Robot (SHR).
I found a link to a robot using a PING sensor, but somewhere along the line I decided to make an SHR myself, using a "ping"-type of sensor. Specifically, I am using the very cheapest one I could find (the SR04) to show the new people that there is no reason you have to pay fifty or a hundred dollars or euros for a sensor in order to get one that works.
The cheapest I find currently are no longer the ones from Polida in China @ $2.99; I found some from a company called Chip_Partner. Their HC-SR04 sensors cost $1.50 US plus $0.92 US shipping to the United States. I have not yet purchased anything from that company, so I cannot vouch for their honesty. I have purchased from Polida and they are fine.
For framework for the robot, I took a couple old CDs and glued them together with contact adhesive and a piece of paperboard / cardboard between to cut down the brittleness and give a strong platform to build on.
I saw a 2 servo (2 degree of freedom) bracket complete with a pair of (9g) servos for ~$7.50 and decided to get one of those also.
The normal Start Here robot uses a single servo to sweep the head back and forth. With this new bracket adding up-down control, I will be able to direct the robot's "vision" in different directions and add a whole new dimension to his perception.
**Do not worry about the following maths if you have not yet had this in school. Just take it for granted that it will work, and skip down to the next picture.**
If the robot scans back and forth and locates an object in a certain direction, he can look up to see how tall it may be. [Since he already got the distance to the object (horizontal or X-axis) and he can determine the distance away of the top of the object (hypoteneuse of the triangle), he can then determine the height (vertical or Y-axis). Since "in a right triangle, the square of the measure of the hypotenuse equals the sum of the squares of the measures of the two sides" [a2 + b2 = c2] We know the hypotenuse (c) and one of the two sides (a) or (b). Rewriting the equation we get: b2 = c2 -a2 and then b = √(c2 -a2). Now our PICAXE μ-Controller can square numbers and add them together (within limits), but it does not take a true square root of that result. [ What it does is a simple lookup table of square roots.] If we wanted it to perform this calculation, one easy way might be to store a list of roots and squares and let it do a look-up to get the height value (b) that we want.
Rather than worry about such calculations, how this up-down scanning might actually be useful is much simpler. The robot looks up the object and finds the top, then drops its "gaze" down slightly. If the object is a human, then it will appear to the human that the robot is staring at him and could help simulate an emotional response.
*[ Quick Quiz: I mentioned taking square roots above. I would be interested to know how many others know how to do so longhand? ---for those of you who are products of the debilitated US school system, do I need to use smaller words? (ha ha) Anyway, how do you take square root longhand? --and NO I do not mean using a calculator. I mean the "pencil and paper" method. ]
Here is the 2 DoF (Degree-of-Freedom) servo bracket as the instructions show how to put it together:
After assembling it, I found two things.
 it does work in that configuration.
 it seemed a wee bit "top-heavy". I noticed that the bottom servo was holding not only the weight of the brackets, the other servo as well as whatever load it would be carrying.
I figured out that if the bottom servo were relocated to the inside of the bracket, that would take the extra load off the servo. Now it only has to move the load, but not itself, the bracket or the other servo.
After cutting out a slot that fit the servo, I positioned the servo in the new slot in the bracket frame and used contact adhesive to hold it in place. That Goop adhesive is pretty strong stuff.
All right, that looks pretty good, so now I'll work on to the robot's frame.
For that, I glue two CDs together to make the frame and placed the two gearmotors onto this CD platform.
Following that, I mounted the bumpar switches as well.
Now I wanted to mount the servo/bracket assembly on the base as well. In order to carry as much extra weight as possible, and because the bottom bracket already had a couple screw heads sticking out of it,
I decided not to simply mount the servo bracket with adhesive but rather to use machine-screws and nuts to hold it to the base.
Now for the head. I looked around for ideas for what to do to make a head rather than use just the sensor by itself, when I saw an empty snuff can and had an idea. As you see in the next picture, I removed the label and the stamped metal lid. I thought of just taking some heavy construction paper and gluing it over the lid until I saw a piece of thin plywood laying near my toolbox. You could use a coping saw or scroll saw to cut out the wood, but since I have a small lathe, I used that. I had to drill a hole in the middle to mount the wood on the lathe, so that would end up hidden by adding an LED for the nose. That would make it look all right, so that is what I did.
I turned it on the lathe, making a step along the edge so the lid would fit in perfectly. If you simply cut it to fit, you could use more of the adhesive to hold it in place, but don't glue it until you have all the wires the way you want them.
Here I was exploring how he would look with a little enhancement. These old CO2 cylanders are nicely shaped and will look cool on the robot even if they don't really do anything. If I do not add a cover over the outside of the robot, I may use them for that reason. After all, part of making a robot is making it look nice to you, so you as the builder get to decide how it should look.
Okay, he has the two wheels that were made to fit the gearmotors I bought, but he either needs to be a balancing robot or I need a third wheel or caster. The casters cost a few dollars, so I think I can make one myself. The small steel ball bearing fits perfectly inside the piece of iron pipe (seen in the top photo), but then I see another thing that will work. I spotted an old piece of copper pipe that was soldered into a fitting. The glass marble rolled into the tubing, but stopped at the ridge on the fitting. Cool. That is what I will use.
I pressed down spots around the edge of the tubing so the glass ball could not come back out and my homemade rear wheel caster was ready..
Sitting around the Robot Garage, waiting for his new tires.
I could have, but did not polish it up by turning it on the lathe. Instead, since it would be underneath and not seen easily, I simply left it somewhat rough and attached it to the bottom of the robot as a caster.
This shows where I am in his construction as of Thursday, 26th of April, 2012.
The next steps in construction are:
■ make and mount a bumper that extends clear across including the wheels
■ attach bumper to the bumper switches (using either solder or glue)
■ mount battery pack. I will use 4 rechargeables to give ~5 volts.
■ make a circuit board with the microcontroller chip and the motor drivers on it
■ mount that, and hook up all wiring.
I have some L293D chips that make good drivers. I also have some Darlington chips such as come with the picaxe project board which could also be used. Alternately, I have a third option of making driver circuits out of transistors, of which I have literally hundreds, since I buy them in packs of 100 for between $2 and $4 depending on the type of transistor. I also have sockets on hand to fit any of the IC chips (including 28 pin sockets for the "brain" chip).
■ Once I have those steps finished, the physical part will be done and I can program the brain chip by writing the programming on my computer
■ and burning it to the microcontroller chip.
See you soon.... ('soon' being a relative term.) :-)
UPDATE: 05 May 2012 --
The little guy was in the "Robot Garage" having his motors and drive train inspected (and hooked up to the breadboarded electronics).
He was able to run the motors using a test mode of his program (which bypassed the head turning and distance measurements).
His motors went forward, backward, spun left and spun right on command. While his neck muscles (servos) and his eyes (ultrasonic sensor) were not hooked up yet, it was a functional proof of function for the processor, motor driver(s) and motors. I used the driver circuitry I drew in the top picture on http://letsmakerobots.com/node/32462 placing 10 KΩ resistors in the transistor circuits. The motor enables and the forward/reverse worked as engineered and so is proof that the engineering function on that page works as planned, also.
That is all the update for now. Going to be away/busy today, so no more progress expected till tomorrow.
UPDATE: 07MAY2012 --
Tried a couple time to upload a new video to YouTube for this. Finally have it ready to go. If it's not obvious, I put it on top and the older one about the heart is after. He is still not fully operational; just sitting here in the "Robot Garage (the small space between my keyboard and trackball "mouse"). This is showing that the motors and head/neck servos are functional.
I have actually only picked a few subroutines at random to show his potential. The ultrasonics are not working yet, so I slipped a "return" command in at the beginning of the "Ultra" subroutine (short for ultrasonic). Because a lot of his movement will relate to what he sees near him, I just made a different "main" routine and did gosubs to subs to do forward, reverse, backup-right, back-left, turn his head different directions side to side and tilting forwards.
UPDATE: 09MAY2012, late it's almost midnight so nearly the 10th of May.
Added some to his programming, added a bumper stuck to the bumper switches with adhesive. Also his ultrasonic sensor is hooked up. I added a couple high intensity white LEDs for headlights, but they are not hooked back to the PICAXE as yet. His nose light is hooked up and I've been using it as a test indicator to tell me what part of the programming he's working in at the time.
I have decided on a name for this little fellow. From now on, he will be Edwin. I have named him after astronomer Edwin Hubble, the first man to prove there were galaxies beyond the Milky Way, and discovered the quality of "Red Shift", known as Hubble's Law).
I have much of his programming finished. I am also working on a mouth utilizing ignoblegnome's suggestion of LEDs.
Added a copy of Edwin's schematics for inspection or download. Here is an onscreen version thereof.
Just added a couple notes. (weight, cpu, etc.)
UPDATE: 18MAY2012 In lieu of other changes to his face, Edwin now has what I call the "Good grief." look (from Charlie Brown of the Peanuts comic strip.) Maybe a bit puzzled, but altogether non-committal.
At this time, I will also tell the "secret" part of this project. Upon advice from the **FAMOUS** Erin, (the) RobotGrrl, this robot will be an "Entropy Bot".
What does that mean, you may ask? Well, my interpretation is that he needed a lot of randomness built into his programming. In partial answer, here are the top lines of his program.
; Function/Filename: A Different sort of *Start Here* Robot with Ping /ULTRAsonics
; Written by: Dan M
; How is a StartHere not a StartHere?
; --only through differences in his program.
; A robot is the sum of his programming and where he takes it, so--
; Directly from suggestions made by Erin, RobotGrrl, this robot will be an:
; ********* ENTROPY 'BOT *********
; Many of his moves will be "random" --except when he realizes
; he is going to hit something, --and decides he doesn't want to.
' Version History
'#revision 1 -initial motor tests
'#revision 2 -added servo testing added more subroutines
'#revision 3 -refined subs, added bumpers
'#revision 4 -functions all passed testing.(Nukes added)
'#revision 5 - introduced random behavior
#revision 6 '- remove extra wait-states used in testing.
low 4 : low 7 'Makes sure the motors are initially turned OFF at power-up
;**************************** Set Variables *****************************
Symbol RndSeed = w9 ; Random seed is 16 bit stored in b18 & b19 (w9)
Symbol Rnd8Bit = b18 ; 8-bit partial random seed
Symbol LeftBumper = b.0 ; INPUT
Symbol RightBumper = b.1 ; INPUT
Symbol Nose = c.7 ; OUTPUT -send flashes to his nose (LED)
'setint OR %00000011,%00000011, B ; bumper interrupts are NOT fully enabled /will OR work with B?
Symbol SendPing = c.0 ; OUTPUT (Trigger) Define output pin for Trigger pulse.
Symbol GetEcho = c.1 ; INPUT (Echo) Analog pin is not needed.
; noSymbol, // b0 & b1 to be (always) available as temporary variables (globally throughout program)
Symbol NodHead = b.2 ; OUTPUT Defines output pin for head-Up-Down servo.
Symbol TurnHead = b.3 ; OUTPUT Defines output pin for head-turning servo.
Symbol Left45 = 220 ; this value puts his head at about 45° Left.
Symbol Right45 = 100 ; this value puts his head at about 45° Right.
Symbol Center = 160 ; Center of travel for right/left servo
Symbol UdCenter = 150 ; Center of travel for up/down servo
Symbol TiltForeLimit = 190 ; do not tip forward past this value.
Symbol TiltBackLimit = 110 ; do not tip back past this value.
Symbol Side2side = b14 ; Current side to side Head position. w7
Symbol TurnGoal = b16 ; Where you want to turn the head to. /using HEADTURN w8
Symbol UpDown = b15 ; Current up and down Head position. w7
Symbol TiltGoal = b17 ; Where you want to tip the head to. /using HEADTILT w8
Symbol PreLoad = 25536 ; to use preLoad pulse repetition of 10ms, set to '45536'
Symbol LeftStore = w4 ; Store distance measured to the Left in b8 & b9
Symbol MidStore = w5 ; Store distance measured in the Center b10 & b11
Symbol RightStore = w6 ; Store distance measured to the Right in b12 & b13
Symbol RightEnable = b.4 ; OUTPUT Enable Right motor /turn On or Off.
Symbol RightMotorDir = b.5 ; OUTPUT Right Motor Foreward or Backward.
Symbol LeftMotorDir = b.6 ; OUTPUT Left Motor Foreward or Backward.
Symbol LeftEnable = b.7 ; OUTPUT Enable Left motor /turn On or Off.
Symbol RawRange = w1 ; analog sensor distance (from a.0). b2 & b3
Symbol Range = w2 ; Temp range variable (for my benefit). b4 & b5
Symbol RangeInches = w3 ; Again, distance is converted to inches for my own benefit.
UPDATE: 24MAY2012 -- I am adding yet another video of the robot on the lift, but I can announce that I have his programming about completed, and in lieu of further fixes and revisions, I will add a copy of the program for download. It is 1217 bytes in uploaded form. which with plenty of comments in BASIC language form is just a bit over 500 lines of code.
( Oh, I might say, sorry about the poor video quality, but this was recorded on my Kodak shirt-pocket camera which is not in the same league as the Canon, but hopefully it is good enough for now.)
I still have to finish the control board with the picaxe chip and motor drivers, so he is thus far still tied to the breadboard.
One last thing for now. I received the nickel-titantium "memory wire" which I thought of using to control some sort of mouth, other than the drawn-on one. However, I have not used it before, so I will need to play with it some to figure the best way using it to control a mouth. In theory, you put the wire into its "permanent" shape and heat it to nearly red hot to lock that shape in. Then you can put it into a different shape and when a light heat, such as not quite boiling water, or an electrical current (about 200 mA for this guage of wire) is applied, it will try to return to the last "memory" shape. Perhaps twisting it into a coiled spring for its permanent shape will work, but as I say, I will have to try it to see if it will work well enough to bother with.
UPDATE: 27MAY2012 -- Just updated the copy of Edwin's programming for download. 1475 bytes in program but still needs some patches... (like how to avoid falling when he comes to the top of a stairs or edge of a drop-off).
UPDATE: 18JUN2012 -- Latest update of Edwin's programming. He seems to be "fully functional" now.
I figured out that the glitches he was having only occured when his batteries got too low, so the remedy is to keep his batteries charged. [Schrödinger has solar cells for his batteries, but Edwin has not.]
UPDATE: 21JUN2012 -- Latest update of Edwin's schematic. I believe I have the connections corrected in the drawing to reflect how Edwin is wired. I moved a few inputs and outputs around from the original sketch and never updated the schematic until now. You see the extra resistors in the sketch; I did actually put those on the board, so I can tie other things to a particular port lead without bothering with extra resistors. I might have labeler those "Reserved for future" but didn't. They are not really needed for those port connections at present. If you were building a similar circuit, remember that these extra resistors are just that, –extra. They are not needed in his current configuration. I considered I might add to Edwin later. (Yes, I have time on my hands and plenty of resistors laying around. <grins> )
UPDATE 06JUL2012 – Added a couple snapshots of Edwin's brain-board. Just to show that everyone makes mistakes, (even me), I had wired the servos to the wrong pins. On the breadboard and in the programming, I used B.2 and B.3 for the two servos, but when I made the board, I wired them to C-pins instead of B-pins 2 and 3. I later fixed this, but here are the pictures, anyway. Everything else was correct: