What can I do if I run on node.js?

The code I support is written for Arduino using the C/C++ code that comes with the Arduino IDE.

The device is compatible (depending on V1 solder jumper) with 3.3V or 5V logic, however a 5V supply is needed for the sensors.

In theory therefore any controller running on 3.3V and 5V will work, if the software is written for it. 

The code is open source, feel free to translate it to any language or platform you like, or write your own from scratch.

Or run a slave arduino (or attiny) to drive the device using my code, and have your node.js system talk to it. There was a similar product on Tindie with the microcontroller built in. Seems to be gone now.

see https://theotherandygrove.com/octasonic/ for info on that

Did you consider using US-100 ultrasonic sensors?  

They are superior to HC-SR04 (or other trigger/echo sensors) because they do the time of flight calculations on board (plus have temperature compensation, which is a smaller increase in accuracy).  eg. for a 697mm measurement I found trigger/echo measurements would overestimate by 25mm and would vary by 6mm.  US-100 gave a measurement that exactly matched my tape measure and returned the same value every time (to mm accuracy).

Using this might make it easier for you to move your robot parallel to a wall using only a single device with a tuned PID - the variability in the results you get from HC-SR04 would likely make that impossible.

See https://github.com/stoduk/PingSerial/ if you want more details.

I'm not familiar with those, however a quick google suggests that they are very similar albeit a bit more accurate and temperature compensated.

https://arduibots.wordpress.com/2013/10/14/comparison-of-ultrasonic-sensors-us-100-and-hc-sr04/

They *don't* seem to do time of flight calculations any different from the HC-SR04, (the controller has to measure the returned pulse length in the same manner) so can you verify where you saw that?

I would think they could be drop-in replacements for the HC-SR04.

The tuned-pid one-sensor approach only works if your robot is travelling forwards so it can tell if it is getting closer as it goes. I want the ability to line up to the wall while not rolling forwards. To do that I need two sensors on each side, spaced wide apart. For this it's more important that they give the same value as each other for the same distance than they give a number that matches a ruler.

Also I'm a cheapskate :-)

https://arduibots.wordpress.com/2014/10/12/us-100-ultrasonic-sensor-in-serial-mode/

Oh, that is interesting. I think my specific hardware solution is only going to work with the trig-echo mode, which matches the SR04. Unless it were possible to send the 9600 baud request messages by flapping the pin on the expander to fake 9600 baud. That's complicated and a lot of work for the Arduino which probably has other things to think about, but a fascinating idea.

HC-SR04 and US101 do the same thing - send pulse, wait for echo, calculate distance based on how long the echo takes to come back.  The difference is in what calculates the distance (sensor vs. microcontroller) and how the communication works (timing magic vs. TTL serial).

With the HC-SR04 your MC sends a pulse (with some timing magic) then wait for the echo pin to go high, and from the elapsed time the MC calculates the distance.  With the US-100 your MC sends a TTL serial message to trigger the measurement, and then gets a TTL serial response with the distance.

The important bit here is where the elapsed time measurement is being done.  With US-100 it is done on the sensor itself, so is as accurate as we can get (plus we get temperature compensation too, which affects accuracy).  With HC-SR04 and similar you rely on the MC to measure the difference - and this potential latency in the MC noticing the echo pulse can cause both inaccuracy  (value calculated is greater than it actually is) and imprecision (measuring a fixed distance doesn't give a fixed result, due to the unpredictable latency).

US-100 are cheap enough that, for me, their improved accuracy and precision is well worth it.  Currently US-100  cost £2.22/sensor vs. £0.99 for HC-SR04, so the difference in absolute terms is small.

I'm not sure I understand how multiple sensors help you line up to a wall better than a single (accurate and precise) sensor.  Two sensors are needed to let you know if you are parallel certainly, but if you aren't parallel and want to get there then you need to move - at which point either one or two sensor setups should do the job.  I'd bet improving your accuracy/precision would help a lot with that, hint hint :)

Anyway, your design certainly looks good, just suggesting some alternatives.  I imagine you could do it with a handful of 555 ICs but I haven't touched them for two decades, so I'm not the one to tell you how to do that.

my initial google found a reference to the trig-echo mode on the SR-100. It was later I spotted the TTL/Serial mode. I agree that doing the time calculations in the module is preferred, as it saves the controller doing it and avoids timing conflicts on the controller.  I think the Ping))) does things on-board too, but they are way expensive. So I do like that, but how would one address the issue of talking to lots of them? Those 74HC4051 analog MUX chips mentioned by the other guys would work, I think.

Take a look at my sonari2c library. I think I'm taking a different approach from the other libs out there in that I am using short hardware interrupt routines to record the timestamps of the start and end points of the echo pulse in microseconds. Parked next to a wall I get *very* stable results. As long as you are careful with your code, (e.g. don't write any other interrupt routines that run long) you should be able to maintain this accuracy. 

My thinking is that having sensors at the end of each side of the bot will help in multiple ways while negotiating tight spaces. 

Specifically I'm thinking about the Robogames Firefighting Challenge. 

http://robogames.net/rules/fire-fighting.php

With that, knowing when my nose is next to an opening and my rear isn't will be useful, as well as other things like my front left is up against a wall but my front right isn't etc. Previous attempt had one front sensor and one on each side, and there really wasn't enough data to navigate intelligently.

You could do the same with two 74HC4051 analog MUX to multiplex the 2 signals to 8 ultrasonic modules.  Just run 3 GPIO to select the address and no need for I2C.

would you choose the analog mux over a 74HC138/74HC151 pair because you can use two of the same 74HC4051 instead of having two different parts, or is there more to it?

Using the same part. Also easier for someone to understand how it is going to work. 

I would just use a CPLD myself, but then again I have already reverse engineered the modules and integrated it with ARM chip.

BTW 74HC138 won't work because the trigger signal is active high and its output is active low.  74HC238 on the other hand is the right part for this application

I don't have to worry about details like that with an analog MUX.

What CPLD would you recommend as a start.  I'm still stuck in the GAL16V8 era :-)

Any of the smallest CPLD would do. They are around $1 range with 32-36 macrocells.  e.g. XC9536XL, EPM3032, LC4032.

Can't use the 74HC138?  Hmm. Is the module not edge-triggered? Can't you just pull the trigger line low then back high to initiate a ping, while the inactive trigger lines all stay high?  or does that make them ping continuously or something equally bad?

But you're right, I always forget the active low outputs of the '138 :-)

I had to look this up as I confess I'm not familiar with those. Looked up the datasheet and that would use 4 more GPIO pins on my robot build. 3 for addressing and one to send the pulse. I'm not counting the I2C pins as I'm already using them to talk to the display and to pass packet data instructions to the embedded atmega328 in the motor driver card. I'm a self confessed pin-miser with an I2C fetish and I don't know yet what I might want to add to those pins. The easiest way to put an LCD on an and Arduino based bot these days is a 1602 with a pre-installed I2C backpack, so they are very often already active in I2C use.

Using those chips would save a little cash - maybe 60c on parts per unit, and they do come in a narrower package than the PCF8574. Also running the echoes through one would protect from any rogue inputs from the sensors or floating inputs on open ports, though that isn't a problem I've seen yet (open ports on the 4078 need to be grounded.)

The trigger for the HC-SR04 is the falling edge of the signal on the trigger line, and the echo pulse is positive, with a duration equal to the round trip of the ultrasound. The trigger signal is not time critical, so I2C is no disadvantage. For accurate timing the echo signal somehow needs to come into a pin with an interrupt set on the rising and falling edges.

Another aspect of my design that I like is that I can daisy-chain another of these on the same interrupt pin and add another 7 units. I'm planning to add 4 - one on each corner where the robot has blind spots. Currently if it is at 45 degrees to a wall it can't see it.

Thanks for this comment, now I have a whole new breed of chips to learn about! 

CPLDs are probably beyond me at this point :-)

Up till the I2C patent expired (years ago), Philips (NXP) was still suing anyone and everyone for money.  So not something I would like to support if I have better alternatives based on principle.

http://www.eetimes.com/document.asp?doc_id=1182191

>Philips Corp. today announced it has filed patent infringement suits against eight more companies accused of violating its technology rights in I2C bus interconnects on semiconductors. The latest round of suits follows similar cases filed against six U.S. chip makers one year ago.

Of course, you know more about the constrains and goals of your own project than we do :-) 

I think this kind of discussion is the sport of hackaday.io - I'm expecting someone to chime in with an NE555 comment, although that may be more hackaday.com-ish

The lawsuit things seems to be against semiconductor manufacturers, and most of the chips I am using are genuine Philips (NXP) chips (though I also used a few  Texas Instruments) chips. This is tiny scale hobby stuff. And that article was from 2001.... Not worried.

It has expired, but I do not agree with their practices. Kind of a sore point for the Open Source thing I think. Thus I said about "not using it based on principle.".

The robot is a work in progress with me learning as I go. It is a step up from the predecessor which had only 3 sensors, one at the front and one on each side near the front. I found with that to follow along a wall you had to move to figure out your angle i.e. "I am getting closer, I need to turn away". This is not very helpful if there is a wall up ahead. So I figured if I had two on each side mounted straight out, I could know not only how far, but at what angle a wall is - without moving. I'd also get an idea of whether my butt is clear of the opening before turning. This works as intended, but showed up the next challenge - blind spots on the corners.

Let me think about your idea - every 45 degrees. Logically that would be one on each side and one on each corner. The sonars can see reliably 15 degrees on either side of center, and dodgily up to 22.5 degrees. see http://www.instructables.com/id/Arduino-based-Distance-Measure-Box/?ALLSTEPS

At a 45 degree spacing you would pretty much be blind-spot free but none of them would be able to see the same wall at the same time, and I'd lose the parallax that allows me to statically adjust relative to flat surfaces.

However, the next step in the plan is to add 4 more sensors at 45 degrees at the corners to cover the blind spots, pretty much like you suggest. I'll just watch for these to have a range lower than the sensors on either side. When that happens I'll rotate out of the blind spot.

The Octosonar echoes can be daisy-chained (they are OR logic gates) so with two of them I can still run 15 sensors on 1 interrupt pin. I breadboarded this out early on.  The challenge is mounting brackets. The more sensors you ping in rotation the longer it takes : 50ms each - 12 would take 0.6s - a long time for a moving robot. That's why the library lets you turn off the ones you care less about, like the ones at the back when moving forwards.

it wouldn't hurt to try :) seems like you still know you're angled to a wall when the side gets closer/ shorter ranges, so it would be possible to counter act that angle like a line follower does. But I'm just assuming here.. 

I want to know the angle to the wall without moving. The firefighter maze is a very confined space. Need the parallax of two sensors. That's why we have two eyes pointing forwards. I think 12 will be enough :-)

Hi, can you please publish a schematic of daisy-chain configuration ? Thanks

I just saw the video of the robot and have one question: why don't you angle the 8 sonar modules on your robot in 45 degrees? Seems like the arrangement of them isn't optimal to show the full capabilities of this project. 

I like the idea of the project itself :) thank you for sharing.