The HC-SR04 sonar modules are available for a mere pittance and, with some coaxing, can do a pretty decent job of helping your robot measure the distance to the nearest wall. But when sellers on eBay are shipping these things in ten-packs, why would you stop at mounting just one or two on your ‘bot? Octosonar is a hardware and Arduino software library that’ll get you up and running with up to eight sonar sensors in short order.
Octosonar uses an I2C multiplexer to send the “start” trigger pulses, and an eight-way OR gate to return the “echo” signal back to the host microcontroller. The software library then sends the I2C command to select and trigger a sonar module, and a couple of interrupt routines watch the “echo” line to figure out the time of flight, and thus the distance.
Having two sonars on each side of a rectangular robot allows it move parallel to a wall in a straightforward fashion: steer toward or away from the wall until they match. Watch the video below for a demo of this very simple setup. (But also note where the robot’s 45-degree blind spot is: bump-bump-bump!)
With three address bits available on the I2C multiplexer, you could add another eight sonars to a project while only demanding one more interrupt pin from your host microcontroller. Heck, at the prices these things go for, why not go for the full 64?!
The comments for this project suggest a couple of alternative ways to go: a different pair of standard multiplexers instead of I2C, a CPLD to handle the logic, or whatever. But if you just want a simple setup, Octosonar has got you covered. If you’d like to dive deep into the HC-SR04 modules, check out this complete reverse engineering and brain transplant or this similar dissection of the modules with great references.
29 thoughts on “Octosonar Is 8X Better Than Monosonar”
Ughh, I hate “8x better” .. “8x as good” is the way to go. We say “100% larger” to mean “twice as large”. And we certainly never say “twice bigger” .. not while sober, at least. Is it so awful to be consistent?
“x better”, “x bigger” etc seems to be a fairly recent (and unfortunate) convention. Stop it … all of you .. stop it this instant
+1. Turning “build” into a noun should be your lifelime limit.
And shame for not having an edit button, like Stack Exchange :-)
Pretty much everyone has fallen victim to “Muphry’s law” a time or two ..
The VL53L0X are cheap now and they are very compact.
Heheh, curiosly HC-SR04 is USD $0.80 http://s.click.aliexpress.com/e/3jMnIUb, and VL53L0X is USD $8.25 http://s.click.aliexpress.com/e/eayBE6y so ultrasonic sensor is “8X Cheaper” than time of flight sensor!
Nope. That links to a HC-SR04 mounting bracket, NOT the HC-SR04 itself.
Wouldn’t an 8 way OR gate also capture echo signals from other modules, thus leading to error?
For example, if another module receives the signal (say the sonar waves hit a wall and bounce into another receiver) before the intended one picks it up…, wouldn’t that cause the program to think the module is closer than what it really is? (or further apart in case the first module doesn’t receives the signal at all)
The modules seem to be powered at all times, so it seems feasible the modules could pick signals from each other, the program has no way of telling if the signal is the correct one, it just reads the first one.
I’m also building a similar robot for a competition and looking to reduce the number of inputs/outputs used. I’m fairly new at this though.
When I saw 8 way pr gate, I mentally substituted 8 to 1 multiplexer, wondering if clarification would emerge.
I see a NOR is used to “sum” all the sonar outputs. Since the processor controls which SONAR is used, the NOR will just pass on the output of the current device.
The chip is an 8 way OR/NOR – it has inverted and non-inverted output pins. I’m using it as an OR gate. CD4078B http://www.ti.com/lit/ds/symlink/cd4078b.pdf
I had the same thought. Any advice on this would be greatly appreciated.
The library polls each sensor in rotation, with a default 50ms spacing to avoid late echoes being heard. Only the active sensor responds to the incoming signal. If you have one of the faulty sensors that locks up and holds the echo pin high forever, it will lock up the whole board. I’m working on a workaround for that, but it is an issue with some poor quality HC-SR04 clones.
I like the general method for extending a larger array of sensors – this could be handy for a broader bit of multiplexing for a lot of projects..
Unfortunately, though, the only thing I could think of with the video was that it lacked an insouciant cat sitting on top, a la Roombas.
Can you compare the front right forward, and the front right side to see if the readings are equal within a range? If so, then there is a wall at that 45° angle. ?
Hmmm… one set of ultrasone sensors can detect a perfectly flat wall when the angle of the sensors is less then 45deg. (angle smaller then 45deg will allow the echo to (completely to partially) bounce back to the sensor, more then 45deg will make the echo almost completely bounce away from the sensors. Think of a snooker ball hitting the sides of the snooker table.
Because this project uses 2 sets of sensors perpendicular to each other the risks of this problem are greatly reduced but not (depending on the surface reflecting of) completely eliminated.
I once had a project to make a model car to drive autonomously across my room. Using only a single set of sensors (this was the 90’s), the intention was to prevent collision with walls. Automatically steer away from the wall, but in the end it resulted in a car that could perfectly hit the walls of my room at a 45deg angle. Although better then a direct hit, I decided that the project was a failure.
These are fun projects, thanks for posting.
PS: this problem can be solved in many ways. Use more sensors… or mount the sensors on a rotating or oscillating platform. The latter looks the coolest.
At a stretch they see about 22 degrees either side of center, so between two sensors at right angles there is a 45 degree blind spot. If you are 45 degrees to a wall, both sensors will see infinite/out of range, and you run right into it. I plan to add more sensors at the corners to detect this condition so I know to rotate out of it.
Two or eight sonars mounted on one side of a robot doesn’t make a difference compared to one sonar. As long as you keep the distance constant between the wall and one sonar device, the robot remains parallel to the wall. Mutli sonar can’t be useful however for a robot to detect moving object coming into collision from any sides. The robot can then issue a sound to signal its position and avoid thecol, ision.
You’re right, of course. One sensor at two different times/places is the same as two at once. Still, I’ve always wanted to make a bot that’s essentially all sensors, just to see how much info is too much and what ways it could be used.
Discriminating between redundant informations is something our brain does continuously. Developping algorithms to perform this in real time on a mobile robot overloaded with sensors of all kind seems a fair technical challenge. Have fun and keep us posted.
You are correct that you can figure out parallel tracking with one sensor while moving, however the objective is for maze following in a confined space. Being able to rotate on the spot in a corner and line up with the wall and know you are straight *before* you roll will be really handy.
“The comments for this project suggest a couple of alternative ways to go: a different pair of standard multiplexers instead of I2C, a CPLD to handle the logic, or whatever.”
Or just use a Parallax Propeller: one cog for each sonar… done :-)
Seriously you’d want to do a thing or two besides listening to the sonars, but I’m sure a cog could easily cope with two sonars: anyway you put it this seems to be the perfect application for the propeller.
I have noted that these send even when they should not. So, you need to mute the MAX232 that powers the speakers (which they do with a transistor when receiving, but it doesn’t work otherwise)
i wonder if you could just spin 1 sensor on top of it to get a 360 view, maybe with a bluetooth module? i mean everything is better if it has bluetooth right? ;-)
Back when the Ping sensor (or scavenged ultrasonics from Polaroid cameras) were state of the art, an ultrasonic ranger cost like $40 and people would mount them on servos. Now a ten-pack of sensors costs less than the servo…
Given the price of an arduino as compared to a PCF8574, why not have I2C slave arduinos that do the measurement for you? On one hand you are offloading the job from the main one, on the other you can program them with whatever I2C addres you want and can fully load the bus.
Or you can get the more advanced US-100 sonars that actually have a microcontroller in them and work with serial port as well and reprogram them to have a different ID. Also better performance and lower supply.
syncing them so they don’t talk to each other would be a fun challenge. There is another board on tindie that takes this approach – a single slave atmega on spi bus. https://www.tindie.com/products/andygrove73/octasonic-8-x-hc-sr04-ultrasonic-breakout-board/
With SPI you can chain as many as you like, but there will be only one master.
With I2C the bus is shared, but each slave can have a different address. Not very difficult (don’t know about the arduino libs about that). If you are brave enough and need it, you can have more than one master.
I build something like this. The problem with this is that with 8 sensors, or even with one sensor and a motor to scan the sensor you have to wait 50ms between “pings” so it takes at least 400 ms to read every sensor. That is almost 1/2 second. If your device is moving at a normal walking speed you need to “look” more often than twice per second. At one meter per second, the robot travels 1/2 meter
The only way around it is to turn off most of the sensors until you can get to at least 10 pings per second. Turning them off makes sense because you really don’t need to run the rear-facing sensors when driving forward.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)