Hello, Im working on a project, A robotic mower and I need help finding out how many 'Distance Measuring sensors' I will need on the bot and were they need to be placed. I have one on the front and one on the back, Should I have some on the side or not? (One on the front will be connected to the servo)
What it looks like at the moment.
The beam angle on most of the these sensors is around 15 degrees, that's fairly narrow up close for something as large as a typical mower blade.
You may benefit from having more sensors, but not necessarily on the sides of the mower, you'll need them in the direction the mower is travelling unless you want to detect "approaching" objects.
If your goal is detect objects you're approaching however, then you would benefit from having multiple sensors aligned perpendicular to the direction your mower can travel.. possibly 3 across a 30 inch span with one on each end and one in the middle. Don't fire them all at once and allow at least 50 ms between pings to minimize interference.
I would test this with a pole fixed into the ground and the mower approaching it directly at different offsets from one of the edges (think of the mower travelling towards a sappling, or a sprinkler head or garden light for example.)
Slimicus:
The beam angle on most of the these sensors is around 15 degrees, that's fairly narrow up close for something as large as a typical mower blade.You may benefit from having more sensors, but not necessarily on the sides of the mower, you'll need them in the direction the mower is travelling unless you want to detect "approaching" objects.
If your goal is detect objects you're approaching however, then you would benefit from having multiple sensors aligned perpendicular to the direction your mower can travel.. possibly 3 across a 30 inch span with one on each end and one in the middle. Don't fire them all at once and allow at least 50 ms between pings to minimize interference.
I would test this with a pole fixed into the ground and the mower approaching it directly at different offsets from one of the edges (think of the mower travelling towards a sappling, or a sprinkler head or garden light for example.)
Thanks, this really helped me. I think I will put more sensors on because I want it to avoid objects.
blinky126:
Thanks, this really helped me. I think I will put more sensors on because I want it to avoid objects.
Look into using the NewPing library - it has an example (and the necessary functions) of how to use multiple ultrasonic sensors without needing to use delay() statements. Basically, it's the "blink-without-delay" and "doing-multiple-things-at-once" examples rolled into a single system. By doing this, you won't slow down the processing of the rest of your system (as blocking statements like delay() will cause) - and you can achieve the fastest update rate for your sensors.
Note that while ultrasonic sensors will work for many things, they may not work for everything you are trying to detect. They work best on hard and smooth reflective surfaces perpendicular to the sensor; soft surfaces, rough surfaces, and surfaces at an angle to the sensor can all present a challenge, or be impossible to detect with such a sensor. You may need to add other sensors as well (such as some Sharp IR sensors, a LIDAR sensor of some sort, or maybe even a machine-vision system). You would then perform a "sensor fusion" of those readings to determine what the best course of action to take would be.
It would be best to also add as a last resort some kind of physical bump sensor system to your robot; if all else fails, physical contact will occur and perhaps "save the day". This kind of sensor has been implemented on mobile robots for decades; so don't re-invent the wheel, instead do your research on how this was done in the past.
For a fairly great example, check out the old SRI Shakey robot:
Seriously - as an aside - for it's time and even today it was a pretty awesome robot. It combined a form of artificial intelligence and sensor fusion from not only bump sensors, but from a vision system and a primitive "lidar" sensor - to allow it to perform some amazing feats, such as path finding and planning. In fact, the A* algorithm came from research using Shakey. You could command it (using a computer terminal) using natural language to perform tasks - and it could reason and plan out the steps needed to accomplish the task, even if the task had "problems" (like, if you told the robot to "move on to the square platform" - and the platform had no method to get on to it, the robot could reason to push a ramp up next to it to roll on top.
Finally - before you go any further - implement a hard safety shutdown switch onto your robot. If it gets out of hand, you want a means to stop it - fast. Don't rely on a microcontroller, or any other indirect method. You want this thing basically wired as directly as possible to the battery, in a fail-safe mode. If you have the battery hooked up through a relay, and the relay has to be energized by the battery and your safety switch - so that when you hit the switch, the relay de-energizes and the battery is disconnected from the system, shutting everything down (and there isn't an easy way to re-energize the relay - in fact, it should not be possible to turn on the robot again without some bit of manipulation) - that would be ok. Safety first - especially when it comes to a mower robot!
Keep in mind that the sensors send 8 40khz pulses out, and the pulses are unassociated with the response received onboard the sensor when it's processed. Typically these sensors will return with 40ms or so for object a couple meters out, however, if you trigger multiple sensors at once, you can occasionally pick up reflections from unintended sources on the wrong sensors.
In a wide open space that probable won't be an issue, but if for example you're turning neat a fence, this could really cause confusion in your logic processing when both the front and rear sensors trigger erroneous readings at the wrong distance at the same time due to reflection interference.
With the speed of a typical mower, you're fine scanning every 50ms, and if you have 6 sensors, you'll still be reading all of them out to 5 feet or so reliably (with the HC-SR04's) in around 300ms (depending on how long your processing code takes of course.)
And lastly check the NewPing thread if you plan on using it, there's a problem with these sensors that NewPing masks but is unable to resolve, I've posted more details there. It could lead to confusion as you develop your code if you intent to receive high rate accurate measuring with these sensors.. in your case, pinging each sensor in turn with a min period of 50ms would almost certainly alleviate the issue (since the "no obstruction" delay is 200ms, but if for example you have one of the really bad sensors that fails to read faster than 1.3 seconds, AND you're pinging them all at once, you won't be able to get an obstruction measurement faster than 1.250 seconds at a time... that's long enough to take out a lawn Gnome.
cr0sh has some excellent points too about using physical bump sensors and kill switches.
Thanks all for the help, This helping me out alot, lets hope I dont wipe out to many objects, haha.
I do have a hard-wired power off button because I know there will be alot of bugs and problems in the first few runs, I also have a app I made for my phone that connects to the bot that will also switch it off.