Hi again,

Hate that your robot runs into everything? This will fix that problem. With 8 sonic sensors this looks complicated...but in fact I made this very easy. I try to post projects that help you learn about Arduino and show an 'outside the box' concept. This post will help you understand 595 switching, pro-minis as a programmable sensor, and the grand use of real time led feedback. If you enjoy Arduino as a 'copy and paste and plug-in' you might just skip this.

I like to use pro-minis. They are about $2.50, work as a full blown uno, and installing headers makes them very flexible. Used as a sensor micro you can have it 'do what you want' instead of what a purchased sensor dictates. With I2C using only 2 wires they can be tied together all on one line. So move over MEGA I can have 4 minis running 4 separate lines of code all at the same time, at just $10.00. Here I use a mini to pop the sonic sensors through a 595 and show realtime led distance. Then just share 8bits of data with the mother board. This takes the load off the mother board and makes the her code very simple.

There is a problem with sonic sensors...no visual feedback. You never know if the sensor is just a dead weight or working! I believe who ever came up with 'BLINK' is smarter than Einstine. Just ONE led and a world of information is relayed by the blinking. So a sonic sensor needs realtime feedback. Here I used an array of leds to monitor each sensor. You don't need them, just make the sensors without the leds. But to have the leds on the PCB is helpful.

Step 1: MAKE PCB

make PCB and populate. CAUTION...I made a mistake on the PCB at the 4 pin connections for the sonic sensors to plug into. The ECHO and TRIGGER Vcc and grounds were going to plug into the pcb. There is not enough room for connectors so I just made the PCB with pin-outs. So you can solder a wire connector to the PCB and plug into the actual sonic sensors. As for the leds I put yellow leds at the inside edge and red at the outside. this helps you see at distance if the sensors are correctly measuring.

This is one of the FEW 2side pcb I ever made. I would rather make 2 ea single side and run jumpers. But to get the led display you need at least the top pcb. I separated the layout in the download.

The PCB is for a pro-mini with A4-A5 inside the edge header. Either way just connect A4-A5 to the Master A4-A5. Don't forget the Vcc and Grounds too.

Step 2: MANY MISTAKES

Now for my mistakes... I tried to pop the Triggers all at once (all tied together) and this sorta worked well but some interactions took place. So now all ECHOS go to the micro (8) and the TRIGGERS are set by a 595. Three more pins (3). As for the leds, multiplexing won't work. You need a full ON time for each led. This means each row of 7 leds has to have its own 595. Once you update the 595 the leds stay lit until the next update. Where multiplexing the led only lights for that tenth of a second. This works well in my readers and it needs a dedicated micro. No time for scanning 8 sonic sensors and measuring distances. I tried and got very poor results. Multiplexing the leds will also mean a grid of row + column and that means around 64+ feed throughs in the PCB.

I used only 7 outputs from the 595 because of clutter on the PCB. At a distance you can't tell if there are 7 or 8 leds just their motion. You may be tempted to tie all the leds to a single resistor and this works, but the brightness of the array changes with the amount of leds that are lite. So one resistor per led is best. I just love the 595 but if they just moved the Vcc and 0-out pins or made a 18 pin ic with ALL outputs on the same side... connecting the all eight outputs would be so easy. But then it wouldn't sell for less than 30 cents.

Step 3: MOUNT SENSORS

Glue sonic sensors to coffee lid. the male jack needs to be bent inward on each sensor. This works better if you bend one pin at a time. I used 2 side foam tape just so the vibration is less. My sensors are too close and they need a 1/4 inch space to match the PCB better. I have used sonic sensors before and sometimes one fails to measure accurately and you need to keep this in mind. So don't GLUE them all in permanently.

It also helps to run a quick distance test on each one before you use them. I get about one sensor with a poor reading in a batch of 20. Not bad for the price I paid.

Step 4: HARD WIRE

I thought there would be room for jacks and plugs from the PC to the

sonic pins but I ran out of room. So I hard wired the pcb end and just made echo and trigger wires with female jacks (8ea). I tied the 8ea Vcc and 8ea grounds of the sensors together so this made only 2 connections to the PCB for them.

With 8 sensors and 8 595s a uno or pro-mini CAN NOT power this. There must be a 5v regulated source as part of this project. My robot has a simple 7805 @ 1amp from the batteries. This ties to all the 5v Vcc for all devices. the 7805 drops about a volt so you need at least 6.5 volts to feed it. That is 2 lithium batteries at 3.3v. My robot has old nicads from used drill packs and 8 nicads run the typical China geared 12v motor in the $20 tank type chassis.

Step 5: DOWNLOAD SONIC SKETCH

Download the sketch and install. There are many ways to talk to

another uno but I like I2c. the confusion is addressing and master/ slave. As with most sensors (think of the 2nd mini as a sensor) you address the sensor and ask for x amount of bytes. same thing here. In the 2nd mini you set aside x amount of bytes you want to send. The confusion is names don't matter. It only helps YOU remember if you share the names. So in the sketch I send the 8 sonic distance measurements in cm as sendR1,sendR2,sendR3,sendR4, sendL1,sendL2,sendL3,sendL4. The master just gets 8 bytes if data and you can call those bytes anything you want. I read them as gotR1,gotR2,got..... The sent order of bytes is the same. So byte A,B,C..... don't think by changing the name will give you different data. And the other catch, you can only receive data that is told to be sent. So if you want other data you must change BOTH master and slave.

eight_ping_led_595_latch.ino
Download

Step 6: COMMUNICATION

You can skip this if you know how to set up 2 Uno's to talk to each other. I do have some tidbits of info at the end. To make it easy I will call the uno in the robot base M1 and the sonic sensor as S2. Connect Vcc,ground,A4,A5 to each other.

In the sketch for the S2 it starts with #include<Wire.h>

Then create the 8 bytes to send. byte R1, byte R2, byte L1 etc. Uno is a 8bit micro so they send 1byte at a time using 'byte' instead of 'int' is correct.

In the 'setup()' add 'Wire.begin(address)' this tells I2c which device this is. The address is usually any number you like between 4 - 200. the size of one byte. Here I used the number 10. So to talk to this sensor S2 the master must call Wire.requestFrom(10,8). This is address 10 and the 8 is how many bytes wanted. Also in the 'setup()' add Wire.onRequest(isr anyName). When the M1 calls the request the S2 sensor reacts with the interrupt. This just calls the function anyName. So this anyName function needs to be created. Look at the sketch and see the function 'sendThis()' This is where the bytes actually get sent to the M1. The bytes alone go and NOT the names and in the order sent. This is where the size and amount of data to send starts from. In this easy format of bytes the send and receive should match. Here 8 bytes sent and 8 bytes received. One note here is calling a function requires the (). Like delay(), millis(), Serial.print(). When using an ISR (interrupt service routine) calling the function drops the (). So Wire.onRequest(sendThis) not Wire.onRequest(sendThis()).

The confusion I had was the master/slave thing. At first I thought the master was ALLWAYS the master. But within the sketch you can switch master/slave to request from other micros or send to other micros. As long as you followed the basic format outlined above. Remember... you ONLY share data that has been assigned.

Two off the wall tid bits. The isr interrupt only interrupts between sketch lines. If you are locked in a 'while or for' loop, nothing happens till the loop exits. NO big deal as this may be a few microseconds and the data is old.

The other problem is, 'inside' a micro there is 100% error free calculation. Any 'outside' (wires) communication is subject to errors. There are many ways to check that the data delivered is error free and matches the source. The easiest way is with checksum. Just add the totals of the sending bytes (actual values) and send the totals and on the receiving end add the totals and see if they match. If they match ok or toss that data set if they don't. Of course this involves sending an integer value and not bytes. So you just split the integer into the HI byte and LO byte and send as separate bytes. Then put together at the receiver.

EASY:

int x = 5696; (any valid int value, max is 65k or 32k negative)

byte hi = x >>8; (22)

byte lo = x; (64)

send the bytes and combine at other end....

byte hi = Wire.read();

byte lo = Wire.read();

int newx = (hi <<8) + lo; (5696)

Step 7: CLOSING

To close, this sonic sensor gives the mother board raw distance data in real time. This frees up the micro and makes the sketch much less complicated. The micro can now make a good decision to slow, turn, stop, or reverse based on good data instead of random guesses. See my other post about bluetooth IDE to upload sketches without wires and having to connect your robot all the time for just a quick change in your sketch. Thanks for viewing this. oldmaninsc.