Let's Make Robots!

Working on a robot platform for various 'bot experiments

 
AttachmentSize
LeftBrain-RightBrain-Layout-Update25FEB12.jpg3.98 MB

A comment about popsicle sticks. <grins> They have become a tried and tested building material for robots.

Schrödinger is no exception. It is very hard to see as they are hidden, but if you look closely at the last picture at the bottom of the page, you may be able to see that the solar cells are not glued directly to the top-cover, but have 3 popsicle sticks as backing on each one. Because the solar cells are thin and glass, I wanted something to help strengthen and protect them, so each one was lined on the back with, --you guessed it, --the famous popsicle sticks. 

Last update: Updated the schematic. I had not finished drawing the solar charging circuit and needed to add the SpeakJet chip and Shrödinger's audio circuitry. Barring any glaring errors, I think that is Shrödinger's circuitry as built.

Schrödinger is now marked as complete.

Many of you know I had "emergency" cancer surgery recently.  What I might add is that this has left me drained of energy to continue working on this robot project, at least at this time. The doctors want me to do chemo-therapy, and if I do, it will continue for 6 months leaving me even less energetic than I am now...  I have decided to mark this robot project completed.

I hope what is here is enough to give people a few good ideas for their own robots. Over time I had added and changed the parameters and scope of this project to include more and more diversity, but Shrödinger, the robot, has already surpassed it original goals. It moves and avoid obstacles. It has "kid appeal" with its flashy-lights display and funky electronic voice. What I did not finish was the real-world mapping using a combination of sensors and the i²c memory chips. What is missing there is software only, as the sensors (visible-light "eyes" plus an infrared and two ultrasonics as well) and the i²c memory board with three memory chips are all in place. This was a more recent addition to the plan over and above the original scope of the project.

What I have planned now is to show this project complete as is, and if I should get energetic later on and work out the mapping software, I will just make that a new project page.  For now, with my low energy levels, I will do well to simply begin planning for a (possible) future 'walker' project.  If I get that planned out and begin the construction stages on it, I may be 'borrowing' (robbing) parts from Shrödinger (especially brain, batteries, the LCDuino readout board {made by PatrickMcCabe} and maybe the i²c memory board as well) for the walker.

 

Good luck to all of you on your own projects.

 

 

Previous Add: Was an updated schematic drawing. I still don't show the SpeakJet chip on this schematic, but I am certain I will be adding it under control of the Right Brain.

Previously Added:     I added a movie demonstrating the SpeakJet chip I have purchased to add a voice to the robot. I should have mentioned the little LCD unit that held Shrödinger's name and credited PatrickMcCabe on a job well-done in making that "LCDuino" board. It is run by an AtMega328 w/Arduino software, which displayed the text and flashed the one LED mounted on it temporarily. The LCD will not be a part of the Shrödinger project (at least no plans for that at this time). I have changed my mind several times as to what I was going to put on Shrödinger, so it is always possible it could end up on the robot as well at some point... --who knows? If I did, I would then have three brains present, two picaxe and one arduino, -all 28 pin types.

______________________________________________

     Since all of you name your robots, I have named this robot Schrödinger.  (That was the name of one of the early proponents of Quantum Mechanics. --the "cat-in-the-box" guy.)

     I finally did a spinal cord / brain stem operation and have his head functions hooked up.  Still have to test them and if correct, I will seal up his skull. Ok, I never did seal his skull but left it accessable. I did, however, enclose his spinal cord wires in a protective but flexible covering.

     I've added a third video, to show a little led board I will stick on the robot somewhere.  I stated that I did not have the communications between brains worked out, but that is not totally true. Here is how I set that up:

The LEFT BRAIN sends numbers to the RIGHT BRAIN to tell what it is doing. RIGHT BRAIN absolutely refuses to be called a "slave" or to refer to LEFT BRAIN as its "master".  Don't tell him, but LEFT BRAIN is pretty much in control, at least of the i2c bus.

LEFT BRAIN sends status updates like: 1-scanning with IR,  2-object found with IR,  3-scanning with sonics,  4-object found with sonics,  5-object too close,  6-full stop,  7-backing away,  8-contemplating which way to turn,  9-quick scan,  10-turning,  11-forward,  12-bumper switch (interrupt),  13-light scan (eyes),  14-need more light (asking right brain to open covers or turn on headlights),  15-area too bright (asking right brain to close covers or turn off headlights), ...  and so forth. Then it marks the interrupt line high going to RIGHT BRAIN.

Over at the RIGHT BRAIN, it gets the interrupt and reads the first (status) byte from i2c memory.the RIGHT BRAIN, having less work to do, uses this input to adjust its "emotions", displays emotions via mouth LEDs, eye covers, switch on/off the headlights and this little LED (flashy lights) activity board, which uses patterns to display brain activities.  Once the RIGHT BRAIN has picked up the number(s) being sent from the LEFT, it stores a number of its own in the same memory slot. When LEFT BRAIN sees this number (%11111111) appear, it knows RIGHT BRAIN got the last status byte it sent (so it can send another). It stores the next status and switches its interrupt line to RIGHT BRAIN high, to interrupt RIGHT BRAIN and tell it, that it has another new status to read.

In some of the pictures, you see a coil of wires on the left front corner of the chassis that is earlier pictures of his "spinal cord" wires, used to connect the head functions (eyes, mouth, eye-covers & headlights) Those have been hooked up now. The wiring of the main board is done. The top-cover has the IR distance sensor with servo and two ultrasonic distance sensors. It also carries the solar cells for charging the main logic batteries, and a small board (underneath) with the charging circuitry as well. All that shows in the first video is head-turning & steering servos plus the drive motors.  Since that video was made, I got hold of better batteries and have much less problems with batteries going dead. I found out that one of the brand new NiMH batteries is bad. It does not hold a charge more than a couple minutes under load, even though the other three in that set are just fine. I got a second set, and a new motor driver battery and it runs fine without rapid brown-outs.

     For the full schematic as I have it drawn so far, see file attachment (JPG file).

     I feel like mentioning something about the price and project costs... The page where we list the robots asked for a monetary amount but that is still unknown. I already have spent about three hundred US dollars on it. I have about everything I need for this project now but if I think of something I would like better, the price could go up.  My basic budget is somewhere between a $5 toy and a multimillion dollar Mars Rover. --So I am well within my budget limits...!  As to how much time I have put into it, I have no clue about that, either.  I fiddle with it whenever I get free time, and being retired, I have quite a bit of that.  I just keep trying different things. My biggest problem was the programming.  On a complex robot like this, there were a lot of sub-routines, and problems getting them to work together.

___________________________________________________________________________________________________________

Much earlier notes:

     Not long ago, I discovered the Picaxe chip(s) and am using those for this project. I currently have three PICAXE 28X2s (post-Dec.2010) available for this project, but may only use two in the robot itself.  Having lots of miscellaneous bits and pieces laying about, (from 40 years in electronics) and wanting to try out the Picaxe, I decided to make a "testbed" robot upon which I could mount various things and change them around at will.  Also, I generally visit one of my brothers every weekend and he has small children underfoot quite often, so I decided further that I should make it "Child Resistant". (Nothing is totally "Child Proof", after all.)  Consequently, most of the robot is metal construction. 

     While I have no movies of the project, but I do lots of photos.

     Collecting things that look like they want to be part of the robot platform project... Looks like I have enough to get started.  It is funny, but in this picture are some of the things I originally planned to use for this robot, and now that I look at the picture, I notice that less than half of them actually got used. I keep making changes.  Well, I did say it was a "platform" for experimentation...

     That motor controller board is actually part of what will be on the robot. It will be mounted directly above the main "brain board".

     Some people may wonder how I can work on such a "messy" desk... Here is a little (true) story you may find interesting:

     Years ago, when I was in an engineering deptartment, the head of the department (I'll call him "Pinhead") was always very neat. That is, his desk was always clear of everything. (No baskets; no telephone... just a bare desktop.) He would take out a letter or spec-sheet or proposal and stare at it for hours, before putting it away and getting out another.

     One day he came back to where I was working and commented, "Your desk is always cluttered. Don't you realize that a cluttered desk is the sign of a cluttered mind?"

     My immediate answer to him was, "...then thank goodness I don't have an empty desk!"

     "Pinhead" didn't get it. --Not sure he ever did. <grins>

 

     Yes, I think this will work...

     I got this old lathe when someone owed me $50 and asked if I would take the lathe as payment.  Not sure if my eyes lit up like beacons, but I know I felt like saying, "I might if you twist my arm and force me to take it." <grins> --Even an old lathe like this one would sell for hundreds, easy. Since that I have put a couple hundred in it, making it smoother and more accurate.

     Here (above) you can see one of the aluminium hub inserts with its bearings.

     Trying the mouth LEDs. I had to put in several diodes to make the different expressions, since some of the LEDs are used for multiple expressions. (Later changed the plastic piece holding them to a metal one, since the plastic one got melted a bit.)

     The motors have now been replaced, since the old ones were only strong enough to move the robot on flat terrain, --no bumps.

     I was not happy with the power of the first stepper motors, so I ordered new ones. (Sanyo B00224s, what I actually received was the upgraded version called the B00324) Running them at 10 volts, they seem to work fantastically (compared to the other ones.)

.

     I had already tested the new motors and unhooked the wires from this controller and the picaxe breadboard, when I thought of snapping this picture.

     Both the old motors and the new ones had shafts that were too long for the space in my chassis.  I had to (carefully) grind them down and sand off the ends so they didn't hit on the other motor when the suspension goes up and down on one side or the other. (and take care to not get any metal dust/filings in the motors.)

     The white "tie-rods" are pieces cut from cheap wire coat-hangers and bent into shape with needle-nosed pliers. Another odd bit; I planned this servo placement to be temporary, but it worked fine, so I just added a cable tie (aka tie-wrap) and locked it in place as is.

     Ok, after finding the wheels did not turn far enough, I decided to drill a couple new adjustment holes in the steering arms. (See next photo.)  The middle holes seem to give me what I want, but I may tweak the steering further after the controllers, batteries, and driver chips are mounted and I can actually test how it handles when sitting on its wheels.

     I put in place ten of the bright white LEDs (scavanged from an LED light bulb). I decided to mount them over the CdS eyes, since the cadmium sulfide sensors will need the help in low light conditions.  I am setting it up for 'medium' light conditions and adding headlights for dark places, and eye covers for too bright conditions. (I could always use a dual op-amp in a comparator circuit, but not sure that will be needed.)

     I'm using wires stripped from a telephone line cord between the brain compartment and the head because they were designed to flex back and forth thousands of times without breaking. Being fine strands wrapped around cord, they are a bit hard to work with (and solder to) but it can be done.

     I was going to mount eyebrows for kid-appeal, but after I decided to put the headlights above the eyes, I won't have room for the other two servos.

     I think I have decided the only place I can mount this unit is fixed on the front of the vehicle. It will only give reading for movement straight ahead... (and I can calibrate it with a reading on a "fixed" object, while the 'Bot is moving. Mostly the proximity detection will be done with the eyes and a ultra-sonic sensors. I also added an infrared sensor mounted on the "top cover" of the body (below the head).

 

     Have the mouth LEDs mounted on the metal replacement part and wired up.  Mounted it on the head soon after. Next I mounted the servos for the "dust covers" for the eyes. Next picture shows them hooked to the picaxe breadboard and being tested.

     The eye covers are working just the way I want them to. In case of light that is too bright, I can rotate them partially closed to limit incoming light, or if the light is too low, I can turn on the headlights (10 ultra-bright white-light LEDs)

 

     The SR-04 ultra-sonic sensor worked so well, I sent for another one.  Most people seem to be using "name brand" ones that cost much more, but these work fine and only cost $8.49 USD. I am starting to think that the number of sensors, lights and servos must always expand to use up all available I/O pins.  :-)

     I am still thinking of adding a gripper arm on the robot, but have not commited to that yet.  If I do, I could either forego adding the LED display matrix and that will give me 7 additional I/O pins, or else add a separate brain to control arm movement.  I already verified that servos will work just fine on any I/O pin if I use the PULSOUT command instead of the SERVO or SERVOPOS commands.

     Here is a list of my I/O's as I currently see them (Still trying to get these to all work together the best way. Doing a lot of programming and testing. I think this will do it.

____________________________________________________________________________________________
LEFT-BRAIN (PICAXE) CONNECTIONs                    PICAXE PIN    AXE-STACK PIN    Usage (?)
V+                                                                              20                                        +5 volts
GND (0V)                                                                    19 & 8                                   0 volts
____________________________________________________
Output 0 (B.0)                                                              21                         0              Ultrasonic PING Left         (Output)
Output 1 (B.1)                                                              22                         1              Ultrasonic PING Right       (Output)
Output 2 (B.2)                                                              23                         2              Head-Turning Servo           (Output)
Output 3 (B.3)                                                              24                         3              Steering Servo                  (Output)
Output 4 (B.4)                                                              25                         4              R Drive Step Motor 3 (&4)  (Output)
Output 5 (B.5)                                                              26                         5              R Drive Step Motor 1 (&2)  (Output)
Output 6 (B.6)                                                              27                         6              L Drive Step Motor 3 (&4)   (Output)
Output 7 (B.7)                                                              28                         7              L Drive Step Motor 1 (&2)   (Output)

In 0 / Out c0 / Infrain                                                     11                         8              Interrupt Out to Right Brain (Output)
In 1 / Output c1 / PWM 1                                              12                         9              Read Left Ultrasonic            (Input)
In 2 / Output c2 / PWM 2                                              13                        10              Read Right Ultrasonic         (Input)
In 3 / Output c3 / I2C SCI / SPI SCK                              14                        11              Memory I2C SCL 
In 4 / Output c4 / I2C SDA / SPI SDI                              15                        12              Memory I2C SDA
In 5 / Output c5 / SPI SDO                                            16                        13              Interrupt From Right Brain   (Input)
In 6 / Output c6 / Kbrd Clk / SER TX                               17                       14              Right Front Bumper Switch  (Input)
In 7 / Output c7 / Kbrd Data / SER RX                            18                        15              Left Front Bumper Switch    (Input)

ADC 0 / In a0 / ULPWU                                                  2                        16              InfraRed SERVO control    (Output)
ADC 1 / In a1                                                                 3                        17              InfraRed Measurement   (ADC in)
ADC 2 / In a2                                                                 4                        18              Right Eye                     (ADC in)
ADC 3 / In a3                                                                 5                        19              Left Eye                        (ADC in)

____________________________________________________
Serial In                                                                         6
Serial Out / A.4 / ADC 4?                                                7
Resonator                                                                      9 & 10
Reset                                                                            1

____________________________________________________________________________________________
RIGHT-BRAIN (PICAXE) CONNECTIONs                   PICAXE PIN    AXE-STACK PIN    Usage (?)
V+                                                                               20                                         +5 volts
GND (0V)                                                                     19 & 8                                    0 volts
____________________________________________________
Output 0 (B.0)                                                              21                         0               Red LEDs -common
Output 1 (B.1)                                                              22                         1                ...available
Output 2 (B.2)                                                              23                         2               Interrupt In from Left Brain
Output 3 (B.3)                                                              24                         3               Interrupt Out to Left Brain
Output 4 (B.4)                                                              25                         4               Right Eye Cover Servo     (Output)
Output 5 (B.5)                                                              26                         5               Left Eye Cover Servo   (Output)
Output 6 (B.6)                                                              27                         6                ...available
Output 7 (B.7)                                                              28                         7               Brake Light (transistor driver)
In 0 / Out c0 / Infrain                                                     11                         8               Mouth - Happy              (Output)
In 1 / Output c1 / PWM 1                                              12                         9               Mouth - Sad                  (Output)
In 2 / Output c2 / PWM 2                                              13                       10               Mouth - Normal              (Output)
In 3 / Output c3 / I2C SCI / SPI SCK                              14                       11               Memory I2C SCL 
In 4 / Output c4 / I2C SDA / SPI SDI                              15                       12               Memory I2C SDA
In 5 / Output C5 / SPI SDO                                           16                       13               \
In 6 / Output c6 / Kbrd Clk / SER TX                              17                       14                 > LED matrix board
In 7 / Output c7 / Kbrd Data / SER RX                           18                        15               /    (horizontal)
ADC 0 / In a0 / ULPWU                                                 2                        16               Headlights (transistor driver)
ADC 1 / In a1                                                                3                        17               \
ADC 2 / In a2                                                                4                        18                 > LED matrix board
ADC 3 / In a3                                                                5                        19               /    (vertical)

____________________________________________________
Serial In                                                                        6
Serial Out / A.4 / ADC 4?                                               7
Resonator                                                                     9 & 10
Reset                                                                           1


___________________________________________________________________________________________________________

     As to the concerns about the steppers: I've ordered a couple new steppers plus new 32 pitch gears to fit them and have them mounted on the chassis where the others were.

     I am including my current working schematic for the robot as a file attachment (.jpg available above). If you spot anything that does not look like it will work properly, be sure and tell me, so I can change it before testing for maximum smoke in the picaxes.      <grin>

     Oh, something I did not list there. The NPN transistors are 2N3904s and the PNPs are 2N4036s but more or less any common transistors would do.  Those are ones I happened to have lying about. I considered using 2N404s, but decided I might need those germaniums for something special some day --(like in the solar battery charger, for instance).

     As to the dual transistor arrangement on the "mouth" lights, I would not have needed that, but I have already wired the diode matrix that runs them for switched positive rather than ground, so I threw in an extra PNP in each circuit to reverse the logic polarity.

     I also did not show the batteries, power switches and solar charger on the schematic yet. (The solar charger circuit is an option. I may or may not use it on this unit.)

     Main battery:  4 x NiMH,  [5 V by 2.5 AH]  -I have ordered another identical battery pack, to help increase the instantaneous available current for running servos, headlights and so forth at the same time.

     Additional battery to boost Stepper Motors (only) on up to 10 volts:  8 x NiCd,  [5 V by 2.0 AH]

     I listed these rechargeables as 5 volts, not 4.8 volts as that is what both sets actually read.

 

 

     The code above is the MOVEMENT section (only three readings for shorter pauses while moving. Takes 1 second plus.

     (Both that and the next one should speed up a little when not needing to send characters to the terminal at 9600 baud.)

     The one below is in the MAPPING section of the code (more readings, but takes 9 - 10 seconds to produce results).

As mentioned before, the program code is still in the process of development.

 

     I needed a miniature double-pole switch to turn on both batteries at once, and finally found some small slide switches in a parts drawer that were DPST.  One of those worked fine.

     If I do use the solar cells on this robot, I have to figure out a circuit that will charge both batteries --as in, disconnect them from the robot electronics (at least the motor "boost" battery) and charge them in paralell. Once they are charged up, they would then automatically switch back to series mode to power the robot.  I would also like them to swing out of the way when not in use, and align to the sun (or brightest light) when the battery gets low. However, this robot is probably complex enough.  I may not even add the solar cells on this one. If I do, I will probably mount them on the top cover (not shown in these pictures yet).

     I have decided not to use the X-band motion detector.  I already have plenty of sensors and not enough room to mount it on this 'Bot.  Basically, it won't be useful to have it there.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Not really much in the line of "intelligent" movement to be seen yet.  Once I get it to where it is doing something I can be proud of, I will figure out about posting a video.

I'm still working on the programming. --trying to figure out how make it move fluidly without the annoying pauses to check sensors and such. They can be several seconds long, as I try to get valid readings (similar readings from multiple sensors).

I have had some odd problems with my sensors. Two ultrasonics and one IR that are still "go" for mounting on the unit, but they give odd results.  I will explain.  I can have an ultrasonic sitting here on the breadboard and powered up, with a 'mini-program' that does nothing else but the ultrasonic sensor and lighting or blinking an LED to tell me where it is in the cycle. It also does two math manipulations to change the incoming results to inches (could as easily have been centimeters, but I think in Imperial measurements).  Ok, so say I have my hand 8 inches away... It will read 8... 8... 8... 8... 3... 3... 3... 8... 8...  Huh?  where did those 3's come from?  Nothing moved.

Same thing, but different numbers --It may have no objects in its field of view (ping) for 36 inches (that would be over 90 cm.) but numbers come up in the debug window showing 36... 36... 36... 36... 12... 12... 12... 12... 2... 2... 2... 2... 32... 36... 36... 36... like some "invisible alien" stuck his hand between the sensor and the wall 36 inches away.  So I took both my sensors; wrote another short program to sample each and display both in debug (or terminal window). They both do the same sort of thing only at different but odd intervals... I can have them both aimed at an object 6 inches (15 cm) away One may read 6, while the other one may be reading 24 at the same time.  The numbers jump around.

Where I had intended to have the ultrasonics aimed at slightly different angles to get a better view of what was out there, I am having to set them to both point straight ahead and then compare the two readings. Since the 'bot won't know which is the right answer (or indeed if either one is right) I wrote the program to compare the two and if they were the same, light a white LED. It can go 15-20 seconds before the LED lights.

I tried capacitors to filter any ripple or noise spikes and it seemed to help some, but not totally. Low pass filter on the output of the sonics, the same... Then I added a third "adjustment" --fuzzy logic,,,    If the values are within 2 of each other, (either up or down) call that "the same" and light the white LED. Yay, it is on 60% to 80% of the time... Next check if they are >2 and <5 of each other. If the Right sensor is in the lower range, light a red LED; if the Left sensor is in the lower range, light an amber LED. Over 90% of the time one of the 3 LEDs is lit. ------BUT it is still not 100% of the time and they are side by side, seeing the same things.

Yes, I put a few milliseconds delay after reading one and before reading the other, so the ping has died out and not causing an issue. And another delay after reading the latter one before looping.

Here is the code where it was just checking if the readings were the same or 1 higher or lower    (no fuzzy logic)

CODE

; Ultrasonic Ranging for TWO ultrasonics
; /************************************/

` ********************************************************************************
`  Speed of sound @ sealevel 1087.4 fps  [Also varies with temperature]
` This is 0.0130488 inches per MICROsecond
` For X2 parts @ 8 MHz use (pulses) x 100 / 153 gives tenths of an inch
`            Oh, and my house is close to sealevel
` ********************************************************************************

#picaxe 28X2
#revision 4
`SetFreq M16

symbol trigL = b.0  '    Define output pin for Trigger pulse (X2 parts)
symbol trigR = b.1  '
symbol echoL = c.1  ' Define input pin for Read Echo pulse (X2 parts)
symbol echoR = c.2  '
symbol RawRangeLeft = w2 '    "raw" output from Left sensor
symbol RawRangeRight = w3 '  "raw" output from Right sensor
symbol RangeLeft = w4 '    Left Raw Range (in 1/10ths of an inch).
symbol RangeRight = w5 '  Right Raw Range (in 1/10ths of an inch).
symbol InchesLeft = w6 '    Show inches to target -Left
symbol InchesRight = w7 ' Show inches to target -Right

main:
pause 400
low 2 : low 3 : low 4                  ' 2 = white LED; 3 = amber LED; 4 = red LED
pulsout trigL,2                          ' Pulse/Ping Output (must be at least two 5 uSec pulse widths)
pulsin echoL, 1, RawRangeLeft  ' measures the range in 5uS steps at 8 MHz. for X2
pause 400                                ` settling time after ranging
RawRangeLeft = RawRangeLeft / 2           ` correct for 8 MHz speed.
RangeLeft = RawRangeLeft * 100             ` to get tanths of an inch
RangeLeft = RangeLeft / 153                    `  from target (~2.54 mm increments)
InchesLeft = RangeLeft + 5                      ` rounding off to give nearest inch
InchesLeft = InchesLeft / 10                     ` InchesLeft are now INCHES-TO-TARGET to closest inch

pause 400                                'I tried putting in extra pauses to minimize interference between the two senosrs.

pulsout trigR,2                          ' Pulse/Ping Output (must be at least two 5 uSec pulse widths)
pulsin echoR, 1, RawRangeRight       ' measures the range in 5uS steps at 8 MHz. for X2
pause 400                                       ` settling time after ranging
RawRangeRight = RawRangeRight / 2      ` correct for 8 MHz speed
RangeRight = RawRangeRight * 100         ` to get tanths of an inch
RangeRight = RangeRight / 153               ` from target (~2.54 mm increments)
let InchesRight = RangeRight + 5             ` rounding off to give nearest inch
InchesRight = InchesRight / 10                ` InchesRight are now INCHES-TO-TARGET to closest inch

If InchesLeft = InchesRight then high 2      'Light white LED if readings are the same
Endif
b26 = InchesRight - 1
b27 = InchesRight + 1
If InchesLeft = b26 then high 3                  ' Light amber LED
Endif
If InchesLeft = b27 then high 4                  ' Light red LED
Endif
pause 400                                               ' another delay so LEDs can be seen on

debug RangeRight                                    ' display range via debug command (Show me the numbers)

goto main                                                ' repeat forever

/CODE

 

To top it off, I have been having similar problems with the Sharp infrared sensor as well, although not nearly as bad as the sonics.

who I consider a PICAXE guru, his .bas for getting an HC-SR-04 ultrasonic working (also included is the Arduino code). There is a warmup phase for the first ping that takes extra time for the Maxbotix as well. Perhaps that's what you need:


#picaxe 20X2
#terminal 9600

' SR04.Bas (PICAXE-20X2)
'
' Illustrates an interface with the SR04

' Launches pulse using PulsOut Command and measures the width of the Echo
' pulse.
'
' PICAXE-20X2                      SR04
'
' Trig (B.0)  --------------------- Trigger
' Echo (B.1) <--------------------- Echo
'
'                       GRD ------- GRD
'                       +5 VDC ---- 5VDC
'
' copyright, Peter Anderson, Baltimore, MD, Nov 9, '10

Symbol Tm = W0
Symbol RInches_10 = W1
  
   dirsB = %00000001
   low B.0

   Pause 1000			' allow system to settle when booting

   Do
      PulsOut B.0, 1	' sonar output, 10 us
      PulsIn B.1, 1, Tm
      If Tm = 0 Then
          SerTxD("OverRange", CR, LF)
		  
	  Else	  
          RInches_10 = 6 * Tm /10
          RInches_10 = 7 * Tm / 100 + RInches_10
          RInches_10 = 8 * Tm / 1000 + RInches_10
          SerTxD (#Tm, "  ", #RInches_10, CR, LF)
      Endif
      Pause 1000

   Loop

Sample Routine - Arduino

 

// SR04 Ultrasonic Ranging Module HC SR04 - Arduino
//
// SC SR04 is available at eBay or http://www.satistronics.com in China
//
// copyright, Peter Anderson, Baltimore, MD, Nov 3, '10

void display_q(long x);
long microsecondsToInches_10(long d_microseconds);
long InchesToCentimeters_10(long inches_10);

#define trigPin 13
#define echoPin 12

void setup()
{
   pinMode(trigPin, OUTPUT);
   digitalWrite(trigPin, LOW);
   pinMode(echoPin, INPUT);
   Serial.begin(9600);
   delay(2000);
}

void loop()
{

  long duration, inches_10, cm_10;

  digitalWrite(trigPin, HIGH); // output a pulse on trigPin
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);


  duration = pulseIn(echoPin, HIGH);


  inches_10 = microsecondsToInches_10(duration);
  cm_10 = InchesToCentimeters_10(inches_10);

  display_q(inches_10);
  Serial.print(" in, ");
  display_q(cm_10);
  Serial.print(" cm");
  Serial.println();
  delay(1000);

}

long microsecondsToInches_10(long d_microseconds)
{
  long inches_10;
  // 1130 feet / second = 0.1356 tenths of inches / us
  // dividing by 2 for the round trip;
  //
  // inches_10 = 0.0678 * d_microseconds

  inches_10 = 6 * d_microseconds / 100
            + 7 * d_microseconds / 1000
            + 8 * d_microseconds / 1000;
  return inches_10;
}

long InchesToCentimeters_10(long inches_10)
{
  long cm_10;

  cm_10 = 2 * inches_10 + 5 * inches_10 / 10 + 4 * inches_10 / 100; // cm = 2.54 * in
  return cm_10;
}

void display_q(long x)
{
   int whole, fract;
   whole = x / 10;
   fract = x % 10;
   Serial.print(whole, DEC);
   Serial.print(".");
   Serial.print(fract, DEC);
}

Thanks.  I have looked at PHAnderson's programming you quoted. It did not seem to apply exactly and mostly his conversion to inches did not come up with the right numbers. The REM in my program explains why I used the number I did (153). I took it directly from the speed of sound corrected for my altitude and the normal temperature in my house. Ah, there is part of it, I just noticed he used 1130 feet per second as the speed of sound but a quick check of the web shows it is in the neighbourhood of 1087.4 which gives me 0.0130488 inches per microsecond.

--Regardless of that, -thank you for the suggestion.

My readings are much better since I found that recommendation on the Maxbotics page. When I first got the sensor, my readings were spot-on, but then I started having problems. Some changes in the wiring must have made it start picking up more noise, but the filtering put it back in the useable range again.

 

He took too many (useless) steps to get to his answer. I prefer compact code in a more concise form.

As to the line above referring to: "0.0130488 inches per microsecond.", the picaxe chips do not do floating-point maths / decimals / so I altered the use of maths in the program to use whole/real integers.

Taking 0.0130488, the reciprocal (giving microseconds per inch) is 76.6(+) and then doubled to include the return trip makes it 153.(+) microseconds per inch, which is what I have used to simplify the calculations.

I learned to use 4 readings or more and average them out. So that routine now takes four times longer to produce a number :-(

Does that mean you had the same sort of problems?

If so, on the MaxBotix page http://www.maxbotix.com/MaxSonar-EZ1__FAQ.html

I found a clue that seems to help. Look clear at the bottom of the page and you will see a "fix" of using a 10 to 100 ohm resistor, and a 100 microfarad capacitor on the power lead for the sensors.

I do not have MaxBotix sensors, so I tried different values to get best effect. It seems to have helped with my problem. I ended up using 27Ω on one sensor and 50Ω  (two 100Ωs in parallel) on the other one, along with a 47μF capacitor on each. (Didn't have any 100s). The sensors must be slightly different internally to need different size resistors, but Maxbotix had mentioned 100Ω, but as low as 10Ω on another model sensor, so I used that as a guide to try different sizes.

Hope it helps you with your problem, too.

 

You may also try a 0.1uF capacitor before the resistor (or after, see which works best) to short out the high frequency spikes that might disturb the power line. Usually a pair of 10u + 0.1u are fine to smooth out the power supply, but it all depends on how many disturbing factors are on the line (how many motors, servos, Sharp sensors, wireless device, switching voltage regulator...). Sometimes more pairs are needed, but also a large capacitor on the power line before the voltage regulator is usually needed to compensate for voltage drop caused by the motors starting or reversing. For 6V motors that draw less than 1A at stall a capacitor of 220u seems to be enough, but for hungryer motors you can end up using a 3000u capacitor.

Video of everything going wrong is both educational and funny. Perfection is boring unless it also happens to be funny.

Perfection is boring, but then again, so is a bot that just sets there doing nothing.  I could have it drive forward ignoring sensors, or I can have it set there checking sensors and too confused by the changing readings to do anything.

I am wondering if anyone else had the same problems with these sensors and figured out how to fix it.  Other robots are not visibly showing problems like these...

The Max-botics pages showed using a low-pass filter to minimize noise, but that only partially helped.

Some ideas to solve the noise issue that you have probably already tried but here goes anywho :)

1) put the power leads on a real-time oscilloscope.  You might get some hints as to where the noise is coming from.  Then you might eliminate the noise at the source.  Also, find the frequency of the noise so you can design a filter that works.  Also, see what noise is still getting through your filter.

2) try adding an inductor to the filter.

3) dont use your hands as a test.  They are soft and round which doesn't reflect sound well.  Use something hard and flat.

Hope that helps!  Thanks for posting you bot!  XD