Posts Tagged ‘ ping

BAT Hat project: Updated

Taken me a while to get back to this project, my “Blind Assistance Technology” (BAT) hat:  Little over a year ago, I blogged about using some Ping Sonar sensors to drive vibrating motors, to turn distance into haptic feedback.  Doing some “trials” at work, the biggest comment was “I don’t like having my head vibrated”.

I thought I’d try a different technique: audio.  Rather than vibrating one’s head, you could simply listen to what the sonar had to tell you.  In theory it seems like a great idea, but as usual in practice, it’s not quite what I expected.  All files are available for download at the bottom.

The Goal:

  • Have multiple Ping sensors around your head, translating the distances into different sounds, in stereo:  Would give you spacial wareness based on the stereo sound.

The Reality:

  • Based on the hardware I choose, it’s not in stereo, nor does it update fast enough.

My current hardware configuration is a Arduino Uno mated with an Adafruit Wave Shield, being fed data from three Ping))) sensors, mounted to some brackets I designed and 3d printed on my Makerbot Replicator (in nylon), being powered by 6xAA batteries attached to the back of the hat.

I thought the wave shield was in stereo when I bought it:  It is not.  Don’t get me wrong, it was easy to solder together and worked immediately, so I have no complaints about that aspect of the hardware.  I simply should have read up on the specs better before settling on it.  Secondly, and unless I’m just missing something (which is possible), each wav file needs to complete before the next beings.  This really limis the ‘audio refresh rate’:  You can only get audio updates as fast as the wav files play back… so unless you’re walking pretty slowly, it’s not quite fast enough.

All that being said, the hardware does work:  But doning the crazy-mad-scientist hat, you can walk around your environment with your eyes closed, and it will give you audio cues when you are within 100cm of something (about the length of an arm):  Is says the letters “F”, “L”, & “R” based on if you’re in range of something.  And to speed up the audio, I detect for multiple directions at once, and made combo audio file sto play back.  Like “F L R”, “F L”, etc.

I generated all the audio via this AT&T site, that does text to speech:    AT&T Natural Voices Text-to-Speech Demo
It saves out all the audio in the exact format the wave shield wants, making that aspect really easy.

The Future:

I think the next step will be swapping out the Arduino\Wave Shield for a Raspberry Pi:  By using PyGame, I can use stereo audio, and play multiple sounds at once.  My hope is to use actual “pinging” sounds rather than speech.  We’ll see what happens…

Downloads:

BAT Hat

You always need a good  acronym when developing a new project.  BAT = “Blind Assistance Technology”.

I came up with an idea… sometime last year while working on my “Ponar” tech, to make a device that would help one navigate blindly, by sonar.  It’s been a really slow process to get this prototype off the ground:  Work\life\learning all take their time.  But I finally got something functional.  During development, other similar items have appeared on the web (a Ping\servo glove-based solution, for example).  And they’re great!  But I’ll just start out by saying this idea came to me on its own, not that others haven’t already envisioned it\implemented it (better) elsewhere.

Conceptually, it’s a device you wear on your head that can sense the world around you via ultrasonic sensors.  Based on a certain distance, motors attached to the device will vibrate, tactually telling you you’re getting close to something.  There are a total of three sensors\motors mounted on the front, and each side.

The brains are an Arduino (Uno).  Parallax Ping))) sensors are used for the ultrasonic distance readings, and vibrating DC motors from Xbox 360 controllers are used to convey the distances to the user.  The framework I used to hook everything up was an old hat, using shapelock to form brackets for the motors, Ping))) sensors, & battery pack, and zipties to hold everything else.  Originally I had a single 9v battery powering it,… but…. it made the device was unreliable.  I switched to 6xAA batteries (still 9v total), and it’s much happier now.

Parts List:

Video of my boy wearing the hat, walking around his room:
More info below the pics:

Here is a Fritzing image of how the whole thing was wired together:

And here’s a link to the Arduino code.

Project Notes:

  • After some research online, I figured out that the rumble motors I received from a friends Xbox 360 controllers only need 2v:  Originally I had a system setup with transistors driving them from the battery directly, but this realization simplified the process.  Furthermore, my multimeter claims they draw less than 20 mA, which makes them safe to be driven off the Arduino’s pins.
  • The motors are driven off PMW Arduino pins so I can vary the voltage as distance changes.  In the current configuration, they’ll start to spin as they approach items 1.5m away, and are at full velocity at 1m.
  • If I can, I’m going to pick up some pager-motors:  They shouldn’t vibrate one’s head as much as those rumble-motors ;)
  • I also have three servos:  It would be interesting to see how well one’s head could ‘detect’ their pressure.
  • I had originally powered the system with a single 9v battery.  But the Ping))) sensors and motors wouldn’t behave properly.  When connecting the Arduino over USB for debugging purposes everything worked fine… which didn’t make sense to my limited electrical knowledge:  USB is only 5v, while the battery pack was 9v.  However, my guess is that the 9v battery wasn’t providing enough current for the whole system, while the USB was.  So I switched out for a 6xAA battery pack (equaling 9v total) and everything started working properly.  Presumably however, since the Arduino/Ping only needs 5v, and the motors only 2v, a 4xAA battery system (6v) should work fine.
Final Thought:
  • Honestly, it doesn’t work as well as I envisioned when starting.  But that was a pretty high bar I set myself.  Don’t get me wrong, it works fine.  But in my head I’d have this robust system of navigating blindly.  However, with only three motors, that detect obstacles at eye level front, left, and right, you’ll still run into problems with items at knee height.  And with ultrasonic sensors, ‘fuzzy’ items like pillows don’t reflect well, and the less perpendicular you are to a surface the less likely it is to reflect the sound back.  Doubling the number of sensors\motors would be a good start.  Or additional systems hooked up to one’s waist, and knees, or even feet.
  • I’d be very interested to have someone who is actually blind give this a try.  If you know anyone in the San Francisco peninsula who is blind and would be up for it, let me know.

 

Arduino 4wd robot & Ping))) sensor

More photos at the bottom. Click to enlarge.

Armed with the knowledge of my previous “Ponar” post, I successfully completed construction and programming of my “Arduino-based 4wd robot with servo-actuated Ping))) sensor”.   It was an enjoyable process with a lot of trial and error since: I’m still learning a lot about how the Arduino works, how hardware hooked up to it works, and electronics work in general.  To get things started, here is a video of it driving around my kitchen:

Here’s the parts list:

Here’s the Arduino program:

How it works:

  • I wanted a simple robot to drive around avoiding obstacles using the ping sensor.  To do that, I sketched out (on paper) the general program, that went like this:
    • Ping to see if there is any obstacles in front.
    • If not, drive forward, while pinging.
    • If there is an obstacle, stop, and take a distance reading to the left and right of the robot.
    • Turn for a fixed period of time in the further direction.
    • Ping again:  If still blocked, keep turning that direction.  If not blocked, go back to drive mode.
  • There are basically three modes the robot can live in:  Drive forward (mode 1), stop and scan (mode 2), and turn (mode 3).  When driving, it can do three things:  Drive straight, turn left, turn right.
  • The hardware is configured like so:
    • The Adafruit Motorshield is plugged into the top of the Arduino.
    • The Arduino is powered off of 5xAA batteries (7.5v) in the belly of the robot.  These are wired to a switch sticking out the back of the robot.
    • The Motorshiled is powered off a separate 4xC battery pack (6v) on top of the robot.  These are wired to another switch on the back of the robot.
    • The 4 DC wheel motors & servo are powered off the Motorshield.
    • The Ping))) sensor draws power form the Arduino.

Things Learned:

  • Next time, use 2-wheeled robot instead:  easier to steer around the house.  The “tank steering” method of this robot seems like it uses a lot of power and doesn’t work very good.
  • I read it in a couple places, and it turns out it’s probably needed:  Solder a 1uf capacitor between the leads on the DC motors to help “smooth out” their operation.  Otherwise it seems little “hiccups” can happen while driving.
  • Voltage, voltage, voltage:
    • I was having all sorts of problems getting the motors to work properly:  They’d start\stop “hiccuping” a lot.  Per the above note I added in extra capacitors on the motors themselves, but it didn’t solve all the problems:
    • Originally I had the motors hooked up to the 5xAA battery pack (7.5v) that came with the robot chassis.  The motors per the specs are rated at max for 6v.  But… I didn’t know this.  I thought it needed moar power.  So I went out and got a 6xC (9v) pack and powered the motors through that.  The stuttering got even worse (although, it went pretty fast when it behaved) and even did something really stupid:  Put one of the batteries in backwards… which caused it to melt-down and leak acid everywhere.  Sigh…
    • Finally (after I knew the correct voltage for the motors and servo) I went out and got a 4xC pack (6v), and that, combined with the extra capacitors, finally gave it a smooth ride.
  • I had to solder in extra connections to the analog pins on the motorshield to allow fo the Ping))) sensor to passthrough it to the Arduino (acting as a digital pin).  However, the motorshield has the pins in the order of “signal\-\+”, while the cables from the Ping))) (and servo) are “signal\+\-”.  Not sure why the motorshield would break ordering convention, but I had to splice and re-wire the Ping))) cable to match the board.
  • The motorshield docs say that servo2 is pin9, but it’s actually pin10.  That took me a while to figure out… :-S
  • I ran into a lot of problems with the programming of the robot itself:
    • The behavior is to run, ping, scan, repeat.  But during “scan” it wouldn’t drive the servo full left\right:  Sometimes it would only  got left, never make it right.
    • To solve this, I put a “timer” in the code, that would only execute the main loop if a certain amount of time in ms had passed (30ms to be exact, which makes it run around 30fps in game terms).  This seemed to make it behave exactly how I wanted.
    • I thought I needed to tell the motors to run on every loop:  It turns out they’re a state machine:  once you tell them to run, they keep running until you tell them otherwise.  Knowing this helped me clean up the code.
  • There doesn’t seem to be any official documentation I could find to the motorshield library, I had to crack open this header file to deduce what it could do:  AFMotor.h

Picture time!  Click to enlarge:

 

Ponar

While at the last Maker Faire, I picked up a 4wd robot kit.

My thought is to hook an ultrasonic sensor to it, to do some simple obstacle avoidance.  Since I’ve never worked with any of these components before (servo’s, ultrasonic sensors, motor-drivers, etc), I want to break down each step so I can really grasp how this stuff works.

I was looking at my bucket of parts and it dawned on me:  I have a servo, I have a Ping))) sensor, a spare Arduino Uno, a bunch of Erector Set parts, and knowledge of Processing programming:  I could (should!) make a simple sonar system.  So the “Ponar” was born:  Ping))) + Arduino + Servo + Processing = Ponar.

How it works:

The Arduino program sweeps the servo back and forth over a 90deg arc.  At each degree, the Ping))) sensor returns back a distance reading.  The degrees and distance values are passed over the serial port to the PC, where the Processing application turns them into a ‘traditional looking’ (in my head at least) sonar read-out.

See it in action:

Want to make one too?  Here’s the steps I went through:

Parts List:

Software List:

Hardware setup:

  • Assemble the servo, bracket, ping, and erector set into a pleasing arrangement.
  • Connect the Arduino’s 5v and ground pins to the mini beadboard with the jumpers.
  • Use jumpers to connect the Vin of the Ping))) and the servo to the Arduino powered row on the mini breadboard.
  • Use jumpers to connect the ground of the Ping))) and the servo to the Arduino grounded row on the mini breadboard.
  • Use a jumper to connect the signal line of the Ping))) to the Arduino’s digital pin 7.
  • Use a jumper to connect the signal line of the servo to the Arduino’s digital pin 9.
  • Connect the Arduino to the PC with the usb cable.
  • Upload the Arduino sketch to the Arduino:  It should start sweeping left and right.
  • Run the Processing sketch:  It should sample the serial stream being passed from the Arduino, and display the sonar view on-screen.

For a couple days work, it was really informative, and actually pretty fun.

Ponar sees beer